Why are secrets in the app binary not secret, and what do you do instead?

Everything you ship runs on a device the attacker owns, and an iOS app binary can be downloaded, decrypted and inspected with common tools in minutes. A string literal in your code is stored in the executable’s data: running strings on the binary, or searching its bytes, finds "sk_live_…" exactly as written, whether the build was optimised or not. The same goes for API keys in Info.plist, JSON config files, asset catalogs and plists in the bundle, and values hidden in #if branches that still ship. Obfuscation (splitting a string, XOR-ing it, base64) only raises the cost slightly: the program must reconstruct the secret to use it, so a debugger, a hook (Frida) or a breakpoint at the use site reveals it. Treat any key that can authenticate to a backend, sign requests or decrypt data as already compromised if it ships in the app.

What to do instead. Keep real secrets on the server. The app should authenticate the user (OAuth, sessions) and receive short-lived tokens; the server holds third-party API keys and calls those services on the app’s behalf (a proxy), which also allows rate limits and revocation. If the client must call a service directly, use scoped, low-privilege, revocable keys with restrictions (bundle id, domain, quota) and rotate them; publishable keys (such as a payment provider’s public key) are designed to be public. Generate per-install secrets at runtime (a random key kept in the Keychain) instead of shipping a global one, and use App Attest to make the server trust requests only from the genuine app. Keep secrets out of version control and CI logs, inject build-time values through the build system without committing them, and scan the repository and the built artefact for leaked keys. Accept the residual risk consciously: a determined attacker can read anything the app can read, so the design goal is that what they extract has little value and is cheap to revoke.