DEV Community: garry

How I Handle State Management in a Health App

garry — Fri, 27 Mar 2026 16:27:50 +0000

State in a Breathing App Is Deceptively Complex

On the surface, Lunair seems like it would have simple state: a breathing pattern is playing or it is not. In reality, the state graph is surprisingly deep once you account for interruptions, background transitions, accessibility events, and user preferences.

The State Machine Approach

Early on I used a collection of boolean flags — isPlaying, isPaused, isComplete. This quickly devolved into impossible states. Could something be both paused and complete? The flags said yes; reality said no.

I switched to an explicit state machine:

enum SessionState: Equatable {
    case idle
    case preparing(pattern: BreathPattern)
    case active(phase: BreathPhase, cycleCount: Int)
    case paused(resumePhase: BreathPhase, cycleCount: Int)
    case completing(totalCycles: Int)
    case completed(summary: SessionSummary)
}

Every possible state is explicitly modeled. The paused case carries the information needed to resume. The completing state handles the wind-down animation before showing results. No impossible combinations.

Managing Transitions

State transitions are handled through a single method that validates and applies changes:

class SessionManager: ObservableObject {
    @Published private(set) var state: SessionState = .idle

    func transition(to newState: SessionState) {
        guard isValidTransition(from: state, to: newState) else {
            assertionFailure("Invalid transition: \(state) -> \(newState)")
            return
        }

        let oldState = state
        state = newState

        handleSideEffects(from: oldState, to: newState)
    }

    private func isValidTransition(
        from: SessionState, to: SessionState
    ) -> Bool {
        switch (from, to) {
        case (.idle, .preparing):           return true
        case (.preparing, .active):         return true
        case (.active, .paused):            return true
        case (.active, .completing):        return true
        case (.paused, .active):            return true
        case (.paused, .idle):              return true
        case (.completing, .completed):     return true
        case (.completed, .idle):           return true
        default:                            return false
        }
    }
}

The assertionFailure catches invalid transitions during development without crashing in production. This has caught bugs multiple times — especially around background/foreground transitions triggering unexpected state changes.

Side Effects at the Boundary

All side effects — haptics, sound, analytics, timer management — happen in handleSideEffects, not scattered throughout the UI:

private func handleSideEffects(
    from oldState: SessionState, to newState: SessionState
) {
    switch (oldState, newState) {
    case (_, .active(let phase, _)):
        hapticEngine.signalPhase(phase)
        timerManager.start(for: phase)

    case (.active, .paused):
        timerManager.pause()
        hapticEngine.stop()

    case (_, .completing(let cycles)):
        hapticEngine.signalSessionComplete()
        analytics.logSessionEnd(cycles: cycles)

    default:
        break
    }
}

This centralization means the views stay purely declarative. They read state and render. That is it.

Persisting Across Interruptions

Phone calls, notifications, backgrounding — all of these can interrupt a breathing session. The state machine handles this cleanly:

func handleScenePhaseChange(_ phase: ScenePhase) {
    switch phase {
    case .background:
        if case .active(let breathPhase, let count) = state {
            transition(to: .paused(
                resumePhase: breathPhase,
                cycleCount: count
            ))
        }
    case .active:
        // Don't auto-resume — let the user choose
        break
    default:
        break
    }
}

Auto-pausing on background is essential. Auto-resuming is not — returning to the app after a phone call should not immediately start a breathing cycle without the user being ready.

What I Would Do Differently

If I were starting Lunair today, I would reach for the Observation framework (@Observable) sooner. The ObservableObject + @Published pattern works, but the newer approach eliminates unnecessary view updates when unrelated published properties change.

The state machine pattern, though, I would not change. It has been the single most stabilizing architectural decision in the entire app.

Testing Timer Accuracy on Different iOS Devices

garry — Tue, 24 Mar 2026 08:17:01 +0000

You Cannot Trust the Simulator

The iOS Simulator runs on your Mac's CPU. Timers in the simulator are suspiciously accurate because they are backed by a desktop processor that is not juggling cellular radios, thermal throttling, or aggressive power management. Real devices lie in different and more interesting ways.

My Testing Methodology

When I built BoxTime, I needed to verify that the timer was accurate across a range of devices. I set up a simple test: start a 3-minute round, compare the app's completion time against an external reference (a stopwatch on another device).

The Test Harness

#if DEBUG
class TimerAccuracyLogger {
    private var roundStartTime: Date?
    private var expectedDuration: TimeInterval = 0

    func roundStarted(expectedDuration: TimeInterval) {
        self.roundStartTime = Date()
        self.expectedDuration = expectedDuration
    }

    func roundEnded() {
        guard let start = roundStartTime else { return }
        let actual = Date().timeIntervalSince(start)
        let drift = actual - expectedDuration
        print("Expected: \(expectedDuration)s, Actual: \(String(format: "%.4f", actual))s, Drift: \(String(format: "%.4f", drift))s")
    }
}
#endif

I ran this across five devices: iPhone SE (2nd gen), iPhone 12, iPhone 14 Pro, iPhone 15, and an iPad Air. Each device ran a full 12-round, 3-minute workout with 1-minute rest periods.

Results

Device	Per-Round Drift	Total Drift (36 min)
iPhone SE (2nd gen)	< 1ms	< 12ms
iPhone 12	< 1ms	< 12ms
iPhone 14 Pro	< 0.5ms	< 6ms
iPhone 15	< 0.5ms	< 6ms
iPad Air (5th gen)	< 1ms	< 12ms

