Mobile app development services: from idea to the App Store and Google Play, with code that stays yours.

We wrote this guide for businesses that want to offer a mobile app to their customers or team, are thinking of having an app built, or have an app that stalled halfway or can’t get through store review. We based store requirements and technical rules on the English documentation of Apple Developer and the Google Play Console Help Center; the sources are listed by number at the end of the page. We verified fees, testing requirements, SDK and API levels against the source as of October 2026. Our own field observations are marked separately under the heading “Expert note”.

Our mobile app work runs in three layers: choosing the right scope and technology, designing and building the app to fit each platform’s conventions, and testing and launching it in line with store requirements. The ten sections below explain how these layers work and what we check at each step, in that order.

What is mobile app development, and how does the process work?

Mobile app development is the process of defining, designing, coding, testing and publishing an app that runs on iOS and Android phones on the App Store and Google Play. On iOS, apps are distributed through Apple Developer Program membership; the App Store lets users discover and download apps in 175 regions, and Apple handles payment processing and hosting.¹ On Android, apps are published on Google Play through a Play Console account.⁷

We cover the app’s interface and user flow separately on our UX/UI design page; this page goes into building the app and getting it into the stores.

iOS and Android app development: native or cross-platform?

An app can be written in separate native code for each platform (Swift on iOS, Kotlin on Android) or with cross-platform tools that ship to both platforms from a single codebase. Flutter is an open-source framework for building natively compiled, multi-platform apps from a single codebase, and it compiles code to ARM or Intel machine code.¹¹ React Native is written in JavaScript and rendered with the platform’s native UI components; for new apps, starting with a framework such as Expo is recommended.¹²

We make the decision not by how popular a technology is, but by what the app will do and who will maintain it. If your company has an in-house software team, we favor the language and tools they know; if the app will be updated for years, the choice that makes maintenance easier is worth more than the one that speeds up the first build.

The cost difference between the two approaches shows up not only in the first build but in the years after. With native code, every new feature is written twice and tested twice; with cross-platform, a feature is written once, but native code is added when a platform-specific capability is needed, and the tool’s own updates have to be followed too. That’s why our proposal shows the first year’s maintenance load alongside the first version.

How do you define the scope of the first version?

The first version should do one job completely: the job that’s the reason a user opens the app. In a booking app, that’s making a booking; in a loyalty app, seeing and using points; in a field team app, receiving and closing a work order. Every screen outside that job delays the first version, adds to the testing load and adds one more feature to explain in store review.

Once the scope is in writing, we prepare the screens as a clickable prototype in Figma and try it with a few real users. A flow problem spotted in a prototype is fixed in hours; the same problem spotted after it’s been coded can cost weeks.

We also write down how we’ll measure the first version’s success together with the scope: how many people download the app and create an account, how many complete the core job, and how many come back to the app a week later. When these metrics are set from the start, in-app event tracking is built alongside development, and what works becomes clear beyond debate in the first weeks after launch.

Interface, accessibility and performance

iOS and Android users have different habits: the back gesture, where menus sit and system buttons vary by platform. Even when we use a cross-platform tool, we respect these differences so the app feels like a native app on each platform.

We treat accessibility not as a feature to add later but as part of development: we give buttons screen reader labels, follow the system text size setting and check color contrast. On performance, we measure launch time and how smoothly lists scroll on older and mid-range devices, and design from the start what the app shows the user when the connection drops.

We also decide at the design stage how the app looks on tablets, in dark mode and on different screen sizes. When these decisions come later, most screens have to be reworked; when they come first, the same components adapt to every size.

Backend, accounts and privacy

Most apps talk to a server: user accounts, bookings, orders or content are kept in a database and reach the app through an API. If you already have a website, an e-commerce platform or an ERP system, we connect the app so it uses the same data as those systems; keeping the same information separately in two places leads to inconsistencies over time.

We plan push notifications and deep links at this stage too. A notification is the most effective way to bring a user back to the app at the right moment, but sent too often, the user turns off notification permission or deletes the app. A deep link opens a user arriving from an email, a text message or your website straight to the relevant screen rather than the app’s home screen; it’s also what makes measuring campaigns possible.

Apple requires apps that support account creation to also offer account deletion within the app, and asks that users can use the app without logging in if its core functionality doesn’t depend on an account.⁴ Every app’s App Store product page carries a privacy label; this information also covers data collected by third-party code integrated into the app, and it’s required to submit new apps and updates.⁶ On Google Play, every developer must complete the Data safety form too; the form includes data collected by third-party libraries and SDKs in the app.¹⁰

TestFlight and Google Play closed testing

