An iOS app preserves connection trust by confirming it is talking to your real backend, not just to any server with a valid certificate, and preserves availability by planning for the moments that check could fail. Otukan checks the keys your hosts present against the set shipped in your app, detects interception and tampered trust checks, reads proxy and VPN context for sensitive requests, and applies a failure rule you set per endpoint. Backup keys and rehearsed rotation keep users connected through certificate changes. Apple’s App Transport Security stays the foundation. For the cross-platform view, see mobile man-in-the-middle attack prevention.
Transport validation and backend identity
By default, iOS accepts a server certificate when its chain ends at any root the device trusts. That is a long list, and it grows when a user installs a configuration profile and enables full trust for its root in Settings. An interception proxy only needs one such root.
Three layers of trust
| Layer | Who provides it | What it confirms | What it misses |
|---|---|---|---|
| App Transport Security | iOS | Modern TLS and a chain to a trusted root | Roots a user or attacker added |
| Key pinning | Otukan in your app | The host presents one of your own public keys | Nothing about the device’s state |
| Trust-check integrity | Otukan runtime checks | The validation code itself has not been replaced | Needs pinning to have something to protect |
Apple also lets apps declare pinned keys in the app’s configuration. Otukan works alongside that and adds what a static declaration cannot: detection when the trust check is hooked, signals to your backend and per-endpoint failure rules. Pinning details are covered on mobile app certificate pinning.
Certificate lifecycle and enterprise networks
Planning for change
Certificates are renewed, keys are rotated and certificate authorities change. Pinning to a whole certificate turns each renewal into an outage. Otukan pins public keys, ships a backup key for every critical host and records which key each connection matched. Your team rehearses the switch on a test host, so the production rotation is routine. A step-by-step rotation plan is in the certificate pinning rotation guide.
Corporate networks
Many organisations inspect TLS with a root pushed by device management. For a workforce app, that is expected behaviour, not an attack. You list the inspection roots your organisation uses, Otukan tells sanctioned inspection apart from any other foreign root, and you choose per host: general content can pass through inspection, while identity, payment and data-export hosts still demand your own keys. Signals mark inspection separately, so your security team is not chasing corporate proxies.
More than one networking layer
Not every request leaves through the same code. Your own API calls, embedded SDKs, web views and cross-platform HTTP clients can each use a different path to the network. Otukan maps which of your hosts are reached through which layer during scoping, applies key checks to the paths that carry sensitive data and states plainly which traffic sits outside that scope. Your team then knows exactly which connections are protected, rather than assuming all of them are.
Supported policies, failure behaviour and recovery
A failed trust check forces a choice between security and service. Make it before it happens.
| Endpoint type | Trust check fails | Proxy or VPN present | Recovery |
|---|---|---|---|
| Public content | Continue, send signal later | Continue | None needed |
| Sign-in | Stop and show a clear message | Warn, then continue | Retry on another network |
| Payments and transfers | Stop | Restrict to low-value actions | Retry on a trusted network |
| Account and security changes | Stop and alert | Step up authentication | Support contact inside the app |
Signals from a failed check are queued and sent once a trusted connection returns, so your backend still learns about the attempt. Users see a message that tells them what to do next instead of a silent failure.
Keeping the service up
Availability also means not punishing ordinary users for ordinary networks. Hotel captive portals, flaky mobile data and carrier proxies all produce connection errors that look alarming but are not attacks. Otukan separates a key mismatch from a plain network failure, so the app retries the second and only applies your trust rule to the first. Support teams see the difference in the signal, which shortens investigation when a customer reports that the app will not connect.
The platform overview is on iOS app security, and implementation material is in iOS app security guides.