With the absolute-time-anchored approach (computing remaining time from Date() rather than counting ticks), drift is negligible on all devices. The sub-millisecond drift comes from the time between the Date() call and the actual notification/haptic firing.

Where Things Go Wrong

Thermal Throttling

I ran the test while the iPhone SE was charging in a warm room. The device thermal-throttled, and frame rates dropped. But the timer accuracy was unaffected because it is not tied to frame rate. The display update was choppy, but the round ended at the correct time.

Low Power Mode

Low Power Mode reduces CPU frequency and limits background activity. Timer accuracy was unaffected in the foreground. However, if the app moves to the background while Low Power Mode is active, iOS is more aggressive about suspending it. The local notification fallback handles this.

App Backgrounding

This is the real threat to accuracy. When the app goes to the background, iOS can suspend it within seconds. My test:

Start a 3-minute round
Switch to Safari for 30 seconds
Return to BoxTime

Result: the timer correctly shows the right remaining time because it recalculates from the absolute end time on every frame after returning to foreground.

func sceneDidBecomeActive(_ scene: UIScene) {
    // Timer automatically shows correct time because remainingTime
    // is computed from Date(), not from accumulated ticks
    // No manual state restoration needed for the display
}

Edge Case: System Clock Changes

What if the user changes their system clock mid-workout? This could theoretically break an absolute-time approach. I handle it with ProcessInfo.processInfo.systemUptime as a sanity check:

func validateTimeConsistency() {
    let wallClockElapsed = Date().timeIntervalSince(workoutStartDate)
    let uptimeElapsed = ProcessInfo.processInfo.systemUptime - workoutStartUptime

    // If wall clock and uptime disagree by more than 2 seconds,
    // the system clock was probably changed
    if abs(wallClockElapsed - uptimeElapsed) > 2.0 {
        // Fall back to uptime-based calculation
        recalibrateFromUptime()
    }
}

This is an edge case I have never seen in production, but it costs five lines of code to handle.

The Takeaway

Timer accuracy on iOS is a solved problem if you use the right architecture. Anchor to absolute time, use CADisplayLink for display updates, and handle backgrounding gracefully. Testing on real devices confirms what the theory predicts -- the approach works across the full range of iOS hardware.

BoxTime has been used for thousands of workout sessions with zero reported timing issues.

Localization for a Fitness App — What I Wish I Knew Earlier

garry — Mon, 23 Mar 2026 18:27:22 +0000

Boxing Is Global, English Is Not

BoxTime started as an English-only app. Then I looked at my App Store analytics: 40% of my downloads came from non-English-speaking countries. Brazil, Japan, Mexico, Germany. I was leaving value on the table by not localizing.

String Catalogs in Xcode 15+

Apple introduced String Catalogs (.xcstrings files) in Xcode 15, replacing the old .strings and .stringsdict files. The migration was worth it -- String Catalogs auto-detect localizable strings and provide a single-file editing experience.

// In code, just use String(localized:)
Text(String(localized: "Round \(currentRound) of \(totalRounds)"))

// Or use the automatic LocalizedStringKey behavior
Text("Round \(currentRound) of \(totalRounds)")

SwiftUI Text views automatically treat string literals as LocalizedStringKey. For a simple app, this means most of your UI is already localization-ready if you used string literals in Text.

The Challenges Specific to Fitness Apps

Number Formatting

Some cultures use commas for decimal separators. Timer displays should use the user's locale:

// Wrong: hardcoded format
Text("\(minutes):\(String(format: "%02d", seconds))")

// Right for a timer: this is one case where you actually want
// a fixed format. Timers are universally read as M:SS.
// But display it clearly:
Text(remainingTime, format: .timerCountdown)

Actually, timer displays are an exception to the localization rule. "3:00" means three minutes everywhere. I deliberately do not localize the countdown format. But labels around the timer ("Round", "Rest", "Rounds remaining") absolutely need translation.

Pluralization

"1 round" vs "3 rounds" is straightforward in English. Other languages have complex plural rules. Russian has three plural forms. Arabic has six.

// In your String Catalog, define plural variants:
// "rounds_remaining" = "%lld rounds remaining"
// With variants for: zero, one, two, few, many, other

Text("rounds_remaining \(roundsLeft)")

String Catalogs handle plural rules per locale. You define the variants, and iOS picks the right one at runtime.

Layout Flexibility

German words are longer than English. Arabic reads right-to-left. Your layout needs to handle both.

// Bad: fixed-width container
Text(phaseLabel)
    .frame(width: 100)

// Good: flexible layout
Text(phaseLabel)
    .frame(maxWidth: .infinity)
    .minimumScaleFactor(0.7)

The .minimumScaleFactor modifier lets text shrink to fit rather than truncating. For BoxTime, I set it on all labels that might be longer in other languages.

What I Localized (and What I Did Not)

Localized:

All UI labels ("Round", "Rest", "Start", "Pause", "Settings")
App Store metadata (title, subtitle, description, keywords)
Notification text

Not localized:

Timer display (universal format)
Sound file names (internal)
Analytics event names (internal)

How I Got Translations

For the initial launch, I used a combination of:

Machine translation (DeepL, not Google Translate) for the first pass
Native speaker review from language exchange communities and Reddit
App Store metadata was the priority -- this is what drives downloads

I focused on five languages first: Spanish, Portuguese, Japanese, German, and French. These covered my top non-English markets.

The Impact

After localizing the App Store listing alone (before even localizing the app UI), downloads from localized markets increased by roughly 60%. Localizing the in-app UI further improved retention in those markets.

If you are an indie dev with a fitness app, check your App Store Connect analytics for your top countries. If you see significant traffic from non-English markets, localization has clear ROI -- even if you start with just the App Store metadata.

BoxTime is currently localized in six languages, with more planned based on download data.

Building a Precision Timer in SwiftUI Without Drift

garry — Mon, 23 Mar 2026 12:17:52 +0000

The Problem With Naive Timers

When I started building BoxTime, my boxing round timer app, I made the classic mistake: I used Timer.scheduledTimer with a 1-second interval and decremented a counter. It looked right in the simulator. It looked right for the first 30 seconds on a real device. Then the drift crept in.

After a 3-minute round, my timer was off by 1-2 seconds. Over a full 12-round session, that adds up. In boxing, timing matters. You can't have a round timer that lies to you.

Why Timers Drift

The fundamental issue is that Timer in iOS is not a precision instrument. It fires on the run loop, and the run loop has other things to do. Each tick might be 1.002 seconds instead of 1.000. Those fractions accumulate.

// The naive approach - DO NOT use this for precision
Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in
    self.remainingSeconds -= 1
}

The run loop might delay a fire by milliseconds. When the UI is busy, it gets worse. Scrolling, animations, haptics -- all of it competes for time on the main thread.

The Fix: Anchor to Absolute Time

Instead of counting ticks, I anchor to a reference point using Date and calculate the elapsed time on every update. The display timer fires frequently, but the actual remaining time is always computed from reality.

@Observable
class RoundTimer {
    private var roundEndTime: Date?
    private var displayLink: CADisplayLink?

    var remainingSeconds: TimeInterval {
        guard let end = roundEndTime else { return 0 }
        return max(0, end.timeIntervalSinceNow)
    }

    func startRound(duration: TimeInterval) {
        roundEndTime = Date().addingTimeInterval(duration)
        startDisplayUpdates()
    }

    private func startDisplayUpdates() {
        displayLink = CADisplayLink(target: self, selector: #selector(tick))
        displayLink?.add(to: .main, forMode: .common)
    }

    @objc private func tick() {
        // View updates automatically via @Observable
        if remainingSeconds <= 0 {
            roundDidEnd()
        }
    }
}

Why CADisplayLink Over Timer

I use CADisplayLink instead of a repeating Timer for the display updates. Two reasons:

It syncs to the screen refresh rate. No point updating faster than the display can render.
Using .common run loop mode means it keeps firing during scrolling and other UI interactions. A default-mode Timer pauses when the user touches the screen -- terrible for a workout app.

The Remaining Subtlety

Even with absolute time anchoring, there is a display quantization issue. If your UI shows whole seconds, you need to decide: do you show the ceiling or the floor? I chose ceiling. When remainingSeconds is 2.3, the display shows "3". This means the display changes from "1" to "0" right as time actually expires, which feels correct to users.

var displaySeconds: Int {
    Int(ceil(remainingSeconds))
}

Results

After this refactor, BoxTime's timer is accurate to within a single frame (~16ms at 60fps). Over a 36-minute session, the cumulative error is zero because there is no accumulation -- every frame recalculates from the absolute endpoint.

If you are building any kind of countdown or stopwatch in SwiftUI, anchor to real time. Never count ticks. Your users might not notice 2 seconds of drift, but they will notice 10. And if they are getting punched in the face, they will definitely notice.

BoxTime is free on the App Store if you want to see this in action.

App Store Optimization for Niche Fitness Apps

garry — Mon, 23 Mar 2026 07:39:39 +0000

ASO When Nobody Is Searching for You

App Store Optimization for a mainstream fitness app is well-documented. But what about a niche app like BoxTime, a boxing round timer? The total search volume for "boxing timer" is a fraction of "workout app." Here is what I learned optimizing for a small but specific audience.

Keyword Research on a Budget

I did not pay for an ASO tool. Instead, I used App Store Connect's search ads feature (even without running ads) to gauge keyword popularity, and I manually searched the App Store to see what competitors rank for.

My primary keywords:

boxing timer
round timer
boxing round timer
fight timer
MMA timer
interval timer boxing

The long-tail matters more in a niche. "Interval timer" is competitive -- massive apps dominate it. "Boxing round timer" has less volume but almost zero competition.

Title and Subtitle Strategy

Apple gives you 30 characters for the title and 30 for the subtitle. Every character counts.

Title:    BoxTime - Boxing Timer
Subtitle: Round Timer for Training

I front-loaded the brand name, included the primary keyword ("Boxing Timer"), and used the subtitle for a secondary keyword phrase. I avoid keyword stuffing -- Apple penalizes it, and it looks unprofessional.

The Description Nobody Reads (But Apple Does)

The long description does not directly impact search ranking (Apple says keywords are what matter), but it matters for conversion. Users who scroll to the description are on the fence. Bullet points work. Walls of text do not.

I structure it as:

One-line value proposition
Three key features as bullets
Brief paragraph about who it is for
Call to action

Screenshots That Convert

For a timer app, the screenshots need to show the timer in action, not a features list. My screenshot strategy:

Timer running -- the hero shot, big countdown, clear round indicator
Configuration -- show how simple setup is
Rest phase -- demonstrate the round/rest cycle visually
Feature callout -- haptics, audio, customization in one frame

I designed these in Figma with device frames. The first screenshot gets 70%+ of the attention, so it must immediately communicate what the app does.

Ratings and Reviews

With a small user base, every rating matters disproportionately. A single 1-star review on an app with 10 ratings tanks your average. I use SKStoreReviewController to prompt for ratings, but timing matters:

func checkForReviewPrompt() {
    guard completedWorkouts >= 5 else { return }
    guard lastReviewPrompt == nil ||
          Date().timeIntervalSince(lastReviewPrompt!) > 60 * 60 * 24 * 30 else {
        return
    }

    if let scene = UIApplication.shared.connectedScenes
        .first(where: { $0.activationState == .foregroundActive }) as? UIWindowScene {
        SKStoreReviewController.requestReview(in: scene)
        lastReviewPrompt = Date()
    }
}

I prompt after 5 completed workouts. At that point, the user has gotten value from the app and is likely to leave a positive review. Prompting on first launch is a recipe for low ratings.

Localization as ASO

I localized the App Store listing (not the app itself initially, just the metadata) into Spanish, Portuguese, and Japanese -- three markets with strong boxing cultures. Each localization gives you a new set of keyword slots. My downloads from Brazil doubled after adding Portuguese metadata.

What Moved the Needle

Honestly? The biggest impact came from:

Choosing keywords with low competition rather than high volume
The first App Store screenshot
Rating prompt timing

Everything else was incremental. For a niche app like BoxTime, discoverability comes more from being the best result for a specific query than from ranking for broad terms.

Building a Breathing App — Why Simplicity Was the Hardest Part

garry — Sun, 22 Mar 2026 19:38:50 +0000

The Trap of Feature Creep

When I started building Lunair, my breathing exercise app for iOS, I had a Notion board full of ideas. Guided meditations, social sharing, streaks, gamification, AI-powered breathing recommendations. The works.

Six weeks in, I had a bloated prototype that did everything poorly and nothing well. The core experience — helping someone breathe — was buried under menus and onboarding flows.

Stripping It Down

The turning point was watching someone use the app for the first time. They opened it, stared at the home screen for ten seconds, then asked "where do I start?" That was the moment I realized I had failed at the one thing that mattered.

I spent the next two weeks removing features. It was painful. Every feature I cut represented hours of work. But each removal made the app feel lighter, more focused.

// Before: A sprawling navigation structure
TabView {
    HomeView()
    ExploreView()
    StatsView()
    ProfileView()
    SettingsView()
}

// After: One screen, one purpose
BreathingView(pattern: selectedPattern)

What "Simple" Actually Means in Code

Simple UI does not mean simple code. In fact, the opposite is usually true. When you strip away navigation chrome, every pixel has to earn its place. The breathing animation needed to feel organic, not mechanical. The timing had to be precise enough to guide but forgiving enough to not stress someone out.

I spent more time on the easing curve of a single circle animation than I did on entire view controllers in previous projects:

struct BreathingCircle: View {
    @State private var scale: CGFloat = 0.6

    var body: some View {
        Circle()
            .fill(breathingGradient)
            .scaleEffect(scale)
            .animation(
                .easeInOut(duration: inhaleDuration),
                value: scale
            )
    }
}

The Paradox of Minimal Design

Here is what nobody tells you about minimal apps: users notice every flaw. In a complex app, a slightly off animation or an awkward transition gets lost in the noise. In a minimal app, it is the entire experience.

I rewrote the main breathing view four times. Not because it was broken, but because "good enough" felt jarring in a context where there was nothing else to look at.

Lessons Learned

Start with the core interaction, not the feature list. If your app's primary action does not feel great in isolation, no amount of features will save it.
Simplicity is a continuous practice. Every update, I fight the urge to add "just one more thing."
Measure by what you remove. The best sessions I had building Lunair were the ones where the line count went down.

Building a simple app taught me more about software craft than any complex project I have shipped. The constraint forced better decisions at every level — architecture, design, and user experience.

If you are building something in the health or wellness space, resist the urge to compete on features. Compete on feel.

Haptic Feedback Design for Workout Apps

garry — Sun, 22 Mar 2026 17:09:32 +0000

Why Haptics Matter More Than Sound in the Gym

When I built BoxTime, I assumed the bell sound would be the primary way users know a round ended. Then I tested it at an actual boxing gym. Between the music, the bag noise, other people training -- you cannot hear your phone. Haptics became the real signal.

The Haptic Engine on iOS

Apple gives you three levels of haptic control, from simple to granular:

UIImpactFeedbackGenerator

The simplest option. Predefined impact styles.

let impact = UIImpactFeedbackGenerator(style: .heavy)
impact.prepare()
impact.impactOccurred()

UINotificationFeedbackGenerator

Semantic feedback for success, warning, and error states.

let notification = UINotificationFeedbackGenerator()
notification.prepare()
notification.notificationOccurred(.success)

Core Haptics (CHHapticEngine)

Full control over haptic patterns. This is where it gets interesting for a timer app.

import CoreHaptics

class HapticManager {
    private var engine: CHHapticEngine?

