DEV Community: Dheerendra Chaturvedi

DesignSystemKit: one design system for SwiftUI and UIKit, with runtime white-label theming

Dheerendra Chaturvedi — Tue, 10 Nov 2026 07:40:12 +0000

If you've built white-label apps, tenant-branded apps or even just a SwiftUI rewrite of a UIKit app, you know the pain: colours hard-coded in three places, buttons that look slightly different on every screen, and a dark mode that only half works.

DesignSystemKit is my answer: a native design system for SwiftUI and UIKit, distributed with Swift Package Manager. One set of tokens, typography, components and icons, with themes you can switch at runtime for white-label apps, tenant branding and seasonal skins. Free, MIT licensed, and no third-party dependencies.

What's inside

Module	What it gives you
`DesignSystemCore`	Semantic colour tokens (light + dark), spacing, radius, border, elevation and motion scales, typography, `DSTheme`, `ThemeStore` with persistence, a tenant `ThemeRegistry`, a `ThemeValidator` that checks WCAG contrast, and field validation. No UI framework imports.
`DesignSystemAssets`	Bundled Poppins fonts, a semantic icon catalog with SF Symbol fallback, and localized component strings (English, Spanish, German, Arabic, Hindi) with plurals.
`DesignSystemSwiftUI`	`.appTheme(...)`, `@ThemeTokens`, Dynamic Type text styles and components including buttons, text fields, checkbox, radio, toggle, picker, date field, card, badge, chip, banner, progress, dialog, empty state, skeleton/shimmer and more.
`DesignSystemUIKit`	Dynamic `UIColor`s and Dynamic Type `UIFont`s, theme observation for view controllers, window appearance binding, `DSUIButton`, `DSUITextField`, `DSUICardView`, `DSUIBadge`, `DSUILabel`.
`DesignSystemPreview`	A browsable catalog of every token and component with a live theme switcher.

Requirements: iOS 16+, iPadOS 16+, Mac Catalyst 16+, macOS 13+ (Core, Assets and SwiftUI). Xcode 16 or later, Swift 6 toolchain.

Install

.package(url: "https://github.com/eeshuu/DesignSystemKit.git", from: "1.0.0"),
// …
.target(name: "App", dependencies: [
    .product(name: "DesignSystemSwiftUI", package: "DesignSystemKit"),
    .product(name: "DesignSystemUIKit", package: "DesignSystemKit"), // only if you use UIKit
]),

Fonts, icons and translations ship with the package. Nothing has to be copied into your app.

SwiftUI in a few lines

@main
struct MyApp: App {
    @StateObject private var store = ThemeStore(persistence: UserDefaultsThemePersistence())
    init() { FontRegistry.registerBundledFonts() }

    var body: some Scene {
        WindowGroup { ContentView().appTheme(store: store) } // once, at the root
    }
}

struct ContentView: View {
    @ThemeTokens private var ds
    @State private var email = ""

    var body: some View {
        VStack(alignment: .leading, spacing: ds.spacing.lg) {
            DSText("Welcome back", style: .title)
            DSTextField("Email", text: $email, kind: .email,
                        validation: FieldValidator([.email("Enter a valid email")], isOptional: true).validate(email),
                        isRequired: true)
            DSButton("Continue", trailingIcon: .arrowRight, fullWidth: true) { }
        }
        .padding(ds.spacing.xl)
        .background(ds.colors.background)
    }
}

UIKit gets the same tokens

final class ProfileViewController: UIViewController, DSThemeable {
    private let store: ThemeStore
    private var subscription: DSThemeSubscription?
    private let titleLabel = DSUILabel(style: .heading1, text: "Profile")
    private let save = DSUIButton(title: "Save", variant: .primary)

    override func viewDidLoad() {
        super.viewDidLoad()
        subscription = store.observe(self) // applies now and on every theme change
    }

    func apply(theme: DSTheme) {
        view.backgroundColor = .ds(.background, theme: theme)
        titleLabel.apply(theme: theme)
        save.apply(theme: theme)
    }
}

Mixed apps work in both directions: DSHostingController themes SwiftUI inside UIKit, and the store is available via @Environment(\.dsThemeStore) for UIKit inside SwiftUI.

Runtime theming and white-label

store.selectTheme(id: "forest")         // brand theme
store.setAppearance(.dark)              // .system, .light or .dark
store.selectTheme(forTenant: "acme")    // tenant mapping you registered

Four themes are built in (standard, forest, sunset and midnight). Create your own in code, or load one from JSON; anything the file leaves out falls back to the standard theme:

var brand = DSTheme.standard
brand.id = "acme"
brand.light[.primary] = "#D9480F"
brand.dark[.primary] = "#FFA94D"
brand.components.buttonShape = .pill
store.apply(brand) // validated, including WCAG contrast; refused if it has errors

{ "id": "acme", "name": "Acme", "light": { "primary": "#D9480F" }, "components": { "buttonShape": "pill" } }

That means a server can ship a tenant's branding as a small JSON file, and a bad palette with unreadable contrast gets rejected instead of shipped.

Accessibility and quality

The test suites cover token values, contrast of every built-in palette, theme JSON, persistence, font registration, localization and plurals, Dynamic Type scaling, UIKit observation, and snapshots in light and dark. The sample app's UI tests cover theme switching, tenants, form validation, accessibility identifiers, mixed navigation and the largest Dynamic Type size.

The repo includes a sample app (Examples/DesignSystemDemo) with a component catalog, a SwiftUI sign-up screen, a UIKit profile screen and a settings tab for theme, appearance and tenant switching.

My other Swift packages

SecureStorageKit: Keychain, Face ID and Secure Enclave storage
AppLoggerKit: privacy-first logging with OSLog, JSON Lines, redaction and export

github.com/eeshuu/DesignSystemKit: MIT licensed (bundled Poppins fonts under the SIL Open Font License). Stars, issues and feedback are very welcome.

AppLoggerKit: privacy-first logging for Swift apps (OSLog, JSON Lines, redaction, export)

Dheerendra Chaturvedi — Tue, 10 Nov 2026 07:39:06 +0000

Logs are one of the most common places sensitive data leaks from an iOS app. They end up in sysdiagnoses, support emails, crash tickets and bug trackers, and a single print("\(user)") or "token=\(token)" can put an email address or a bearer token in all of them.

I wanted Apple's unified logging, optional log files users can send to support, and real privacy guarantees, without pulling in a third-party SDK. So I built AppLoggerKit: a free, MIT-licensed logging and local diagnostics package for Swift, SwiftUI and UIKit with no third-party dependencies.

What's inside

