Sharing an IPA or APK over 200 MB with testers
· 7 min read
Test builds grow quietly. A game adds a level pack, a Flutter app picks up a few native SDKs, someone switches the CI job to a debug configuration, and one morning the upload fails because the file is over the limit of the tool you use. 200 MB is a common wall: it is the free upload limit on InstallOnAir as published on their site in November 2026, and many teams first meet it there. This article covers why builds get big, what you can cut without changing how the app behaves, and which tools take large files when cutting is not enough.
Why test builds get big
A test build is often much larger than what a user downloads from the App Store or Google Play. The stores slim the app per device; a file you share by link does not get that treatment. The usual reasons:
- Debug configuration. Debug builds keep symbols, skip code shrinking and often include extra tooling. A debug APK or a Development .ipa can be several times the size of a release build of the same code.
- Every architecture in one file. An Android APK built for all ABIs (arm64-v8a, armeabi-v7a, x86, x86_64) carries native libraries four times. A universal APK made from an .aab does the same, because it has to run on any phone.
- Every device variant on iOS. An .ipa exported without app thinning holds assets for every screen scale and device family.
- Assets. Uncompressed audio, video, large images, bundled fonts, offline maps and machine learning models are usually the biggest single item.
- Cross platform runtimes. Flutter, React Native and Unity apps ship an engine or runtime on top of your code. That is normal, but it adds a fixed amount to every build.
To see what is actually inside, open the file in the free IPA inspector or APK analyzer. Both read the file in your browser, so nothing is uploaded and there is no size limit. They list architectures, embedded frameworks, native libraries and whether the build is debuggable.
Cuts that do not change behavior
The goal of a test build is to behave like the release. These cuts keep that true while making the file smaller.
Android
- Test a release variant, not debug. Build the release variant (or a dedicated beta flavor) signed with your upload key. Turn on R8 code shrinking and resource shrinking as you would for the store, so testers also catch shrinking bugs early.
- Split by ABI. Gradle's
splits { abi { ... } }block, orflutter build apk --split-per-abi, makes one APK per architecture. Most real phones today only need the arm64-v8a file. Share that one, and keep the others for older or emulator testers. - Drop x86 from device builds. If nobody tests on an emulator, there is no reason to ship x86 libraries to phones.
iOS
- Use the right export method. Export Ad Hoc or Development for testing, from a Release configuration where you can.
- Consider app thinning on export. Xcode's export options can produce thinned variants per device type. That gives smaller files, but one per device family, so it suits a fixed group of test phones better than an open link.
- Keep dSYM files out of the shared file. Symbols belong in your crash tool, not in the .ipa you send testers.
Both platforms
- Compress assets the way the release does. Use the same image and audio formats as the store build.
- Download heavy content after install. If the release fetches levels, maps or models on first launch, the test build should too. Testers then also check that flow.
- Watch the trend. A sudden jump in size often means a debug flag or a duplicate library slipped in. On AppForShare, the "what changed" view compares each build with the previous one of the same app, including size, frameworks and SDK, on every account plan.
Upload limits by tool
When the build is as small as it will get and still too big, the limit of the tool decides. Figures for other tools are as published on their sites when we checked (InstallOnAir in November 2026, Diawi on November 2, 2026); they change, so check before you rely on them.
| Tool and tier | Largest file | Notes |
|---|---|---|
| InstallOnAir guest or free account | 200 MB | A $2 upload credit allows one upload up to 1 GB on a free account; unused credits are kept |
| Diawi Free account | 20 MB | Starter 50 MB, Premium 250 MB, Enterprise 1.2 GB; upload size add-ons on paid plans |
| AppForShare Guest | 50 MB | No account needed |
| AppForShare Free | 150 MB | Free account |
| AppForShare Pro | 2 GB | $12 a month |
| AppForShare Team | 4 GB | $39 a month |
To be fair about the free tiers: for a single file between 150 MB and 200 MB, InstallOnAir's free plan takes it and ours does not, and their $2 credit is a cheap way to send one build up to 1 GB. Our free tiers stop at 150 MB. Above that, AppForShare needs Pro, which also keeps links live while you subscribe and adds CI uploads. More detail is in InstallOnAir limits in 2026 and Diawi limits in 2026.
Large files also cost bandwidth
File size is only half the limit. Every install downloads the whole file. On AppForShare, a 1 GB build installed 10 times is about 10 GB of downloads. Free includes 10 GB a month, Pro 40 GB and Team 150 GB, and Pro and Team can add 50 GB for $10 (up to 4 times a month). Uploading itself is free. If you share a big build with many testers, the ABI split above pays off twice: a smaller file and less bandwidth per install.
Uploading 1 GB plus builds from CI
Large uploads through a browser are fragile: a hotel Wi-Fi drop at 80 percent means starting over. For big builds, upload from CI or a terminal with the CLI, which sends the file in resumable parts and picks up where it stopped.
export APPFORSHARE_TOKEN=afs_your_token
npx appforshare upload build/MyGame.ipa --notes "Build 311, new level pack" --channel betaIt prints the install link and the channel link. The same upload runs from the GitHub Action, fastlane plugin and other CI systems, and each command is documented in the CI API reference. CI uploads need an API token, which comes with Pro and Team.
If you use a Diawi style curl script with our Diawi compatible endpoint, note that one request there carries at most 100 MB. For anything bigger, switch that step to the CLI.
If your pipeline only makes Android App Bundles, you can upload the .aab directly on Free and up. AppForShare turns it into one universal APK that testers can install. That APK contains every architecture, so it can be larger than what Google Play delivers to one phone. See installing an .aab on Android.
Give testers one link for big builds
With large builds, every extra link means another full download for someone who did not need it. On Pro, a channel such as Beta has one stable address that always opens the newest build put into it, so testers bookmark it once and install only when you promote a new build. See beta and live channels.
If you are moving from InstallOnAir because of size, the step by step guide is Move from InstallOnAir, and the full comparison is AppForShare vs InstallOnAir.
Common questions
What is the InstallOnAir file size limit?
As published on their site in November 2026, 200 MB for guests and free accounts, or up to 1 GB on a free account with a $2 upload credit, one credit per large upload.
What is the largest file AppForShare accepts?
50 MB without an account, 150 MB on Free, 2 GB on Pro and 4 GB on Team.
Can I zip an .ipa to make it smaller?
Not really. An .ipa is already a zip archive, so zipping it again saves almost nothing. Cut the content instead.
Will splitting an APK by ABI change how the app behaves?
No, as long as the tester installs the file that matches the phone. It only leaves out native libraries the phone would never load.
