iOS App Testing Checklist for Indie Developers

Use this checklist before you submit a build to App Review, and again after the app is live. Most items need only Xcode, the Simulator and one iPhone. Copy the checklist into your task tracker. Mark each item when you complete it.

Apple says that, on average, over 40% of unresolved review issues relate to guideline 2.1, App Completeness. This guideline covers crashes, placeholder content and incomplete information. A checklist finds most of these issues, so it is worth the time.

Before you start

Test the build that you will release. Install it through TestFlight, not only from Xcode, so that you see the release configuration.
Delete the app from your test iPhone first, so that you start as a new user.
In the Simulator, select Device, then Erase All Content and Settings. This gives you a clean device with no saved permissions or data.
Write down each problem when you find it. Fix the problems after the full pass, not during it.

First run and onboarding

Do a clean install and go from launch to the first useful screen. Write down each step that feels slow or unclear.
Check that a user can complete every onboarding screen. Check that Back and Skip go where you expect.
Force-quit the app in the middle of onboarding, then open it again. You should not get stuck or lose data.
Launch the app for the first time with no network. The app should explain the problem. It should not show a blank screen.
Look at every empty state: no items, no history, no search results. Each empty state should tell the user what to do next.
If the app has accounts, sign up, sign out and sign in. Then reset the password and sign in on a second device.
Ask a person who has never seen the app to complete onboarding, and watch them. You know your app too well to test your own onboarding like a new user. Our guide on how many testers you need explains why five people per round is enough.

Devices, screen sizes and iOS versions

Run the app in the Simulator on the smallest and the largest iPhone that you support.
If you release for iPad, test at least one iPad size. If your app supports multitasking, also test narrow and wide window sizes.
Install a Simulator runtime for the oldest iOS version in your deployment target. Run the main flows on it.
Test on at least one real iPhone. Apple asks you to test on devices running the latest software before you submit. A real device also shows you the true performance and the real network behavior. It also shows how touch targets feel under a thumb.
On the smallest screen, open every form. Check that the keyboard does not cover the field or the submit button.
Check that no content is under the notch, the Dynamic Island or the home indicator.
If you support landscape, rotate the device on every main screen.

Dynamic Type, Dark Mode and VoiceOver

When the app runs from Xcode, use Environment Overrides in the debug bar. With them, you can change the appearance and the text size without changing the device settings. Apple shows the text size override in Get started with Dynamic Type.
Set the largest accessibility text size. Look for cut-off labels, overlapping text and buttons that move off the screen with no way to scroll.
Switch to Dark Mode and look at every screen. Look for hard-coded colors, images with white backgrounds and text that you cannot read.
Add VoiceOver to the Accessibility Shortcut. Then you can turn it on and off with a triple-click. Complete your main flow with VoiceOver on. VoiceOver should read a clear name for every button.
Run an audit in Accessibility Inspector (Xcode, then Open Developer Tool). The audit finds clipped text, elements without labels and low color contrast.

Network loss and slow network

Turn on Airplane Mode at three points: before launch, during a request and during an upload.
Use Network Link Conditioner to test a slow connection. Apple explains this tool and the related Xcode tools in Adapt to changing network conditions.
Check that no spinner runs forever. Every request should end with content or with a clear error and a way to retry.
Double-tap every submit button on a slow network. You should not get duplicate posts or double charges.
Make sure that the text the user typed is still there after a request fails.
Guideline 2.5.5 requires apps to work on IPv6-only networks. Do not use hard-coded IPv4 addresses in your networking code.

Permission prompts

Read every purpose string. Apple wants each string to explain clearly and completely why the app needs the data. Unclear requests are one of the common review issues.
Show each prompt after a screen that explains why you ask. Do not show it at first launch.
Deny every permission once. The app should still work, with an alternative where possible. Guideline 5.1.1 gives an example: let people type an address when they decline Location.
After you deny a permission, turn it on in the Settings app and return to the app. The feature should start to work without a reinstall.
Turn the permission off again in Settings and return to the app. The app should handle the missing permission without errors or out-of-date data.
For Photos, test the limited access option, where the user selects only some photos.
Deny notifications. Check that each feature that depends on reminders tells the user what is missing.

Interruptions

