Most iPhone apps handle user data badly. Get security wrong and you damage users, destroy your reputation, and sometimes break the law. Here’s the security baseline every iOS developer must cover — from data storage and authentication to network safety and shipping clean release builds.

Data Storage: Where Most Apps Fail

Use Keychain for Sensitive Data

UserDefaults is not secure. It’s stored as a plain plist file. Anyone with device access or a backup can read it.

Credentials, tokens, and anything sensitive go in the Keychain. Full stop. If your app stores an auth token in UserDefaults, fix it today.

• Use kSecAttrAccessibleWhenUnlockedThisDeviceOnly for tokens that shouldn’t survive a device restore.
• Never store passwords. Store tokens. Expire tokens. Refresh them.

Encrypt Sensitive Files

If your app writes sensitive data to disk — documents, cached responses, user data — use iOS Data Protection. Set NSFileProtectionComplete on files that should only be accessible when the device is unlocked.

Core Data and SwiftData support Data Protection too. Enable it in your entitlements, not just in code.

Network Security

HTTPS Everywhere

App Transport Security (ATS) enforces HTTPS by default in iOS. Don’t disable it. Don’t add NSAllowsArbitraryLoads exceptions unless you have a documented reason.

TLS 1.2 minimum. TLS 1.3 where your server supports it.

Certificate Pinning for Sensitive Flows

For apps handling financial data, health data, or authentication — pin your certificates. This prevents man-in-the-middle attacks even when the device trusts a rogue CA.

Use URLSession with a custom URLSessionDelegate to implement pinning. Libraries like TrustKit handle the heavy lifting if you don’t want to maintain it manually.

Not every app needs pinning. Healthcare, fintech, and anything with sensitive user data does.

Authentication

Use OAuth 2.0 with PKCE

Don’t roll your own auth. Use OAuth 2.0 with PKCE (Proof Key for Code Exchange) for user authentication. It’s the current standard and eliminates the authorization code interception attack.

Apple’s ASWebAuthenticationSession handles the browser-based flow correctly. Use it.

Biometric Authentication

Face ID and Touch ID are handled through the Local Authentication framework. Use them for local app unlock, not as a replacement for a server-side session. Biometrics confirm the device owner — not the account owner.

Sign in with Apple

If your app supports third-party login (Google, Facebook, etc.), Apple requires Sign in with Apple as an option. It’s also genuinely good for users — no email harvesting, built-in privacy relay. Implement it properly, not as an afterthought.

API Keys and Secrets

Don’t put secrets in your app bundle. Ever.

• API keys in source code get extracted from the binary. This is trivial. Don’t do it.
• Secrets belong in your backend. Your app authenticates to your backend; your backend calls the third-party API.
• For keys that must live on device (analytics SDKs, etc.), use obfuscation — not security, but it raises the bar.

Check your codebase for hardcoded API keys before every release. Use git-secrets or similar tooling to catch them in CI.

User Privacy

Request Only What You Need

Every permission request — camera, location, contacts — must have a clear purpose string. Apple reviews these. Users read them. Vague strings get rejected; aggressive permissions get deleted.

Ask for permissions at the point of use, not at launch. Asking for location on first open before showing why you need it guarantees a deny.

App Privacy Labels

Your App Store listing requires accurate privacy nutrition labels. Lying on these gets your app removed. Audit what data your third-party SDKs collect — analytics and advertising SDKs often collect more than you realize.

Code-Level Risks

Input Validation

Validate everything that comes from the user or the network. Don’t assume the server will catch it. Don’t assume the UI constraints are sufficient. Validate at the model layer.

Jailbreak Detection

For high-security apps (banking, healthcare), add jailbreak detection. It’s not foolproof, but it raises the cost of attack. Check for common jailbreak paths, Cydia, and sandbox violations.

Disable Debug Logging in Production

Verbose logs in release builds are a security risk. Use conditional compilation to strip debug output: #if DEBUG ... #endif. Never log tokens, passwords, or PII — not even in debug builds.

Build and Deploy Security

• Enable Hardened Runtime for macOS catalyst apps.
• Code sign all builds. Unsigned builds can be tampered with.
• Use App Store Connect’s export compliance information accurately. Most apps qualify for the standard encryption exemption.
• Rotate credentials on every team member departure.

Where to Start

If you’re auditing an existing app, prioritize in this order:

1. Credential storage — move anything sensitive from UserDefaults to Keychain.
2. Network security — verify HTTPS everywhere, no ATS exceptions.
3. API keys — find and remove anything hardcoded.
4. Privacy labels — audit what your SDKs actually collect.
5. Input validation — add model-layer validation for user-facing fields.

Don’t try to fix everything at once. Fix the critical issues first, then systematically work through the rest.

When to Bring in Help

Security audits by specialists are worth it before major launches, fundraising rounds, or when entering regulated industries. A good audit surfaces issues your team is too close to the codebase to see.

At Applefy, we build security in from the start — not as a retrofit. If you’re inheriting a codebase and want an honest assessment, talk to us.

Frequently Asked Questions

What’s the most common iOS security mistake?

Storing credentials in UserDefaults instead of Keychain. It’s the most frequent issue we see in code reviews and the easiest to fix.

Does every app need certificate pinning?

No. Certificate pinning makes sense for apps handling financial data, health records, or authentication tokens. For most consumer apps, standard HTTPS is sufficient.

How do I check if my app has hardcoded API keys?

Search your codebase for common patterns: strings ending in _key, _secret, _token. Run git-secrets or trufflehog on your repo. Check your third-party SDK configurations.

What happens if my app fails Apple’s privacy label review?

Apple will reject the build and ask you to correct the labels before resubmitting. Repeated inaccuracy can result in removal from the App Store.

Do I need to implement Sign in with Apple?

Yes, if your app supports any third-party login method (Google, Facebook, Twitter, etc.). Apple requires Sign in with Apple as an option in those cases.