A Guide to Having a Mobile App Built: Process, Cost and Common Mistakes
Most mobile app projects do not slip on the code — they slip on the steps before and after it. This guide walks through the whole process from start to finish.
Mobile is a different game from the web. There are two stores, two review processes, device variety, permissions, notifications and an update cycle. In this guide we walk through the whole process in order, for teams commissioning their first app.
Native or cross-platform?
Native development means writing two separate apps: Swift for iOS and Kotlin for Android. Cross-platform means shipping to both platforms from one codebase — today the most common option is React Native (together with Expo).
| Criterion | Native (Swift/Kotlin) | React Native + Expo |
|---|---|---|
| Development time | Roughly 1.7–2× | Reference |
| Cost | Clearly higher | Lower |
| Performance | Highest | Enough for most apps |
| Access to device features | Full | Broad; a bridge is needed in special cases |
| Heavy graphics / AR / games | The right choice | Not suitable |
| Update speed | Depends on store approval | Some updates can ship instantly |
In practice: for almost all content, e-commerce, booking, field operations, health tracking and education apps, React Native is the right choice. Native is preferred for heavy 3D graphics, real-time video processing or work very close to the hardware.
The process, start to finish
- Discovery (1 week): target audience, critical journey, platform decision, store requirements.
- Design (2–3 weeks): flows, screens, respecting the differences between iOS and Android, clickable prototype.
- Setup (1 week): project skeleton, data model, authentication, deployment pipeline, first install on test devices.
- Development (4–8 weeks): weekly builds; tested on real devices every week.
- Store preparation (1 week): icon, screenshots, description copy, privacy policy, data collection declaration.
- Review and release (2–7 days): App Store and Google Play review; a fix round if a rejection comes.
Decisions that blow the budget
- Supporting tablet and phone at the same time. That means two layouts, twice the design and twice the testing. Usually a v2 job.
- Offline mode. It sounds small; data synchronisation and conflict resolution can be the most expensive part of the project.
- In-app purchases. Subscription management, refund scenarios and store rules are a work item of their own.
- Adding notifications without a notification strategy. The technical setup is easy; designing what gets sent on which event is the real work.
- Supporting old devices. Reaching far back in OS versions multiplies the testing load.
Store rejection: the most common reasons
A significant share of first submissions get rejected; that is normal, and it is usually for these reasons: a missing privacy policy, a data collection declaration that does not match the app, no test account provided, empty or crashing screens, directing payment outside the store, and asking for permissions without giving a reason.
All of these can be closed off in advance. With the right preparation, getting approved on the first submission is not an exception — it is the expected outcome.
The basics of store visibility (ASO)
Being found is a separate job from being built. The fields that determine ranking in the App Store and Google Play are limited and largely fixed at release — so this belongs in the design phase, not at the end of development.
- App name: the most valuable field. Brand + your strongest keyword (“Name — What It Does”).
- Subtitle / short description: the second most valuable field; your second keyword cluster goes here.
- Keyword field (App Store only): 100 characters; do not repeat words, separate them with commas.
- Screenshots: the first two images decide most of the conversion. Use captioned promotional frames, not raw screen grabs.
- Ratings: the score affects both ranking and downloads. Ask for a rating inside the app at the right moment — after value has been felt.
Permissions, privacy and data protection
This is where store review gets stuck most often. Three rules close most of it off: ask for each permission at the moment it is needed, with its reason, declare everything you collect completely in the store form, and make the privacy policy link reachable both on the store page and inside the app.
On iOS, if you are going to do advertising tracking, App Tracking Transparency permission has to be requested separately, and tracking without asking for it is a direct rejection. If you process personal data of users in the EU, the GDPR requires a lawful basis and a clear privacy notice; in Türkiye, KVKK requires the same through its own disclosure and explicit consent flow inside the app.
After release
Once the app is out, three things get tracked: crash rate, first-week retention and store reviews. On top of that, a maintenance release is needed at least a few times a year to stay compatible with operating system updates — putting that in the budget from the start is the healthy approach.
How we run the mobile development process end to end is set out on our service page. If you would like a roadmap for your own app, write to us.
Frequently asked questions
How long does it take to have a mobile app built?
A mid-sized app built for iOS and Android from a single codebase typically ships in 8–14 weeks. That includes design, development, store preparation and the review process.
Should I choose React Native or native development?
For almost all content, e-commerce, booking, field operations and similar business apps, React Native delivers enough performance at a much lower cost. Native should be preferred for apps that need heavy 3D graphics, games or real-time video processing.
Why would my app be rejected from the App Store?
The most common reasons are a missing privacy policy, a data collection declaration that does not match the app, not giving the review team a test account, crashing or empty screens, and permission requests without a justification. All of these can be prevented with a pre-submission checklist.