TestFlight allows Unity developers to distribute iOS builds to testers before releasing a game publicly on the Apple App Store.
Testing through TestFlight is an important step because it allows you to test the production-style build on real devices and collect feedback before submitting the final version for public release.
This guide covers a practical TestFlight workflow for Unity games.
TestFlight is Apple's testing platform for distributing pre-release versions of iOS applications.
It can be used to test:
- Gameplay
- Performance
- Crashes
- UI behavior
- Touch controls
- Ads
- In-app purchases
- Login systems
- Device compatibility
Testing through TestFlight helps identify problems that may not appear during local development.
Before preparing a TestFlight build, verify that your Unity project is configured correctly.
Check:
- Bundle Identifier
- Version number
- Build number
- Signing configuration
- Required permissions
- App capabilities
- Third-party SDK configuration
Also test the game locally on a physical iPhone or iPad before uploading.
After Unity generates the Xcode project and you complete the required configuration, create an archive using Xcode.
Before archiving, verify:
- Release configuration is selected
- Correct Apple Developer team is selected
- Bundle Identifier is correct
- Version number is correct
- Build number is updated
- Signing is configured correctly
After creating the archive, validate the build and upload it through the available Apple distribution workflow.
Internal testing is useful for developers and team members who need to test a build quickly.
Use internal testing to check:
- Application installation
- Game startup
- Core gameplay
- Save systems
- Ads
- In-app purchases
- Login functionality
- Major crashes
Internal testers should test the important features before the build is shared with a wider audience.
External testing allows you to share the application with a larger group of testers.
This can help identify:
- Device-specific issues
- Performance problems
- Gameplay bugs
- UI problems
- Unexpected crashes
- Network issues
- Monetization problems
Depending on the current Apple workflow and account configuration, external testing may involve additional review requirements before testers can access the build.
Allow enough time for this process before planning your public release.
A practical workflow for Unity developers can look like this:
Unity Development
↓
Local Device Testing
↓
Generate Xcode Project
↓
Configure Signing
↓
Create Archive
↓
Upload Build
↓
Internal Testing
↓
Fix Critical Issues
↓
External Testing
↓
Collect Feedback
↓
Final Release Build
↓
App Store Submission
The exact process may vary depending on your team and application requirements.
Do not test your Unity game on only one iPhone model.
Try to test on different devices when possible.
Review:
- Screen sizes
- Device performance
- Touch input
- UI scaling
- Device orientation
- Loading times
- Memory usage
- Battery usage
- Device temperature
Older devices may reveal performance or compatibility issues that newer devices do not.
Before your public release, test all monetization systems.
This may include:
- Rewarded ads
- Interstitial ads
- Banner ads
- In-app purchases
- Restore purchases
- Subscription features, if applicable
Make sure the complete user flow works correctly.
For additional guidance, see:
If your game already has an existing version, test the update process.
Verify:
- Bundle Identifier remains unchanged
- Existing save data behaves correctly
- New features work correctly
- Previous users can update successfully
- Version and build numbers are configured correctly
Testing only a fresh installation may not reveal problems affecting existing users.
Give testers clear instructions about what you want them to test.
Ask them to report:
- Device model
- iOS version
- Steps that caused the problem
- Screenshots or screen recordings
- Crash details
- Performance problems
- Monetization issues
Organized feedback makes it easier to reproduce problems and fix them before release.
Before preparing your final App Store submission, confirm:
- The Unity project has been tested on a physical device
- Bundle Identifier is correct
- Version number is correct
- Build number has been updated
- Release signing is configured
- The Xcode archive was created successfully
- The build was uploaded successfully
- Internal testing has been completed
- Core gameplay has been tested
- UI and touch controls have been tested
- Ads have been tested
- In-app purchases have been tested
- Login systems have been tested, if applicable
- External testing has been completed when needed
- Tester feedback has been reviewed
- Critical bugs and crashes have been fixed
- The final release build has been tested
Each new build should use an appropriate build number progression.
Before uploading another build, verify that the build number has been updated correctly.
Signing issues may prevent the archive from being created or uploaded.
Review:
- Apple Developer team
- Bundle Identifier
- Certificates
- Provisioning configuration
For more information, see:
Certificates and Provisioning Profiles
A build that works during development may still fail on a tester's device.
Collect:
- Device model
- iOS version
- Steps to reproduce the crash
Then test and fix the issue before preparing another build.
Always test purchases and advertising in the appropriate testing environment.
Do not wait until after the public launch to verify monetization.
After completing TestFlight testing, continue with:
For a complete comparison between Android and iOS publishing:
Unity Android vs iOS Publishing: Key Differences Every Developer Must Know
For developers preparing Unity projects for customization and publishing: