Back
ProjectCase Study

Focusin

A native macOS focus-and-reset loop

A local-first SwiftUI menu bar app that turns a focus deadline into one state-aware micro-break, then gets out of the way.

Year2026
ExperienceNative macOS build
CategoryNative macOS product
SwiftUISwiftmacOSAccessibility
Focusin moving from a focus interval into an active micro-break
ContextThe work

A small reset that knows when to get out of the way.

Focusin turns a focus deadline into one state-aware micro-break. The product keeps the loop local, optional, and resilient across sleep, relaunch, permission changes, and the imperfect timing of desktop work.

01

The problem

Help desk workers move from a focus interval into a useful micro-break without adding a dashboard, an account, or another decision at the moment their attention is already depleted.

02

The user

Mac-based desk workers who notice stiffness, fatigue, scattered attention, or anxiety and want a small, optional reset that stays close to their current task.

03

My role

Independent product direction, native macOS UX, SwiftUI implementation, state and persistence architecture, accessibility, testing, and release preparation

ProofDecisions

The choices that made the product hold together.

01

Persisted wall-clock deadlines instead

Persisted wall-clock deadlines instead of countdown ticks so focus and break state reconcile after sleep, relaunch, clock changes, and delayed timers.

02

Separated non-negotiable safety preferences

Separated non-negotiable safety preferences from softer state, duration, and same-day novelty matching through a documented fallback order.

03

Bundled a versioned, human-reviewed

Bundled a versioned, human-reviewed activity catalog instead of introducing remote generation, accounts, or runtime networking.

04

Kept notification and login-item

Kept notification and login-item services outside the local state core so platform denial never blocks the focus-and-break loop.

ProcessHow it took shape

Small on the surface. Deliberate underneath.

The process moved from product restraint to runtime truth, then through content safety and hostile-state verification.

  1. 01

    Find the smallest useful loop

    I reduced the product to one repeatable transition: focus, notice the deadline, take one suitable reset, and return. Accounts, streaks, task management, and remote content stayed outside version one.

  2. 02

    Model time as durable state

    The interaction was mapped as a date-derived state machine before visual polish. Persisted deadlines let the app reconcile honestly after sleep, relaunch, delayed timers, and clock changes.

  3. 03

    Make recommendations inspectable

    A reviewed 21-activity catalog and ordered fallback policy separate hard safety preferences from softer state, duration, and novelty matching—without remote generation.

  4. 04

    Prove the uncomfortable states

    The release work concentrated on permission denial, quiet hours, invalid content, large text, contrast, reduced transparency, and service failures—not only the ideal timer path.

ScreensSelected work

The interface, in context.

Focusin macOS micro-break recommendation
The lifecycle changes clearly from break due to one active, time-bounded reset.
Focusin activity and system settings showing local preferences and recovery
Preferences shape the recommendation while platform-service failure stays recoverable and non-blocking.
ReleaseProof and boundaries

What the build makes visible.

Verification

  • Fifty-four deterministic tests cover lifecycle, persistence, quiet hours, recommendation passes, catalog validation, permission reconciliation, and beta templates.
  • Twenty-one bundled activities pass state, duration, safety, and default-filter coverage validation, with named human content approval for version 0.1.0 (1).
  • Forty-one recorded appearance and accessibility captures cover light and dark modes, large text, increased contrast, reduced transparency, recovery states, and Settings; they remain engineering evidence rather than final release media.

Limitations

  • The current build and unsigned Release integrity are verified; no signed archive, installable external beta, TestFlight build, or App Store listing exists yet.
  • Exact-candidate VoiceOver, notification, login-item, lifecycle, upgrade, and final-media checks remain open until a signed candidate exists.
  • The five-to-eight-person beta has not run, so the case study makes no usability, satisfaction, or real-world recommendation-quality claim.
MoreCurrent case studies

Explore the other current projects where product thinking is carried through interface, architecture, testing, and release.