The iOS app MVP checklist: what to build first, and what to leave out

Step 1: write the one-sentence promise

Before any features, write one sentence: “[Who] can [do what] so that [outcome].” For example: “Members of a climbing wall can book a session from their phone in under a minute, so they stop ringing the front desk.”

If you can’t write it, the idea needs more thought before it needs an app. If you can, it becomes the test for every feature: does this help keep that promise?

Step 2: map the core journey

List the steps someone takes to get the promised outcome, from opening the app for the first time to getting value. For the climbing wall:

1. Open the app and see available sessions.
2. Sign in or create an account.
3. Choose a session and book it.
4. Pay, or confirm that it’s covered by membership.
5. Get a confirmation, and a reminder before the session.
6. Cancel if plans change.

That’s the MVP. Everything else is a candidate for version two.

Step 3: sort the feature list

Take every feature anyone has suggested and put it in one of three columns:

• Must have: without it, the core journey doesn’t work, or the app can’t legally or practically launch.
• Should have soon: valuable, but people can get the core outcome without it. Plan it for the first updates.
• Later, maybe: nice ideas that need evidence before they earn a place.

Be strict. Typical “later” items in a first version: social features, favourites and lists, in-app chat, detailed profiles, multiple languages beyond your launch market, an iPad-optimised layout, an Apple Watch app, widgets, gamification and complex settings screens.

Each of these may be right eventually. None should delay finding out whether people want the core journey.

The checklist

Product

• One-sentence promise written and agreed.
• Core journey mapped, with every screen and its states: empty, loading, error, offline.
• Feature list sorted into must, should and later.
• One or two measures of success chosen, such as bookings per week or repeat use after a month.
• A way to hear from users: in-app feedback, a support email, short interviews.

Design

• Uses Apple’s standard components and navigation where possible; they’re cheaper to build and familiar to users.
• Works with larger text sizes, VoiceOver and dark mode for the core journey (accessibility guide).
• Error messages say what happened and what to do next, in plain English.
• Onboarding is as short as possible; ideally people see value before being asked to sign up.

Technical

• Platform decision made: native iOS, cross-platform or web (how to decide).
• Minimum iOS version chosen, with a reason.
• Backend approach chosen: none, a managed service or a custom API.
• Analytics limited to what answers your success measures, and privacy-respecting.
• Crash reporting in place before the first external beta.
• Automated tests for the business rules in the core journey (testing guide).
• Source code in a repository you own.

Apple requirements that can’t be cut

These aren’t optional, even for a first version:

• Apple Developer Program membership in your own name or your organisation’s (launch process).
• A privacy policy URL and a support URL, both working. Apple’s App Review page says a link to user support and a link to your privacy policy are required for all apps.
• Clear purpose strings for every permission the app requests.
• A privacy manifest declaring required-reason APIs, and App Privacy details in App Store Connect that match (privacy guide).
• If people can create an account, a way to delete it from inside the app, per Apple’s account deletion guidance.
• If you offer third-party sign-in, check guideline 4.8 of the App Review Guidelines for the equivalent login option it requires.
• If you sell digital content or features inside the app, In-App Purchase is generally required (guideline 3.1.1); physical goods and services aren’t covered by this.
• No placeholder content, and a demo account for the reviewer if sign-in is needed.

Launch

• Internal and external TestFlight rounds completed, with fixes.
• Product page ready: name, subtitle, keywords, description, screenshots, age rating.
• Release option chosen: manual or scheduled for a planned launch.
• A plan for the first month: who watches crashes and reviews, and when the first update ships.

Common ways MVPs go wrong

Too big. The “minimum” grows as stakeholders add their must-haves, and launch slips by months. Protect the one-sentence promise.

Too small to be useful. An MVP isn’t a broken app. The core journey must be complete and pleasant, or you’ll learn that people dislike a half-built app, which you already knew.

No way to learn. If you don’t decide in advance what success looks like and how you’ll measure it, you’ll finish the MVP with opinions instead of evidence.

Skipping the boring requirements. Privacy, account deletion and support links are quick to do at the start and stressful to discover during review.

Building the admin side first. Internal tools, dashboards and content management can often be a spreadsheet or a managed service’s dashboard for the first few months.

After the MVP

Once real people are using the app, look at what they do rather than what they say they’d do. Check your success measures, read every piece of feedback, and watch where people drop out of the core journey. Then pick the next most valuable thing from the “should have” column, or something new that users have shown you need.

The cost and scoping guide explains how features translate into effort, and the maintenance guide explains what to budget for after launch.

A worked example: sorting the climbing wall’s ideas

Here’s how the feature list for the made-up climbing wall app might be sorted:

The result is an app that does one thing completely. It can launch sooner, and the first months of real bookings will show which of the “should have” items matter most.

Measuring an MVP without collecting more than you need

You need evidence, but not surveillance. Count the events that answer your success measures, such as “booking completed” or “cancellation made”, without tying them to identifiable people unless there’s a reason to. Privacy-respecting analytics, crash reports and a short in-app question (“Was this easy?”) usually tell you enough. Collecting less also keeps your App Store privacy details short and your privacy policy simple, which helps people trust a new app.

Key takeaways

• Write a one-sentence promise and use it to judge every feature.
• The MVP is the complete core journey and nothing more, built properly.
• Sort ideas into must, should and later, and be strict.
• Apple’s requirements, such as privacy details, support links and account deletion, are never optional.
• Decide how you’ll measure success before you launch, so version two is based on evidence.

If you’d like help turning an idea into a tight, buildable first version, send me your one-sentence promise and a little about who it’s for. I’ll come back with questions and a suggested scope.

Written by Lee Johnson. Published 30 October 2026.