    func prepareEngine() {
        guard CHHapticEngine.capabilitiesForHardware().supportsHaptics else { return }

        do {
            engine = try CHHapticEngine()
            try engine?.start()
        } catch {
            print("Haptic engine failed: \(error)")
        }
    }

    func playRoundEndPattern() throws {
        // Three strong taps with decreasing intervals - feels like a boxing bell
        let events: [CHHapticEvent] = [
            CHHapticEvent(
                eventType: .hapticTransient,
                parameters: [
                    CHHapticEventParameter(parameterID: .hapticIntensity, value: 1.0),
                    CHHapticEventParameter(parameterID: .hapticSharpness, value: 0.8)
                ],
                relativeTime: 0
            ),
            CHHapticEvent(
                eventType: .hapticTransient,
                parameters: [
                    CHHapticEventParameter(parameterID: .hapticIntensity, value: 0.8),
                    CHHapticEventParameter(parameterID: .hapticSharpness, value: 0.6)
                ],
                relativeTime: 0.15
            ),
            CHHapticEvent(
                eventType: .hapticTransient,
                parameters: [
                    CHHapticEventParameter(parameterID: .hapticIntensity, value: 0.6),
                    CHHapticEventParameter(parameterID: .hapticSharpness, value: 0.4)
                ],
                relativeTime: 0.30
            ),
        ]

        let pattern = try CHHapticPattern(events: events, parameters: [])
        let player = try engine?.makePlayer(with: pattern)
        try player?.start(atTime: CHHapticTimeImmediate)
    }
}

Designing a Haptic Language

In BoxTime, I use different haptic patterns for different events, so the user can feel what is happening without looking at the screen:

Round start: Two sharp taps (get ready, fight)
Round end: Three descending taps (imitates a bell resonating)
10-second warning: Single soft pulse (heads up)
Workout complete: Long success pattern (celebration feel)

The key insight is that haptic patterns should be distinct enough to be recognized without visual context. If your round-start and round-end patterns feel similar, the user has to look at the screen to know what happened, which defeats the purpose.

The .prepare() Call Matters

Haptic engines have a spin-up latency. If you create a generator and immediately fire it, there may be a perceptible delay. Always call .prepare() ahead of time.

// Bad: latency on first fire
func roundEnding() {
    let impact = UIImpactFeedbackGenerator(style: .heavy)
    impact.impactOccurred() // might be delayed
}

// Good: pre-warm the engine
func roundStarted() {
    upcomingHaptic.prepare() // warm up for the end-of-round haptic
}

func roundEnding() {
    upcomingHaptic.impactOccurred() // fires immediately
}

In BoxTime, I prepare the next haptic event as soon as the current phase starts. By the time the round ends, the engine is ready.

Testing Realities

The iOS Simulator does not support haptics. You must test on a real device. And not all devices support Core Haptics -- the iPhone 7 supports basic UIFeedbackGenerator haptics but not the full CHHapticEngine. Always check CHHapticEngine.capabilitiesForHardware().supportsHaptics and fall back gracefully.

What I Learned

Haptics are not a nice-to-have in fitness apps. They are essential. A boxer with gloves on cannot easily tap their phone screen. They need to feel the transitions. Investing time in distinct, well-timed haptic patterns was one of the highest-impact improvements I made to BoxTime.

Designing a Minimal UI — What I Removed and Why

garry — Sun, 22 Mar 2026 14:57:04 +0000

The First Version Had Too Much

The first version of BoxTime had a tab bar, a settings gear icon, a history view, round statistics, a customizable color picker, and an animated boxing glove mascot. It was a mess. I know this because nobody used it for more than 30 seconds before closing it.

A boxing timer needs to do one thing: tell you when to fight and when to rest. Everything else is noise.

What I Cut

The Tab Bar

Three tabs: Timer, History, Settings. The History tab tracked past workouts. Nobody asked for this. I was building it because other apps had it, not because my users needed it. Removed.

Round Statistics

Average round time, total training time this week, a little chart. Cool engineering, zero value for the core use case. The person using this app has boxing gloves on. They are not analyzing charts. Removed.

The Color Picker

Custom accent colors. I spent a day building a nice HSB color picker. One of my testers said "why would I change the color?" Fair point. Removed.

Complex Onboarding

A three-screen onboarding flow explaining what a round timer is. If someone downloaded a boxing timer app, they know what a round timer is. Removed.

What Stayed

After the purge, BoxTime has essentially two screens:

Configuration: Set rounds, round duration, rest duration. Start.
Timer: Big countdown number, current round indicator, start/pause.

That is it. The configuration uses simple steppers and pickers. The timer screen is dominated by the countdown -- large enough to read from across the room.

The Design Principles I Followed

1. Glanceability

During a workout, you should understand the app's state in under one second. Big numbers, high contrast, minimal text.

Text(timeString)
    .font(.system(size: 96, weight: .bold, design: .monospaced))
    .foregroundStyle(phase == .round ? .primary : .green)

2. Reachability

Everything interactive is in the bottom half of the screen. During a workout, you are holding your phone in one hand (or it is on a shelf at eye level). Tap targets are large.

3. Progressive Disclosure

Settings exist, but they are not visible during a workout. Configuration happens before you start. Once the timer is running, the only controls are pause and stop.

4. State Through Color

Instead of labels that say "ROUND" or "REST," the entire screen color shifts. You do not need to read text to know which phase you are in. Your peripheral vision catches the color change.

var backgroundColor: Color {
    switch phase {
    case .round: return .black
    case .rest:  return Color(.systemGreen).opacity(0.15)
    case .warning: return Color(.systemRed).opacity(0.15)
    }
}

The Hard Part Is Saying No

Every feature I cut was something I enjoyed building. The history view had a nice SwiftUI chart. The color picker used some clever geometry. But features are not free -- every one adds cognitive load, maintenance burden, and potential bugs.

The version of BoxTime on the App Store today is maybe 30% of the code I originally wrote. The other 70% made the app worse by making it more complex.

If you are building a utility app, start by listing every feature. Then remove half of them. Then remove half of what remains. What is left is probably your app.

Marketing a Mental Health App With Zero Budget

garry — Sun, 22 Mar 2026 12:35:08 +0000

The Cold Reality

I launched Lunair with exactly $0 in marketing budget. No paid ads, no influencer deals, no PR agency. Just me, a shipped app, and the internet.

Six months later, the app has organic downloads that continue to grow. Here is what actually worked and what was a complete waste of time.

What Worked

Dev Community Content

Writing about the technical process of building Lunair brought more downloads than any other single strategy. Posts on Dev.to, Hacker News, and indie dev communities generated genuine interest because they provided value beyond "download my app."

The key was leading with the technical insight and letting the app be the context, not the pitch:

"How I built custom haptic patterns for a breathing app" works
"Check out my new breathing app" does not

Reddit (Carefully)

Reddit hates self-promotion and can smell it immediately. What works is genuine participation in relevant communities — r/SwiftUI, r/iOSProgramming, r/IndieGaming — where I shared specific technical solutions. My flair mentioned Lunair, and interested people clicked through.

I never posted "I made this app." I posted solutions to problems other devs were having, using my app as an example.

App Store Optimization

ASO was the highest-ROI activity by far. I spent two weeks researching keywords, rewriting my app description, and iterating on screenshots:

Title: Include your primary keyword naturally
Subtitle: Your second most important keyword phrase
Keywords field: All 100 characters, no spaces after commas, no duplicating words from the title
Screenshots: The first two screenshots decide everything; they need to communicate the core value in under 2 seconds

Twitter/X Indie Dev Community

The #IndieDev and #SwiftUI communities on Twitter are genuinely supportive. I posted build progress, design decisions, and small wins. The engagement was modest but highly targeted — people who follow these hashtags are either developers or tech-curious users.

Product Hunt Launch

Lunair's Product Hunt launch brought a spike of about 200 downloads in 48 hours. Not life-changing, but those early users provided invaluable feedback and several became repeat users who left reviews.

What Did Not Work

Cold Outreach to Press

I emailed 30 app review sites. Two responded. Zero published anything. Small indie apps without a hook beyond "it is well-made" do not get coverage. The effort-to-result ratio was terrible.

Social Media Ads (Small Test)

I ran a $50 test on Instagram. The CPM was reasonable but the conversion was near zero. Health app ads compete with massive companies spending millions. My $50 was invisible.

Feature Request Sites

Submitting to "app of the day" aggregator sites generated zero measurable impact. Most of these sites have minimal real traffic.

The Compounding Strategy

The real insight is that everything I did was compounding content. Dev articles stay indexed. Reddit answers stay searchable. ASO improvements work every single day. Unlike ads that stop working when you stop paying, content keeps generating returns.

Numbers I Will Share

Total marketing spend: $50 (the failed Instagram test)
Highest single-day downloads came from a Hacker News comment, not a post
ASO changes increased organic search traffic by roughly 40%
Average time from "discovers app" to "downloads" was under 24 hours — people who found Lunair through content were pre-qualified

Advice for Indie Devs

Your development process is your marketing content
Provide value first; mention your app second
Invest heavily in ASO — it is the only "free" channel that scales
Be patient. Organic growth is slow but durable
Every user who finds you through content is worth ten from ads

Zero budget marketing is not free. You pay with time and consistency. But for indie devs, time is the one resource we actually have.

Managing App State With SwiftUI @Observable

garry — Sun, 22 Mar 2026 12:15:08 +0000

From ObservableObject to @observable

When I started BoxTime, I used ObservableObject with @Published properties everywhere. It worked, but the boilerplate was annoying and the performance was worse than it needed to be. Then iOS 17 shipped @Observable, and I migrated everything in an afternoon.

The Old Way

// Pre-iOS 17
class TimerManager: ObservableObject {
    @Published var currentRound: Int = 1
    @Published var remainingTime: TimeInterval = 0
    @Published var phase: TimerPhase = .idle
    @Published var isRunning: Bool = false
    @Published var totalRounds: Int = 12
    @Published var roundDuration: TimeInterval = 180
    @Published var restDuration: TimeInterval = 60
}

struct TimerView: View {
    @StateObject var timer = TimerManager()
    // or @ObservedObject, @EnvironmentObject...
}

The problem: every time any @Published property changed, every view observing the object re-evaluated its body. If remainingTime updated 10 times per second, every view depending on TimerManager re-rendered 10 times per second -- even views that only read totalRounds, which almost never changes.

The New Way

@Observable
class TimerManager {
    var currentRound: Int = 1
    var remainingTime: TimeInterval = 0
    var phase: TimerPhase = .idle
    var isRunning: Bool = false
    var totalRounds: Int = 12
    var roundDuration: TimeInterval = 180
    var restDuration: TimeInterval = 60
}

struct TimerView: View {
    var timer: TimerManager

