It is not unusual for large corporations to use HTTPS proxy for data inspection. According to a paper titled "The Sorry State of TLS Security in Enterprise Interception": Network traffic inspection, including TLS traffic, in enterprise environments is widely practiced. — https://dl.acm.org/doi/10.1145/3372802

According to data reported by Cloudflare, "between 4% and 10% of the web’s encrypted traffic (HTTPS) is intercepted." — https://blog.cloudflare.com/understanding-the-prevalence-of-web-traffic-interception/

The impact on your API communication can be either exposing your user's private data to unintended third-party observers, or service interruption if you are doing TLS pinning.

This is why I have been pushing for API level security, using public/private keys, building on the foundations of Zero-Trust Architecture.

When building your next API, if you are transferring PII (Personally Identifiable Information) you shouldn't rely on the transport layer to provide the security. It should be built into your infrastructure and API layer.

Zero-Trust Architecture: A Quick Primer

Zero-Trust is a security model built on a simple premise: no network location, device, or connection is inherently trusted. Every request must prove its legitimacy, every time.

The concept was formalized by NIST in SP 800-207 ("Zero Trust Architecture"), which lays out the core tenets: verify explicitly, use least-privilege access, and assume breach. The traditional perimeter-based model "everything inside the firewall is safe" falls apart when your traffic is being inspected, rerouted, or decrypted by middleboxes you don't control.

This is directly relevant to API security. If your confidentiality guarantee lives entirely in the transport layer, then anyone who terminates that TLS session — legitimately or not — sees everything in plaintext. Zero-Trust pushes that trust boundary down to the application itself. The data should be protected independent of the pipe it travels through.

