In this guide 6 sections
Before each release, check what ships inside the app: stored tokens, local database encryption, certificate pinning, debug flags, exported components, keys left in the build and the permissions requested. Open the built Android or iOS package yourself, because the code in the repository is not what customers download.
Check what the app stores on the phone
Start with login tokens. On Android they belong in the Keystore, and on iOS in the Keychain. Tokens placed in SharedPreferences, UserDefaults or a plain text file can be read on a rooted or jailbroken phone, or from an unencrypted backup.
Next, look at the local database. A SQLite file with customer names, invoices or delivery addresses should be encrypted, for example with SQLCipher. Check the cache too. Check logs. Check the screenshots folder.
Ask what happens at logout. Tokens and cached records should be wiped, not just hidden. Test it by logging out and browsing the app’s folder on a test device.
- Tokens in Keystore or Keychain only
- Local database encrypted
- No personal data in logs or crash reports
- Cache cleared on logout
- Backup flag set deliberately
Look for secrets and switches left in the build
Unpack the release file and search it. An APK or IPA is just an archive. Strings inside it are easy to read. Hardcoded API keys, test passwords and admin URLs turn up more often than anyone admits.
Confirm debug mode is off. A debuggable flag in the Android manifest, verbose logging, or a hidden test menu lets anyone attach tools to your app. Check the staging server address has been replaced with the live one, and not the reverse.
Treat any key that was ever in the bundle as exposed. Rotate it, and move the call that needs it to your server.
Check the connection to your server
Every request should use HTTPS with current TLS. Android’s network security config and iOS App Transport Security both let developers allow plain connections for testing. Make sure those exceptions are gone before release.
Consider certificate pinning for apps that handle payments or health records. Pinning makes the app trust your certificate only. It also breaks the app when the certificate changes, so plan renewals and keep a backup pin.
Remember the app is not the security boundary. A customer can run a modified copy. The server must check every request again for who is asking and what they may see.
- HTTPS only, no cleartext exceptions
- Pinning decision recorded with renewal plan
- Server checks the role on every call
- Token expiry and refresh tested
Review exported components and permissions
On Android, an activity, service or content provider marked as exported can be started by any other app on the phone. List every exported component and justify each one. Deep links need the same attention, since a crafted link can open a screen without logging in.
Read the permissions list as a customer would. A delivery app that asks for contacts, call logs and exact location all day will lose trust, and may be rejected by the store. Remove any permission that no feature uses.
On iOS, review the URL schemes and universal links the app answers, and the purpose strings shown to the user.
Make the checklist part of the release
Run the checks on the signed release build, not a debug one. Dependencies matter too. Scan third party libraries for known issues, and note any SDK that sends data to an outside company.
Keep one person responsible for sign off, and record the result against the version number. If a check fails, the release waits.
Once a year, or after a large change, ask an outside tester to attempt a manual assessment of the app and the API behind it.
- Run on the signed release build
- Library and SDK review
- Named sign off per version
- Outside test on major changes
Mobile release security sheet
Sheet with a row per check and four columns: check, Android result, iOS result and owner. Rows cover token storage, database encryption, log contents and hardcoded keys. More rows cover the debuggable flag, cleartext exceptions, pinning, exported components, deep links, permissions and third party SDKs. The last row takes sign off, version number and date.
Open a blank worksheet to printQuestions owners ask
Is it enough to scan the source code?
No. The build can differ from the source through build settings, bundled test files and third party libraries. Inspect the final APK or IPA as well.
Do small internal apps need these checks?
Yes. An internal app often holds customer data and a login to your server, and staff phones are lost like any other. The same checks apply, even if the review is shorter.
Should every app use certificate pinning?
Not always. It suits apps with payments or sensitive records. It adds maintenance, because expired or changed certificates break the app until users update.
Who should own this checklist?
The mobile lead usually runs it, with the backend developer checking server side rules. One named person signs off each release so that nothing is assumed.