    var body: some View {
        // This view only re-renders when remainingTime or phase change
        // because those are the only properties accessed in body
        Text(formatTime(timer.remainingTime))
        Text(timer.phase.label)
    }
}

The @Observable macro automatically tracks which properties each view reads during its body evaluation. Only changes to accessed properties trigger re-renders. This is per-view granular observation, and it is a massive performance win.

Practical Architecture in BoxTime

BoxTime has a few observable objects:

@Observable
class TimerManager {
    var currentRound = 1
    var remainingTime: TimeInterval = 0
    var phase: TimerPhase = .idle

    // Configuration (rarely changes)
    var config = WorkoutConfig()

    // Computed properties work automatically
    var displayTime: String {
        let minutes = Int(remainingTime) / 60
        let seconds = Int(remainingTime) % 60
        return String(format: "%d:%02d", minutes, seconds)
    }

    func startWorkout() {
        phase = .round
        remainingTime = config.roundDuration
        startTimer()
    }
}

@Observable
class WorkoutConfig {
    var rounds: Int = 12
    var roundDuration: TimeInterval = 180
    var restDuration: TimeInterval = 60
}

I separated WorkoutConfig from TimerManager because configuration is edited on one screen and consumed on another. Keeping them separate means the configuration view does not observe timer ticks, and the timer view does not care about config edits.

Environment Injection

Passing observable objects through the environment is cleaner with @Observable:

@main
struct BoxTimeApp: App {
    @State private var timerManager = TimerManager()