Module	What it gives you
`AppLoggerCore`	`AppLogger` with seven levels, lazy messages, categories and scoped loggers; structured `LogRecord` with a versioned JSON schema; public / private / sensitive metadata; a `Redactor`; `LogContext` for correlation IDs. Foundation only.
`AppLoggerOSLog`	`os.Logger` output with level mapping, Console.app filtering and OSLog privacy annotations.
`AppLoggerFile`	JSON Lines files with size/time rotation and retention, streaming search, paging, statistics, and redacted JSON Lines / text / ZIP exports.
`AppLoggerUI`	Optional SwiftUI and UIKit log viewer, live console, ShareLink export button and `\.appLogger` in the environment.
`AppLoggerTesting`	In-memory and failing destinations plus `AppLogger.capturing()` for your tests.

Requirements: iOS 16+, iPadOS 16+, Mac Catalyst 16+, macOS 13+. Xcode 16 or later, Swift 6 toolchain.

Install

.package(url: "https://github.com/eeshuu/AppLoggerKit.git", from: "1.0.0"),
// …
.target(name: "App", dependencies: [
    .product(name: "AppLoggerCore", package: "AppLoggerKit"),
    .product(name: "AppLoggerOSLog", package: "AppLoggerKit"),
    .product(name: "AppLoggerFile", package: "AppLoggerKit"), // only if you want log files
]),

Quick start

import AppLoggerCore
import AppLoggerFile
import AppLoggerOSLog

let fileLog = FileLogDestination(configuration: .default) // opt-in: no files without it

let logger = AppLogger(configuration: .init(
    subsystem: "com.example.myapp",
    minimumLevel: .debug,
    categoryLevels: ["network": .trace],
    destinations: [OSLogDestination(), fileLog]
))

logger.info("Application launched", category: "lifecycle")
logger.error("Unable to load profile", metadata: ["feature": "profile", "attempt": 2], error: error)

Messages and metadata are autoclosures, so a call below the active level never builds its string.

Privacy is the main feature

Nothing is captured automatically. No request or response bodies, headers, device identifiers or user data. Only what you pass is logged.

Metadata has a privacy class, enforced by the compiler. Literals are public; runtime values must say what they are, so "\(user.email)" doesn't compile as metadata:

logger.notice("Signed in", metadata: [
    "method": "password",              // public literal
    "userID": .private(user.id),       // shown in live outputs, redacted from files and exports
    "token": .sensitive(token),        // never reaches any destination
    "endpoint": .url(request.url!),    // credentials, fragment and query values stripped
])

Redaction runs before every destination. Keys like authorization, token, password, secret, cookie and api_key are redacted whatever their class, and bearer tokens, JWTs and password=… patterns are scrubbed from messages, values and error descriptions. You can add your own rules.

Files and exports are stricter. Private values are redacted by default, and an export re-applies redaction to whatever was stored.

Correlation IDs that follow async code

try await LogContext.withCorrelationID(requestID) {
    logger.info("Fetching profile")
    try await api.loadProfile() // every log inside, at any depth, carries the ID
}

Search and export logs on device

Perfect for a "Send logs to support" button:

let reader = LogReader(store: fileLog.store)
let recentErrors = try await reader.tail(matching: LogQuery(minimumLevel: .error, since: .now - 3600))

await logger.flush()
let export = try await LogExporter(store: fileLog.store).export(LogExportRequest(
    format: .zip,              // logs.jsonl + logs.txt + manifest.json
    query: LogQuery(since: .now - 86_400),
    maxBytes: 5_000_000,
    note: "Ticket 4821"
))
// Present export.url with ShareLink or UIActivityViewController(logExport: export).

Built for Swift 6 concurrency

Every API is safe from any thread or actor. Log calls never block on I/O: records are queued under a lock and delivered in order by one background task. OSLogDestination writes on the calling thread so the last records before a crash aren't lost. Levels can be changed at runtime from a debug menu or remote flag without touching call sites, and a destination that throws never affects the call site.

Testable

import AppLoggerTesting

@Test func loadingLogsProgress() async {
    let (logger, capture) = AppLogger.capturing()
    await ProfileRepository(logger: logger).load()
    await logger.flush()
    #expect(capture.messages == ["Loading profile", "Profile loaded"])
}

What it deliberately doesn't do

No hosted dashboards or remote ingestion, no analytics or behaviour tracking, no crash reporting, and no encrypted storage: log files are ordinary local files protected by iOS file protection and excluded from backups. If you need to store secrets, that's what my other package, SecureStorageKit, is for.

The repo includes a sample app (Examples/LoggerDemo) and docs on architecture, privacy and the file format.

github.com/eeshuu/AppLoggerKit: MIT licensed. Stars, issues and feedback are very welcome.

My other Swift packages

SecureStorageKit: Keychain, Face ID and Secure Enclave storage
DesignSystemKit: one design system for SwiftUI and UIKit, with runtime white-label theming

SecureStorageKit: a dependency-free Swift package for Keychain, Face ID and Secure Enclave storage

Dheerendra Chaturvedi — Tue, 10 Nov 2026 07:33:00 +0000

Every iOS app I've worked on in the last decade ended up with its own hand-rolled Keychain wrapper. Most of them had the same bugs: errSecDuplicateItem not handled, queries that didn't match the attributes used to save, background reads failing with errSecInteractionNotAllowed and logging the user out, and tokens quietly ending up in print statements.

So I packaged the patterns I keep rewriting into SecureStorageKit: a free, open-source Swift package for storing secrets on iOS, iPadOS and macOS. It's serverless, built only on Apple frameworks (Keychain, LocalAuthentication, CryptoKit and the Secure Enclave), and has no third-party dependencies.

What's inside

Area	Features
Keychain	Save, read, update and delete Strings, Data and Codable values. Scoped clear, accessibility options, access groups, iCloud sync, typed errors, migration from legacy Keychain wrappers.
Biometrics	Item-level Face ID / Touch ID / passcode protection, `biometryCurrentSet`, availability checks and lockout.
Crypto	AES-256-GCM in a versioned envelope, HKDF, key manager (create, rotate, retire), recoverable key rotation engine, streaming encrypted file vault, Secure Enclave signing and sealing.
Accounts	Token store with refresh, per-account isolation and logout cleanup; multi-account vault.
Ops	Redacted logging, audit log, in-memory mock, versioned Codable migrations, password-protected backup and restore.

Requirements: iOS 15+, macOS 12+, Mac Catalyst 15+, Swift 6 toolchain (Xcode 16 or later).

Install

In Xcode: File ▸ Add Package Dependencies… and paste the repo URL. Or in Package.swift:

.package(url: "https://github.com/eeshuu/SecureStorageKit.git", from: "1.0.1"),
// …
.target(name: "App", dependencies: [
    .product(name: "SecureStorageKit", package: "SecureStorageKit"),
]),

Quick start

import SecureStorageKit

let storage = SecureStorage(service: "my-app")