Receive a phone call or a FaceTime call during an important flow. Examples are a purchase, a recording or a long form.
Send the app to the background during a task. Wait a few minutes, then return. Check that the app keeps its state.
Open several heavy apps, then return to your app. If the system closed your app, the app should restore the user's place.
Lock the screen during a long operation, then unlock it.
Open Notification Center and Control Center during animations and video.
Turn on Low Power Mode and run the main flows again.
If the app plays audio, disconnect the headphones while it plays. Also start audio in another app while your app plays.

In-app purchases and subscriptions

Use StoreKit Testing in Xcode with a StoreKit configuration file for fast local tests. You can also test failed transactions. StoreKit Testing needs no connection to App Store servers.
Then test in the sandbox environment with a Sandbox Apple Account from App Store Connect. TestFlight builds always use the sandbox. In the sandbox settings, you can make subscription renewals faster, turn on interrupted purchases and clear the purchase history.
Cancel on the payment sheet. The app should return to a normal state, and no spinner should stay on the screen.
Let a test subscription expire. Paid features should lock, and the paywall should appear again.
Test restore: buy, delete the app, install it again, and check that the purchase comes back. Then do the same test on a second device. Guideline 3.1.1 asks for a restore mechanism for restorable purchases. Apple's StoreKit docs suggest a Restore Purchases button.
Check that every price on the screen comes from the store and not from a hard-coded string.

Localization, if you ship more than one language

In Xcode, open Product, Scheme, Edit Scheme, then Run, then Options. Set App Language and App Region. Apple describes these steps in Testing localizations when running your app.
Try the double-length and right-to-left pseudolanguages from the same App Language menu. They show truncation and layout problems before you have real translations.
Check dates, numbers and currencies in each region that you support.
Check plural strings with 0, 1, 2 and 5 items.
Look for strings that you forgot to translate, including alerts and errors.
Make sure that the App Store metadata and screenshots exist for each language.

Crash reporting

Learn where your crash reports go. The Crashes organizer in Xcode shows reports from TestFlight and the App Store. TestFlight testers share crash reports automatically. App Store users share them only if they share diagnostics.
Include symbol information when you upload a build. Then crash reports show function names that you can read.
If you use a third-party crash reporter, cause a test crash in a TestFlight build. Make sure that the report arrives. When you run the app from Xcode, the debugger catches the crash, so detach the debugger first.
Some problems never appear in the Crashes organizer, for example watchdog events from a slow launch and high memory use. Check the launch time and the memory use on your oldest supported device.

Common App Review rejection points

Before each new app, read Apple's Avoiding common issues list and the App Review Guidelines. These items cause the most problems for small teams:

Demo account. If features need sign-in, give a working demo username and password. Put them in the App Review Information section of App Store Connect. Keep your backend on during review (guideline 2.1).
No placeholder content. Remove test text, lorem ipsum and unfinished screens.
Working links. Every link must work. All apps need a support link with current contact information. All apps also need a privacy policy link.
Privacy policy. Link it in App Store Connect and inside the app, in a place where it is easy to find (guideline 5.1.1).
App privacy details. Answer the privacy questions in App Store Connect. Include the data that third-party SDKs collect. Apple requires these answers for new apps and updates.
Account deletion. If users can create an account in the app, they must be able to start account deletion inside the app. Deactivation alone is not enough.
Login options. If you offer a third-party or social login for the main account, read guideline 4.8. You may also need to offer an equivalent login option that focuses on privacy.
Accurate metadata. Screenshots should show the app in use, not only a splash or login screen. They must match what the app does (guideline 2.3).
Review notes. Describe new features in the notes for App Review (guideline 2.3.1). If the reviewer cannot find an in-app purchase in the app, explain the reason in the notes (guideline 2.1).

After launch: keep testing

Approval is not the end of testing. Real users find problems that no checklist covers.

Watch new users use the live app. On Raizy, another indie iOS developer installs your app from the App Store on their own iPhone and uses it. Then the tester sends a short silent screen recording or a screenshot with written notes. A moderator checks every feedback session. Each feedback session costs 1 credit, and you earn credits when you test the apps of other developers. Raizy works only for apps that are live on the App Store.
Check crash logs. Open the Crashes organizer in the first days after release and after every update. Fix the crashes that affect the most users first.
Watch App Store reviews. Read them in App Store Connect and reply to bug reports. The customer gets a notification and can update the review.
Repeat a short version of this list for every update: first run, purchase, restore, offline launch, and the flow you changed.