Mobile

Building a Mobile App People Keep

7 min readAbsolute Foundry

A successful mobile app isn't the one that launches — it's the one still on the phone in week four. Most apps are deleted within days, so the real engineering problem isn't features; it's earning a place on a crowded home screen. We design backwards from retention.

When a founder pitches us an app, the first thing we pressure-test isn't the feature list — it's whether it deserves to be an app at all, and how it survives the first session.

01 Does it even need to be native?

The trade-off we weighedNative vs. cross-platform vs. a great mobile web app. Native (Swift/Kotlin) gives peak performance and platform feel at double the build cost. Cross-platform (React Native / Flutter) ships one codebase to both stores, fast — ideal for most products. And plenty of "apps" should just be a fast mobile web app or PWA with no store at all. We pick by what actually needs the phone: camera, push, offline, heavy interaction → cross-platform or native; everything else → web first. Don't pay the app tax for a website.

02 The first session decides everything

Retention is won or lost in the first 60 seconds. So we design the cold-start ruthlessly: get the user to the "aha" before we ask for anything. That means deferring sign-up and permissions until there's a reason, a sub-second perceived launch, and a first run that delivers one obvious win.

No sign-up wall before value — let them feel it first.
Ask for push/location only when the moment justifies it (and you'll actually get the yes).
Design empty states as onboarding, not dead ends.

03 Build the loop, then the features

Apps that stick have a core loop — a reason to return that compounds (a streak, a feed, a balance, a notification worth opening). We build that loop first and let features hang off it, rather than shipping a pile of screens with no gravity.

04 Shipping to the stores without the pain

App review, signing, TestFlight, staged rollout — this is where timelines quietly slip. We set up the release pipeline early, so submitting isn't a panic at the end. Push, crash reporting and analytics go in from day one, because you can't improve retention you can't see.

Where we'd landCross-platform unless the product truly needs native; a first session engineered for the "aha"; a core return loop before features; and a release + analytics pipeline set up from the start.

Key takeaways

Decide native vs cross-platform vs web by what genuinely needs the phone.
Win the first 60 seconds — value before sign-up and permissions.
Build the core return loop first; features hang off it.
Set up release, push and analytics early — retention needs visibility.

FAQ

React Native or native?

Cross-platform fits most products and ships faster. Reach for native when performance, deep platform features or heavy graphics demand it.

Do I need an app or a mobile web app?

If you don't need camera, push, offline or heavy interaction, a fast mobile web app or PWA may serve you better than the store overhead.

Can you design and build it?

Yes — product design through to build and release.

We build apps designed to survive the home screen.

Build my app