try await storage.save("secret", forKey: "access_token")
let token: String? = try await storage.retrieve("access_token", as: String.self)
try await storage.delete("access_token")
try await storage.clearAll() // only this namespace, nothing else

// Protected by the Keychain item itself: no Face ID, no data.
try await storage.save("private", forKey: "vault", protection: .biometryCurrentSet)
let value: String? = try await storage.retrieve("vault", as: String.self,
                                                authenticationReason: "Unlock secure data")

retrieve returns nil when the key doesn't exist, and every failure is a typed StorageError.

A few things I'm proud of

Tokens that refresh themselves, once. Concurrent callers share a single refresh, and token values print as <redacted>.

let tokens = SecureTokenStore(service: "my-app", refresher: AuthAPI())
let bearer = try await tokens.validAccessToken(for: "alice") // refreshes once, even if called concurrently
try await tokens.logout(account: "alice") // tokens + session secrets

Encryption with real key rotation. Old data keeps decrypting while new data uses the new key; retire the old one when nothing needs it.

let keys = KeyManager(storage: SecureStorage(service: "my-app", namespace: "keys"))
let sealed = try await keys.encrypt(data, associatedData: Data(recordID.utf8))
try await keys.rotate()            // new data uses default#2; default#1 still decrypts
try await keys.retire(version: 1)  // destroys default#1 once nothing uses it

Secure Enclave keys that never leave the chip.

let se = SecureEnclaveManager(storage: storage.namespaced("se"))
let publicKey = try await se.createSigningKey(tag: "device", protection: .biometryCurrentSet)
let signature = try await se.sign(challenge, tag: "device", prompt: .init(reason: "Approve sign-in"))

Testable without a device. An in-memory Keychain lets you simulate Face ID cancel, a new fingerprint, or a locked device in unit tests.

let mock = InMemoryKeychain()
let storage = SecureStorage(configuration: .init(service: "test"), backend: mock)
mock.authenticationResult = .failure(.userCancelled)
mock.simulateBiometryEnrollmentChange()
mock.isDeviceLocked = true

Easy migration. Import existing items from KeychainAccess, SwiftKeychainWrapper or raw SecItem code with MigrationManager.

The repo also ships a SwiftUI demo app (Keychain, Biometrics, Encryption and Tokens tabs), 66 unit tests, a full API reference and a written threat model.

An honest note

SecureStorageKit has a full test suite but has not had an independent security audit yet. The threat model in Docs/ThreatModel.md spells out what is and isn't protected. If you work in security, reviews, issues and PRs are very welcome.

Want the background?

If you'd like the reasoning behind these choices (accessibility classes, ThisDeviceOnly, biometry binding, Secure Enclave keys), I wrote a long guide: iOS Application Security: SSL Pinning, Keychain, API Encryption and App Attest.

github.com/eeshuu/SecureStorageKit: a star helps other iOS devs find it. MIT licensed.

My other Swift packages

AppLoggerKit: privacy-first logging with OSLog, JSON Lines, redaction and export
DesignSystemKit: one design system for SwiftUI and UIKit, with runtime white-label theming

iOS Application Security: SSL Pinning, Keychain, API Encryption and App Attest

Dheerendra Chaturvedi — Tue, 10 Nov 2026 07:32:14 +0000

iOS has a strong security baseline: code signing, sandboxing, App Transport Security, Data Protection and the Secure Enclave are all on by default. That baseline leads many teams to assume the platform covers everything. It doesn't. The platform protects the user from malicious apps very well, but it does much less to protect your backend from a modified copy of your app, a scripted client that impersonates it, or a user who deliberately intercepts their own traffic.

This guide looks at four questions that come up in almost every security review of an iOS app. For each one, the goal is an honest answer: what the technique actually protects against, what it does not, and how to implement it correctly if you decide you need it.

Is SSL Pinning Still Necessary?
Secure Keychain Storage vs UserDefaults
API Request Encryption Beyond HTTPS
Device Attestation, App Attest and Application Integrity

Code samples use Swift 5.9+ with CryptoKit, Security and DeviceCheck. Minimum OS versions are noted where an API requires them.

A threat model to keep in mind

Attacker	Capabilities	Typical goal
Network attacker	Public Wi-Fi, rogue access point, compromised router or CA	Read or modify traffic of an unsuspecting user
Curious / hostile user	Owns the device, installs a proxy CA, may jailbreak, runs Frida	Understand your API, bypass paywalls, cheat, scrape
Automated abuser	Scripts calling your API directly, emulators, device farms	Fake signups, credential stuffing, promo abuse, bots
Device thief / forensics	Physical access, backups, possibly a jailbreak exploit	Extract tokens, credentials, personal data at rest

Keep these four actors in mind as you read. Most disagreements about whether a control is "necessary" come from people silently assuming different attackers.

1. Is SSL Pinning Still Necessary?

TL;DR — For most apps, ATS plus Certificate Transparency is enough, and pinning adds outage risk for limited gain. Pinning is still worth it for banking, health, payments, enterprise and high-value APIs, where a mis-issued or locally installed certificate is a realistic threat. If you pin, pin public keys (SPKI), pin at the CA or intermediate level, always ship a backup pin, and prefer Apple's declarative NSPinnedDomains over hand-written code.

What pinning actually does

During a normal TLS handshake, iOS checks that the server certificate chains up to any root in the device trust store and that the hostname matches. Pinning adds a second, stricter rule: the chain must also contain a specific certificate or public key that you chose. Even a perfectly valid certificate from another CA is rejected.

That closes two gaps that standard validation leaves open:

Mis-issued or compromised CA certificates. Any of the ~150 trusted roots can, in principle, issue a certificate for your domain.
User- or MDM-installed root certificates. Corporate proxies, debugging tools (Charles, Proxyman, mitmproxy) and malware-installed profiles all rely on adding a root that iOS then trusts for every app.

What has changed since pinning became popular

Pinning became standard advice around 2012-2015. Several things have shifted since:

App Transport Security (iOS 9+) enforces TLS 1.2+, forward secrecy and strong ciphers by default. Plain HTTP requires an explicit exception.
Certificate Transparency is enforced by Apple for publicly trusted certificates. A mis-issued certificate must be publicly logged, which makes silent attacks much harder and lets you monitor logs for your domain.
Custom root certificates require explicit user action. Since iOS 10.3 a user must manually enable full trust for an installed profile's root in Settings.
Certificate lifetimes are shrinking. Public TLS certificates now rotate far more often than they used to, and the CA/Browser Forum has approved a schedule that keeps shortening maximum validity over the next few years. Leaf pinning is becoming an operational hazard.
Apple added declarative pinning. Since iOS 14, NSPinnedDomains in Info.plist lets you pin without writing trust-evaluation code.

