Security checks before you share an IPA or APK build
· 7 min read
A test build feels like an internal thing, but once it leaves your machine it is a file anyone with the link can download and unpack. An .ipa or .apk is a zip archive. Its manifest, its resources and much of its code can be read with free tools in a few minutes. Before you send a build to testers, and especially before you send one to a client or someone outside the company, it is worth a short check.
This is a practical list of what to look at, why it matters, and how to see it. None of it replaces a proper security review of the app, but it catches the mistakes that show up most often in builds that were meant to be "just for testing".
Android: what to check in the APK
1. Is it debuggable?
A build with android:debuggable="true" lets anyone with the device and a USB cable attach a debugger, inspect memory and run code in the app's context. Debug builds from Android Studio set this flag automatically. It is fine for a developer's own phone, not for a build that goes to a client. Google Play also refuses debuggable builds, so it is a sign the wrong variant was built.
2. Is it signed with the debug key?
The Android debug keystore is generated per machine with a known password. A build signed with it shows the signer as CN=Android Debug. Two problems: the signature proves nothing about who built it, and testers who install it cannot later update to a release signed build without uninstalling first, because Android refuses an update signed by a different key. Our post on Android app signing, APK vs AAB explains the signature side in detail.
3. Permissions
Read the full permission list of the merged manifest, not just the one in your source. Libraries add their own permissions during the build. A test build is a good moment to notice that an analytics SDK added location access, or that a permission you removed months ago is back. If you would have to explain a permission to a reviewer, you should be able to explain it to a client.
4. Exported components
Activities, services, broadcast receivers and content providers with android:exported="true" can be started or queried by other apps on the device. Since Android 12, components with an intent filter must declare android:exported explicitly, which helped, but a debug menu or a deep link handler exported by accident is still common. Check that only the components meant to be reachable from outside are exported, and that exported content providers are protected by a permission.
5. Network and backup settings
Look for android:usesCleartextTraffic="true" or a network security config that allows plain HTTP or trusts user added certificates. Both are often added to talk to a local test server and then forgotten. Also check android:allowBackup: if the app stores tokens, decide whether they should be included in device backups.
iOS: what to check in the IPA
1. Signing and distribution type
Know what you are sending. Development builds include the get-task-allow entitlement, which allows a debugger to attach. Ad Hoc builds are the normal choice for testers, and they install only on devices listed in the profile. Check the profile expiry too: a build that stops opening next week is a support problem, not a security one, but it is caught in the same place. If you are not sure which signing you need, see unlisted apps vs Ad Hoc vs install links.
2. Entitlements
Entitlements say what the app is allowed to do: push notifications (and whether the push environment is development or production), associated domains, app groups, keychain sharing, HealthKit, iCloud. An entitlement that is in the build but not used by the code is a sign of a copied profile or an old capability. An associated domain pointing to a staging host tells anyone reading the file where your staging servers live.
3. Usage descriptions
Every NS...UsageDescription key in Info.plist is a permission the app may ask for. Check that each one is still needed and that the text explains the real reason. Vague purpose strings are a common App Store rejection, so fixing them in the test build saves a round trip later. See App Store rejection reasons.
4. Privacy manifest
Since 2024, Apple expects a PrivacyInfo.xcprivacy file that declares tracking, collected data types and the reasons for using certain APIs. Commonly used third party SDKs must ship their own. A missing or incomplete manifest blocks App Store uploads, and it is also a good inventory of what data the build touches.
5. App Transport Security
The iOS equivalent of cleartext traffic is an NSAppTransportSecurity dictionary with NSAllowsArbitraryLoads set to true, or exceptions for specific domains. Like on Android, these are often added for a test server and never removed.
Both platforms: leftovers in the bundle
This is general advice rather than something a quick inspector can fully check, but it is where real leaks come from:
- API keys and secrets. Anything compiled into the app can be extracted. Run
stringson the main binary, or decompile an APK withjadxorapktool, and search forkey,secret,tokenandBearer. Keys for services that bill you or give admin access should never be in a client app at all. - Test and staging endpoints. Search the bundle for internal hostnames, IP addresses and
localhost. A build pointed at staging is fine for testers, but make sure staging is not open to the internet with real data in it. - Bundled files. Look through the resources for JSON fixtures, sample databases, log files,
.envfiles and certificates that were copied in by a build script. - Debug menus and feature flags. A hidden screen that switches servers or skips login is useful for QA. Decide whether the people receiving this build should have it.
- Logging. Verbose logs that print tokens or personal data can be read from a connected device.
Going deeper: MobSF
For a fuller automated check, MobSF (Mobile Security Framework) is an open source scanner that runs static analysis on Android and iOS app files, and can also run dynamic analysis. It reports insecure manifest settings, hardcoded secrets, weak crypto use and more. It runs on your own machine or server, so the build does not go to a third party. Expect some false positives; treat its report as a list of things to look at, not a verdict.
What our free inspectors show
For the quick pass, the IPA inspector and APK analyzer read the file in your browser. The file is not uploaded unless you choose to share the build. Here is what they cover from the list above:
| Check | Shown by our inspector | Use instead |
|---|---|---|
| Debuggable flag (APK) | Yes | Not needed |
| Debug signing key (APK) | Yes, plus signer name and signature schemes v1/v2/v3 | Not needed |
| Permissions (APK) | Yes | Not needed |
| Native libraries and ABIs (APK) | Yes | Not needed |
| Exported components, cleartext, backup (APK) | No | apktool or MobSF |
| Distribution type, profile, expiry, devices (IPA) | Yes, with the full UDID list | Not needed |
| Entitlements (IPA) | Yes (keychain groups hidden) | Not needed |
| Usage descriptions with their text (IPA) | Yes | Not needed |
| Privacy manifest, background modes, extensions, frameworks (IPA) | Yes | Not needed |
| App Transport Security (IPA) | No | Read Info.plist or MobSF |
| Hardcoded secrets and endpoints | No | strings, jadx, MobSF |
| Malware | No | A dedicated security product |
Both tools also run the store readiness rules, such as target API level, 16 KB page size, iOS SDK version and privacy manifest requirements. That is guidance about store rules, not a security scan, and AppForShare does not scan builds for malware.
Sharing the build once it is clean
When the build passes your checks, how you share it matters as well. A file in a chat thread gets forwarded and stays there for good. With AppForShare you upload the build and send an install link instead: links can have a password, download links are signed and short lived, and on Free a link expires after 7 days. On the Team plan, private projects open only for invited testers, and you can see who installed. For client work, see sending app builds to clients.
Start with the free IPA inspector or APK analyzer on your next build, then create a free account when you are ready to share it.
