Before submitting a mobile app, protect the signing keys, remove embedded secrets and debug flags, store sensitive data safely on the device, enforce encrypted transport, trim permissions, review third party SDKs, and plan for fast updates. A released app cannot be recalled, so the checks have to come first.
Signing and secrets
- Signing keys are stored in a managed place with limited access. Losing control of a signing key means someone else could ship updates as you. Back it up and record who can use it.
- No secrets inside the app. Anything packaged in the binary can be extracted. API keys that grant real power belong on your server. Keys that must be in the client should be scoped and restricted to what the app needs.
- Debug features are off. Debug builds, verbose logs, test endpoints, developer menus and permissive certificate settings must not reach the store build.
Data on the device
- Sensitive data uses the platform's secure storage, not plain preference files or the shared storage area. Do not store more than you need, and clear it on sign out.
- Logs and screenshots. Check that sensitive screens are protected from the app switcher snapshot and that logs contain no tokens or personal data.
- Backups. Decide whether app data should be included in device backups, and exclude sensitive files if not.
Network and permissions
- All traffic uses TLS, with certificate validation left on. Consider pinning only if you have a plan to rotate pins, since a bad pin can lock out every user.
- Request the fewest permissions. Each permission is a prompt users may reject, and a power an attacker could abuse. Remove those added during experiments.
Third party code
Review every SDK: analytics, ads, crash reporting, payments. Each is code with your app's permissions. Note the version, where it sends data, and whether it has known vulnerabilities. Produce a dependency list for each release so you can answer quickly when a new advisory appears.
Test and ship
Test against a recognised mobile security verification standard, such as the OWASP MASVS, using a build that matches the release. Test authentication flows, deep links and any web views, which often accept untrusted input. Check that your backend can force an upgrade or disable an old version, because users update slowly.
Safeguard's dependency and SBOM scanning can cover the libraries inside a mobile project.
Build the checks into your release pipeline where you can. A scan for embedded secrets, a dependency report and a check that the build is not marked debuggable are all easy to automate and run on every candidate. Keep a short release record: version, build number, signing identity, dependency list and who approved. It helps when you need to answer a question about an old version.
Quick check
Is obfuscation a substitute for secure design?
No. It raises the effort for attackers a little. It does not protect secrets placed in the app.
How do I handle a vulnerable SDK after release?
Update and ship a new build, and use a server side minimum version to push users along.
Last reviewed: 19 October 2026.
