Mobile App MVP: What to Build First, What to Skip, and What the App Stores Won't Let You Skip

A minimum viable product is the smallest version of an app that lets you learn whether people want it, using real behaviour rather than opinions. For a mobile app, that means something people can install from a store, use for the one task you are betting on, and return to. A clickable prototype is not an MVP, because it cannot tell you whether anyone comes back on day seven. A full product with ten features is not an MVP either, because when usage is low you will not know which of the ten failed.

The mobile version of this problem has one twist that web MVPs do not: two app stores sit between you and your users. Their review rules, testing requirements and quality thresholds decide part of your scope for you. The rest of this guide separates what you choose to cut from what you are not allowed to cut.

Start from the job, not the feature list. Write one sentence that names who the user is, the task they are trying to get done and the moment they would open your app. Then name one metric that proves the job is being done, such as the share of new users who complete the core task twice in their first week. Every proposed feature is then tested against a single question: does the core task fail without it?

Decide before launch what result would make you continue, change direction or stop, and write it down next to the metric. Teams that skip this step tend to read any number as encouraging. The cut list below is not a list of bad ideas; it is a list of ideas waiting for evidence from the first version.

Launch where your first users are. If you can name your first hundred users, ask them which phone they carry. If both platforms matter, a cross-platform framework lets one team ship both from one codebase; we compare the options in our React Native vs Flutter vs native guide. If the core job works in a browser, also read our PWA vs native app comparison before committing to the stores at all.

One practical note: Android release timing is less flexible for new developers than many teams expect, because of the closed testing rule described below. If you plan to launch on both platforms on the same day, the Android test has to start at least two weeks earlier.

Several requirements apply to every app, however small. Apple's App Review Guidelines say submissions should be final versions with placeholder text and temporary content removed, tested on a device, and accompanied by demo account details (with the back end turned on) if the app has a login. Guideline 4.2 adds that an app should offer features, content and UI that elevate it beyond a repackaged website, which rules out an MVP that is only a web view of an existing site.

Accounts carry the most hidden scope. Apple's guideline 5.1.1(v) says that if an app supports account creation, it must also offer account deletion within the app, and Apple's guidance states that only offering to deactivate an account is insufficient. Google Play requires an in-app path to delete the account and associated data, plus a web link where users can request deletion, entered in the Data safety form. If your app offers a third-party or social login as its main sign-in, Apple's guideline 4.8 generally requires an equivalent alternative login option as well.

Both stores give you a way to put the MVP in real hands before a public launch, and on Android it is mandatory for many new developers. Google Play requires personal developer accounts created after November 13, 2023 to run a closed test with at least 12 testers who have been opted in continuously for at least 14 days before applying for production access. Testers who leave before 14 days do not count. The requirement is written for personal accounts, but a closed test is worth running either way.

On iOS, TestFlight lets you invite up to 100 internal testers from your App Store Connect team and up to 10,000 external testers. The first build shared with external testers must pass App Review for TestFlight, so the demo account and guideline basics apply here too. Each build can be tested for up to 90 days.

Minimum does not mean unstable. Google Play states that an app's core vitals affect its visibility, and that if an app exceeds a bad behaviour threshold, Play may reduce its visibility and may show users a warning on the store listing. The thresholds are a user-perceived crash rate of 1.09% and a user-perceived ANR (app not responding) rate of 0.47% across devices, and 8% for either on a single phone model, assessed over the last 28 days.

For an MVP this has two consequences. Crash reporting is part of the minimum, not a later addition. And testing on a few real, older, lower-memory devices that your target users actually carry finds more problems than another round on the team's latest phones.

This is the list we use to scope a first version. It is short on purpose: anything not on it needs a reason tied to the core job.