Beta distribution has a vocabulary problem. Half the words come from Apple's tooling and half from Android's, and the platforms happily use the same word for different things.
Each entry opens with a definition that stands on its own, then says what it means when a build is finished and a tester is waiting.
An .ipa is the packaged build file for an iOS app: a ZIP archive whose Payload/ folder holds the signed .app bundle, its compiled binary, its resources, its Info.plist and usually an embedded.mobileprovision, and it is what Xcode writes when you export an archive.
Renaming a .zip does not produce one. What decides whether it installs is the signature and the profile inside, both of which the IPA inspector reads without a Mac.
An .apk is the format an Android device actually installs: a ZIP archive carrying compiled classes.dex bytecode, a binary AndroidManifest.xml, resources, native libraries split by ABI, and a signature block, which any phone can install once the user permits installs from the app doing the install.
It is the only Android artifact a phone installs without Play in the middle, which is why BetaDrop distributes it rather than the bundle. The APK inspector decodes the binary manifest.
An .aab is a publishing format rather than an install format: it carries your compiled code and resources and defers APK generation and signing to Google Play, which builds a device-specific APK per ABI, density and language, and it has been mandatory for new Play apps since August 2021.
No phone installs one directly; bundletool turns it into APKs first. Its size on disk overstates what a user downloads, which the AAB inspector corrects and testing Android App Bundles works around.
Code signing attaches a cryptographic signature to a build so the operating system can verify who produced it and that nothing changed afterwards, and both platforms refuse to install an unsigned app, though neither checks that you are trustworthy so much as that this build carries the last build's key.
That distinction explains most failed installs: they are identity failures, not code failures. Your private key never leaves your machine, which is why any site offering to re-sign an IPA wants what it should not have.
A signing certificate binds your identity to a public key Apple has countersigned, and it lives in your keychain paired with a private key you generated locally; iOS checks it at install time, so a build signed with an expired or revoked certificate is refused by the device itself.
Lose the private key and the certificate is dead weight: revoke, reissue, and every build signed with the old one stops installing. It belongs to the developer account rather than to the project.
A provisioning profile is a signed plist Apple issues that ties an App ID to one or more signing certificates, a set of entitlements and, for development and ad hoc types, an explicit list of device UDIDs, and iOS refuses to install your build on any device that is not on that list.
Profiles expire after a year, which is why a build that installed in March stops installing the following March. The provisioning profile decoder reads its expiry and device list, and iOS provisioning profiles explained covers the rest.
Entitlements are the capabilities a signed iOS app may use, such as push notifications, iCloud, App Groups, HealthKit or associated domains, declared in a plist compiled into the signature; they must be a subset of what the provisioning profile grants, and asking for more makes the install fail.
The failure names no entitlement, so the fastest diagnosis is to read both sides and compare. The IPA inspector pulls them from the build; the profile decoder pulls them from the profile.
A UDID, or Unique Device Identifier, is the 25-character string (40 characters on older hardware) identifying one specific iPhone or iPad, and because Apple's development and ad hoc profiles work by listing UDIDs, a tester can install your build only if you registered theirs beforehand.
Collecting them is the usual bottleneck. The UDID checker reads one off the device itself, no Mac and no cable, and UDID collection links do a whole tester group at once.
A keystore is the password-protected file holding the private key Android uses to sign your app: a Java KeyStore, usually .jks or .keystore, containing one or more named key aliases, and since Android identifies an app by package name plus signing key, that file is the app's identity.
Lose it and you cannot update an installed app: the device rejects a build signed by a different key with a bare “App not installed”. Android app signing explained maps which key does what.
Ad hoc distribution is Apple's way of installing a signed build on a fixed set of registered devices without the App Store or TestFlight: you register each tester's UDID, generate a distribution profile containing them, export the build against that profile, and only those devices accept it.
Its ceiling is Apple's device registration limit, and its friction is that adding one device means a new profile and a new export. What iOS ad hoc distribution actually is walks the full loop.
Release-testing is the value Xcode's ExportOptions plist now expects where the method used to be called ad-hoc: Apple deprecated the old name in Xcode 15.4 and Xcode 26 rejects it outright, so a workflow copied from an older tutorial fails at the export step.
Only the string changed; the export is the same one. fastlane is not exempt either: gym copies export_method into that same method key, so a Fastfile still on ad-hoc fails the same way. Recent fastlane takes release-testing directly; if your version rejects it as an invalid value, pass it as export_options: { method: "release-testing" } instead.
Enterprise distribution uses the Apple Developer Enterprise Program to install in-house apps on company devices with no UDID registration and no App Review, and it is deliberately hard to get, because Apple wants 100 or more employees, a D-U-N-S number, and evidence that ad hoc and TestFlight would not do.
It is for employees, not beta testers or clients, and Apple revokes certificates used outside that. Testers also hit a trust prompt on first launch, which is the Untrusted Enterprise Developer error.
TestFlight is Apple's own beta distribution service, run through App Store Connect, where testers install the TestFlight app, accept an invitation and get builds inside it, with up to 100 internal testers and 10,000 external ones, and the first external build goes through Beta App Review.
A TestFlight build stays installable for 90 days and then stops. If the review wait or the tester-side app is your problem rather than the price, TestFlight alternatives sets out what changes.
Internal testing and closed testing are two Google Play release tracks, where internal testing pushes a build to as many as 100 named testers within minutes and skips most review, while closed testing serves larger invited groups (up to 50 email lists per track, of 2,000 users each) through the normal review path.
Both still need an .aab uploaded and a release created, which costs an afternoon when one person needs to see one build. Internal app sharing vs closed testing compares the fast paths.
Apple's device registration limit is 100 devices per product type per membership year, meaning 100 iPhones and 100 iPads rather than 100 in total, and that pool is what development and ad hoc profiles draw their UDID lists from, so it caps how many testers one ad hoc build can reach.
The list resets only when the membership renews, and removing devices frees slots only before you add the first new one that year. Forward how to find an iPhone UDID to testers rather than asking in chat.
Sideloading means installing an app from outside the platform's official store, and on Android it is a supported flow: the user grants install-unknown-apps permission to whichever app is doing the installing (per source since Android 8.0) and taps the APK, while iOS needs a signed build and a profile.
The word carries a security connotation it does not always deserve: a signed build from your own CI is not the risk an APK from a forum is. Safe Android sideloading draws that line.
OTA installation, short for over-the-air, means a device downloads and installs an app straight from a web address with no cable and no desktop involved; on iOS that is the itms-services flow below, and on Android it is a browser download of an .apk plus the install prompt.
It is what turns a build into a URL you can paste into a chat. Installing IPA files over the air covers the iOS mechanics end to end.
itms-services is Apple's URL scheme for starting an over-the-air install, written as itms-services://?action=download-manifest&url=…, whose entire payload is an HTTPS pointer to a manifest; Safari does not follow it itself but hands it to the system install daemon, which fetches that manifest and takes over from there.
Two things break it: a link tapped inside Slack or Gmail, whose in-app WebView swallows the scheme silently, and a manifest URL that redirects. When an itms-services link does nothing is the checklist.
A manifest plist is the small XML document an iOS over-the-air install actually begins with: it names the build's HTTPS URL under an asset of kind software-package, plus the bundle identifier, version, title and optional icon URLs, and the daemon reads it before downloading a byte.
This is exactly why a Google Drive or Dropbox link cannot install an iOS build: there is nowhere to put the document about the file. Sending a build to testers works through that mismatch.
An install link is the single URL you send a tester, pointing at a page that offers the right install path for whatever device opened it: the itms-services handoff on an iPhone, a direct download on Android, and a QR code when the phone is in your hand.
The tester needs no account and nothing installed first. On BetaDrop a free link starts at 3 days and stretches to 7 days, a guest upload lasts 24 hours, and paid plans hold one open out to a year on Pro or 10 years on Studio.
Nobody reads a glossary for pleasure. Every term above is somewhere the trip from your machine to a tester's phone can stop, which is the only reason any of it is worth knowing.
BetaDrop takes an .ipa or .apk up to 500 MB free and 1 GB on Studio, generates the manifest, and hands back one link that behaves on both platforms. If you would rather have the procedure than the vocabulary, the quickstart is the short version and the free build inspectors read a file you already have.
Four of them. The file format you are shipping (.ipa or .apk), code signing, the provisioning profile if the build is for iOS, and the install link. Everything else on this page is background for the day something breaks. On Android you can skip the profile and the UDID entirely: a signed APK and a link is the whole story.
Not for a direct install link. The link opens in the phone's own browser and installs from there, through the itms-services handoff on iOS or a normal download plus the install-unknown-apps prompt on Android. TestFlight is the exception: it requires the tester to install the TestFlight app and accept an invitation tied to their Apple ID.
Because the two platforms solved distribution from opposite ends. Apple gates every install on a per-device provisioning profile and treats anything outside the App Store as an exception authorised in advance, while Android treats the signature as the app's identity and lets the device owner allow installs from a source they pick. So signing means prove who you are to Apple on one side, and prove this update came from whoever wrote the last one on the other.
