I built a native Apple app for 4 platforms in one afternoon with my AI workflow

Developer and author of ClearTime built native Apple apps for Mac, iPhone, Apple Watch, and Apple TV in about five hours, from a 4:05 PM first commit to working TestFlight builds on all four platforms, using an AI-assisted workflow. The author, who has ADHD and recently developed SVT requiring a week in the ICU and a heart ablation, built the visual timer app to manage time blindness without ADHD medication. ClearTime shows a solid disc of color that shrinks as time passes, floating over work on Mac and staying visible via widgets, Live Activities, and the Dynamic Island on iPhone.

I’ve never written a build post like this, but the numbers still sound made up when I say them out loud: about five hours from the first commit to working TestFlight builds on Mac, iPhone, Apple Watch, and Apple TV. Pretty funny that this writeup took more of my time than the actual design and build.w The part I don’t want to skip is why I built it. Why now? I have ADHD, and a clock only tells me what time it is. It doesn’t help me feel how much time is left. Ten minutes and twenty minutes can feel exactly the same until the moment I realize I’m late. I’d seen physical visual timers on Amazon and liked the basic idea, but I wanted one that could follow me from screen to screen. So to handle this I'd usually just be early for as many things as I could to overcompensate. That worked for almost 30 years until about a month ago when my whole life changed overnight. I was resting in the afternoon, woke up, and my heart started racing. I thought maybe it's just anxiety or something. This wouldn't stop and it was getting worse in a matter of minutes. It got so intense sitting in my living room chair that I could barely talk to the operator when I called 911. They took me to the hospital and discovered I developed SVT, a heart rhythm that made my heart suddenly take off. Most people experience that in their teens; I seemed to develop it at 48. My heartbeat reached 220 beats per minute and stayed there. I spent a week in the ICU. I’ll never forget the way the doctors and nurses looked at me when it wouldn’t stop. They were stunned that my heart had been beating that fast for that long. Medication would bring it down, but it kept taking off again. I ended up on a continuous IV until I could have an ablation, a procedure that “burned out” the tiny areas of my heart that were helping trigger the rhythm. Recovery has been slow. I've now changed many things in my life to live healthier and eliminate anything that could make my heart run away. That also means that until all the testing is complete, and my doctors are confident it’s safe, I’m not taking my ADHD medication. We need to be sure it won’t send my heart racing again. I KNOW, it's like letting the dog loose in a field. My mind is all over the place, and it's 20 times harder for me to concentrate on specific tasks, albeit the small, boring ones. So I’m recovering from a heart procedure while also relearning how to get through the day without the ADHD medication I relied on. Neither the ADHD nor the time blindness went anywhere. We're in this together like hostages lol So that's how we get to now, creating an application to help me with my time blindness. You see, a clock gives me another number to process and doesn't really register with me. A visual timer gives me something I can recognize immediately. I needed that on the devices already around me throughout the day. I decided to build a visual timer with a solid disc of color that shrinks as time passes. A full disc means I have the whole block. A thin sliver means it’s time to wrap it up. I don’t have to do math or hunt for a tiny countdown in a corner. I can glance at it and know. I call it ClearTime. I call it ClearTime. It’s a tool that helps me see time when my brain won’t hold onto it, especially now that I need more structure and patience than usual. I’d wanted to make something like it for a while. After the ICU, I stopped putting it off. What I built ClearTime works differently on each screen. On Mac, the timer can float over whatever I’m working on. On iPhone, it stays visible through widgets, Live Activities, and the Dynamic Island. On Apple Watch, it’s always a glance away. On Apple TV, it becomes a shared timer that can fill the room. At 4:05 PM, I made the first commit. About five hours later, ClearTime was running in TestFlight on all four of those platforms. These weren’t four mockups or a web app wrapped four times. They were four native Apple apps, built with Swift and SwiftUI. My hands-on time was about 45 minutes, and I’m also brand new to app development. I know how that sounds, so here’s what actually happened, including the receipts. No, one prompt didn’t build this I didn’t type “make me a timer app” and go make coffee. I split the work so each tool had a clear job: 1. ChatGPT helped me pressure-test the idea. 2. Claude Design worked out the interface and created the handoff files. 3. Claude Code built the native apps. 4. TestFlight told me what was actually true. 5. Claude Code turned the finished product into its own showreel.. That was the basic outline. The details are where the time savings came from. 1. I worked through the idea in ChatGPT Before I opened Xcode, I used ChatGPT to work through the product: - What does a visual timer need to do for ADHD and time blindness? - What does a physical dial already do well? - What can software add without making the timer more complicated? - What should this product refuse to become? That last question kept the project small. ClearTime isn’t trying to become a task manager, calendar, habit tracker, or productivity empire. Its job is to make the passage of time easier for me to see on whatever device I’m using. ChatGPT helped me work through those boundaries before I had code pulling the product in one direction or another. I’ve tried doing this kind of planning with other models. Right now, ChatGPT Sol 5.6 at Extra High has been the best brainstorming partner for me. I can pressure-test an idea before I get attached to the implementation. 2. Claude Design worked out the product before coding started Next I moved into Claude Design. I had a fairly specific picture of ClearTime in my head, but most of it was still just that: in my head. I needed to get those decisions into files that Claude Code could follow without stopping every few minutes to ask what I meant. We started with the logo as part of the product, not as something to paste onto it afterward. We explored several versions of the C before choosing the Cut C: one circular shape with an 80-degree opening and a smaller circle cut from its center. That same mark became the hub of the timer, where its opening rotates to point toward the remaining time. We paired it with a Manrope wordmark, worked through horizontal and stacked lockups, and made light, dark, monochrome, and tinted icon variants. The final app icon is a Tide teal tile with the cream C. By the end, the logo wasn’t just a brand asset. It was part of the interface on every platform, from the menu bar and Watch complications to the dial itself. That mark gave us the starting point for the timer itself. Claude Design helped me define the round body, cream face, shrinking field of color, counter-clockwise numbers, and the C-shaped hub that points toward the remaining time. We chose Tide teal as the main color, then worked through alternate colors and a few playful faces. Including making them accessible for color blindness. We also spent a surprising amount of time deciding what the dial should never do. It shouldn’t use gradients. It shouldn’t become visually busy. Nothing on the screen should compete with the remaining-time shape. Those decisions sound small, but writing them down meant I didn’t have to keep making the same judgment later. Then we worked through how that object should behave on each platform. The Mac version needed to float over my real work and shrink into the menu bar. The iPhone version needed to remain useful after I closed the app, which meant thinking through widgets, Live Activities, and the Dynamic Island. The Watch needed to be readable at a glance and feel natural with the Digital Crown. The TV version had to work from across a room. The platforms share the same dial, colors, and basic interactions, but the reference designs were made separately. I didn’t want four copies of the same screen at different sizes. This was HUGELY beneficial for me to see what it would look like across all devices before we built anything. By the time we were done, Claude Design had produced much more than a few mockups: - A detailed design brief covering the dial, interactions, states, accessibility, and each platform - Brand assets, the app-icon direction, typography, color tokens, sizing, spacing, and motion rules - Reference boards for the Mac app and floating timer, iPhone, widgets, Dynamic Island, Watch, Apple TV, and the landing page - The dial geometry as code, including test vectors and “golden” reference files so every platform could draw the same object - A build guide that told the coding agent which source was authoritative whenever two documents disagreed The build guide solved a boring but real problem: what happens when two files disagree? If a screen didn’t match its reference board, the board was right. If one platform drew the dial differently, the shared geometry and test vectors were right. Claude Code had an answer it could check instead of making a new design decision on the fly. The original technical handoff proposed a different cross-platform stack - Tauri for the desktop apps and Expo for mobile. We later replaced it with native Swift and SwiftUI, but the design work still held up. The dial, colors, states, reference boards, and platform behaviors moved directly into the native build because they weren’t tied to a particular framework. This is where Claude Design saved me the most time. Claude Code didn’t have to invent the product while it built the product. It could open the Watch reference, check the dial geometry, find the correct color token, and keep going. I still made the taste calls, but I made them once, before Claude Code opened the project. 3. Claude Code built the product For implementation, I used Claude Code with Claude Opus 5.5 , High effort, and Bypass permissions . The original technical handoff called for Tauri on desktop and Expo on mobile. I had been wanting to use those for a long time and thought this would be a good reason. Before Claude Code started building, I asked whether that was overkill. I felt in my gut it might be. Claude explained why starting with native Swift and SwiftUI would be simpler for this first version and suggested we try it that way before committing to two cross-platform frameworks. The answer was basically: let’s do it native first and see how that goes. I agreed, and the entire build changed direction before the first app target was created. The stack was intentionally boring: - Native Swift + SwiftUI - One Xcode workspace - Seven targets across macOS, iOS, watchOS, tvOS, widgets, Watch widgets, and TV Top Shelf - One shared package for the timer engine, dial geometry, color math, UI, and tests I also connected Xcode’s MCP bridge, so Claude Code could work with the actual project instead of guessing from snippets pasted into a chat. Then I gave it a simple working agreement. The rules I gave Claude Code I told the agent to handle routine implementation decisions and keep moving: - Solve implementation problems on your own. - Decide the small stuff. - Document meaningful changes in the decision log. - Run the tests. - Merge your own pull requests after CI passes. - Don’t stop to narrate every dead end. It was supposed to interrupt me for only two reasons : 1. A decision would change the product, the stack, or something we planned to claim publicly. 2. A build was ready for me to test on real hardware. If signing broke, it should fix it. If an entitlement was miswired, it should fix it. If the dial felt wrong on my wrist, that was a reason to bring me the build. “Keep moving” sounds obvious until your supposedly autonomous agent asks permission every 90 seconds. “Bypass permissions” made that agreement practical because I’d already bounded the work to this repo, this product, and this stack. I use it once in a while, but only when I’m clear about where the agent’s room to operate ends. 4. I used TestFlight early The design boards looked right and the simulators ran, but I needed to know whether the timer worked on the devices where I’d actually use it. I treated a TestFlight build as part of the first implementation, not something to worry about near launch. That meant building the unglamorous parts too: - App Store Connect setup - Signing and entitlements - Repeatable upload scripts - Internal TestFlight distribution - Real-device feedback on iPhone, Watch, Mac, and TV I wasn’t waiting for launch polish. I wanted the shortest path to seeing the timer in my pocket, on my desk, across the room, and on my wrist. The first time I looked down and saw the disc shrinking on my Watch was the first time it felt like a real product. I showed my youngest kid, and she was freaking out right along with me that I made this so quickly. Not gonna lie, it was a pain in the ass setting up the App Store Connect, Team, and getting it all working BUT Claude Code did a lot of the lifting here and gave me spot on directions of what i needed to do where it needed my help. 5. Claude Code made the showreel I wanted to show ClearTime moving across all four platforms, not just place four screenshots side by side. I got the inspiration and the basic prompt structure from this post by Andras https://x.com/heyandras/status/2103463340567646661?s=20 and this one by Stephan Livera https://x.com/stephanlivera/status/2103315922098470926?s=20 . Then I gave Claude Code this prompt: make a dynamic 15-second motion graphics video that shows what an incredible motion designer you are, like it's your showreel for a résumé and it is based on the new application we have made called ClearTime. It works on MacOS, iOS, watchOS, and tvOS. That prompt was intentionally broad, but Claude Code wasn’t starting from a blank page. It had the working apps, the shared dial package, the platform designs, the brand rules, and the approved copy sitting in the repo i targeted it at. What it made wasn’t a stitched-together screen recording. Claude Code built a small, dependency-free Swift renderer that draws every frame using the app’s actual dial and typography. It synthesized the music and sound design in code, added adaptive motion blur, and used AVFoundation to export a 15-second, 1920 × 1080 film at 60 frames per second. The reel follows one timer from Mac to iPhone to Apple Watch to Apple TV, brings all four screens together, and ends with the empty dial becoming the app icon. The visual transitions aren’t disguising four unrelated mockups. They’re showing the same product and the same running timer moving through the Apple ecosystem. This is another capability I didn’t have before this project. I didn’t learn motion-design software or assemble a production pipeline by hand. I described the standard I wanted, and Claude Code used the finished product itself as the raw material. The receipts By the end of the night, the repo had: - 48 commits - 16 merged pull requests - 52 tracked Swift files - 6,216 lines of Swift - Around 80 package tests - CI building all four apps - TestFlight builds for Mac, iPhone + Watch, and Apple TV What I actually did AI wrote most of the code. I decided what should exist, defined how it should feel, set the boundaries for the agent, tested the builds, and kept the public claims honest. This was very difficult for me to finally come to this acceptance like DHH exclaimed https://x.com/scottstts/status/2103401938058723765?s=20 earlier this week. I don’t review every line of code. I’m new to app development. I review the product feel, the proof, and the release path. I also need to know which decisions I can hand off and which ones need me. That’s the part of this process I’m learning fastest. The workflow I’m going to keep using I’m going to keep making some of the ADHD tools I’ve wanted for myself. I also have a few ideas related to my government and nonprofit work that I want to try this way. So here's the process that worked for me. Your mileage may vary: 1. Start in ChatGPT and pressure-test the idea before spending time on it. 2. Move into Claude Design and make the visual decisions concrete enough to hand off. 3. Give Claude Code a strong model, a bounded lane, and clear reasons to stop and ask me. 4. Get the result into TestFlight as soon as possible and use it on real hardware. 5. Once the product is real, let Claude Code use its source and design rules to make the showreel. What's for sure is that Claude Code can type Swift much faster than I can. What made this project move was the preparation. By the time coding started, the agent had product boundaries, platform-specific references, shared dial geometry, and rules for when it needed me. It spent less time guessing, and I spent less time answering avoidable questions. That’s the part of the process I plan to repeat. 24 hours ago, ClearTime was a tool I kept wishing existed. By the end of the night, it was on my wrist. I’m still kind of stunned by that. I hope this helps other developers, designers, and product managers who keep trying to build with AI Just do the thing and find your flow that you feel comfortable repeating. If you want to check out the app on your various devices then feel free to sign up for the TestFlight at . If you do, let me know what you think, any issues and any ideas to make it better. Cheers everybody 🍹 P.S. I'm still waiting on approval from Apple to make my TestFlight public for all devices. You can checkout the website in the meantim https://cleartimeapp.com e or reply with ⏱️ or your favorite emoji and I'll let you know when it's ready to test PSS. It literally took longer to write this up then to make the whole thing lo l