    var body: some Scene {
        WindowGroup {
            ContentView()
                .environment(timerManager)
        }
    }
}

struct TimerView: View {
    @Environment(TimerManager.self) var timer

    var body: some View {
        Text(timer.displayTime)
    }
}

No more @EnvironmentObject -- just @Environment with the type. And you get compile-time type safety instead of runtime crashes when the object is missing.

One Gotcha: Bindings

Creating bindings to @Observable properties in SwiftUI requires @Bindable:

struct ConfigView: View {
    @Environment(TimerManager.self) var timer

    var body: some View {
        @Bindable var timer = timer
        Stepper("Rounds: \(timer.config.rounds)", value: $timer.config.rounds, in: 1...20)
    }
}

This tripped me up during migration. The @Bindable wrapper must be declared inside body (or the property must be @Bindable at the struct level).

Migration Effort

Migrating BoxTime from ObservableObject to @Observable took about 3 hours. Most of it was removing @Published, @StateObject, and @ObservedObject annotations. The result: less code, better performance, and more intuitive data flow.

If you are building a new SwiftUI app today and targeting iOS 17+, there is no reason to use the old observation system. BoxTime runs noticeably smoother after the migration, especially on the timer screen where updates happen many times per second.

Haptic Feedback Patterns for Eyes-Free UX

garry — Sun, 22 Mar 2026 08:55:20 +0000

Why Haptics Matter More Than You Think

When I watch people use Lunair, something interesting happens. After a minute or two of following the breathing animation, most users close their eyes. Makes sense — you are trying to relax. But the moment they close their eyes, they lose the visual guide.

This is where haptics become the primary interface.

The Haptic Vocabulary

Apple's haptic engine is surprisingly expressive if you treat it as a design language rather than a notification mechanism. In Lunair, I developed a small vocabulary of haptic patterns that users learn intuitively:

class BreathingHapticEngine {
    private let softGenerator = UIImpactFeedbackGenerator(style: .soft)
    private let lightGenerator = UIImpactFeedbackGenerator(style: .light)
    private let rigidGenerator = UIImpactFeedbackGenerator(style: .rigid)

    func prepareAll() {
        softGenerator.prepare()
        lightGenerator.prepare()
        rigidGenerator.prepare()
    }

    func signalInhaleStart() {
        softGenerator.impactOccurred(intensity: 0.7)
    }

    func signalExhaleStart() {
        lightGenerator.impactOccurred(intensity: 0.5)
    }