Before an app reaches the stores, it should be tried on real devices with real users. On iOS, TestFlight lets you invite up to 10,000 external users to beta builds using just their email address or a public link.¹ On Google Play, personal developer accounts created after November 13, 2023, must run a closed test with at least 12 testers opted in continuously for 14 days before publishing; once that’s met, you apply for production access.⁸

We try to choose testers from the app’s real audience: a few people from your team, loyal customers and acquaintances who use different devices. We collect feedback and crash reports from testing in a single list, and separate what must be fixed before launch from what can wait for the next version.

Developer accounts and store review

The Apple Developer Program annual fee is 99 US dollars; the price is shown in local currency by region.² To open a Google Play Console account, you must be 18 or over and pay a one-time registration fee of 25 US dollars; developer identity details are verified during signup.⁷ We open these accounts in your company’s name; the app, store listing and revenue sit in your account.

Apple reviews apps, updates and in-app purchases before they reach the App Store, and typically reviews at least 50% of submissions in less than 24 hours and 90% in less than 48 hours.³ The submitted build should be final, with placeholder text and empty links removed and the app tested on device, and if the app has a login, a demo account should be provided for review.⁴

Current technical requirements: SDK and API level

The stores require apps to be built with current development tools, and these requirements rise every year. Apps uploaded to Apple since April 28, 2026, must be built with Xcode 26 or later using the iOS 26 SDK.⁵ On Google Play, starting August 31, 2026, new apps and app updates must target Android 16 (API level 36); those who need more time can request an extension to November 1, 2026.⁹ Existing apps must target at least Android 15 (API level 35) to remain available to new users.⁹

After launch: maintenance, measurement and being found in the stores

The work doesn’t end once the app is live. Operating system updates, store requirements and new versions of the libraries you use mean the app has to be updated regularly. We track in-app events and crashes, and see from the data which screen users get stuck on and why they leave the app; we add fixes and new features to the release plan based on that data.

Rather than releasing new versions to everyone at once, we first offer them to a small group of users, and widen the rollout if the crash rate and feedback look normal. That way, if a bug appears, it can be fixed before every user is affected.

Being found in the stores is a separate job: the app’s name, subtitle, screenshots and reviews decide how many people see and download it in search. We prepare the first version of the store listing with this in mind before launch, and show the app’s core job in the first screenshot. We cover this work separately on our ASO consulting page.

How our mobile app development services work in the first 30 days

The job of the first 30 days isn’t writing code; it’s setting up scope, technology and accounts correctly and reaching a prototype tested with users. We work in this order:

1. Week 1 · Scope: the job the app will do, user groups and first-version screens are written down; existing systems are reviewed.
2. Week 2 · Technology and accounts: the native or cross-platform decision is made; Apple and Google developer accounts are opened in your company’s name.
3. Week 3 · Prototype: screens are prepared as a clickable prototype in Figma and tried with real users.
4. Week 4 · Plan: with fixes from the prototype, development cycles, the testing schedule and store preparation are planned together.

How to choose a mobile app development company

When you hire someone to build an app, the bigger question is not who writes the code but who keeps the app healthy once it’s live. There are three common models:

Whichever model you pick, compare proposals on the same points:

1. Account ownership: the Apple and Google developer accounts are opened in your company’s name, and the developer is added as a user. Taking over an app published under someone else’s account makes moving its store history and reviews harder.
2. Where the code lives: the source sits in a repository in your name and is current after every release, rather than being handed over at the end.
3. Written scope: first-version screens, connected systems and what is out of scope are listed one by one. “Everything included” usually means scope was never discussed.
4. Testing and store responsibility: it’s clear who runs TestFlight and Google Play closed testing and who prepares review notes and privacy disclosures.
5. Maintenance plan: operating systems and store rules change every year, so first-year maintenance appears as its own line in the proposal.
6. How deadlines are framed: a fixed launch date before scope is settled, or a “guaranteed store approval”, isn’t realistic; the store makes the review decision.

What drives mobile app development cost?

The cost of a mobile app comes from the scope of the first version plus the maintenance load after launch. These are the factors that move a proposal most:

Pricing usually has two parts: a project fee for the first version, tied to a written scope, and monthly maintenance after launch. We work out the scope together in the first meeting and then send a written proposal; Apple and Google developer account fees are separate from our fee and are paid directly to the stores from your company’s account.

Mobile app development pricing: starting prices and ranges

The lower end of each range is the starting price; excluding VAT. Scope is confirmed in a written proposal after the first meeting. The row marked “/ month” is monthly. As of October 2026.

If you’d like to work through your app idea together, pick a meeting day that suits you below; in the first meeting we clarify the job the app should do, its users and your existing systems.