Clear HIIT: The Path to Building My First App (and the Two Problems That Stood in My Way)

George Gaskin — Fri, 17 Jul 2026 09:20:28 +0000

Original Article in Linkedin : https://www.linkedin.com/pulse/clear-hiit-path-building-my-first-app-two-problems-stood-gaskin-mbsoe

This article tells the story of my first published app, from the first line of code to the App Store submission: Clear HIIT.

For those who haven't come across it, Clear HIIT is an interval training timer for iOS. Four session types — Standard, Run, Circuit, and Spin — built around two simple ideas: you should be able to prop the phone up some distance away and still read what it's telling you at a glance, and you should be able to lock it, put it in your pocket, and trust that it will keep time for you regardless. No subscription. No fuss. Just a timer that does its job properly.

That last sentence — "keep time for you" — turned out to be one of the two hardest technical problems I solved on this project. The other one wasn't technical at all. Let me explain.

The Impulse to Build
I built it because I couldn't find an interval timer I actually liked. Every one I tried on the App Store was either cluttered, ad-heavy, or stopped working properly the moment the screen locked — which, as it turns out, was about to become the exact problem I'd spend the most time solving myself.

Why Expo Go
I've spent thirty-odd years in telecoms, mostly in C# and .NET. (but also C, Python and PHP - if you've been around as long as me - you will have probably picked up the same or similar set of languages). More recently, client work has been written in Angular and, lately, React. None of that is iOS development. So when I decided to build my own app rather than freelance on someone else's, I went looking for the shortest honest path from "developer who knows React" to "developer who has shipped something on the App Store."

That path was Expo. I already knew React reasonably well from adjacent work and some front-end freelancing, and React Native is, by association, a much smaller leap than starting from Swift with no prior exposure to Apple's ecosystem. Expo Go let me get a working prototype on my own phone within an evening, which for a solo indie developer with limited time is not a small thing.

The side benefit — and I say this cautiously, because I don't want to overstate where the project actually is today — is that React Native's whole premise is "write once, run on more than one platform." Clear HIIT is an iOS app at the moment, full stop. But the architecture underneath it doesn't lock me into iOS the way a pure SwiftUI build would have. If and when I decide an Android release is worth the effort, the foundation is already there rather than being a rewrite. That optionality was worth a great deal to me going in, even if I haven't cashed it in yet.

The Confession: Keeping Time When Nobody's Watching
Here's the bit that genuinely had me worried I'd picked an unbuildable feature — because of the non-native framework I'd chosen.

A HIIT timer that only works while the screen is on and the app is in the foreground is, frankly, a toy. Nobody doing a spin session or a treadmill interval run is going to stare at their phone screen for thirty minutes. They lock it, they may put it in an armband or a pocket, and they expect the audio cue for "work" and "rest" to arrive exactly when it's supposed to — over whatever they're already listening to, without interrupting the track.

My first instinct, like most developers coming at this fresh, was to reach for a plain JavaScript timer — a setInterval ticking away, counting down the phases, firing an audio cue at zero. It worked beautifully in the simulator. It worked beautifully with the screen on. Then I locked the phone and background-tested it, and the timer simply stopped altogether once iOS decided to suspend the JS thread. Yes, yours truly fell victim, once again, to the age-old developer assumption that "it runs on my device" means "it runs."

The lesson, once I'd stopped swearing at my own optimism, was that iOS treats a backgrounded app as a guest it's actively trying to evict unless you give it a very good, very specific reason to let it stay awake. A generic timer is not that reason.