What pinning does NOT protect against

Be precise about this in design reviews, because pinning is often oversold:

A user reverse-engineering your API on their own jailbroken device. Tools like Frida and objection disable pinning in seconds by hooking the trust-evaluation functions. Pinning raises the bar for casual inspection, nothing more.
Server-side vulnerabilities. Broken authorization, injection and IDOR bugs are reachable through any client, including curl.
Compromised devices. Malware with root access reads data before it is encrypted.

In other words, pinning protects the honest user on a hostile network. It is not a defense against the device owner.

The real cost: bricking your own app

The classic pinning failure is self-inflicted. You pin the leaf certificate, the certificate auto-renews with a new key, and every installed copy of the app stops talking to your backend until users update, which some never do. Teams that have experienced this outage usually remove pinning entirely rather than fix it, which is the wrong lesson.

Decision guide

App type	Recommendation
Content, social, utilities, most consumer apps	Do not pin. Rely on ATS + Certificate Transparency. Invest in server-side auth and App Attest.
Fintech, banking, payments, crypto wallets	Pin SPKI of your CA / intermediate with at least one backup. Often required by regulators and pentest checklists (OWASP MASVS-NETWORK).
Healthcare, government, enterprise / MDM apps	Pin, unless your customers' corporate TLS inspection is a requirement; then document the exception.
Apps talking to your own private PKI	Pin your private root; standard validation won't trust it anyway.

Option A: Declarative pinning with NSPinnedDomains (recommended)

This is Apple's own mechanism, evaluated by the networking stack for URLSession, WKWebView and Network.framework. No delegate code, no chance of forgetting to call the completion handler.

<!-- Info.plist -->
<key>NSAppTransportSecurity</key>
<dict>
  <key>NSPinnedDomains</key>
  <dict>
    <key>api.example.com</key>
    <dict>
      <key>NSIncludesSubdomains</key>
      <true/>
      <!-- Pin the issuing CA / intermediate, not the leaf -->
      <key>NSPinnedCAIdentities</key>
      <array>
        <dict>
          <key>SPKI-SHA256-BASE64</key>
          <string>PRIMARY_CA_SPKI_HASH_BASE64=</string>
        </dict>
        <dict>
          <!-- Backup: a different CA you could switch to tomorrow -->
          <key>SPKI-SHA256-BASE64</key>
          <string>BACKUP_CA_SPKI_HASH_BASE64=</string>
        </dict>
      </array>
    </dict>
  </dict>
</dict>

Use NSPinnedLeafIdentities instead only if you control certificate issuance and key reuse tightly. Generate a pin from a live server like this:

# Compute an SPKI SHA-256 pin
openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts </dev/null \
  | openssl x509 -pubkey -noout \
  | openssl pkey -pubin -outform der \
  | openssl dgst -sha256 -binary \
  | openssl enc -base64

Note that the command above hashes the first certificate (the leaf). To pin an intermediate, save the chain with -showcerts, extract the intermediate into its own PEM file and run the same pipeline on it.

Option B: Programmatic pinning with URLSessionDelegate

Use code when you need runtime flexibility: remotely updatable pins, different pins per environment, or telemetry when a pin fails. The key detail most tutorials get wrong: SecKeyCopyExternalRepresentation returns the raw key, not the SubjectPublicKeyInfo structure that openssl hashes. You must prepend the correct ASN.1 header before hashing, or your pins will never match.

// PinningDelegate.swift (iOS 15+)
import Foundation
import CryptoKit
import Security

final class PinningDelegate: NSObject, URLSessionDelegate {

    /// Base64 SHA-256 of SPKI. Always include at least one backup.
    private let pinnedHashes: Set<String>

    init(pinnedHashes: Set<String>) { self.pinnedHashes = pinnedHashes }

    // ASN.1 SPKI headers for the two key types you will realistically see
    private static let rsa2048Header: [UInt8] = [
        0x30, 0x82, 0x01, 0x22, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86,
        0xf7, 0x0d, 0x01, 0x01, 0x01, 0x05, 0x00, 0x03, 0x82, 0x01, 0x0f, 0x00]
    private static let ecP256Header: [UInt8] = [
        0x30, 0x59, 0x30, 0x13, 0x06, 0x07, 0x2a, 0x86, 0x48, 0xce, 0x3d, 0x02,
        0x01, 0x06, 0x08, 0x2a, 0x86, 0x48, 0xce, 0x3d, 0x03, 0x01, 0x07, 0x03,
        0x42, 0x00]

    func urlSession(_ session: URLSession,
                    didReceive challenge: URLAuthenticationChallenge,
                    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                                  URLCredential?) -> Void) {
        guard challenge.protectionSpace.authenticationMethod ==
                NSURLAuthenticationMethodServerTrust,
              let trust = challenge.protectionSpace.serverTrust else {
            completionHandler(.performDefaultHandling, nil); return
        }

        // 1. ALWAYS run the system evaluation first (chain, hostname, expiry, CT).
        var error: CFError?
        guard SecTrustEvaluateWithError(trust, &error) else {
            completionHandler(.cancelAuthenticationChallenge, nil); return
        }

        // 2. Then require that some certificate in the chain matches a pin.
        let chain = (SecTrustCopyCertificateChain(trust) as? [SecCertificate]) ?? []
        let matched = chain.contains { cert in
            guard let hash = Self.spkiHash(of: cert) else { return false }
            return pinnedHashes.contains(hash)
        }

        if matched {
            completionHandler(.useCredential, URLCredential(trust: trust))
        } else {
            // Report to telemetry here, then fail closed.
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }

    private static func spkiHash(of cert: SecCertificate) -> String? {
        guard let key = SecCertificateCopyKey(cert),
              let raw = SecKeyCopyExternalRepresentation(key, nil) as Data?,
              let attrs = SecKeyCopyAttributes(key) as? [CFString: Any],
              let type = attrs[kSecAttrKeyType] as? String,
              let bits = attrs[kSecAttrKeySizeInBits] as? Int else { return nil }

        let header: [UInt8]
        switch (type, bits) {
        case (kSecAttrKeyTypeRSA as String, 2048):         header = rsa2048Header
        case (kSecAttrKeyTypeECSECPrimeRandom as String, 256): header = ecP256Header
        default: return nil   // add headers for RSA-4096 / P-384 if your chain uses them
        }
        let digest = SHA256.hash(data: Data(header) + raw)
        return Data(digest).base64EncodedString()
    }
}

Operational checklist

