Case study: small, focused Apple apps, and what they show about scoping

Everything described here is on this site: the apps page, the StromaScape project page and the two MetricEdition articles. Where an app is still in development, I say so.

The apps at a glance

Decision 1: one job per app

Each app has a promise you can say in one sentence. bPositive puts a positive thought on your wrist through the day. MetricEdition shows what time it would be if the decimal time of the French Revolution had stuck. +StromaNotes captures a note before you forget it.

Keeping to one job means every screen can be judged against that promise. Features that don’t serve it don’t get built, which keeps each app within reach of one developer to finish and keep up to date.

For your project: write the one-sentence promise before the feature list, as described in the MVP checklist. It’s the cheapest scoping tool there is.

Decision 2: start where the moment happens

Four of the six apps are for the Apple Watch alone, because that’s where their moment happens. A note you need to capture while walking, a quote that arrives as a gentle nudge, the time at a glance: these are wrist moments. Tipple Units is planned for both iPhone and Apple Watch, and AiCuttr is a Mac app.

The watch has its own constraints: a tiny screen, short interactions measured in seconds, and a battery shared with everything else. The articles Designing for the Apple Watch and Optimising battery efficiency go into the details.

For your project: ask where and when people will actually use the app. If the answer is “in a few seconds, while doing something else”, a widget, a Live Activity or a watch app might matter more than another screen in the main app. See Widgets, App Intents and Live Activities.

Decision 3: no server unless the job needs one

MetricEdition runs entirely offline, with no adverts and no external dependencies, as the MetricEdition review notes. For a clock, that’s the right call: it has no reason to talk to anything.

No server means nothing to host, nothing to pay for monthly, no accounts to secure and far less to declare in privacy details. It also means the app keeps working when the connection doesn’t, which matters on a watch.

For your project: many ideas assume a backend from the start. Ask whether version one really needs accounts, shared data or live updates. If it does, that’s fine, but it’s often half the project, as What an iOS app really costs explains.

Decision 4: respect people’s attention

bPositive shows its quotes hourly between 8am and 9pm, not around the clock. It’s a small detail, and the kind that decides whether an app that sends prompts is welcome or switched off. MetricEdition’s red night mode makes the same point about the evening: an app that’s comfortable to look at in the dark is one people keep.

For your project: every notification, prompt and permission request spends a little of the user’s goodwill. Decide when and how often the app asks for attention as a design decision, not an afterthought.

Decision 5: trusted sources for anything that matters

Tipple Units calculates alcohol units from the drink’s strength, volume and timing using UK government guidelines, rather than an invented formula. When an app gives people information they might act on, the source of its rules is part of the product.

For your project: if your app calculates prices, doses, eligibility or anything else people rely on, agree the source of the rules at the start, keep it in one place in the code, and cover it with tests. Testing iOS apps with Swift Testing shows how to test rules like these with a table of known cases.

Decision 6: be honest about status

The apps page shows each app’s status plainly: live, available, coming soon, in production, in testing. Tipple Units, +StromaNotes and AiCuttr aren’t presented as finished, because they aren’t.

For your project: the same honesty helps during a build. Regular TestFlight builds you can install, with a clear note of what works and what doesn’t yet, are better than a polished demo that hides the gaps.

Decision 7: review your own work in public

I published a full technical review of MetricEdition’s code, followed by an article of proposed changes, Enhancing the MetricEdition app. The review is candid: the app lived in a single SwiftUI view, used a one-second Combine timer, had minimal accessibility support and was English only. The proposed changes split the code into smaller views, move timing to TimelineView, add VoiceOver and Dynamic Type support, and prepare it for localisation.

Small apps often start as one file, and that’s a reasonable way to prove an idea. The skill is knowing when to restructure, and doing it before the next feature makes it harder.

For your project: ask any developer how they review and improve existing code. An app that is never revisited only gets harder to change. The maintenance guide covers what ongoing care involves.

Decision 8: the brand and the web around the app

StromaScape is a brand as well as an app. Alongside the watchOS app on the App Store, there are Apple Watch faces made in the Clockology app, with the website stromascape.com as the shop window, and many faces released in limited runs capped at the first 30 downloads. In 2023 I also built an early app version of the site with Expo and React Native. The full story is on the StromaScape project page.

For your project: an app rarely stands alone. Plan the website, the App Store page and how people will find the app alongside the build, not after it.

What this means if you’re planning an app

None of these decisions is specific to watch faces or clocks. They apply to a booking app, a field-service tool or a customer loyalty app just as well:

1. One clear job per app or per version.
2. Build for the moment and the device where it’s used.
3. Add a server, accounts and integrations only when the job needs them.
4. Treat people’s attention as something to spend carefully.
5. Use trusted sources for anything people act on, and test those rules.
6. Be honest about what’s finished.
7. Review and restructure code before it becomes expensive to change.
8. Plan the web presence and launch alongside the app.

How these decisions translate to client apps

The same choices look different in a business setting, but the reasoning carries over:

Key takeaways

• Small, focused apps are easier to finish, cheaper to maintain and clearer for users.
• Starting on the device where the moment happens, often the watch, shapes better apps.
• Avoiding a server where possible removes running costs and privacy obligations.
• Honest status and candid code review are habits that keep projects healthy.
• The same scoping decisions apply to client apps of any kind.

If you’d like to apply this approach to your own idea, whether it’s for iPhone, Apple Watch or Mac, tell me what you have in mind.

Written by Lee Johnson. Published 30 October 2026.