After a lot of digging through the dark vaults of developer forums (this app's base code is over two years old at this point, so plenty had moved on in the meantime), I landed on the idea that keeping an active audio session running on the app was what stopped iOS from killing its thread. Conveniently, Clear HIIT already needed an audio channel anyway, since the whole point is layering cues over the user's music rather than replacing it. By leaning on a proper background audio session rather than a bare JavaScript clock, and scheduling the cue points against real elapsed time rather than a tick counter that iOS could pause at will, the timing became reliable regardless of screen state. The app earned its keep in the background instead of asking the OS for a favour it wasn't going to grant.

Bear in mind that real-world testing here was considerably more tedious than that paragraph makes it sound — locking the phone, waiting, unlocking, checking drift, over and over, across different session lengths, is not glamorous work. But it's exactly the kind of unglamorous verification that separates "demoed it once" from "shipped it."

The Second Confession: I Cannot Design
If you've read my other articles (in Linkedin), this one won't surprise you. Code, I can wrangle. Interfaces, historically, have been my weak spot — and not in a "needs polish" way, in an "actively repels users" way.

The original layout

My first pass at Clear HIIT's interface looked exactly like what you'd expect from a backend developer left unsupervised near Figma: functional, and about as inviting as a spreadsheet. Buttons where I needed buttons. Labels wherever there was space. It worked, in the same sense that the drifting timer "worked" — technically true, practically embarrassing.

What actually moved the needle was using AI as a genuine design collaborator rather than a code generator. I fed it what I had, described what each screen needed to communicate at a glance — target speed for Run, named exercises for Circuit, difficulty for Spin — and iterated on layout, spacing, and the two themes (Tidal and Daybreak) until something emerged that looked like it belonged on the App Store rather than in a university coursework folder. I confess that without it, Clear HIIT would either still be sitting half-finished on my laptop, or would have shipped looking like something nobody wanted to open twice.

The AI-assisted redesign

Where I'd Push Back on Myself
I don't want to leave the impression that AI simply designed the app for me while I sat back and watched. It didn't. It got me to a defensible starting point far faster than I'd have got there alone, but every decision about what actually stayed — which layout survived, which colour did the job, which screen was still too busy — was still a judgement call I had to make. AI is very good at generating options and very bad at knowing which one you'll still be happy with in six months. That part remains stubbornly human, and I'd be doing readers a disservice if I pretended otherwise.

What Beta Testers Taught Me
Before any of this went live, the app went through a beta stage, and I got some genuinely useful feedback out of it — the kind that reshapes a feature list rather than just polishing what's already there. Voice prompting and haptic feedback both came directly out of that round: testers wanted to know a phase had changed without having to glance at the screen at all, which, in hindsight, is exactly the same "trust it without watching it" principle that drove the background timer work in the first place. I just hadn't extended it far enough on my own.

The other change was adding difficulty and power levels to the Spin (indoor cycling) session type. That one hadn't occurred to me until testers who actually spin pointed out that a bare countdown means nothing without knowing how hard to push during each interval — so now every phase tells you exactly that, rather than leaving you to guess.

An upcoming update will build on the same theme: optional folders, so users can group their sessions rather than scrolling through one flat list. I suspect this will matter most to personal trainers, who could use it to keep each client's sessions organised separately rather than lumped in together.

Somewhere along the way I also had to learn how to actually get the app in front of people once it was live — putting your first app on the App Store is an experience all of its own, and bringing awareness to it across the iPhone ecosystem globally turned out to be a challenge that had nothing to do with code at all. That's a story for another day, but it deserves a mention here as the one that's still ongoing.

Final Thoughts
Between an unreliable background timer and an interface only a developer could love, Clear HIIT gave me two genuinely different kinds of problem to solve — one where the fix was understanding iOS's rules for background execution properly, and one where the fix was admitting my own limits and bringing in help. Both, in their own way, were refactoring exercises: taking something that technically ran and turning it into something that actually worked for the person using it.

If you want to try the app free for 30 days (and maybe give me a favourable review), you can download it from the Apple App Store: https://apps.apple.com/us/app/clearhiit/id6781863028

And if you do try it — whether you love it, it's not for you, or you've got improvement suggestions — let me know either way. I'd genuinely like to hear it.

George Gaskin is a freelance developer and Lecturer with more than thirty years of software development experience in the telecommunications industry, and the independent developer behind Clear HIIT.

DEV Community: George Gaskin

Clear HIIT: The Path to Building My First App (and the Two Problems That Stood in My Way)