Native or cross-platform: deciding on evidence rather than preference
Both approaches build excellent products. The decision follows device capability requirements, team composition and roadmap shape.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Anything in the binary is inspectable — there are no client-side secrets.
- Enforce authorisation and validation on the server, always.
- Use platform keystores; audit logs, backups and task-switcher snapshots.
- Obfuscation is friction, not a control.
Assume the client is hostile
Applications can be decompiled, network traffic intercepted and runtime behaviour modified. Any secret in the binary is not a secret, and any check performed only on the client can be bypassed.
Authorisation, business rules and validation must be enforced server-side. Client-side versions of those checks are a user experience feature, not a control.
Store data carefully
- Use the platform keystore or keychain for credentials and tokens.
- Do not log sensitive values; logs are readable in many circumstances.
- Consider what remains in memory, in backups and in screenshots of the task switcher.
- Clear sensitive state on logout properly, including cached responses.
Protect the transport and the API
Enforce TLS and consider certificate pinning for high-value applications, understanding that pinning complicates certificate rotation and needs an update strategy.
Treat the mobile API as a public API, because it is. Rate limit it, authenticate every request, and never assume a request came from your app.
Raise the cost of tampering
Obfuscation, root and jailbreak detection and integrity checks do not make an application secure, and they do raise the effort required for casual attacks.
Treat them as friction rather than protection, and keep the real controls on the server where they cannot be removed by editing the client.
Handling authentication tokens
Token handling is where most practical mobile security problems appear. Store refresh tokens in the platform keystore, keep access tokens short-lived, and ensure logout genuinely revokes server-side rather than only clearing local state.
- Bind tokens to the device where the risk profile justifies it.
- Handle expiry gracefully rather than dropping the user to a login screen mid-task.
- Clear cached responses containing personal data on logout.
- Ensure biometric unlock gates access to the token rather than to the interface alone.
That last point matters: protecting a screen while leaving the token readable protects nothing against anyone with device access.
Frequently asked questions
For applications handling sensitive transactions, often yes. It defends against intercepting proxies and requires a plan for certificate rotation so an expiry does not break the installed base.
Ideally you do not ship them. Where a key must reach the device, obtain it after authentication and store it in the platform keystore, scoped as narrowly as possible.
For applications handling payments, health or personal data, it is expected and often contractually required. It also finds issues that code review does not.
