How to prepare your app release build for a security review
Short answer
Send the exact build you plan to ship, built with release settings: an Android AAB or APK, or an iOS IPA exported from Xcode. Add the dependency lockfile, a short description of the app and test accounts without real personal data. Agree scope and permission first. Never send signing keys or production secrets, and send source code only if the agreed scope asks for it.
The checklist
- Agree scope and permission first. Name the app and version, prove you own it, sign an NDA and a written authorisation. No build should change hands before that.
- Build for release. Use your release configuration, the same one you ship to the store.
- Send the right file. Android: the AAB or APK. iOS: the IPA you export from Xcode.
- Add the dependency lockfile for that exact build.
- Describe the app in a few lines. What it does, which data it handles, and anything unusual, such as certificate pinning or root detection.
- Provide test accounts with fake data, one per user role if roles differ.
- Use the agreed transfer method. Never attach builds to ordinary emails or web forms.
Android: release settings to check
- Not debuggable. Google's release guide sets the release build type to not debuggable. A debuggable build is not the build your users get.
- Logging removed. Google asks you to deactivate logging and remove debug tracing calls before release.
- Cleartext traffic. Apps that target Android 9 (API level 28) or higher have cleartext traffic disabled by default. It can be switched back on with usesCleartextTraffic in the manifest or in the network security configuration. If yours does that, know why.
- Debug overrides. Debug-only trusted certificates under debug-overrides are ignored when the build is not debuggable. If your app only works with them, the release build will show it.
Google's release guide also recommends enabling app shrinking, which removes unused code and shortens class and variable names. Send the build as you ship it, whether shrinking is on or off.
iOS: export the right IPA
- In Xcode, check that your scheme archives with the Release configuration, then choose Product > Archive.
- In the Organizer, select the archive, click Distribute App and choose Release Testing. Apple describes it as signing the app much like the App Store option, for devices your team registers. Avoid Debugging, which produces a development build.
- Send that exported IPA, not a copy downloaded from the App Store. App Store apps are protected with FairPlay encryption, and OWASP's testing guide says it must be removed first, usually by decrypting the app on a device.
An IPA exported this way only installs on devices registered in your provisioning profile, so we agree during scoping which test device to add.
Which lockfile to include
The lockfile lists the exact versions of the libraries in your build, so known vulnerable versions can be checked. Common ones:
| Framework or tool | Lockfile |
|---|---|
| Flutter (pub) | pubspec.lock |
| React Native or Node (npm) | package-lock.json |
| React Native or Node (Yarn) | yarn.lock |
| iOS (CocoaPods) | Podfile.lock |
| iOS (Swift Package Manager) | Package.resolved |
| Android (Gradle, with dependency locking enabled) | gradle.lockfile |
Lockfiles are often in a subfolder, for example Podfile.lock in the ios folder of a Flutter or React Native project, or gradle.lockfile next to a module. Not sure which one you have? We confirm it during scoping.
What never to send
- Source code, unless the agreed scope asks for it. Some reviews use it; ours is built around the release build.
- Signing keys and certificates, such as an Android keystore or Apple signing certificates.
- Production secrets, such as API keys for live systems or admin passwords.
- Real personal data, in test accounts or anywhere else.
What happens to your build at Vybebat
Your build is handled in an isolated analysis environment. The build file is never uploaded to online scanners, sample-sharing services or AI services, and excerpts only go to an AI service if you agree in writing. Client artifacts are deleted within 30 days of report delivery unless agreed otherwise, and we confirm the deletion in writing. See how it works or send us a question.
Common questions
- Can I send a debug build?
- Please send the release build. Debug builds are debuggable and can use different network settings, so they are not what your users run.
- Do you need my source code?
- No. We review the release build and the dependency lockfile. Source code is only part of the work if a separate written scope says so.
- Should I turn off certificate pinning or root detection first?
- No. Send the build exactly as you ship it. Tell us about these protections in your app description so we can plan the device tests.
- Can I send the App Store version instead of an IPA?
- Please export an IPA from Xcode instead. App Store downloads are protected with FairPlay encryption, which must be removed first, usually by decrypting the app on a device.
Sources
- Android Developers: Prepare your app for release
- Android Developers: Network security configuration
- Apple Developer: Distributing your app to registered devices
- Android Developers: application element (usesCleartextTraffic)
- Apple Developer: Distributing your app for beta testing and releases
- OWASP MASTG: iOS platform overview (FairPlay)
- OWASP MASTG: Disassembling iOS apps (remove FairPlay first)
- Gradle: dependency locking
Vybebat is not affiliated with, endorsed or certified by the OWASP Foundation. We check these facts against the sources above and update the guide when they change.