If you work on an iOS app that touches money, health, identity, or enterprise data, you've probably heard some version of:
“iOS is secure by default. Apple takes care of that.”
In this episode, I break down what that actually means for your app—and where you're still completely on your own.
What we cover in this episode
We start from a simple but often-missing question:
“Who or what are we actually worried about for this app?”
From there, we walk through:
1. A practical threat model for iOS apps
Instead of abstract attacker diagrams, we focus on four concrete categories:
- Lost or stolen devices
- Curious or malicious users (jailbreakers, debuggers, tinkerers)
- Network attackers (dodgy Wi‑Fi, intercepted traffic, TLS issues)
- Backend compromise (your own services, or a third-party you depend on)
This alone already gives you a clearer lens for every “is this secure?” discussion on your team.
2. What iOS actually gives you
We then look at the main security building blocks Apple provides:
Hardware‑backed device security
Secure Enclave, hardware keys, and full‑device encryption as a baseline.
Code signing & sandboxing
Each app is signed and isolated; you don't get to poke around in other apps' files.
Data protection classes
Files can be made accessible only when the device is unlocked (or under stricter rules) if you choose the right class.
Keychain & Secure Enclave for secrets
Tokens and keys belong here, not sprinkled across UserDefaults and random files.
Platform‑level protections
App Store review, permission prompts, and transport security defaults that make many classes of attacks harder.
Used correctly, this is a very solid baseline.
3. The gaps Apple does not cover for you
This is where most teams get surprised:
Backend & API security
If an attacker has a valid token, platform security doesn't save you. Your authorization, rate limiting, and anomaly detection do.
Business logic & abuse
Limits, second factors, and high‑risk flows are entirely your responsibility. iOS has no idea how your product is supposed to behave.
Secrets baked into the app
Anything compiled into the binary should be treated as recoverable: static API keys, “secret” flags, hard‑coded crypto keys.
Phishing & social engineering
Most real‑world account takeovers start in someone's brain, not in the Secure Enclave.
Three things you can do this week
The episode closes with three concrete actions you can take in a few hours, not quarters:
1. Write a one‑page threat model
For your app, list the worst realistic outcomes for users and which of the four threat categories they fall into.
2. Review where you store sensitive data
Find out exactly where access/refresh tokens and encryption keys live. If anything critical is in UserDefaults or a plain file, create a task to move it into the Keychain or use a stricter data protection class.
3. Delete one “fake secret” from your app
Remove at least one hard‑coded key, static “shared secret”, or client‑only guardrail that your security model implicitly relies on.
Small, boring changes like this are often where the real security wins live.
About Sandboxed
A podcast for iOS engineers, security engineers, and product leads who work on apps where security actually matters—health, finance, identity, enterprise.
Each episode gives you a mental model you can apply this week—concrete enough to act on, without the 50-page spec.
If that sounds useful, I'd love to have you along.
Ready to dive deeper?
Next episode: Inside Keychain & Secure Enclave—the mistakes everyone makes.