Why Ollim was built natively for iPhone and Apple Watch

When you build alone, choosing a platform is also choosing what you will not build yet.

The tempting answer is everything: every phone, every watch, every screen. It sounds inclusive and ambitious. In the first month of a product, it can also mean spreading one person's attention across several experiences before any of them feels complete.

I chose iPhone and Apple Watch for a simpler reason: I use them.

TL;DR

Ollim was built natively for iOS and watchOS to keep the first product focused and to put each training interaction on the device closest to the moment. The phone handles the wider view. The watch handles the seconds between sets. Native was a scope and context decision, not a claim that one platform is right for everyone.

Start with what you can observe

Using the product's devices every day gave me a direct feedback loop. I could notice whether a screen felt out of place, whether an interaction took too long, and whether something that looked fine at a desk still worked when I was standing beside a bench.

That does not make one person's experience representative of everyone. It does make the first questions concrete. I did not have to imagine how the phone and watch fit into my day before I could test them. They were already there.

For a solo developer, that proximity mattered. The first version needed fast, honest observation more than theoretical platform reach.

One ecosystem was a scope decision

Native development can sound like a technical preference. For Ollim, it was first a product- management decision.

Choosing one ecosystem meant I could spend the month on the full path: see the next session, open the workout, follow the target, log the set, wait through the rest timer, and review what happened. The alternative was to divide the same time among more platforms and risk building several thin paths.

Focus did not guarantee a good product. It made the surface area small enough to examine. When a set took too many taps to log, there was one interaction to fix. When the phone and watch disagreed, there was one shared workout experience to trace.

The constraint gave the work somewhere to go.

The phone and watch have different jobs

The iPhone is useful before and after the set. It has room for the session, the exercise list, the training history, and the progress view. It is where a wider decision can be understood.

During the set, that screen is often in the wrong place. The phone may be in a pocket, on the floor, or inside a bag. Taking it out, unlocking it, finding the session, and putting it away again is a small interruption repeated many times.

The Apple Watch changed the shape of the product. Ollim puts the target weight and repetitions on the wrist, lets you log the completed set there, and runs the rest timer before the next one. Heart rate is captured automatically while you train. The interaction is deliberately smaller because the moment is smaller: look, log, recover, continue.

Apple's workout-session APIs are designed for this context. An active workout session can continue on Apple Watch in the background, collect workout data, and return to view when the wrist is raised. That platform behavior is not decoration around Ollim. It is part of how the between-set experience can remain available without asking the phone to be present in your hand.

Native means accepting the constraints too

Building natively is not only gaining access to platform capabilities. It is accepting the shape of the devices.

The watch has a small screen, limited attention, a battery to respect, and a workout already in progress. It cannot be a reduced copy of every phone screen. The phone can explain more, but it can also tempt the product to show more than the next decision needs.

Permissions matter. Health data belongs behind the system's consent. Background workout behavior has rules. Communication between the devices can be interrupted. A native app still has to handle all of that clearly; using the platform does not remove the responsibility.

Those constraints helped separate the jobs. Planning and review can breathe on the phone. The live session on the watch stays close to the immediate action.

What this choice does not mean

This is not an argument that native software is automatically faster, better designed, or more thoughtful. A framework cannot make those decisions for you. It is also not a promise about which platform comes next.

It is the record of one early tradeoff: build deeply where I could test honestly, and let the phone and watch become different parts of one training loop.

If you are building a product across devices, start with the moment rather than the hardware list. Ask where the user is, what their hands are doing, and how much attention they can spare. Then give each screen only the job that belongs there.

Build for the moment, not just the screen.

Sources

• Workouts and activity rings, Apple Developer Documentation.
• Running workout sessions, Apple Developer Documentation.