The journey
In five chapters: idea, design, build, app store release and updates. The last one never really ends, and that's how it should be.
Before any screen there's a question: who opens the app, how often, and to do what. We pin down the core flow and what stays out of version one, because an app with everything in it never ships. If the idea still needs testing, we start with validation.
Wireframes, then a clickable prototype you try on a real phone, then the final interface with its design system. We follow iOS and Android conventions wherever people expect them: navigation, gestures, permission prompts. That's our product design and UX work.
We pick the technology to fit the product (the table further down explains how). App and backend are built together: sign-in, data, push notifications, in-app purchases, analytics. Every version goes through automated tests and a test build on the team's own phones.
Developer accounts, store listings, screenshots, privacy details, signed builds, review. Apple and Google check every app before it goes live, and preparing for their rules saves you rounds of rejection.
After launch the real data arrives: crashes, reviews, features nobody touches. We ship regular updates, keep up with new iOS and Android releases, and keep app and web in step, since with Capacitor they share one codebase.
Technology
It depends on what already exists and what the app has to do. If you already have a web app or a SaaS, Capacitor is often the shortest route; if the app lives on hardware and graphics, go native.
| Approach | How it works | Choose it when | Watch out for |
|---|---|---|---|
| Native | Two separate apps, Swift for iOS and Kotlin for Android, using Apple's and Google's own tools | Deep system features, graphics and performance pushed to the limit, augmented reality | Two codebases to build and maintain |
| React Native | JavaScript or TypeScript driving native interface components | Apps with a native feel and a team that already knows React | Native modules to write for less common features |
| Flutter | The Dart language and its own rendering engine, identical on every platform | Highly custom interfaces that must look the same everywhere | Little code shared with an existing website or web app |
| Capacitor | Your web app runs inside a native shell, with plugins for push, purchases and the camera | Products that already live on the web, like a SaaS: one codebase for web, iOS and Android | Complex animations and gestures need care; some features need plugins |
Athleex runs on Capacitor: the web platform and the iOS and Android apps share one codebase. The full story is in the Athleex case study.
App stores
With a developer account for each store, a complete listing and a signed build that passes review. The route is the same for every app; what changes are the details that get it rejected.
The Apple Developer Program and Google Play Console, registered to your company, so the app and its reviews stay yours.
Name, description, screenshots, category, age rating and the disclosure of what data the app collects.
Signed builds tested by real people: TestFlight on iOS, internal and closed testing on Google Play, which some accounts must complete before going live.
Apple and Google check content, payments, privacy and stability. If they reject, they cite the rule: you fix it and resubmit.
A manual or staged roll-out, then crash reports and reviews watched closely over the first days.
First-hand
Three lessons from the Athleex iOS app, each one learned from a real problem.
The problem
Apple rejected a version over its in-app purchase rules (App Review Guideline 3.1.1).
What we did
We added in-app purchases with StoreKit 2 and the version was approved. Decide how people pay inside the app before your first review.
The problem
Push notifications weren't arriving on iOS, for three causes independent of each other: configuration, permissions and delivery.
What we did
We checked them one at a time, because fixing one doesn't fix the others. We now test push cause by cause.
The problem
With iCloud Private Relay, a user's country can show up as somewhere else.
What we did
The currency shown has to be decided with judgement, not from the IP address alone: pricing is a product decision, not a technical detail.
Mostly it depends on how many platforms you need, how many phone features (push, payments, camera) and the backend behind it. We don't publish a price list: after a first meeting we give you an estimate against a written scope. The main cost drivers are covered in pricing and timelines.
If people will look for you in the app stores, or you need deep phone features, build an app. If the product is mostly used at work or on a laptop, a web app or PWA costs less and updates instantly.
Both produce iOS and Android apps from one codebase. React Native suits teams that know React or already have a React web product; Flutter suits highly custom interfaces that must look identical everywhere. If your product is already a web app, we look at Capacitor first.
We do, using your company's developer accounts, so the app, listings and reviews stay yours. We prepare the listing, screenshots and privacy details and see the review through to approval.
Yes, through Apple's and Google's in-app purchases. On iOS, Apple generally requires them for unlocking digital features or content inside the app: on Athleex we added them with StoreKit 2 after a rejected review. Make that call before you submit.
Mobile appsHow to build a mobile app: a founder's guide from idea to the app storesRead 
Mobile appsHow much does it cost to build an app? What drives the price, and what comes after launchRead 
Mobile appsReact Native vs Flutter vs Capacitor: choosing a cross-platform framework for your startupRead 
Mobile appsHow to publish an app on the App Store and Google Play: steps, review and lessons learnedRead We reply within one business day.
Let's talk