Pin public keys (SPKI), never whole certificates. Keys can survive renewal; certificates can't.
Pin the intermediate or root CA unless you have a strong reason to pin the leaf.
Ship at least two pins, one of which is a backup key or second CA not currently in use.
Add a remote kill switch or pin-update channel (signed config) so an incident does not require an App Store release.
Log pin failures to analytics. A spike tells you about either an attack or your own misconfiguration.
Keep pins out of debug builds or make them configurable, so QA can still use proxies.
Monitor Certificate Transparency logs for your domains (crt.sh, or a CT monitoring service).

2. Secure Keychain Storage vs UserDefaults

TL;DR — UserDefaults is a preferences file, not secure storage. Anything that grants access (tokens, passwords, API keys, encryption keys, PII) belongs in the Keychain with the strictest accessibility class your app can tolerate, ideally a ThisDeviceOnly variant. For the highest-value secrets, generate keys inside the Secure Enclave so they can never be exported at all.

Where UserDefaults data actually lives

UserDefaults.standard writes a property list to Library/Preferences/<bundle-id>.plist inside your app's container. That file:

is stored as plain text / binary plist, with no application-level encryption;
is protected only by the default file Data Protection class, which means it is readable whenever the device has been unlocked once since boot;
is included in iCloud and computer backups and can be read from an unencrypted local backup with free tools;
is trivially readable on a jailbroken device, and by anyone with filesystem access to a simulator or test device.

UserDefaults is perfect for what it was designed for: theme choice, onboarding flags, last selected tab. It was never meant to hold secrets.

How the Keychain is different

Keychain items are stored in an encrypted SQLite database managed by the securityd daemon, not inside your container. Each item is encrypted with a per-item key, wrapped by a class key that is tied to the device UID (fused into the Secure Enclave hardware) and, for most classes, to the user's passcode. Your app never touches the database directly; it asks securityd through the SecItem API, which enforces your app's access group.

Side-by-side comparison

	UserDefaults	Keychain
Encryption at rest	File-level Data Protection only	Per-item encryption, hardware-bound keys
Access control	Anyone with access to the container	securityd enforces app / access group; optional biometrics
Backups	Always included	Included unless ThisDeviceOnly; encrypted
Survives app deletion	No	Usually yes (plan for it)
Sharing between apps	App Groups suite	Keychain access groups
Performance	Fast, cached in memory	Slower IPC call; cache in memory carefully
Good for	Preferences, flags, non-sensitive state	Tokens, passwords, keys, secrets, PII

Choosing an accessibility class

The kSecAttrAccessible attribute decides when an item can be decrypted and whether it can leave the device in a backup. Pick the strictest one that still works for your feature:

Class	Readable when	Migrates to new device?	Use for
WhenPasscodeSetThisDeviceOnly	Unlocked, and only if a passcode is set (item is deleted if passcode is removed)	No	Highest-value secrets
WhenUnlockedThisDeviceOnly	Device unlocked	No	Session tokens used in foreground
WhenUnlocked (default)	Device unlocked	Yes	Credentials you want restored
AfterFirstUnlockThisDeviceOnly	After first unlock since boot	No	Tokens needed by background refresh / push
AfterFirstUnlock	After first unlock since boot	Yes	Background access + restore

All class names are prefixed with kSecAttrAccessible. The old Always classes are deprecated; do not use them.

A small, correct Keychain wrapper

Most Keychain bugs come from three mistakes: not handling errSecDuplicateItem, querying with a different set of attributes than you saved with, and ignoring errSecInteractionNotAllowed when code runs in the background while the device is locked. This wrapper handles all three.

// KeychainStore.swift
import Foundation
import Security

enum KeychainError: Error {
    case unexpectedStatus(OSStatus)
    case itemNotFound
    case locked          // errSecInteractionNotAllowed: device locked, try later
}

struct KeychainStore {
    let service: String
    var accessGroup: String? = nil
    var accessibility: CFString = kSecAttrAccessibleWhenUnlockedThisDeviceOnly

    private func baseQuery(_ account: String) -> [CFString: Any] {
        var q: [CFString: Any] = [
            kSecClass: kSecClassGenericPassword,
            kSecAttrService: service,
            kSecAttrAccount: account,
            kSecUseDataProtectionKeychain: true   // consistent behaviour on macOS too
        ]
        if let accessGroup { q[kSecAttrAccessGroup] = accessGroup }
        return q
    }

    func set(_ data: Data, for account: String) throws {
        let query = baseQuery(account)
        let update: [CFString: Any] = [kSecValueData: data,
                                       kSecAttrAccessible: accessibility]
        var status = SecItemUpdate(query as CFDictionary, update as CFDictionary)
        if status == errSecItemNotFound {
            var add = query
            add.merge(update) { $1 }
            status = SecItemAdd(add as CFDictionary, nil)
        }
        try check(status)
    }

    func data(for account: String) throws -> Data {
        var query = baseQuery(account)
        query[kSecReturnData] = true
        query[kSecMatchLimit] = kSecMatchLimitOne
        var result: AnyObject?
        let status = SecItemCopyMatching(query as CFDictionary, &result)
        try check(status)
        guard let data = result as? Data else { throw KeychainError.itemNotFound }
        return data
    }

    func delete(_ account: String) throws {
        let status = SecItemDelete(baseQuery(account) as CFDictionary)
        if status != errSecItemNotFound { try check(status) }
    }

    private func check(_ status: OSStatus) throws {
        switch status {
        case errSecSuccess: return
        case errSecItemNotFound: throw KeychainError.itemNotFound
        case errSecInteractionNotAllowed: throw KeychainError.locked
        default: throw KeychainError.unexpectedStatus(status)
        }
    }
}

// Usage
let tokens = KeychainStore(service: "com.example.app.auth")
try tokens.set(Data(accessToken.utf8), for: "accessToken")

Protecting an item with Face ID / Touch ID

You can bind an item to biometrics so it can only be read after the user authenticates. The check happens inside the Secure Enclave, not in your app process, so hooking LAContext does not bypass it.

// Biometric-bound Keychain item
import LocalAuthentication

func storeBiometricProtected(_ secret: Data, account: String) throws {
    var cfError: Unmanaged<CFError>?
    guard let access = SecAccessControlCreateWithFlags(
        nil,
        kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
        .biometryCurrentSet,         // invalidated if fingerprints / face are re-enrolled
        &cfError) else {
        throw cfError!.takeRetainedValue() as Error
    }

    let query: [CFString: Any] = [
        kSecClass: kSecClassGenericPassword,
        kSecAttrService: "com.example.app.vault",
        kSecAttrAccount: account,
        kSecAttrAccessControl: access,
        kSecValueData: secret,
        kSecUseDataProtectionKeychain: true
    ]
    SecItemDelete([kSecClass: kSecClassGenericPassword,
                   kSecAttrService: "com.example.app.vault",
                   kSecAttrAccount: account,
                   kSecUseDataProtectionKeychain: true] as CFDictionary)
    let status = SecItemAdd(query as CFDictionary, nil)
    guard status == errSecSuccess else { throw KeychainError.unexpectedStatus(status) }
}

