iOS test build checklist for 2026
· 7 min read
Most failed iOS test rounds do not fail because of a bug in the app. They fail before anyone opens it: the build will not install, opens to a Developer Mode alert, crashes the first time it asks for the camera, or stops working halfway through the test week because a profile expired. Each of these is cheap to catch at your desk and expensive to catch through a tester's screenshot.
This is the checklist we would run on every iOS test build in 2026, in the order the problems tend to appear. It assumes you share builds outside TestFlight, as an Ad Hoc, Development or Enterprise .ipa, but most of it applies to any test build.
The checklist at a glance
| Check | Why it matters | Where to look |
|---|---|---|
| Export method | App Store builds cannot install from a link | Distribution type in the IPA inspector |
| Devices in the profile | Ad Hoc and Development builds install only on listed UDIDs | UDID list in the IPA inspector |
| Profile and certificate expiry | Expired builds stop installing and opening | Expiry and days left |
| Developer Mode | Required for Development and Ad Hoc builds on iOS 16 and later | Tester's Settings |
| Minimum iOS and device family | Testers on older iOS or on iPad may be excluded | Minimum iOS, device family |
| Usage descriptions and entitlements | Missing strings crash, missing entitlements block installs | Usage keys, entitlements, extensions |
| SDK and privacy manifest | The store build will be checked for both | SDK, Xcode, privacy manifest |
| Release notes and link settings | Testers need to know what to test | Your upload |
Almost every row can be checked in one place: the free IPA inspector, which reads the .ipa in your browser without uploading it.
1. Export with the right method
In Xcode's Distribute App dialog, Release Testing is the current name for Ad Hoc and Debugging is a development export. In an export options plist, the matching method values are release-testing and debugging; the older ad-hoc name is deprecated in recent Xcode versions. An App Store Connect export is for TestFlight and the App Store only and will not install from a link. Enterprise exports are only for members of the Apple Developer Enterprise Program and only for internal use.
2. Every tester's device is in the profile
For Ad Hoc and Development builds, the profile inside the build lists the allowed devices. A device registered after the profile was generated is not in it until you edit the profile and export again. Search the inspector's UDID list for each new tester before you send the link. New testers can read their UDID with the free UDID finder.
Remember the limit: Apple allows 100 registered devices per product family (iPhone, iPad and so on) per membership year, disabling a device does not free its slot, and slots come back only when you remove devices at the start of a new membership year. The full routine is in register devices for Ad Hoc builds.
3. The profile will outlive the test round
Ad Hoc profiles and distribution certificates are valid for about a year. When the profile expires, the build stops installing and apps already installed from it stop opening. A profile that references a revoked certificate becomes invalid too.
The inspector shows the expiry date and days left. If the number is smaller than your test round, regenerate the profile now rather than in the middle of user acceptance testing. If a certificate was lost or revoked recently, read lost or revoked iOS distribution certificate before you rebuild.
If you test the store build through TestFlight as well, keep in mind that TestFlight builds expire 90 days after upload.
4. Testers know about Developer Mode
Since iOS 16, Development and Ad Hoc builds do not open until the tester turns on Developer Mode under Settings, Privacy and Security, restarts the phone and confirms. Enterprise, TestFlight and App Store installs do not need it. Put one line about it in the message that goes with the link, and point first time testers to how to enable Developer Mode on iPhone. It saves the most common "the app won't open" reply.
5. Minimum iOS and device family match your testers
Check the minimum iOS version and device family in the inspector against the phones your testers actually use. A deployment target that was raised quietly in a dependency update can lock out the one tester still on an older iOS version, and an iPhone only build installs on an iPad only in compatibility mode, which is not what an iPad tester should be judging.
6. Usage descriptions, entitlements and extensions
- Usage descriptions: if the app asks for the camera, location, photos, contacts, Bluetooth or similar, the matching
NS...UsageDescriptionkey must be in Info.plist. Without it, iOS terminates the app when it touches that resource, which looks like a crash to the tester. The inspector lists every usage description key with its text, so you can also proofread what testers will see. - Entitlements: every capability the app claims, such as push notifications, App Groups or associated domains, must be in the profile. A mismatch usually blocks the install with "integrity could not be verified".
- Push environment: Ad Hoc builds use the production APNs environment. If your backend sends test pushes to the sandbox, Ad Hoc testers will not receive them.
- Extensions: widgets, share extensions and notification extensions each have their own profile. One stale extension profile is enough to stop the install.
Each of these, with how to confirm and fix it, is in iOS code signing errors that block test installs.
7. SDK, Xcode and privacy manifest
A test build is the cheapest place to find out that the store build will be refused, so test what you will ship:
- SDK: since April 28, 2026, App Store Connect accepts only uploads built with Xcode 26 or later using the iOS 26 SDK. The SDK does not affect whether an Ad Hoc build installs, but a test build made with an older Xcode is not the build you will submit.
- Moving to Xcode 27: Apple's iOS 27 release notes state that apps built with the latest SDK must adopt the UIKit scene based life cycle or they fail to launch. If your app still relies on the app delegate alone, a test build made with the iOS 27 SDK is where you will see it. Apple's technote TN3187 covers the migration.
- Privacy manifest: apps and listed third party SDKs need a
PrivacyInfo.xcprivacyfile, and uses of required reason APIs must be declared. Missing declarations come back from App Store Connect as ITMS-91053 and ITMS-91061 issues. They do not block an Ad Hoc install, which is exactly why they are easy to miss until upload day.
The inspector shows the SDK, Xcode version and whether a privacy manifest is present, and it runs the same store readiness rules that AppForShare applies to uploaded account builds: SDK version, privacy manifest and required reason APIs, profile expiry and more. It is guidance to fix things early, not a promise of approval.
8. Release notes and link settings
Testers who do not know what changed test whatever they open first. Write two or three lines: what is new, what to focus on, known issues. Then decide who should be able to open the link. A password protected link is enough for a small group or a client.
Running the checklist with AppForShare
The IPA inspector covers the file checks for free with no account. When the build passes, upload it to AppForShare to get an install link and QR code that testers open in Safari. Every build in an account gets the store readiness check, and "what changed" compares it with the previous build of the same app: version, minimum OS, permissions, SDK, frameworks and provisioned devices. The Free plan includes password protected links that last 7 days. Pro at $12 a month adds release notes on the install page, CI uploads from the CLI and links that stay live while subscribed; Team at $39 a month adds private projects for invited testers. Details are on the pricing page, or create a free account and run your next build through it.