    func signalSessionComplete() {
        let pattern: [TimeInterval] = [0, 0.15, 0.3]
        for (index, delay) in pattern.enumerated() {
            DispatchQueue.main.asyncAfter(deadline: .now() + delay) {
                self.rigidGenerator.impactOccurred(
                    intensity: CGFloat(pattern.count - index) / CGFloat(pattern.count)
                )
            }
        }
    }
}

The key insight: inhale gets a softer, slightly stronger tap. Exhale gets a lighter, gentler tap. Your brain maps these to the actions after just two or three breathing cycles.

Preparing Generators Ahead of Time

One of the most common haptic mistakes in iOS development is not preparing your feedback generators. There is a perceptible delay between creating a generator and it being ready to fire. In a breathing app where timing is everything, that delay breaks the experience:

// Called when a breathing session starts
func sessionWillBegin() {
    hapticEngine.prepareAll()
    // Generators are now "spun up" and ready
    // First haptic will fire with zero delay
}

I prepare generators at session start rather than at first use. The Taptic Engine stays warm for about 2 seconds after preparation, so for continuous use during a breathing session, you really only need to prepare once.

Core Haptics for Advanced Patterns

For the premium breathing patterns in Lunair, I use Core Haptics instead of the basic UIFeedbackGenerator. This lets me create continuous haptic textures that can ramp up and down — matching the breathing curve:

func createInhalePattern() throws -> CHHapticPattern {
    let rampUp = CHHapticParameterCurve(
        parameterID: .hapticIntensityControl,
        controlPoints: [
            .init(relativeTime: 0, value: 0.1),
            .init(relativeTime: 0.5, value: 0.6),
            .init(relativeTime: 1.0, value: 0.3)
        ],
        relativeTime: 0
    )

    let event = CHHapticEvent(
        eventType: .hapticContinuous,
        parameters: [
            CHHapticEventParameter(parameterID: .hapticSharpness, value: 0.3)
        ],
        relativeTime: 0,
        duration: inhaleDuration
    )

    return try CHHapticPattern(events: [event], parameterCurves: [rampUp])
}

This creates a haptic sensation that swells and fades with the breath — a gentle vibration that intensifies as lungs fill and softens as you approach the hold phase.

Respecting User Preferences

Not everyone wants haptics. Some users find them distracting. In Lunair, haptic intensity is adjustable from off to strong, and the setting persists:

enum HapticIntensity: String, CaseIterable {
    case off, subtle, moderate, strong

    var multiplier: CGFloat {
        switch self {
        case .off: return 0
        case .subtle: return 0.3
        case .moderate: return 0.6
        case .strong: return 1.0
        }
    }
}

Testing Haptics

You cannot test haptics in the simulator. This seems obvious, but I spent an embarrassing amount of time wondering why my haptic code "was not working" before remembering this. Always test on a physical device, and test with your eyes closed — that is the actual use case.

Haptics turned out to be one of Lunair's most praised features. Users consistently mention the eyes-closed experience in reviews. It is a small investment that fundamentally changes how people interact with the app.

Data Privacy in Health Apps — What I Chose Not to Collect

garry — Sat, 21 Mar 2026 10:19:39 +0000

The Default Is to Collect Everything

When I set up analytics for Lunair, every tutorial and SDK I encountered was designed to maximize data collection. Session recordings, user journeys, demographic profiling, device fingerprinting. The default for modern app development is to hoover up everything and figure out what is useful later.

For a mental health app, I decided to go the opposite direction.

What Lunair Does Not Collect

No personal health data leaves the device. Breathing session history, pattern preferences, and usage frequency stay in local storage. Period.
No user accounts. No email, no sign-up, no social login. There is nothing to breach because there is nothing stored server-side.
No location data. I have no reason to know where someone is breathing.
No third-party analytics SDKs. No Firebase Analytics, no Mixpanel, no Amplitude. Every one of these sends data to third-party servers with their own privacy policies.

What I Do Collect (and Why)

I use Apple's built-in App Analytics through App Store Connect. This gives me:

Download numbers
Session counts (aggregate, not per-user)
Crash reports
Device type distribution

This is enough to make informed product decisions without knowing anything about individual users.

The Technical Implementation

Keeping data local is surprisingly straightforward with SwiftUI and SwiftData:

@Model
class BreathingSession {
    var patternId: String
    var startDate: Date
    var duration: TimeInterval
    var completedCycles: Int

    init(patternId: String, startDate: Date,
         duration: TimeInterval, completedCycles: Int) {
        self.patternId = patternId
        self.startDate = startDate
        self.duration = duration
        self.completedCycles = completedCycles
    }
}

All session data lives in the local SwiftData container. It syncs via iCloud if the user has it enabled — meaning the data goes to their iCloud account, not mine. I never see it.

The Privacy Nutrition Label

Apple's App Privacy labels forced me to think carefully about every data point. Lunair's label is almost empty:

Data Not Collected
- We do not collect any data from this app.

That label is a feature. Users see it before downloading and it builds immediate trust, especially in the health category where privacy concerns are elevated.

The Business Trade-Off

I will not pretend there is no cost. Without detailed analytics, I cannot do:

A/B testing of features
Funnel analysis to optimize onboarding
Cohort analysis for retention
Personalized recommendations

These are real capabilities I am giving up. But for a breathing app, the trust equation tilts heavily toward privacy. Users open Lunair during their most vulnerable moments. The implicit promise is that those moments are private.

How I Make Product Decisions Without Data

Without analytics, I rely on:

App Store reviews. Qualitative feedback from people who care enough to write.
Direct email. The app has a "Send Feedback" option that opens a pre-filled email. No tracking, just human communication.
TestFlight beta testers. A small group who provide detailed feedback on new features.
My own usage. I use Lunair daily. If something bothers me, it probably bothers others.

// The feedback mechanism is intentionally simple
Button("Send Feedback") {
    let url = URL(string: "mailto:feedback@example.com?subject=Lunair%20Feedback")!
    UIApplication.shared.open(url)
}

Advice for Health App Developers

Default to not collecting. Add data collection only when you have a specific, justified need.
Avoid third-party SDKs. Each one is a privacy liability you cannot fully control.
Make privacy a feature. Communicate it clearly in your App Store listing.
Local-first architecture pays off. It is simpler, faster, and eliminates an entire category of security concerns.

The best security for user health data is not having it in the first place.