func readBiometricProtected(account: String) throws -> Data {
    let context = LAContext()
    context.localizedReason = "Unlock your vault"
    let query: [CFString: Any] = [
        kSecClass: kSecClassGenericPassword,
        kSecAttrService: "com.example.app.vault",
        kSecAttrAccount: account,
        kSecReturnData: true,
        kSecUseAuthenticationContext: context,
        kSecUseDataProtectionKeychain: true
    ]
    var result: AnyObject?
    let status = SecItemCopyMatching(query as CFDictionary, &result)  // shows Face ID
    guard status == errSecSuccess, let data = result as? Data else {
        throw KeychainError.unexpectedStatus(status)
    }
    return data
}

Remember to add NSFaceIDUsageDescription to Info.plist. Use .userPresence instead of .biometryCurrentSet if you want passcode fallback.

Going further: keys that never leave the Secure Enclave

For signing keys, the best secret is one your app can use but never read. CryptoKit makes this a few lines. The private key is generated inside the Secure Enclave; your app only receives an encrypted, device-bound blob that is useless on any other device.

// Secure Enclave signing key
import CryptoKit

guard SecureEnclave.isAvailable else { /* fall back to a software P256 key */ }

let key = try SecureEnclave.P256.Signing.PrivateKey()
// Persist the opaque handle (NOT the key material) in the Keychain:
try tokens.set(key.dataRepresentation, for: "deviceSigningKey")

// Later
let blob = try tokens.data(for: "deviceSigningKey")
let restored = try SecureEnclave.P256.Signing.PrivateKey(dataRepresentation: blob)
let signature = try restored.signature(for: Data("payload".utf8))
let publicKeyToRegister = restored.publicKey.derRepresentation

Common mistakes

Keychain items survive uninstall. If a user deletes and reinstalls, an old token may still be there. Store a "has launched" flag in UserDefaults (which is deleted) and wipe stale Keychain items on first launch.
Hard-coding API secrets in the binary and then "protecting" them in the Keychain. Anything compiled into the app can be extracted with strings. Real secrets must stay on the server.
Reading Keychain items from background tasks with a WhenUnlocked class, then treating errSecInteractionNotAllowed as "logged out".
Logging tokens with print or os_log using %{public}@.
Forgetting other leak paths: URLCache, screenshots in the app switcher, pasteboard, Core Data / SwiftData stores, and crash reports can all contain sensitive data.

3. API Request Encryption Beyond HTTPS

TL;DR — HTTPS already encrypts your traffic in transit, so adding a second layer is not automatically better. It earns its place in specific situations: TLS terminates before your trusted service, you need end-to-end confidentiality for regulated data, you must prove a request was not tampered with or replayed, or you want requests bound to a specific device. The strongest pattern is device-bound request signing (Secure Enclave key) plus, where needed, payload encryption with ephemeral key agreement (ECDH or HPKE). A shared symmetric key baked into the app is not security.

What HTTPS gives you, and where it stops

TLS gives confidentiality, integrity and server authentication between two endpoints. The important word is endpoints. In real architectures, TLS often ends well before the code that handles the data:

CDNs, WAFs and load balancers terminate TLS and see plaintext request bodies;
API gateways and service meshes may log headers and payloads for debugging;
on the client, a user with a proxy CA (or a hooked TLS library) reads every request;
TLS says nothing about which client sent a request, or whether it is a replay.

Application-layer protection addresses those gaps. It does not stop a determined attacker who controls the device from reading data before it is encrypted, and it's worth being upfront about that.

Three distinct goals, three different tools

Goal	Tool	Protects against
Integrity + authenticity	Request signing (asymmetric, device-bound key)	Tampering by intermediaries, forged requests from other clients, stolen bearer tokens being used elsewhere
Freshness	Timestamp + nonce inside the signed data	Replay of captured requests
Confidentiality end-to-end	Payload encryption (ECDH / HPKE + AES-GCM)	Plaintext exposure at TLS terminators, logs, proxies

Anti-pattern: a static AES key in the app

The most common "encryption beyond HTTPS" implementation is AES with a key compiled into the app. Every copy of the app shares the same key, it can be extracted from the binary in minutes, and once it leaks every user's traffic is exposed retroactively. HMAC with an embedded secret has the same flaw for signing. If the key ships in the IPA, assume the attacker has it.

Pattern 1: Device-bound request signing

At registration (ideally right after App Attest, see section 4), the app creates a Secure Enclave key and sends the public key to the server, which associates it with the user and device. Every sensitive request is then signed. A stolen access token is useless without the private key, which cannot leave the device.

Build a canonical string

Signature schemes break when client and server serialize differently. Define a strict canonical form and hash the body rather than including it raw:

METHOD \n
PATH_WITH_QUERY \n
TIMESTAMP (unix seconds) \n
NONCE (random, base64url) \n
BASE64(SHA256(BODY))

// RequestSigner.swift
import CryptoKit
import Foundation

struct RequestSigner {
    let key: SecureEnclave.P256.Signing.PrivateKey
    let keyID: String          // id the server assigned at registration

    func sign(_ request: inout URLRequest) throws {
        let method = request.httpMethod ?? "GET"
        let path = request.url.map { u in
            u.path + (u.query.map { "?" + $0 } ?? "")
        } ?? "/"
        let timestamp = String(Int(Date().timeIntervalSince1970))
        let nonce = Self.randomNonce()
        let bodyHash = Data(SHA256.hash(data: request.httpBody ?? Data()))
            .base64EncodedString()

        let canonical = [method, path, timestamp, nonce, bodyHash]
            .joined(separator: "\n")
        let signature = try key.signature(for: Data(canonical.utf8))

        request.setValue(keyID, forHTTPHeaderField: "X-Key-Id")
        request.setValue(timestamp, forHTTPHeaderField: "X-Timestamp")
        request.setValue(nonce, forHTTPHeaderField: "X-Nonce")
        request.setValue(signature.derRepresentation.base64EncodedString(),
                         forHTTPHeaderField: "X-Signature")
    }

    private static func randomNonce() -> String {
        var bytes = [UInt8](repeating: 0, count: 16)
        _ = SecRandomCopyBytes(kSecRandomDefault, bytes.count, &bytes)
        return Data(bytes).base64EncodedString()
            .replacingOccurrences(of: "+", with: "-")
            .replacingOccurrences(of: "/", with: "_")
            .replacingOccurrences(of: "=", with: "")
    }
}

Server-side verification rules

Reject if |now - timestamp| exceeds a small window (e.g. 60-300 seconds).
Reject if the nonce has been seen within that window (store nonces in Redis with a TTL).
Rebuild the canonical string from the received request, never from client-sent values alone.
Verify the ECDSA P-256 signature with the public key registered for X-Key-Id, and check that key belongs to the authenticated user.

