Mobile App Security: Protecting User Data on iOS and Android

Users don't ask about security until something goes wrong — by then it's too late

Almost no client asks us for a security audit line item when they first come to us — they ask for features, a timeline, a price. Mobile app security best practices come up later, usually after a client has read about a competitor's data breach or their own compliance team has asked a question nobody on the founding team can answer. By the time security becomes an explicit ask, it's usually because someone got scared, not because they planned for it, which is exactly backwards, because the cheapest time to build security in is before the first user's data ever touches the app.

We build a baseline set of protections into every app regardless of whether the client asked, because retrofitting them later means auditing every existing data flow instead of designing it in from the schema up.

Storing data on-device: what belongs in the keychain, and what shouldn't be stored at all

The most common mistake we see in apps we inherit from other teams is sensitive data — tokens, personal information, cached API responses with user details in them — sitting in plain local storage on Android or a plist on iOS, both of which are trivially readable on a rooted or jailbroken device, and sometimes even without one. Anything that identifies or authenticates a user belongs in the platform keychain, iOS Keychain or Android Keystore, which is backed by hardware-level encryption, not app-level convention. The better rule is simpler: if data doesn't need to persist on the device at all, don't persist it — the safest data is the data you never stored.

Transport security: certificate pinning and why HTTPS alone isn't enough

HTTPS is table stakes, not a security feature you get credit for. What actually protects an app against a meaningful attacker running a proxy to intercept traffic on a compromised network is certificate pinning, which stops the app from trusting a certificate that isn't specifically yours even if it's technically valid. It adds complexity to certificate rotation, which is exactly why teams skip it, but for anything handling financial data, health data, or credentials, we treat it as required rather than optional.

Beyond network-level protections, we also think about the device itself as untrusted territory for anything high-stakes. Root and jailbreak detection isn't foolproof, and a determined attacker can usually work around it, but it raises the cost of attack enough to matter for apps handling payments or health records, and it gives you a signal you can act on, like disabling biometric shortcuts or requiring step-up authentication on a device that reports as compromised. The same logic applies to code obfuscation and tamper detection on the binary itself: none of these controls stop a sufficiently motivated reverse engineer, but stacking several imperfect controls together is a genuinely different risk profile than relying on any single one, and for regulated industries, that layered posture is often what a security questionnaire is actually asking about.

Authentication and session handling on mobile

Mobile sessions live far longer than web sessions by user expectation, nobody wants to log into their banking app every time they open it, which means token handling has to be more careful, not less. Short-lived access tokens with silent refresh via a securely stored refresh token, biometric re-authentication gating for sensitive actions, and immediate token revocation on logout across all devices are the baseline. A session model copied directly from a web app, where the assumption is a fresh login every session, doesn't hold up against mobile usage patterns.

The most dangerous mobile security bug isn't the one an attacker finds. It's the one that was sitting in plain text on every user's device for a year before anyone looked.

Reverse engineering and why client-side checks aren't security

Any check that lives only in the client — a paywall gate, an admin flag, a discount validation — should be assumed public, because both iOS and Android apps can be decompiled and inspected by anyone with the right tooling and a few hours. Client-side logic is a UX convenience, never a security boundary; the enforcement has to happen server-side, every time, regardless of what the client claims about itself.

What we build in by default

Keychain or Keystore for anything sensitive, pinned certificates for financial or health data, server-side enforcement of every rule that matters, and token expiry that assumes the device will eventually be lost or compromised — these go into the base architecture of every app we build, not a checklist we run through if the client asks. Security that only exists because a client requested it in the spec is security that gets cut the first time the timeline gets tight.

If you're scoping something like this, see our mobile app development services.