Where do Themis integrations usually go wrong in a production iOS app?

Answer: The library removes cipher-level mistakes but not key-management or operational ones, and those are where real integrations fail. Themis will happily encrypt with a hardcoded key or a key you can never rotate.

The recurring problems:

1. Force-unwrapping the initialisers. TSCellSeal(key:) and TSMessage(...) return optionals and are nil for invalid key material. ! turns a recoverable key-loading bug into a crash on a user's device.
2. No rotation plan. Ciphertext with no version marker cannot be re-encrypted under a new key later. Prefix stored blobs with a scheme version from day one.
3. Forgetting the context. Secure Cell's context is not stored in the ciphertext; if you cannot reconstruct the exact bytes at decrypt time, the data is gone.
4. Losing the key on reinstall. Keychain items outlive app deletion, but a wiped or restored-to-new-device Keychain does not — encrypted caches must be discardable, never the only copy.
5. Debuggability collapse. Once every request body is a blob, Charles and Proxyman show you nothing. Build a debug-only unwrap path early or you will pay for it during every incident.
6. Binary size and build time. The pod pulls in a full OpenSSL/BoringSSL build.

Key Points:

• Treat every Themis initialiser as failable and surface a typed error.
• Version your ciphertext format before you ship it, not after.
• Encrypted local caches must always be safe to delete and refetch.