Pattern 2: End-to-end payload encryption

When the payload itself must stay confidential past TLS termination, encrypt it to a public key whose private half lives only in the service that needs the data (ideally in an HSM or KMS). The client generates a fresh ephemeral key for every request, so there is no shared secret in the app and past traffic stays safe even if a device is compromised later.

Option 2a: HPKE (iOS 17+)

Hybrid Public Key Encryption (RFC 9180) is the standardized version of exactly this pattern, and CryptoKit supports it natively. Prefer it when you can raise your deployment target, because the server side can use any RFC 9180 library.

// HPKE with CryptoKit
import CryptoKit

@available(iOS 17.0, *)
func sealWithHPKE(_ plaintext: Data,
                  serverPublicKey: P256.KeyAgreement.PublicKey) throws
    -> (encapsulatedKey: Data, ciphertext: Data) {

    let suite = HPKE.Ciphersuite.P256_SHA256_AES_GCM_256
    let info = Data("com.example.api.v1".utf8)     // binds ciphertext to this protocol
    var sender = try HPKE.Sender(recipientKey: serverPublicKey,
                                 ciphersuite: suite, info: info)
    let ciphertext = try sender.seal(plaintext)
    return (sender.encapsulatedKey, ciphertext)
}

Option 2b: ECDH + HKDF + AES-GCM (iOS 13+)

If you support older OS versions, the same construction can be built from CryptoKit primitives. Document the exact parameters so the backend team can mirror them.

// Manual hybrid encryption
import CryptoKit

struct EncryptedEnvelope: Codable {
    let ephemeralPublicKey: String     // base64 x9.63
    let salt: String                   // base64
    let ciphertext: String             // base64 AES.GCM combined (nonce|ct|tag)
}

func encrypt(_ plaintext: Data,
             to serverKey: P256.KeyAgreement.PublicKey,
             associatedData: Data) throws -> (EncryptedEnvelope, SymmetricKey) {

    let ephemeral = P256.KeyAgreement.PrivateKey()          // new for every request
    let shared = try ephemeral.sharedSecretFromKeyAgreement(with: serverKey)

    var saltBytes = [UInt8](repeating: 0, count: 32)
    _ = SecRandomCopyBytes(kSecRandomDefault, saltBytes.count, &saltBytes)
    let salt = Data(saltBytes)

    let key = shared.hkdfDerivedSymmetricKey(
        using: SHA256.self,
        salt: salt,
        sharedInfo: Data("com.example.api.v1 request".utf8),
        outputByteCount: 32)

    // Authenticate method + path so a payload can't be moved to another endpoint
    let sealed = try AES.GCM.seal(plaintext, using: key, authenticating: associatedData)

    let envelope = EncryptedEnvelope(
        ephemeralPublicKey: ephemeral.publicKey.x963Representation.base64EncodedString(),
        salt: salt.base64EncodedString(),
        ciphertext: sealed.combined!.base64EncodedString())
    return (envelope, key)   // keep `key` to decrypt the server's response
}

func decryptResponse(_ combined: Data, key: SymmetricKey,
                     associatedData: Data) throws -> Data {
    let box = try AES.GCM.SealedBox(combined: combined)
    return try AES.GCM.open(box, using: key, authenticating: associatedData)
}

For responses, a cleaner design derives a separate response key from the same shared secret with a different sharedInfo label, so request and response never reuse a key/nonce space. Never reuse a GCM nonce with the same key.

Key management on the server

Keep the decryption private key in a KMS or HSM; the app only ships the public key.
Include a key version (kid) in every envelope so you can rotate without breaking old app versions.
Pin or sign the public key distribution: if you fetch it at runtime, verify a signature over it with a key built into the app.
Never log decrypted payloads; log request IDs instead.

When NOT to do this

Payload encryption costs real things: harder debugging, no WAF inspection of bodies, more complex client and server code, and crypto that someone must maintain. If your only goal is "stop people seeing our JSON in Charles", it will not achieve that against a motivated user, and pinning plus obfuscation is cheaper. Use it when the threat is infrastructure between TLS termination and your service, or when a regulation requires end-to-end protection of specific fields.

4. Device Attestation, App Attest and Application Integrity

TL;DR — Your server cannot trust anything a client says about itself, including "I am your genuine app". Apple's App Attest (DeviceCheck framework, iOS 14+) lets the Secure Enclave produce cryptographic proof, signed by Apple, that a request came from a genuine copy of your app on a genuine Apple device. Use it to gate sensitive endpoints, combine it with server-side risk scoring, and never hard-block users whose devices simply don't support it.

The problem attestation solves

API keys, client IDs, user-agent strings and obfuscated secrets all live inside your app, so anyone can copy them into a script. That is how bots create fake accounts, farm referral bonuses, scrape catalogs and abuse free tiers. Attestation flips the model: instead of the client knowing a secret, the client proves something using a key that hardware generated and Apple vouched for.

The DeviceCheck family

API	What it gives you	Typical use
DCDevice (iOS 11+)	An opaque token your server exchanges with Apple to read/write 2 bits per device, plus a timestamp. Survives reinstall and reset.	"Has this device already claimed the free trial / promo?"
DCAppAttestService (iOS 14+)	A Secure Enclave key attested by Apple, then signed assertions on requests.	Prove requests come from your genuine, unmodified app
App Attest fraud metric	Apple-reported estimate of how many attested keys a device has created recently.	Detect device farms and reinstall abuse

How App Attest works

There are two phases. Attestation happens once per key (typically once per install). Assertion happens on each sensitive request afterwards.

Phase 1: Attestation (once)

App checks DCAppAttestService.shared.isSupported.
App calls generateKey(); the Secure Enclave creates a P-256 key and returns its keyId.
App fetches a one-time random challenge from your server.
App calls attestKey(keyId, clientDataHash: SHA256(challenge)). Apple's servers sign a certificate for the key that encodes your Team ID + bundle ID and that this is an unmodified App Store / TestFlight / development build.
App sends the attestation object, keyId and challenge to your server, which verifies it and stores the public key and a counter.

Phase 2: Assertion (per request)

App builds the request and computes clientDataHash = SHA256(requestData), where requestData includes a server challenge or timestamp.
App calls generateAssertion(keyId, clientDataHash:).
Server verifies the signature with the stored public key and checks the counter increased. No call to Apple is needed.

Client implementation

// AppAttestManager.swift
import DeviceCheck
import CryptoKit