If you want to go deeper, NIST SP 800-207 is the canonical starting point (https://csrc.nist.gov/pubs/sp/800/207/final). For a more practical take, the CISA Zero Trust Maturity Model gives a staged adoption framework (https://www.cisa.gov/zero-trust-maturity-model).

Strategies for API-Level Cryptography

Web Apps

JWE (JSON Web Encryption, RFC 7516) is a well-supported standard for this. You encrypt the payload using the recipient's public key, and only their corresponding private key can decrypt it. Libraries exist for virtually every major language and platform.

For simpler cases, you can use a hybrid approach: exchange a symmetric key using asymmetric encryption (e.g., ECDH or RSA key exchange), then encrypt payloads with AES-GCM. This is essentially what TLS does internally. You're just moving that negotiation into your application protocol.

Encryption gives you confidentiality, but you also need to know the message hasn't been tampered with and actually came from who it claims to. Message signing addresses this.

JWS (JSON Web Signature, RFC 7515) lets the sender sign a payload with their private key, and the recipient verifies with the sender's public key. This proves both origin and integrity. You can combine JWS and JWE (sign-then-encrypt) for both properties.

HTTP Message Signatures (RFC 9421) is a newer standard worth watching, it lets you sign not just the body but also specific HTTP headers, method, and path, which protects against replay and request-manipulation attacks that payload-only signing misses.

Mobile Apps

For mobile applications, you can go a step further than software-only cryptography by leveraging hardware-backed key storage. Both iOS and Android offer secure hardware enclaves that can generate, store, and use cryptographic keys in a way that the private key material never leaves the hardware — not even your own app can extract it.

iOS: Secure Enclave + CryptoKit

On iPhone, the Secure Enclave supports P256 elliptic curve keys for both key agreement (ECDH) and signing (ECDSA). AES-GCM is hardware accelerated on Apple silicon. The general flow:

1. On the server side, generate an ECC P256 key pair in an HSM (or a cloud KMS such as AWS KMS or GCP Cloud HSM). Publish the public key through a key discovery endpoint, including a key ID for rotation. Avoid hardcoding the key in your app binary, as this creates the same update-to-rotate problem as TLS pinning.

2. In your mobile app, use the Secure Enclave to generate a hardware-bound P256 key agreement key pair via CryptoKit's SecureEnclave.P256.KeyAgreement.PrivateKey.

3. Perform ECDH between the client's Secure Enclave private key and the server's public key to derive a shared secret.

4. Use HKDF to derive AES symmetric keys from that shared secret. Be deliberate about the HKDF parameters: use a unique salt per session and include context in the info parameter (e.g., client identifier, server identifier, and key purpose) to bind the derived key to a specific use.

5. Encrypt payloads using AES-GCM, which provides both confidentiality and integrity in a single operation, with fallback to AES-CTR + HMAC-SHA256 if you require streaming encryption.

For request authenticity, the Secure Enclave also supports P256 signing (SecureEnclave.P256.Signing.PrivateKey). Have the client sign each request (or a digest of it) so the server can verify the request genuinely came from a device holding the corresponding private key. This gives you the mobile equivalent of the message signing pattern described in the web section above.

A note on algorithm choice: prefer AES-GCM over AES-CTR. AES-CTR provides confidentiality only, it has no built-in integrity protection, meaning a payload encrypted with CTR alone can be silently modified in transit. If you require the ability to stream data for encryption, for example encrypting very large file in an app extension, you may have to fallback to AES-CTR and implement your own integrity validation using HMAC-SHA256 which is also hardware accelerated.

Android: Keystore + StrongBox

Android offers a similar model through the Android Keystore system, with StrongBox providing hardware-level protection on supported devices (Pixel 3+, Samsung Galaxy S9+, and most flagships since 2018).

1. Generate a P256 key pair in the Android Keystore with setIsStrongBoxBacked(true)where available (falling back to TEE-backed Keystore otherwise).

2. Use KeyAgreement with ECDH to derive a shared secret against the server's public key.

3. Derive AES keys using HKDF with the same parameter discipline as on iOS.

4. Encrypt with AES-GCM via Cipher.getInstance("AES/GCM/NoPadding").

For signing, the Android Keystore supports ECDSA with P256 (SHA256withECDSA), giving you the same request authentication capability.

Key Discovery and Rotation

A natural question is how the app gets the server's public key in the first place, and how you rotate it over time. Bundling the operational encryption key directly in your app binary works initially, but creates the same update-to-rotate brittleness as TLS pinning.

The temptation is to solve this with a key discovery endpoint, fetching the latest key when you encounter an unknown key ID. But this reintroduces the problem you are trying to solve: that request isn't protected by your API-level encryption, so you're trusting the transport layer for the most sensitive exchange of all.

The approach that avoids this chicken-and-egg problem is to separate the trust anchor from the rotatable keys:

Bundle a long-lived signing-only public key in your app. This key does not encrypt anything. Its sole purpose is to verify the authenticity of other keys. Store its private counterpart in an HSM, use it for nothing else, and treat it as a root of trust.

Your key discovery endpoint then serves rotatable encryption and key-agreement public keys, each accompanied by a signature produced by the long-lived signing key and a key ID. When the app encounters an unfamiliar key ID, it fetches the new key from the endpoint and verifies the signature against the bundled trust anchor before accepting it. If the signature doesn't verify, the key is rejected regardless of what the transport layer says.

This gives you the ability to rotate operational keys at will, no app update required, while keeping trust rooted in a narrow, infrequently-changing anchor. The only scenario that forces an app update is compromise of the signing key itself, which is a much rarer event when that key lives in an HSM and is used exclusively for signing other keys.

It doesn't eliminate the bundled-key dependency entirely, but it reduces it to the smallest possible surface: a single verification key with a long lifespan and a minimal attack profile.

Conclusion

Transport-layer security is necessary but not sufficient. If your API handles sensitive data, and most do, the confidentiality and authenticity guarantees should live where the data lives: in the application layer. The standards and tooling are mature enough that this is no longer a heroic engineering effort. It's a design choice.

Start by identifying which API endpoints carry PII or other sensitive payloads. You don't need to encrypt everything, focus on where the exposure actually matters. Pick the strategy that fits your platform: JWE/JWS for web applications with broad library support, hardware-backed cryptography for mobile where the Secure Enclave and Android Keystore give you stronger guarantees. Design for key rotation from day one, because the alternative is painting yourself into the same corner that TLS pinning creates.

The building blocks are all standardized and well-documented. What's been missing is the habit of reaching for them.

Further Reading

• NIST SP 800-207 — Zero Trust Architecture: The foundational document on Zero-Trust principles. Free to read at https://csrc.nist.gov/pubs/sp/800/207/final

• CISA Zero Trust Maturity Model: A practical staged framework for adopting Zero-Trust in your organization. Available at https://www.cisa.gov/zero-trust-maturity-model

• RFC 7516 (JWE) and RFC 7515 (JWS): The IETF standards for JSON Web Encryption and JSON Web Signature, the backbone of web application payload security.

• RFC 9421 — HTTP Message Signatures: A newer standard for signing HTTP message components including headers, method, and path — useful for request authenticity beyond just the payload. https://www.rfc-editor.org/rfc/rfc9421

• Apple CryptoKit — SecureEnclave: Apple's documentation on hardware-backed P256 key agreement and signing. https://developer.apple.com/documentation/cryptokit/secureenclave

• Android Keystore System: Android's documentation on hardware-backed key storage, including StrongBox support. https://developer.android.com/privacy-and-security/keystore

• "The Sorry State of TLS Security in Enterprise Interception": The research paper referenced at the top of this post, covering the prevalence and risks of TLS interception in corporate environments. https://dl.acm.org/doi/10.1145/3372802

When one session gives me an implementation plan, I copy/paste the plan into the other and ask for a review of the plan for any issues.

While the AI attempts to review its own work, during the development of the plan it made assumptions and may have poisoned its own context with those decisions. But when you paste the plan in a new context and ask for analysis, this new context will not have those assumptions known and may point out interesting findings.

As a "Human in the loop", I decide whether the feedback on the plan requires me to go back to the original drawing board, or if I should just provide the feedback to the first session to self-correct.

This is also a really good time to re-evaluate what changes would have been required in the original inputs (your CLAUDE.md, Skills, MCP or your prompt) to avoid the highlighted issues. Sometimes, it means scrapping the entire session, and changing your original prompt to contain more information.

This process is what leads me to use external markdown files most of the time for my tasks, then just ask the AI to read the markdown file to know what is needed. This way, if any corrections are needed, I always have access to the original prompt data (in the markdown file).

I treat AI as a genius brand new developer joining your team. It doesn't matter how good they are, without context they won't be able to succeed. So knowing what to add, or what to remove, is what will make your AI session succeed or fail.

#HumanInTheLoop #AIDevelopment #CodeQuality

The culprit? Re-entrancy.

The False Sense of Security

Consider this innocent-looking actor:

actor BankAccount {
    private var balance: Double = 1000

    func withdraw(_ amount: Double) async -> Bool {
        // Check if we have sufficient funds
        guard balance >= amount else {
            return false
        }

        // Simulate an async operation (logging, validation, network call, etc.)
        await performAsyncValidation()

        // Deduct the amount
        balance -= amount
        return true
    }

    private func performAsyncValidation() async {
        try? await Task.sleep(for: .milliseconds(100))
    }
}

Looks safe, right? The actor should serialize access to balance. Let's test it:

let account = BankAccount()

async let withdrawal1 = account.withdraw(600)
async let withdrawal2 = account.withdraw(600)

let results = await [withdrawal1, withdrawal2]
print(results) // [true, true] — Wait, what?!

print(await account.getBalance()) // 💥 -200

Both withdrawals succeeded, and we've gone negative. This is a data race.

Why Does This Happen? The Mailbox Model

Actors only do one thing at a time—that's true. But actors also don't like to sit around doing nothing. Think of an actor as having a "mailbox" of pending work. When you call an actor method, you're dropping a message into that mailbox.

Here's the key insight: when an actor method hits an await, it suspends—and the actor immediately picks up the next message from its mailbox rather than waiting idle.

Here's the sequence that leads to our bug:

1. withdraw(600) #1 starts, checks balance >= 600 ✅ (balance is 1000)

2. withdraw(600) #1 hits await performAsyncValidation() and suspends

3. Actor picks up next message: withdraw(600) #2 starts (re-entrancy!)

4. #2 checks balance >= 600 ✅ (balance is still 1000—#1 hasn't modified it yet)

5. #2 hits await and suspends

6. #1 resumes, deducts 600 → balance is now 400

7. #2 resumes, deducts 600 → balance is now -200 💥

The guard check and the mutation are not atomic across the await boundary. The actor only guarantees that synchronouscode blocks don't interleave.

Two Flavors of Re-Entrancy Problems

Re-entrancy can cause two distinct types of issues:

Problem 1: Incorrect State (Data Corruption)

This is what we saw above—multiple operations interleave and corrupt shared state, leading to invalid results like a negative bank balance.

Problem 2: Wasteful Duplicate Work

Even when state doesn't get corrupted, re-entrancy can cause unnecessary work. Consider a cache that fetches from a remote server:

actor DataCache {
    private var cache: [UUID: Data] = [:]

    func read(_ key: UUID) async -> Data? {
        if let data = cache[key] {
            return data
        }

        // Fetch from remote if not cached locally
        guard let data = try? await fetchFromServer(key) else {
            return nil
        }

        cache[key] = data
        return data
    }
}

When multiple concurrent reads request the same uncached key:

cache read called for DDFA2377-...
attempt to read remote cache for DDFA2377-...
cache read called for DDFA2377-...          // Re-entrancy!
attempt to read remote cache for DDFA2377-... // Duplicate request!
cache read called for DDFA2377-...          // Re-entrancy again!
attempt to read remote cache for DDFA2377-... // Another duplicate!

We made three network requests when one would have sufficed. The first request would have cached the result for the others—but they all started before any completed.

Now let's look at strategies to handle both types of problems.

Strategy 1: Bounce Concurrent Requests

The simplest approach: if an operation is already in progress, reject new requests immediately.

actor BankAccount {
    private var balance: Double = 1000
    private var isWithdrawing = false

    enum WithdrawError: Error {
        case operationInProgress
        case insufficientFunds
    }

    func withdraw(_ amount: Double) async throws -> Double {
        // Reject if another withdrawal is in progress
        guard !isWithdrawing else {
            throw WithdrawError.operationInProgress
        }

        isWithdrawing = true
        defer { isWithdrawing = false }

        guard balance >= amount else {
            throw WithdrawError.insufficientFunds
        }

        await performAsyncValidation()

        balance -= amount
        return balance
    }
}

When to use: Idempotent operations, UI button debouncing, preventing duplicate submissions.

Pros: Simple, explicit, fast failure.

Cons: Callers must handle rejection and potentially retry.

Strategy 2: Queue and Await Previous Operations

Instead of rejecting concurrent requests, queue them up and process them serially.

actor BankAccount {
    private var balance: Double = 1000
    private var pendingOperations: [CheckedContinuation<Void, Never>] = []
    private var isOperationInProgress = false

    private func acquireLock() async {
        if isOperationInProgress {
            // Wait our turn
            await withCheckedContinuation { continuation in
                pendingOperations.append(continuation)
            }
        }
        isOperationInProgress = true
    }

    private func releaseLock() {
        if let next = pendingOperations.first {
            pendingOperations.removeFirst()
            next.resume() // Wake up the next waiter
        } else {
            isOperationInProgress = false
        }
    }

    func withdraw(_ amount: Double) async -> Result<Double, WithdrawError> {
        await acquireLock()
        defer { releaseLock() }

        guard balance >= amount else {
            return .failure(.insufficientFunds)
        }

        await performAsyncValidation()

        balance -= amount
        return .success(balance)
    }
}

When to use: When all requests must eventually be processed, order matters, or you need transactional semantics.

Pros: No requests are dropped; guaranteed serialization.

Cons: Increased latency for queued requests; potential for queue buildup.

Strategy 3: Optimistic Execution with Rollback

Sometimes you want to proceed optimistically and verify/rollback if conditions changed during the async operation.

actor BankAccount {
    private var balance: Double = 1000
    private var transactionLog: [UUID: Double] = [:]

    func withdraw(_ amount: Double) async -> Result<Double, WithdrawError> {
        // Initial validation
        guard balance >= amount else {
            return .failure(.insufficientFunds)
        }

        // Capture pre-await state
        let transactionId = UUID()
        let balanceBefore = balance

        // Optimistically reserve the funds
        balance -= amount
        transactionLog[transactionId] = amount

        // Perform async work
        let validationPassed = await performAsyncValidation()

        // Post-await verification
        let stateCorrupted = balance < 0
        let validationFailed = !validationPassed

        if stateCorrupted || validationFailed {
            // Rollback
            if let reserved = transactionLog.removeValue(forKey: transactionId) {
                balance += reserved
            }
            return .failure(validationFailed ? .validationFailed : .insufficientFunds)
        }

        // Commit
        transactionLog.removeValue(forKey: transactionId)
        return .success(balance)
    }
}

When to use: When async operations are expensive and you want to maximize throughput; when rollback is cheap.

Pros: Maximum concurrency, no blocking.

Cons: Rollback logic can be complex; may waste work on rolled-back transactions.

Strategy 4: Re-validate After Await

A simpler variant of Strategy 3—just re-check your preconditions after awaiting:

actor BankAccount {
    private var balance: Double = 1000

    func withdraw(_ amount: Double) async -> Result<Double, WithdrawError> {
        // First check
        guard balance >= amount else {
            return .failure(.insufficientFunds)
        }

        let balanceSnapshot = balance

        await performAsyncValidation()

        // Re-validate after await
        guard balance == balanceSnapshot else {
            // State changed during await—abort or retry
            return .failure(.stateChanged)
        }

        guard balance >= amount else {
            return .failure(.insufficientFunds)
        }

        balance -= amount
        return .success(balance)
    }
}

When to use: When you can afford to fail and have the caller retry.

Pros: Very simple; no complex state tracking.

Cons: May require retry logic; can fail even when it theoretically could have succeeded.

Strategy 5: Coalesce with In-Progress Task Tracking

This elegant pattern solves the "duplicate work" problem by tracking in-flight operations. Subsequent requests for the same resource await the existing task rather than starting a new one.

The key insight is to store the task itself (not just a boolean flag) so concurrent callers can await the same result:

actor DataCache {
    enum CacheEntry {
        case inProgress(Task<Data?, Error>)
        case loaded(Data)
    }

    private var cache: [UUID: CacheEntry] = [:]

    func read(_ key: UUID) async -> Data? {
        // Already have the data? Return immediately.
        if case let .loaded(data) = cache[key] {
            return data
        }

        // Already fetching? Await the existing task.
        if case let .inProgress(task) = cache[key] {
            return try? await task.value
        }

        // Start a new fetch and store the task immediately (before awaiting!)
        let task: Task<Data?, Error> = Task {
            try await fetchFromServer(key)
        }

        cache[key] = .inProgress(task)

        // Now await our own task
        if let data = try? await task.value {
            cache[key] = .loaded(data)
            return data
        } else {
            cache[key] = nil
            return nil
        }
    }
}

Now concurrent reads coalesce into a single network request:

cache read called for DDFA2377-...
cache read called for DDFA2377-...  // Sees .inProgress, awaits same task
cache read called for DDFA2377-...  // Sees .inProgress, awaits same task
attempt to read remote cache for DDFA2377-...  // Only ONE network call!
remote cache HIT for DDFA2377-...
cache read finished for DDFA2377-...
cache read finished for DDFA2377-...
cache read finished for DDFA2377-...

When to use: Caching, token refresh flows, any idempotent fetch where duplicate requests are wasteful.

Pros: Eliminates duplicate work; all callers get the same result; elegant state machine.

Cons: Slightly more complex; requires thinking about task lifecycle.

This pattern is explained in depth in Donny Wals' excellent article on actor re-entrancy, which also covers practical applications like token refresh flows and image loaders.

Strategy 6: Immutable State + Version (Compare-and-Swap)

Instead of mutating state, use a version number to detect concurrent modifications:

actor BankAccount {
    private var state: AccountState

    struct AccountState: Sendable {
        let balance: Double
        let version: Int
    }

    init(balance: Double) {
        self.state = AccountState(balance: balance, version: 0)
    }

    func withdraw(_ amount: Double) async -> Result<Double, WithdrawError> {
        let snapshot = state

        guard snapshot.balance >= amount else {
            return .failure(.insufficientFunds)
        }

        await performAsyncValidation()

        // Compare-and-swap: reject if state changed
        guard state.version == snapshot.version else {
            return .failure(.stateChanged)
        }

        state = AccountState(
            balance: snapshot.balance - amount,
            version: snapshot.version + 1
        )
        return .success(state.balance)
    }
}

When to use: Complex state objects; when you want clear semantics about what constitutes a "change."

Pros: Clear state transitions; easy to debug; works well with audit trails.

Cons: Requires immutable state design; version conflicts need retry logic.

Choosing the Right Strategy

Bounce → Debouncing, idempotent ops • Low complexity • High throughput (fails fast)

Queue → Ordered processing, transactions • Medium complexity • Low throughput (serialized)

Optimistic + Rollback → High-throughput systems, cheap rollback • High complexity • High throughput

Re-validate → Simple operations, retriable • Low complexity • Medium throughput

Coalesce (Task Tracking) → Caching, deduplication • Medium complexity • High throughput

Immutable + Version → Complex state, audit trails • Medium complexity • Medium throughput

Key Takeaways

1. Actors protect synchronous access, not sequences of operations spanning await.

2. Think "mailbox": when your method suspends, the actor immediately processes the next queued message.

3. Two problems to watch for: incorrect state (data corruption) and wasteful duplicate work.

4. The golden question: Every time you write await inside an actor, ask yourself: "What assumptions have I made about state before this await that I need to re-verify after?"

5. Choose your strategy based on your use case: correctness vs. throughput vs. simplicity.

6. Test concurrent access explicitly—create stress tests that hammer your actors from multiple tasks simultaneously.

The next time you write an actor method with an await, pause and ask yourself: "What could change while I'm suspended?" Your future self will thank you.

For more on this topic, I highly recommend Donny Wals' deep dive on actor re-entrancy, which includes practical examples like building token refresh flows and async image loaders.

What patterns have you found useful for managing actor re-entrancy? Share your experiences in the comments!

#Swift #iOSDevelopment #Concurrency #SwiftConcurrency #Programming #SoftwareEngineering

First, what not to do:

• Don't store your license/API key as a string in your source code

• Don't store your license/API key as a value in Info.plist

• Don't store your license/API key in a .xcconfig file that is used to populate your Info.plist

• Don't store your license/API key in an environment variable used to populate your source code at compile time which will just store the value as a string in your source code.

• Don't base64/base32 encode your key and think it's safe

• Don't XOR your key.

Yikes, so.. with all that, what can we do then?

You will want to use a cryptographically proven algorithm, like AES.GCM to encrypt the key at compile time, then use AES.GCM to decrypt the key at runtime.

I hear you, AES.GCM requires an encryption key, so how will you store the key? And that, my friends, is how the ride starts.

Let's ride.

Pick a password

Come up with a good password. If you are not sure, uuidgen command in terminal is a relatively safe bet. Plus it won't look like a password so, bonus point for confusing your attackers.

Pick a shared secret

Next, at some point you will need a "shared secret" to derive your key. Hit that uuidgen command once more.

Pick an obfuscator

Grab an obfuscator library of your choice. SwiftSecretKeys (https://github.com/MatheusMBispo/SwiftSecretKeys) seems decent enough, there are others. Most of them are not cryptographically safe but that's okay. It will be better than storing your password and shared secret as strings in your source code.

Make sure you understand how to use the chosen obfuscator. Store your password and shared secret in there. Please give them creative names. If your obfuscator works with string keys, go ahead and generate two more UUID to use as keys.

output: Generated/
keys:
  kE2110F7359B34F6EB11AC01F96652F44: '77783393-62DE-499E-8848-68FF3D4A2979'
  k3A0535981E94408E86BAB3CFE466C399: '849C3BB6-2519-4BF4-8E7A-3E6D7D9C003B'

let mySharedSecret = SecretKeys.kE2110F7359B34F6EB11AC01F96652F44
let myPassword = SecretKeys.k3A0535981E94408E86BAB3CFE466C399

Assuming your stuff is setup right, this should give you a mySharedSecret variable that contains the string "77783393-62DE-499E-8848-68FF3D4A2979" and myPassword that contains the string "849C3BB6-2519-4BF4-8E7A-3E6D7D9C003B"

Learn how to use HKDF

Apple's doc on HKDF is at https://developer.apple.com/documentation/cryptokit/hkdf

In short, HDKF is a key derivation algorithm, you give it a password, a salt, and tell it how many bytes of data you need for the key, and it's going to do its magic until there's enough data to fill the key. In our case we will be using AES.GCM with 256-bit keys. Given 8-bits per byte, we will need 32 bytes.

let passwordData = myPassword.data(using: .utf8)!
let sharedSecretData = mySharedSecret.data(using: .utf8)!
let aesKey = HKDF<SHA512>.deriveKey(
            inputKeyMaterial: passwordData,
            info: sharedSecretData,
            outputByteCount: 32)

Learn how to use AES.GCM

Apple's doc on AES.GCM is at https://developer.apple.com/documentation/cryptokit/aes/gcm

AES is the encryption algorithm, GCM is the block cipher which also includes some AEAD authentication data at the end. No need to go into too much details here, it allows you to encrypt some plain text data into gibberish unintelligible data commonly known as cipher text.

plain text = stuff not encrypted

cipher text = gibberish

AES.GCM uses something called a SealedBox to store the cipher text. So when you want to encrypt your plain text, you use AES.GCM.seal() to create a SealedBox, and when you want to decrypt your cipher text back to plain text you first create a SealedBox using the cipher text, and you open the SealedBox using AES.GCM.open().

Creating the [UInt8] sequence to include in your source code, assuming you already have the HKDF to generate the aesKey:

let myApiKey = "I love Apple"
let myApiKeyPlainText: Data = myApiKey.data(using: .utf8)!
let sealedBox = try! AES.GCM.seal(myApiKeyPlainText, using: aesKey)
let myApiKeyCipherText: Data = sealedBox.combined!
let cipherRepresentation = myApiKeyCipherText.map { String(format: "0x%02X", $0 }.joined(separator: ",")
print("private let apiKeyCipherText = [\(cipherRepresentation)]")

// will print:
// private let apiKeyCipherText: [UInt8] = [0xA2,0xC3,0xC7,0x56,0x66,0x28,0x73,0x87,0x1B,0xC6,0xF8,0x64,0x8D,0x8F,0x80,0x2C,0xB0,0xF2,0x87,0x57,0xFF,0x87,0x75,0x74,0x03,0x7B,0x92,0xD6,0xFC,0xF7,0xDF,0xB9,0xD6,0xBA,0x80,0xB9,0x1D,0xCD,0x6E,0xAB]

In your source code, assuming you already have the HKDF to generate the aesKey:

 private let apiKeyCipherText: [UInt8] = [0xA2,0xC3,0xC7,0x56,0x66,0x28,0x73,0x87,0x1B,0xC6,0xF8,0x64,0x8D,0x8F,0x80,0x2C,0xB0,0xF2,0x87,0x57,0xFF,0x87,0x75,0x74,0x03,0x7B,0x92,0xD6,0xFC,0xF7,0xDF,0xB9,0xD6,0xBA,0x80,0xB9,0x1D,0xCD,0x6E,0xAB]
 let sealedBox = try! AES.GCM.SealedBox(combined: Data(apiKeyCipherText))
 let myApiKeyPlainText = try! AES.GCM.open(sealedBox, using: aesKey)
 let myApiKey = String(data: myAPiKeyPlainText, encoding: .utf8)!
 print(myApiKey)

 // will print
 // I love Apple

Congrats!

You can now securely store license keys and secrets, in your mobile app.

You are not done.

If you went through all this trouble just to send your API key over some network request using HTTPS, your API key will be easily accessible to hackers using TLS bypass attacks.

You can learn more about this by searching for Radare2, Frida or Objection. You can detect TLS bypass attacks but you can't really prevent them. So your API key will be exposed the moment you send it over the network, unless you encrypt before sending it over to the server.

Most online services expect you to send your API key as is, so most of your hard work to keep your API key secret will, well, be for naught.

But, if your API key is used locally in a commercial library, then you are all set, or almost.

You will want to finish protecting your application with jailbreak detection, debugger detection, etc.

Happy coding!

First, if your module/library will need to be distributed with assets, you should go with a .xcframework as it can include additional files. Manually distributing a .a or .dyld file along with a set of assets to include is a recipe for disaster. So you'll pick .xcframework; and in that framework will be your static and/or dynamic library.

As for static vs dynamic, it depends on how your app will be using it. If it will always be loaded and your app requires that functionality to work, then build it as a static library. Your main app executable will be slightly larger but still smaller than app binary + dynamic library. And since you will always need to load the dynamic library, you will also save some time because it will already be linked at compile time. So... faster for your users.

However, if your library contains a bunch of stuff that's mostly needed only for specific edge cases in your app, then you will want to pick a dynamic library. This will allow your app to start immediately, and iOS will load the dynamic library as needed at runtime.

Note that using a dynamic library may also introduce some unexpected delays due to the dynamic nature of the linking. So be careful about making use of a function from a dynamic library for the first time during animations.

Notice that the attacker did not even need to match the function name. Swift uses a dynamic lookup table for non-final classes to identify where the implementation of a function is located.

Since world() is the first function of the Hello class, and notSoFast() is the first function of the Hack class, when the hello instance type is changed to Hack and we call the world() function on it, underneath Swift will retrieve the first function implementation of the dynamic lookup table of the Hack class, and end up executing notSoFast() instead of world().

When you use final(), Swift will directly refer to the implementation of world() and skip the dynamic lookup table. Making your code safer from attackers.

Edit: As pointed out by several in the community, this "trick" is mostly prevented by Swift Whole Module optimization (-wmo or -whole-module-optimization). Provided your libraries and your application have the right build settings, the role of final keyword is mostly to prevent other developers from extending your classes.

I greatly appreciate the interest this generated in the community. And hopefully this allowed many of you to learn more about Swift dynamic lookup and class handling.

You can read more about Whole Module Optimization at https://www.swift.org/blog/whole-module-optimizations/

However when we are using Swift as our programming language, a certain feature called Reflection, embeds in the app binary all the necessary names and types of every class/struct you have defined in your project so you can Mirror() the object and list all the attributes/types dynamically at runtime.

This trove of information is an incredible source of information to hackers. Apparently, this can be controlled by a Swift compiler flag SWIFT_REFLECTION_METADATA_LEVEL.

I stumbled on this in an Apple Developer Forum post: https://developer.apple.com/forums/thread/720978

Which lead me to this Apple Documentation page: https://developer.apple.com/documentation/xcode/build-settings-reference#Reflection-Metadata-Level

So if you are securing an iOS/macOS app, make sure to go into your Xcode project build settings, and find Swift Compiler General -> Reflection Metadata Level and set the value to None.

Reference Use Case

A class depends on the services of another class. Your first instinct will likely be to create a protocol that will define the interface that you will require.

struct GroceryList: Codable {
    var items: [String]
}

protocol GroceryListLoader() {
    func loadFromURL(_ url: URL) throws -> GroceryList
}

class MyGroceryListManager {
    let loader: GroceryListLoader
    var groceryLists = [Name: GroceryList]()

    init(loader: GroceryListLoader) {
        self.loader = loader
    }

    func openList(name: String) throws {
        let listUrl = URL(string: "file://path/to/\(name).json")!
        groceryLists[name] = try loader.loadFromUrl(listUrl)
    }
}

This allows you to replace the implementation of the GroceryListLoader with a mock/stub during unit tests. It also makes your code more flexible as it can work with any number of implementations as long as they can conform to the GroceryListLoader protocol.

Reference Case Unit Test

Let's create a small unit test to demonstrate how this is typically implemented:

class GroceryListLoaderMock: GroceryListLoader {
    enum Errors: Error {
      case fileNotFound
    }

    var lists = [URL: GroceryList]()
    func loadFromURL(_ url: URL) throws -> GroceryList {
        guard let list = lists[url] else {
            throw Errors.fileNotFound
        }
        return list
    }
}

class GroceryListManagerTests: XCTestCase {
    func testThrowsWhenFileIsMissing() {
        let mockLoader = GroceryListLoaderMock()
        let manager = GroceryListManager(loader: mockLoader)
        XCTAssertThrow(try manager.openList(name: "Walmart"))
    }
}

Nothing unusual here. When executing testThrowsWhenFileIsMissing() a mockLoader is created, and since no list was assigned to the mock's lists, the loadFromURL() function will throw the Errors.fileNotFound. In turn the GroceryListManager implementation of openList() because it doesn't capture any error throw by the loader, will simply allow the thrown error to carry on to the caller of the openList() function therefore passing the test.

Typealias alternative

struct GroceryList: Codable {
    var items: [String]
}

typealias LoadGroceryList = (_ url: URL) throws -> GroceryList

class GroceryListManager {
    let loader: LoadGroceryList
    var groceryLists = [Name: GroceryList]()

    init(loader: @escaping LoadGroceryList) {
        self.loader = loader
    }

    func openList(name: String) throws {
        let listUrl = URL(string: "file://path/to/\(name).json")!
        groceryLists[name] = try loader(listUrl)
    }
}

Here, instead of defining a protocol, we define a typealias with the signature of the closure we need. In the GroceryListManager we will store a reference to that closure, ensuring we tag it as @escaping since it will be used outside the scope of init(). Finally, in openList() we execute the closure to receive the list at the given URL.

Typealias Unit Test

class GroceryListManagerTests: XCTestCase {
    func testThrowsWhenFileIsMissing() {
        enum Errors: Error {
           case fileNotFound
        }
        let mockLoader: LoadGroceryList = { _ in throw Errors.fileNotFound }
        let manager = GroceryListManager(loader: mockLoader)
        XCTAssertThrow(try manager.openList(name: "Walmart"))
    }
}

Because the typealias defines the closure signature needed to fulfill the requirements needed by GroceryListManager class, we no longer need a mock class to be created. We can directly implement a custom implementation needed in the closure.

It could even be simplified to the following:

class GroceryListManagerTests: XCTestCase {
    func testThrowsWhenFileIsMissing() {
        enum Errors: Error {
           case fileNotFound
        }
        let manager = GroceryListManager(
            loader: { _ in throw Errors.fileNotFound })
        XCTAssertThrow(try manager.openList(name: "Walmart"))
    }
}

As you can see, the unit test is much easier to comprehend, as we no longer depend on the specific implementation of the Mock.

Declaring conformance in another class

In reality, many of your classes may expose multiple functions. You can still be empowered to use typealias, for example:

typealias LoadGroceryList = (URL) throws -> GroceryList

class MyGroceryListLoader {
   let loadFromUrl: LoadGroceryList = loadGroceryList

   private func loadGroceryList(_ url: URL) throws -> GroceryList {
     ...
   }
}

You can also define protocol conformance like you used to if needed:

typealias LoadGroceryList = (URL) throws -> GroceryList
typealias WriteGroceryList = (GroceryList, URL) throws -> Void

protocol GroceryListLoaderWriter {
   var loadFromURL: LoadGroceryList { get }
   var writeToURL: WriteGroceryList { get }
}

class MyGroceryListLoaderWriter: GroceryListLoaderWriter {
   let loadFromURL: LoadGroceryList = loadGroceryList
   let writeToURL: WriteGroceryList = writeGroceryList

   private func loadGroceryList(_ url: URL) throws -> GroceryList {
      ...
   }

   private func writeGroceryList(_ groceryList: GroceryList, _ url: URL) throws {
      ...
   }
}

class MyGroceryListManager {
   let loader: GroceryListLoaderWriter
   var openedLists = [Name: GroceryList]()

   init(loader: GroceryListLoaderWriter) {
      self.loader = loader
   }

   func openList(name: String) throws {
      let listUrl = URL(string: "/path/to/\(name).json")!
      openedLists[name] = try loader.loadFromUrl(listUrl)
   }
}

let myLoaderWriter = MyGroceryListLoaderWriter()
let myManager = MyGroceryListManager(loader: myLoaderWriter)

In the above case however, we can notice that MyGroceryListManager doesn't use the writer, only the reader, so it can be simplified to:

class MyGroceryListManager {
   let loader: LoadGroceryList
   var openedLists = [Name: GroceryList]()

   init(loader: @escaping LoadGroceryList) {
      self.loader = loader
   }

   func openList(name: String) throws {
      let listUrl = URL(string: "/path/to/\(name).json")!
      openedLists[name] = try loader(listUrl)
   }
}

let myLoaderWriter = MyGroceryListLoaderWriter()
let myManager = MyGroceryListManager(loader: myLoaderWriter.loadFromUrl)

Conclusion

Using typealias can provide you with additional flexibility and may end up requiring fewer lines of code in your app and in your unit tests.

If your class depends on the entirety of the protocol, then please continue to use your protocols like you are used to. However, if your class depends only on a subset of your protocol, a typealias may just be the tool that will allow you to simplify your unit tests and your dependency injections.

How do you receive email addresses in your JSON? Do you use a simple string variable?

There is a high likelihood that your current JSON is not as secure as it could be. When combined with other vulnerabilities in libraries and operating systems, a wide range of undesirable outcomes, from crashes to compromised user devices, may arise due to insecure JSON handling.

Typical “Client” struct

Let's envision a scenario where we need to obtain a list of prospective clients from an API, which includes their names, ages, and email addresses.

[{"name":"John Doe","age":35,"email":"john@doe.test"}]

It would be typical to expect the following associated code:

struct Client: Codable {
    let name: String
    let age: Int
    let email: String
}

func decodeClientList(data: Data) throws -> [Client] {
    return try JSONDecoder().decode([Client].self, from: data)
}

Unfortunately, this allows for various inputs that don't make sense in our context. For instance, does it make sense for a client's age to be 150,000 years old? Yet, your JSON permits it. Similarly, the email address could be set to "Hello" in the JSON, and the decoder wouldn't raise any issues.

You may need to perform validation on the Client data after it has been decoded. Additionally, remember to re-validate the data when retrieving it from CoreData later on or when accessing it through your caching layer.

Instead, you could declare your Codable in such a way that validation is performed while decoding.

Age

Let’s begin by defining the minimum and maximum age for your clients.

• Any “age” value higher than 150 is likely a mistake and shouldn’t be allowed.

• Negative values are clearly out of the question (you could use UInt..)

• You might even want to set a minimum value, let’s go with 1 for now

struct Age: Codable {
    let value: Int

    enum Errors: Error {
        case outOfRange
    }

    static let minimumAge = 1
    static let maximumAge = 150

    @discardableResult
    static func evaluated(_ age: Int) throws -> Int {
        guard (minimumAge...maximumAge).contains(age) else {
            throw Errors.outOfRange
        }
        return age
    }

    init(from decoder: Decoder) throws {
        let age = try decoder
            .singleValueContainer()
            .decode(Int.self)
        self.value = try Age.evaluated(age)
    }    
}

In the code above, we have created a struct that contains an integer value representing age, and we have defined the errors that will be thrown if the value does not meet our criteria. We then proceed to create a static function that evaluates the value against our criteria.

The purpose of using a static function for evaluation outside the decoder is that it can be reused in other initializers or anywhere within our app where we need to determine if a value meets the criteria.

Finally for the Age struct, we define the initializer, that extracts the value, evaluates and stores it.

Name

After taking some time to reflect on client names, I realize that I'm not aware of anyone having a name longer than 100 characters, and certainly no one with a name exceeding 500 characters. It's also safe to assume that no one has an "@" symbol or a backslash in their name. Defining some rules, we obtain:

• Can contain alphabetical characters (from various alphabets and languages)

• Can contain spaces but only between the names

• Should contain at least 2 characters

• Should be no longer than 100

struct Name: Codable {
    let value: String

    enum Errors: Error {
        case tooShortOrTooLong
        case invalidCharacters
    }

    static let minimumTrimmedLength = 2
    static let maximumTrimmedLength = 100
    static let allowedCharacters: CharacterSet = .alphanumerics
        .union(.whitespaces)

    @discardableResult
    static func evaluated(_ name: String) throws -> String {
        let trimmed = name.trimmingCharacters(in: .whitespacesAndNewlines)
        guard (1...100).contains(trimmed.count) else {
            throw Errors.tooShortOrTooLong
        }
        let disallowedCharacters = allowedCharacters.inverted
        guard trimmed.rangeOfCharacter(from: disallowedCharacters) == nil else {
            throw Errors.invalidCharacters
        }
        return trimmed
    }

    init(from decoder: Decoder) throws {
        let string = try decoder
            .singleValueContainer()
            .decode(String.self)
        self.value = try Name.evaluated(string)
    }
}

We begin the same way by defining the criteria and possible evaluation errors. Followed by the static function to perform the evaluation and the initializer.

Email

Emails are one of the hardest to validate by syntax alone, and this can clearly be seen by the sheer amount of RegEx that exists, all different from one another, to perform the same task.. all succeeding or failing to various degrees. Ref: https://stackoverflow.com/questions/156430/is-regular-expression-recognition-of-an-email-address-hard

If you are looking for a strong Email syntax validation library, consider usingSwiftEmailValidatoravailable for free on GitHub.

import SwiftEmailValidator

struct Email: Codable {
    let value: String

    enum Errors: Error {
        case incorrectlyFormatted
    }

    @discardableResult
    static func evaluated(_ string: String) throws -> String {
        let trimmed = string.trimmingCharacters(in: .whitespacesAndNewlines)
        guard EmailSyntaxValidator.correctlyFormatted(trimmed) else {
            throw incorrectlyFormatted
        }
        return trimmed
    }

    init(from decoder: Decoder) throws {
        let string = try decoder
            .singleValueContainer()
            .decode(String.self)
        self.value = try Email.evaluated(string)
    }
}

Secure “Client” struct

We can now go in our original Client struct and update the struct to use our new Codable values:

struct Client: Codable {
    let name: Name
    let age: Age
    let email: Email
}

func decodeClientList(data: Data) throws -> [Client] {
    return try JSONDecoder().decode([Client].self, from: data)
}

Conclusion

It is fairly easy to greatly improve our handling of JSON data by defining custom data types with their own evaluation rules and initializers.

Remember that validation rules need to be evaluated against:

• Your business requirements

• Intended demographics

• RFC documents

• Other libraries with which you interact (maximum variable length, CoreData SQL injections, …)

• Other restrictions imposed by the database administrator, API, etc…

Finally, always define unit tests to validate that your code works as intended.

In this article, we will cover how to define a new class and type-specific enum to ensure that each key can only read/written by a specific data type.

Problem definition

Given a key for UserDefaults, you can store and retrieve any type. For example:

let userDefaults = UserDefaults.standard
userDefaults.set(35, forKey: "MyValue")
userDefaults.set("I love Swift", forKey: "MyValue")

In the example above, we initially set an integer type value for the key “MyValue” but then we overwrite that value with a string. If the value is read back expecting an Integer we might not get what we expected:

let integerValue = userDefaults.integer(forKey: "MyValue")
print("MyValue:", integerValue)
// MyValue: 0

UserDefaults will silently store different types for the same key. It will also silently return to you automatically converted values between the last stored type for a given key and the type you are trying to retrieve.

While this flexibility may be useful, developers have to manually ensure they are using the correct data types associated to each key. Below is a method by which we can guarantee at compile time that any given key is only accessed using the expected type.

Enforcing Type in UserDefaults

Let’s start by creating a new class which will supervise read/write operations to UserDefaults for two types: Integer and String.

class TypeSafeUserDefaults {

    // Integer
    func integer(forKey key: String) -> Int {
        UserDefaults.standard.integer(forKey: key)
    }

    func set(_ integer: Int, forKey key: String) {
        UserDefaults.standard.set(integer, forKey: key)
    }

    // String
    func string(forKey key: String) -> String {
        UserDefaults.standard.string(forKey: key)
    }

    func set(_ string: String, forKey key: String) {
        UserDefaults.standard.set(string, forKey: key)
    }
}

So far, nothing would prevent us from encountering the same issue we did with UserDefaults. We could very easily set either an Integer or a String for any given key. Let’s solve this:

class TypeSafeUserDefaults {

    enum IntegerKey: StringLiteralType, RawRepresentable {
        case myIntegerValue
    }

    enum StringKey: StringLiteralType, RawRepresentable {
        case myStringValue
    }

    // Integer
    func integer(forKey key: IntegerKey) -> Int {
        UserDefaults.standard.integer(forKey: key.rawValue)
    }

    func set(_ integer: Int, forKey key: IntegerKey) {
        UserDefaults.standard.set(integer, forKey: key.rawValue)
    }

    // String
    func string(forKey key: StringKey) -> String? {
        UserDefaults.standard.string(forKey: key.rawValue)
    }

    func set(_ string: String, forKey key: StringKey) {
        UserDefaults.standard.set(string, forKey: key.rawValue)
    }
}

Let's see if it works....

Success! Our TypeSafeUserDefaults now prevents us from storing a string in a key expected to be used to store integers. Better yet, we get immediate feedback directly in Xcode and our project will fail to compile if we attempt to use the wrong type.

Ensuring all keys are unique

While the TypeSafeUserDefaults prevents storing values of the wrong type, if the two enums define the same keys, we can still end up with the same issue. Consider:

enum IntegerKey: StringLiteralType, RawRepresentable {
  case myValue
}

enum StringKey: StringLiteralType, RawRepresentable {
  case myValue
}

Unfortunately I haven’t found a way to get compile time errors from this. Luckily, Xcode supports unit tests so we can confirm our keys are unique by making our enum CaseIterable and using some unit tests. Let’s generate some enum with duplicated keys:

enum IntegerKey: StringLiteralType, RawRepresentable, CaseIterable {
    case myIntegerValue
    case myOtherValue
}

enum StringKey: StringLiteralType, RawRepresentable, CaseIterable {
    case myStringValue
    case myOtherValue
}

Now let’s implement a unit test to confirm all keys are unique:

import XCTest
@testable import TypeSafeUserDefaultsDemo

class TypeSafeUserDefaultsEnumTests: XCTestCase {

    func testKeysAreUnique() {
        var keysAlreadyEncountered: Set<String> = Set()

        TypeSafeUserDefaults.IntegerKey.allCases.forEach {
            keysAlreadyEncountered.insert($0.rawValue)
        }

        TypeSafeUserDefaults.StringKey.allCases.forEach {
            XCTAssertFalse(keysAlreadyEncountered.contains($0.rawValue), "StringKey \($0) conflicts with an already defined key")
            keysAlreadyEncountered.insert($0.rawValue)
        }
    }
}

When the unit tests run, we will now get this failure:

XCTAssertFalse failed — StringKey myOtherValue conflicts with an already defined key

I hope this saves you hours of troubleshooting. Enjoy!

When management attempts to qualify the quality of their product and development processes, they often look for existing metrics to inform their decisions.

Unfortunately...

Most automated code quality metrics should not be utilized by management. The number of "issues" discovered, or the complexity of a function, are metrics intended for developers themselves, to help steer their work.

In many instances, these metrics rely on false positives. Unless your team consistently reviews issues flagged by the automated tool, a significant portion of the identified issues will be false positives. Likewise, the tool will probably overlook more substantial concerns, such as excessively complex architecture.

The metrics that matters the most are:

• How long it takes for a new programmer on the team to understand what the code does?

• How happy are the developers working on the code base?

By focusing on reducing the amount of time it takes to onboard a new developer, you are indirectly making the code easier to understand. Code that is easier to understand inevitably leads to fewer defects.

Focusing on making your developers happy leads to greater productivity and less turnover.

Finally, if you really want to focus on producing quality, look at the customer/user reviews.

Let’s imagine that you create a view and it’s view model. Everything works, the project is released and everyone is happy. A couple months after, a new feature is added and you need another view that looks 100% like the one you implemented, except the logic in how the view is used is entirely different.

You find yourself having to either duplicate the SwiftUI view, or refactor the one you had created so it’s no longer tightly coupled, jeopardizing the stability of the already developed feature.

If your view requires interaction with a view model, you should extract all the visible parts of the view into its own SwiftUI view, keeping it agnostic of the view model. You end up with two SwiftUI views, one with knowledge of the view model that doesn’t have any design whatsoever in it, and another with all the design and no reference to the view model.

Example of what NOT to do:

import SwiftUI

struct BadDesignView: View {
    @StateObject var viewModel: LoginViewModel

    var body: some View {
        VStack {
            if viewModel.showLoginForm {
                TextField("Username", text: $viewModel.enteredUserName)
                Button("Login", action: viewModel.login)
            }
            if let username = viewModel.loggedInUser {
                Text("Greetings, \(username)")
            }
        }
    }
}

struct BadDesignView_Previews: PreviewProvider {

    static let loggedInVm: LoginViewModel = {
        let vm = LoginViewModel()
        vm.enteredUserName = "Mike Mousey"
        vm.login()
        return vm
    }()

    static let loggedOutVm: LoginViewModel = LoginViewModel()

    static var previews: some View {
        BadDesignView(viewModel: loggedOutVm)
            .previewDisplayName("Logged Out")
            .previewLayout(.sizeThatFits)

        BadDesignView(viewModel: loggedInVm)
            .previewDisplayName("Logged In")
            .previewLayout(.sizeThatFits)
    }
}

Example of reusable design:

import SwiftUI

struct ReusableDesignView: View {

    let showLoginForm: Bool
    @Binding var enteredUserName: String
    let loggedInUser: String?
    let loginAction: () -> Void

    var body: some View {
        VStack {
            if showLoginForm {
                TextField("Username", text: $enteredUserName)
                Button("Login", action: loginAction)
            }
            if let username = loggedInUser {
                Text("Greetings, \(username)")
            }
        }
    }
}

struct ReusableDesignView_Previews: PreviewProvider {
    static var previews: some View {
        ReusableDesignView(
            showLoginForm: true,
            enteredUserName: .constant(""),
            loggedInUser: nil,
            loginAction: { /* do nothing */ })

        ReusableDesignView(
            showLoginForm: false,
            enteredUserName: .constant(""),
            loggedInUser: "Mike Mousey",
            loginAction: { /* do nothing */ })
    }
}

import SwiftUI

struct LoginView: View {
    @StateObject var viewModel = LoginViewModel()

    var body: some View {
        ReusableDesignView(
            showLoginForm: viewModel.showLoginForm,
            enteredUserName: $viewModel.enteredUserName,
            loggedInUser: viewModel.loggedInUser,
            loginAction: viewModel.login)
    }
}

In a MVVM architecture, the logic is moved into a view model to allow testing the logic separately from the user interface.

Isolating a designed view from the view model improves re-usability of the view.

As a side effect, creating your Previews will be easier. You no longer have to find a way to bring the view model into the expected state, or have to create mock view models.

If you want to study on your own, make sure you understand Symmetric and Asymmetric cryptography, how to use CryptoKit, how to encrypt/decrypt files using AES GCM, how to sign and verify signature of data using P256, how to generate a symmetric key using asymmetric keys using P256 ECDH key derivation.

You will also want to understand how to use Apple's TouchId and FaceID, how to use the SecureEnclave, the Keychain.

Make sure you know how to enable iOS file protection when writing files to disk (NSFileProtectionComplete) and how you can also set this by default using App Entitlements.

There's also Runtime Application Self-Protection (RASP), TLS Pinning, making sure you account for TLS bypass attacks.

Understanding mobile security also means knowing which tools the hackers use, so get familiar with MobSF, Frida, Ghidra, and Radare2. Be aware that like most topics, this is a rabbit hole from which you may never reach the end.

Other stuff you may want to brush up on:

• Data validation

• User input sanitation

• Data categorization (PII, public, private, classified, export controlled, etc)

• Data retention

• Privacy cover screen

• Secure text fields

• API documentation (defining maximum lengths, allowed characters, date formats, integer ranges, nullable fields, etc)

• Memory safety

• Objective-C method swizzling

• AppDelegate swizzling

• Red Team / Blue Team

Make sure to also watch security forums, read up on all the latest zero-days. Hackers keep innovating and discovering new ways to compromise our systems so we have to find new ways to defend our apps!

Go blue team!

TLS Pinning is a method by which we setup a URLSession delegate, during the TLS handshake the delegate will compare the public certificate against an expected certificate.

Hackers have since developed a method to bypass this using a tool named Objection, distributed as part of Frida. Using this tool, they use the .dylib loading mechanism to intercept and redirect SSL library calls. They can then immediately accept all certificate requests, all with a single command.

When they do this, the two attacks they can perform is to either skip the app URLSession delegate method entirely, or change the response from the URLSession delegate from Rejected to Accepted.

So how can we protect against this?

In the solution below, when a secure communication is required, we create a brand new URLSession and its delegate. A query is made and verify the TLS certificate like we usually do for TLS Pinning. However, we also record whether or not the TLS certificate was validated and if it passed validation.

Upon receiving the data/response, we double-check with the delegate whether it received a certificate validation request and whether the validation was successful.

Assuming either of the current Objection attacks, this method would correctly detect a TLS validation bypass attack. If they skip the validation and return data, it will be detected. And if they override the rejection with an acceptation, since we are performing the extra step of double-checking with our custom used-once delegate, it will also detect it.

SecureURLSession

final class SecureURLSession {

    private final class Delegate: NSObject, URLSessionDelegate {
        private let expectedHost: String
        var validatedChallenge: () -> Void = { /* to be set later */ }
        private let allowedSignatures: [Data]

        init(host: String, allowedSignatures signatures: [Data]) {
            expectedHost = host
            allowedSignatures = signatures
            super.init()
        }

        func urlSession(
            _ session: URLSession,
            didReceive challenge: URLAuthenticationChallenge,
            completionHandler: @escaping @Sendable (URLSession.AuthChallengeDisposition, URLCredential?) -> Void
        ) {
            guard expectedHost == challenge.protectionSpace.host,
                  let serverTrust = challenge.protectionSpace.serverTrust,
                  let signature = signatureFromTrust(serverTrust),
                  allowedSignatures.contains(signature)
            else {
                completionHandler(.rejectProtectionSpace, nil)
                return
            }

            validatedChallenge()
            completionHandler(.useCredential, challenge.proposedCredential)
        }

        private func signatureFromTrust(_ trust: SecTrust) -> Data? {
            guard SecTrustGetCertificateCount(trust) > 0,
                  let certificate = SecTrustGetCertificateAtIndex(trust, 0)
            else {
                return nil
            }

            let certificateData = SecCertificateCopyData(certificate) as Data
            let digest = SHA256.hash(data: certificateData)
            return Data(digest)
        }
    }

    init(configuration: URLSessionConfiguration = .default, host: String, allowedSignatures: [Data]) {
        let sessionDelegate = Delegate(host: host, allowedSignatures: allowedSignatures)
        session = URLSession(
            configuration: configuration,
            delegate: sessionDelegate,
            delegateQueue: nil)
        delegate = sessionDelegate
        delegate.validatedChallenge = { [weak self] in self?.continuation = { true } }
    }

    private let delegate: Delegate
    private let session: URLSession
    private var continuation: () -> Bool = { false }

    enum Errors: Error {
        case sslBypassDetected
    }

    func data(from url: URL) async throws -> (Data, URLResponse) {
        let (data, response) = try await session.data(from: url)
        guard continuation() else {
            throw Errors.sslBypassDetected
        }
        return (data, response)
    }
}

How to use

And here’s a sample code securely fetching an Emoji using TLS Pinning while preventing TLS bypass:

extension URLResponse {
    func isHttpWithStatusCode(_ statusCode: Int) -> Bool {
        guard let httpResponse = self as? HTTPURLResponse else {
            return false
        }
        return httpResponse.statusCode == statusCode
    }
}

struct FetchEmojiActivity: Sendable {

    enum Errors: Error {
        case unexpectedServerResponse
    }

    /// {
    ///   "name": "hugging face",
    ///   "category": "smileys and people",
    ///   "group": "face positive",
    ///   "htmlCode": ["🤗"],
    ///   "unicode": ["U+1F917"]
    /// }
    struct DTO: Decodable {
        let name: String
        let unicode: [String]
    }

    func begin() async throws -> String {
        let emojiHubTlsSignature = Data(base64Encoded: "88bp12uxOpEr+AukM0O/I/9Jt+/gYpN+u2FPiLeD8tI=")! <-- do not store your security hash in a string in a Production
        let secureUrlSession = SecureURLSession(
            host: "emojihub.yurace.pro",
            allowedSignatures: [emojiHubTlsSignature]
        )
        let randomEmojiUrl = URL(string: "https://emojihub.yurace.pro/api/random")!
        let (data, response) = try await secureUrlSession.data(from: randomEmojiUrl)
        guard response.isHttpWithStatusCode(200) else {
            throw Errors.unexpectedServerResponse
        }

        let dto = try JSONDecoder().decode(DTO.self, from: data)
        let emoji = dto.unicode
            .compactMap { (_ seq: String) -> String? in
                guard let int = Int(seq.replacingOccurrences(of: "U+", with: ""), radix: 16),
                      let scalar = UnicodeScalar(int)
                else {
                    return nil
                }
                return String(scalar)
            }
            .joined()
        return emoji
    }
}

CAVEAT: For sake of simplicity, the TLS certificate in the FetchEmojiActivity is included as a string. This should be avoided unless you have some kind of cryptographic signature validation elsewhere in your code to ensure the hacker has not replaced it with its own validation hash.

Limitations and Usage

We shouldn’t be re-using the above SecureURLSession instance for multiple queries. Reusing the SecureURLSession class above for multiple queries would allow the attacker to bypass the TLS validation after the first request is made.

This will have an impact on performance. Doing this for background URLSession is not recommended as it will trigger your app to be throttled by the system.

The mechanism described here should only be used when the utmost security is required, like when bootstrapping a public/private asymmetric key exchange with the server.

Remember to implement TLS certificate update mechanism in your application. Your TLS certificate will eventually expire or may have to be revoked; you will want your current app installations to continue working after you publish a new TLS certificate on your server. Consider using LaunchDarkly or other similar services to transmit an encrypted hash overriding the built-in hash.

If your application needs to do multiple parallel server queries or background transfers, consider using symmetric cryptography for your API queries & responses on top of the standard URLSession without TLS pinning; limit the use of SecureURLSession to transfer your encryption keys and certificates.

Conclusion

It seems possible to prevent typical TLS pinning bypass attacks by creating a custom URLSession and delegate when making a new request.

It’s impossible to fully protect against all attacks. If the attacker is able to do a memory dump of your process, use a debugger, modify your binary executable, there’s not much you can do. Clever attackers may even be able to acquire the master secret used to establish the TLS connection along with the exchanged keys then combined with Pcap gain access to all encrypted traffic. The best protection against these kinds of attack is Runtime Application Self-Protection (RASP).

However, as with anything, an extra layer of security means fewer hackers able to pull off the attack, or at the very least more efforts required which may be just enough to discourage an attacker.

Assuming RASP is able to detect runtime intrusion, the mechanism here should be able to properly protect your TLS communications.

Stay safe!

1. The mobile app should retrieve only the minimum amount of information required to operate from the servers.

2. All user data stored by the app, whether on disk, Keychain, or UserDefaults, should be encrypted. Do not rely on the Keychain to do the encryption for you or the iOS to enforce its protection mode.

3. Use TLS pinning to validate that the communication to/from the server is secure and not intercepted by a “trusted” certificate on the device. Make sure to also build an update mechanism so the mobile app installations can continue working when your server certificate is updated.

4. When recording logs or analytics, make sure not to record any PII (Personally Identifiable Information). You can use encryption, cryptographic hashing or tokenization, or better yet, keep the information recorded as generic as possible. Make sure those same logs and analytics do not record any API response data unless that data is once again encrypted.

5. If you store API keys or software licenses in your mobile application, do not store the information in the Info.plist or in strings. Even strings injected by your CI/CD pipeline at build time are unsafe.
   If possible, use server services, and only if required, use encryption to protect your API keys and licenses and only decrypt them in memory at runtime. Never store the decrypted keys anywhere.

6. Use only trusted third-party libraries and frameworks. If you cannot vouch for the identity or trustworthiness of the library's maintainer, you shouldn’t use it. If you insist on using it, you should do an in-depth security assessment at every update you want to include, then use cryptographic signature validation to ensure the authenticity of the library hasn’t been compromised.

7. Use a privacy screen to cover the information displayed by the app when the app is pushed to the background. This will prevent iOS from automatically capturing screenshots of your app when it goes to the background, which could lead to PII leaks.

8. When your app receives information via copy/paste, or if the user can manually enter information in a field, always validate the information entered by the user to the maximum extent possible.
   Check for maximum length, allowed characters, and the values match expectations. If the information should never leave the app, make sure to set up and use a custom Pasteboard unique to your app.

9. Use biometrics carefully. It doesn’t validate the user's identity, only that this user can use biometrics to unlock it. Often, a family will set up multiple faces or fingerprints to unlock a device, leading to multiple users passing biometric validation.

10. Validate all the data you receive from API response or even data loaded from disk previously saved by your app. A third party may have compromised or modified this data if the device is hacked.

11. Never assume that a compromised device is intentional on the user's part. Hackers may remotely take control of the device using zero-day vulnerabilities, and the user may not be aware their device was compromised.

While this list doesn’t fully represent the entire extent of security mechanisms, I find that it covers what I consider the very minimum that every app developer should do.

Even if you think the jogging route isn’t critical data, when a celebrity or diplomat enters the jogging route recorded in your app, leaking this data may risk personal harm to the individual.

If you have any doubts, play it safe. And remember to do a full threat assessment.

Community Contributions

12. Use the Swift language for new projects and allocate meaningful resources to your plan to migrate your codebase from Objective C to Swift. Use memory-safe languages for cloud server components.

13. Use automated unit tests to ensure your application architecture's designed security elements remain secure as your application evolves.

14. Use DocC to document the security features of your application design in the code so that future developers can understand the context and decisions made. This will help prevent security from being accidentally undermined by future changes to the system design.

Here’s a reference for more information.

For a more complete guide to application security, you should refer to the OWASP MAS by clicking this link.