Free tools, no signup, for the moments a mobile build stops cooperating: an install that fails without saying why, a manifest you can't read, a fingerprint a console insists on, a tester who doesn't know what a UDID is.
They exist because BetaDrop's actual product is build distribution (upload an .ipa or .apk, get an install link and QR code), and every tool here answers a question that comes up on the way to a working install.
One inspector per file format. Each parses the file in your browser, and their pages say it plainly: nothing is uploaded, so a build under NDA never touches anyone's server.
Opens an .ipa and reads the bundle ID, version and build, minimum iOS version, device families, architectures and the embedded provisioning profile, plus a static security scan and a file explorer. Parsed in your browser; the build is never uploaded.
You have the build file but not a Mac, and you need to know what's inside: the bundle identifier for a config, or which devices the embedded profile actually covers before you ask anyone to rebuild.
Open the IPA inspectorDecodes the binary AndroidManifest.xml: package name, versionCode and versionName, minSdk and targetSdk, permissions with the dangerous ones flagged, components, native ABIs, and a security scan for debuggable and cleartext flags, exported components and hardcoded secrets. Parsed locally; nothing is uploaded.
The build on the device doesn't behave like the one you think you shipped. Reading the manifest of the exact .apk in hand settles what it declares, without installing the Android SDK to get aapt.
Opens an Android App Bundle, decodes its protobuf manifest, lists base, feature and asset-pack modules with their delivery modes, and estimates the real per-device download by costing one ABI, one density and one language instead of the whole file. Decoded in the browser, no upload.
Play takes bundles, but an .aab's file size tells you nothing about what a user downloads. This gives you the honest number, and reports whether the upload signature Play checks is present.
Failed installs rarely say why. These turn “it doesn't work” into a specific, fixable cause.
Reads an APK's signing certificate: SHA-1, SHA-256 and MD5 fingerprints in the colon-separated hex that Firebase, Google Cloud Console and assetlinks.json expect, plus subject, issuer, validity and which signature schemes the file carries.
Android's “app not installed” on an update usually means the new build is signed with a different key than the one on the device, and the error never says so. Compare fingerprints from both builds and you have proof, not a hunch. It refuses keystore files on purpose: reading a fingerprint never requires a private key.
Check an APK signatureOpens a .mobileprovision file in your browser (nothing uploaded) and shows the profile type, team, expiry, entitlements, certificates and the full list of registered device UDIDs, with search.
An ad-hoc build installs only on devices whose UDIDs are in the profile. When a tester's install fails, search the device list for their UDID: if it's missing, you've found the cause. Register it in the Apple portal and rebuild.
Decode a provisioning profileGets an iPhone or iPad's UDID from the device itself via a configuration profile: no Mac, no cable, no app to install.
The follow-up to the decoder: the tester's device wasn't in the profile, and now you need their UDID to register it. Send them this link instead of talking them through Finder over chat.
Get a device UDIDEverything above reads a file you already have. These write one you do not: the plist that exports the archive, and the manifest that installs it from your own server.
Builds the ExportOptions.plist that xcodebuild -exportArchive reads, with the current method values, and prints the matching xcodebuild and fastlane lines beside it. Dropping a .mobileprovision fills in the team ID, profile name and bundle identifier without the file leaving your browser.
Xcode 15.4 renamed the export methods (ad-hoc became release-testing, app-store became app-store-connect), and current Xcode only warns about the old names, so a plist copied from an older answer still exports on a deprecated alias. fastlane's gym is the opposite trap: it still rejects the new names. The picker here emits only the current ones, and a fastlane lane that exports with xcodebuild instead.
Writes the manifest.plist and the matching itms-services:// link for a build you host on your own server, and the QR code for the link. Dropping the .ipa fills the bundle identifier, version and title from the build itself, parsed in your browser.
Hand-writing the manifest is where over-the-air installs break: the two different keys both named kind, the percent-encoding in the url= parameter, and the fact that the link carries the manifest URL while the manifest carries the build URL.
Finds any iOS app's bundle identifier and numeric App Store ID, with a verified list for the most-searched apps.
Firebase configs, MDM policies, deep links and review-prompt URLs all want an identifier the App Store page never displays. Look it up instead of unzipping an .ipa to read Info.plist.
Turns any URL into a QR code with PNG and SVG export. Generation happens entirely in your browser, so the link never leaves your machine.
The fastest way to move an install link from a screen to a phone is a camera. And an unreleased build's URL is exactly the kind of link you don't want logged by a random online generator — this one structurally can't.
Generate a QR codeThey read; they don't repair. Nothing here re-signs a binary, edits a manifest, converts an .aab into an installable .apk, or turns an .apk into an .ipa — see why no APK to IPA converter exists. BetaDrop distribution takes an .apk, not an .aab, and does not re-sign builds. When a signature or profile is wrong, the fix is a rebuild on a machine that holds your keys. If a site offers to re-sign an IPA for you, read why online IPA signing is a bad idea before uploading anything.
They don't bend Apple's rules either. Decoding a profile shows which devices a build covers; it can't add one. Ad-hoc installs still need the UDID registered and the build re-exported, and enterprise builds still need the trust step.
And if you have the SDKs installed, your terminal already does these jobs: aapt2 dump badging for the manifest, apksigner verify --print-certs for fingerprints, security cms -D -i profile.mobileprovision for profiles. The tools earn their keep on the machines that don't have those installed — a PM's laptop, a borrowed desk, a phone.
The usual reason to inspect a build is that someone is waiting to install it. BetaDrop turns an .ipa or .apk into an install link and QR code that testers open in the phone's browser: no tester accounts, no cables, no review wait. Your first guest upload works without an account.
Yes: every tool here is free, with no signup, no watermark and no BetaDrop account required, because the paid product is build distribution rather than the tools themselves. Each tool answers a question that comes up on the way to a working install.
Most of them never send it: the three inspectors, the provisioning profile decoder and the QR code generator all run client-side in the page, as each of their pages states directly. The one exception is the APK signature checker — reading an X.509 signing certificate needs a parser that runs on our API, so that file is uploaded, read, and not retained.
No — they are read-only and diagnostic. Nothing here re-signs a binary, edits a manifest, converts an .aab into an .apk or turns an .apk into an .ipa. On iOS, the fix for a device missing from the provisioning profile is registering its UDID in the Apple Developer portal and rebuilding. On Android, a signature mismatch means uninstalling the existing app or rebuilding with the original key. Both fixes happen in your own toolchain, on a machine that holds your keys.
The APK signature checker. Android refuses to update an installed app when the new build is signed with a different key, and the error message never says so. Read the SHA-256 fingerprint from the build that installs and from the one that does not; if they differ, you have found the cause. For the iOS equivalent (an ad-hoc build that will not install), the provisioning profile decoder shows whether the tester's device UDID is in the profile.