actor AppAttestManager {
    private let service = DCAppAttestService.shared
    private let store = KeychainStore(service: "com.example.app.attest",
                                      accessibility: kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly)
    private let api: AttestAPI          // your networking layer

    init(api: AttestAPI) { self.api = api }

    var isSupported: Bool { service.isSupported }

    /// Call once (e.g. after login). Returns the attested keyId.
    func attestIfNeeded() async throws -> String {
        if let existing = try? store.data(for: "keyId"),
           let keyId = String(data: existing, encoding: .utf8) {
            return keyId
        }
        guard service.isSupported else { throw AttestError.unsupported }

        let keyId = try await service.generateKey()
        let challenge = try await api.fetchChallenge()            // server nonce
        let clientDataHash = Data(SHA256.hash(data: challenge))

        do {
            let attestation = try await service.attestKey(keyId,
                                                          clientDataHash: clientDataHash)
            try await api.registerAttestation(keyId: keyId,
                                              attestation: attestation,
                                              challenge: challenge)
            try store.set(Data(keyId.utf8), for: "keyId")
            return keyId
        } catch let error as DCError where error.code == .serverUnavailable {
            // Apple's service temporarily unavailable: retry later with the SAME keyId
            throw AttestError.retryLater
        }
    }

    /// Produce an assertion for a sensitive request body.
    func assertion(for requestData: Data) async throws -> (keyId: String, assertion: Data) {
        let keyId = try await attestIfNeeded()
        let clientDataHash = Data(SHA256.hash(data: requestData))
        do {
            let assertion = try await service.generateAssertion(keyId,
                                                                clientDataHash: clientDataHash)
            return (keyId, assertion)
        } catch let error as DCError where error.code == .invalidKey {
            // Key lost (e.g. restored to a new device). Start over.
            try store.delete("keyId")
            return try await assertion(for: requestData)
        }
    }
}

enum AttestError: Error { case unsupported, retryLater }

Add the App Attest capability in Xcode. It creates the entitlement com.apple.developer.devicecheck.appattest-environment; set it to production for App Store and TestFlight builds. With development, attestations come from Apple's sandbox environment and your server must accept the development AAGUID only in non-production backends.

Server verification of the attestation

The attestation object is CBOR-encoded with format apple-appattest. Your server must check every one of these, in order. Skipping any single step usually breaks the whole scheme:

#	Check
1	Decode CBOR; extract `x5c` certificate chain, `receipt` and `authData`.
2	Validate the chain up to Apple App Attestation Root CA (download from Apple's Private PKI page and embed it).
3	Compute `nonce = SHA256(authData \
4	SHA-256 of the leaf certificate's public key must equal the {% raw %}`keyId` the app sent.
5	`rpIdHash` in authData must equal `SHA256("TEAMID.com.example.app")`.
6	The counter in authData must be 0.
7	AAGUID must be `appattest` followed by seven zero bytes (production) or `appattestdevelop` (development).
8	Credential ID in authData must equal the keyId.
9	Challenge must be one you issued, unexpired and unused. Store public key, counter and receipt against the user.

Server verification of each assertion

#	Check
1	Decode CBOR; extract `signature` and `authenticatorData`.
2	Recompute `clientDataHash` from the request data the server actually received.
3	`nonce = SHA256(authenticatorData \
4	{% raw %}`rpIdHash` must match your App ID hash again.
5	Counter must be strictly greater than the stored counter; then store the new value.
6	The embedded challenge / timestamp in requestData must be fresh and unused.

Don't hand-roll the CBOR and X.509 parsing if you can avoid it. Maintained open-source verifiers exist for Node, Go, Python, Java and Swift on the server (search for "app attest server validation" for your stack), and Apple's documentation article Validating apps that connect to your server is the authoritative specification.

Rolling out App Attest safely

Don't block on unsupported devices. Simulators, some older devices and some extension contexts return isSupported == false. Treat them as higher risk, not as attackers.
Ramp gradually. Apple asks large apps to roll out attestation to a percentage of users over time, since the attestation step calls Apple's servers. Assertions are local and cheap.
Start in monitor mode. Verify and log for a few weeks before enforcing, so you learn your real failure rate.
Gate by value. Require assertions on signup, login, payments, rewards, and other abuse-prone endpoints, not on every image request.
Use the receipt. Periodically refresh the attestation receipt with Apple to read the fraud metric for that device and feed it into your risk engine.

What App Attest does not do

App Attest proves the app binary is genuine and the key is hardware-bound. It does not prove the device is not jailbroken, and it cannot stop an attacker who drives your real, unmodified app on a real device (for example through UI automation on a device farm). That is why the fraud metric, rate limiting and behavioural signals still matter.

Other application integrity signals

Signal	Value	Caveat
StoreKit 2 `AppTransaction` (iOS 16+)	JWS signed by Apple proving the app was obtained from the App Store; verify on server	About purchase/ownership, not runtime tampering
Jailbreak heuristics	Detect common file paths, writable system dirs, injected dylibs	Easily bypassed; use only as a risk signal
Debugger / hooking detection	Check P_TRACED via sysctl, scan loaded images for Frida	Arms race; raises cost, never decisive
Code obfuscation	Slows reverse engineering of logic and endpoints	Not a substitute for server-side checks

Putting it all together

A sound architecture for a high-value app looks like this: the app attests its Secure Enclave key with App Attest on first sensitive use; the server registers that key against the user; sensitive requests carry an App Attest assertion (or a Secure Enclave signature as in section 3); secrets live in the Keychain with ThisDeviceOnly accessibility (section 2); transport uses ATS, with SPKI pinning where the threat model justifies it (section 1); and the server combines all of these signals with rate limiting and behavioural analysis instead of trusting any single one.

The one rule behind all four sections: Every client-side control can be bypassed by someone who owns the device. Client-side security exists to protect honest users and to raise the cost of abuse. The final decision about what to trust must always be made on the server.

Don't want to write all this Keychain code yourself?

I packaged the storage patterns from section 2 (and more) into SecureStorageKit, a free, MIT-licensed Swift package with no third-party dependencies: typed Keychain storage, biometric-protected items, AES-GCM with key rotation, Secure Enclave signing and a token store. More on it in my next post.

References for further reading

Apple Developer Documentation: Establishing your app's integrity and Validating apps that connect to your server (DeviceCheck / App Attest).
Apple Developer News: Identity Pinning: How to configure server certificates for your app (NSPinnedDomains).
Apple Platform Security Guide: Keychain data protection, Secure Enclave and Data Protection classes.
Apple Developer Documentation: CryptoKit (SecureEnclave, HPKE, AES.GCM, P256).
OWASP Mobile Application Security Verification Standard (MASVS) and Testing Guide (MASTG).
RFC 9180: Hybrid Public Key Encryption.

Over to you: has SSL pinning ever caused an outage for your team? Did you fix it with backup pins, or remove pinning altogether? I'd love to hear real-world stories in the comments.