A mobile app is the only software product you build that a third party can remove from distribution. Apple and Google set the rules, change them on their own schedule, and enforce them with deadlines that do not move because your roadmap is full. That is the part most app project plans underestimate — not the build, but everything that comes after it.
It is also a genuinely different discipline from web development. You are shipping compiled software to devices you do not control, through a review process you cannot appeal quickly, to users who will not update unless you make them.
This guide covers the decisions that matter: whether you need an app at all, how to choose between native and cross-platform, what the stores actually require, the compliance deadlines that can quietly make your app invisible, and what maintaining it really costs. The platform requirements below link to primary documentation, because they change and second-hand summaries go stale quickly.
Do you actually need an app?
This question deserves an honest answer before any budget is committed, because a large share of apps are built to do something a good mobile website would have done better and more cheaply.
An app makes sense when at least one of these is true:
- People will use it repeatedly — daily or weekly, not once a year.
- It genuinely needs device capabilities: camera, GPS in the background, Bluetooth, offline operation, biometrics.
- Push notifications are core to the value, not a nice-to-have.
- Performance requirements exceed what a browser can deliver comfortably.
- The app itself is the product you sell, rather than a channel to something else.
It usually does not when:
- The core interaction is browsing, reading, or a one-off transaction.
- You need it primarily so the brand has an icon on the home screen.
- The same functionality already works fine in a mobile browser.
- You have no plan or budget for maintaining it after launch.
The last point is the one that quietly kills projects. An app is not a deliverable that finishes. It is a commitment to keep shipping updates as long as it is published, because the platforms will require it whether or not the product has changed.
Native or cross-platform
The perennial question, and one where the honest answer has shifted as cross-platform frameworks matured.
| Approach | What it means | Suits |
|---|---|---|
| Native | Separate codebases — Swift/SwiftUI for iOS, Kotlin for Android | Performance-critical apps, heavy device integration, platform-specific experiences |
| Cross-platform | One codebase producing both apps — React Native or Flutter | Most business apps, where the UI is shared and time to market matters |
| Progressive web app | A website with offline support and installability | Content and transactional products that don't need deep device access |
The performance argument against cross-platform is weaker than it used to be. React Native’s New Architecture — Fabric for rendering and TurboModules over a direct JavaScript interface, replacing the old asynchronous bridge — has been enabled by default in all projects since React Native 0.76. That closed much of the gap that the older bridge-based architecture created.
A caution on framework comparisons: much of what circulates online quotes version numbers and market-share figures that do not survive checking. Framework choice should turn on your team’s existing skills, your device-integration needs, and who will maintain the code in three years — not on a benchmark in a blog post.
What the app stores actually require
Both stores review submissions against published guidelines, and both reject apps routinely. The rejections that surprise teams are rarely technical.
- Incomplete functionality — placeholder content, broken links, or features that need credentials the reviewer wasn't given.
- Missing or inaccurate privacy disclosures.
- Payment rules: digital goods and subscriptions generally have to use the platform's billing, with specific exceptions.
- Insufficient value — apps that are essentially a repackaged website with no reason to exist as an app.
- Account deletion: if your app lets users create an account, it must also let them delete it from within the app.
- Permissions requested without a clear, user-visible justification.
The practical mitigation is boring and effective: submit a build that is genuinely complete, provide a working demo account in the review notes, and make sure every permission your app requests has an obvious reason a reviewer can see without being told.
The deadlines that can pull your app
This is the requirement most often missed by businesses who treat an app as a finished project, and it has real distribution consequences.
Google Play enforces a target API level requirement on an annual cycle. As of 31 August 2026, new apps and updates must target Android 16 (API level 36) or higher, and existing apps must target at least Android 15 (API level 35) to remain available to new users on current devices. Developers needing more time can request an extension to 1 November 2026.
The consequence of missing it is worth understanding precisely, because it is not a takedown. An app that falls behind stays installed for existing users, but becomes unavailable to new users on devices running newer versions of Android — Google Play simply tells them the app was made for an older version. Your app does not disappear; it quietly stops being installable by most of the market.
Apple operates equivalent requirements on its own schedule, requiring submissions to be built with recent SDKs. The structural point is the same on both platforms: an app that is not maintained does not stay still, it degrades.
Privacy disclosures and manifests
Both stores now require you to declare what data your app collects and why — Apple through privacy nutrition labels, Google through the Data safety section. These declarations are public, and they need to match what the app actually does, including what the third-party SDKs you have embedded do.
Apple went further with privacy manifests and required reason APIs. A small set of APIs can be misused to fingerprint devices, so developers must declare an approved reason for using them in a privacy manifest. Apple’s documentation sets out how these files work; the requirement applies both to your own code and to third-party SDKs you include, and commonly used SDKs additionally need privacy manifests and valid signatures.
The practical implication is that your dependencies are now a compliance surface, not just a technical one. Every analytics tool, crash reporter, advertising SDK, and convenience library you add carries disclosure obligations you inherit. Auditing what you actually need before adding it is cheaper than unpicking it later.
Distribution rules in the EU
The EU’s Digital Markets Act changed iOS app distribution in ways that remain in flux. Since 2024, Apple has made changes in the EU that allow apps to be distributed through alternative app marketplaces and directly from a developer’s website, alongside the App Store, with apps still going through a notarisation process for baseline platform integrity.
The commercial terms attached to these options have been revised repeatedly, including changes announced in 2026 following discussions with the European Commission. For that reason this guide does not quote specific commission rates: any figure published today has a meaningful chance of being wrong within months. Apple maintains a current summary of EU changes that is the only sensible place to check the terms that apply now.
For most businesses the practical takeaway is modest: alternative distribution exists in the EU, it carries its own obligations, and for the majority of apps the App Store and Google Play remain the route worth planning around.
Scoping a first release
App projects overrun for a specific reason: the review cycle punishes iteration. A web fix ships in minutes; an app fix ships after a build, a submission, a review, and then only to users who update. That makes getting the first release right more valuable than it is on the web.
A first release should include:
- The single job the app exists to do, done properly on both platforms.
- Authentication, and in-app account deletion if accounts exist.
- Crash reporting and basic analytics, so you learn what actually happens.
- A remote configuration or feature-flag mechanism, so you can turn something off without shipping a build.
- A forced-update path for the day a critical fix cannot wait for voluntary adoption.
- Accurate privacy disclosures and, on iOS, the required privacy manifests.
Those last two are the ones teams skip and later wish they had not. Without remote configuration, every small change is a full release cycle. Without a forced-update path, a serious bug lives on in the wild for as long as users decline to update.
Designing for two platforms
Shipping the identical interface on both platforms is a common mistake, and it reads as unfamiliar to users on at least one of them. The platforms have genuinely different conventions: navigation patterns, back-button behaviour, share sheets, date pickers, and typography all differ.
The workable approach is to keep your brand, layout, and content structure consistent while letting platform-native components handle the interactions users already have muscle memory for. Cross-platform frameworks support this — the shared codebase does not require an identical presentation.
Two other design realities worth planning for:
- Devices vary enormously in screen size, aspect ratio, and safe areas. Test on small phones, not just the newest flagship.
- Accessibility is a platform-level expectation. Dynamic type, sufficient contrast, screen-reader labels, and adequate touch targets are baseline, not enhancements.
Maintenance is the real cost
The build is the visible cost. The maintenance is the one that determines whether the app is still working in three years, and it is genuinely unavoidable rather than optional.
| Ongoing work | Why it is not optional |
|---|---|
| Target SDK and API level updates | Missing the annual deadline makes the app unavailable to new users on current devices |
| OS release compatibility | New iOS and Android versions ship yearly and routinely break things |
| Dependency and SDK updates | Security patches, and third-party libraries that stop being supported |
| Store policy changes | Privacy disclosures and platform rules change on the platforms' schedule |
| Certificate and provisioning renewals | Expired credentials block releases, sometimes at the worst moment |
| Crash monitoring and fixes | Device and OS combinations produce failures you cannot fully predict |
A useful planning assumption is that a published app needs meaningful engineering attention every year even if you add no new features at all. Budgeting for the build and not the upkeep is the most common financial mistake in mobile projects.
Getting through review and launching
Review is a process with predictable failure modes, and preparing for it saves weeks.
- Submit a complete build — not a demo with placeholder screens.
- Provide working test credentials and clear reviewer notes, including how to reach anything behind a login or paywall.
- Make sure every permission prompt has a clear purpose string explaining why you need it.
- Check that your privacy declarations match what the app and its SDKs actually collect.
- Prepare store listings properly: screenshots, description, and keywords are the entirety of your conversion surface.
- Plan the first update before launch, because there will be one.
On timelines, review duration varies and neither platform guarantees it. Build slack into launch plans rather than scheduling a campaign that depends on approval landing on a particular day.
Mistakes worth avoiding
- Building an app for something a mobile website already does well.
- Budgeting for the build with nothing allocated to annual platform maintenance.
- Missing the Google Play target API deadline, then wondering why installs from new users stopped.
- Shipping identical UI on both platforms and ignoring native conventions.
- Adding SDKs casually, then inheriting their privacy disclosure obligations.
- Launching without crash reporting, so you learn about failures from reviews.
- No remote configuration, making every trivial change a full release cycle.
- No forced-update mechanism, leaving a critical bug live for months.
- Choosing a framework from a comparison article rather than from your team's actual skills and needs.
Frequently asked questions
For most business apps, cross-platform is now a reasonable default. React Native's New Architecture — Fabric rendering and TurboModules over a direct JavaScript interface — has been the default since version 0.76 and closed much of the historic performance gap. Native still makes sense for performance-critical apps or deep platform integration. The decision should follow your requirements and your team's skills.
Final thoughts
The difference between an app that works for a business and one that becomes an expensive orphan is rarely the quality of the initial build. It is whether the organisation understood that publishing an app is an ongoing commitment on someone else’s terms.
Platform requirements change annually. Privacy obligations extend to every SDK you embed. Distribution rules in the EU are still moving. None of this is a reason to avoid building an app — it is a reason to budget for the whole life of one, and to be honest at the start about whether the product genuinely needs to be an app at all.
Get that decision right, scope a first release that does one job properly, and put the operational scaffolding in place before launch rather than after. The apps that stay useful are the ones built by teams who planned for year three, not just for launch day.
