AI & Trends Sep 22, 2026 · 2 min read

Shipping the same on-device app on iOS and Android without a cloud

Building an on-device app for both phone platforms means sharing the rules, rewriting the machine learning, and being honest about what genuinely differs.

Shipping the same on-device app on iOS and Android without a cloud

The usual way to get an app onto both phone platforms is to put the important part on a server and let two thin clients call it. That works, and it quietly makes every feature dependent on a network, an account, and somebody's ongoing hosting bill. If the app is supposed to run entirely on the device, you have to solve parity a different way.

The shared part is the rules, not the code

Start by separating the parts of a product that are genuinely universal from the parts that are platform work. The universal part is usually smaller than it feels and more important than it looks: the scoring rules, the state machine, the thresholds, the exact definition of what counts as a repetition or a valid entry.

That layer should be specified precisely enough that two implementations cannot drift. Not the same code necessarily, but the same rules, written down, with the same edge cases enumerated. Parity bugs almost never come from a button being three pixels off. They come from two platforms quietly disagreeing about a boundary condition nobody wrote down.

Everything above that layer is genuinely platform work, and pretending otherwise produces an app that feels foreign on both.

Platform-native machine learning is a constraint, not a portability problem

The interesting case is a feature built on device-side inference. Form Coach watches you through the camera, counts repetitions, and scores each one from joint angles, all locally. Both phone platforms can do that. Neither does it the same way.

So you do not port the model layer, you re-implement it against each platform's native pose estimation and then verify that both produce the same score for the same movement. The rules layer is what makes that checkable: if a squat scores differently on the two phones, one of them is wrong, and you have a written definition to settle it.

Parity is not two identical screenshots, it is two devices reaching the same answer about the same moment, using entirely different machinery to get there.

What genuinely differs

Some things should differ, and forcing them not to is a mistake. Navigation conventions, back-button behavior, share sheets, notification models, and permission flows all belong to their platform. Users notice imported conventions immediately and read them as sloppiness.

Hardware access differs too. Local network discovery, camera pipelines, and background permissions have different shapes, different prompts, and different failure modes on each side, and a remote-control app that talks straight to a TV on your home network runs into all three. The honest approach is to match the outcome and let the mechanism be native.

The reward for all this is an app that keeps working on a plane, in a basement gym, and after we stop paying for anything, on both platforms, free, with no subscriptions, ever.

On-device models are getting better faster than the gap between platforms is getting wider, which means this kind of build is getting easier, not harder. That is the direction we are betting on.

Form Coach runs on iPhone and Android; the rest of the catalog is on the apps index.

Recent posts

0 comments

No comments yet — be the first.

Leave a reply

Sign in with Google to join the conversation. We require a quick sign-in to keep comments spam-free.

Sign in with Google to comment