Application protection fits a Swift app by following how the app is built: which code is compiled into your executable, which ships as your own frameworks, which arrives signed by a vendor, and which runs in app extensions. Otukan protects the Swift you write and the dependencies linked into it, hardens the metadata Swift leaves in a binary, and adds runtime checks for the paths where Swift and Objective-C meet. Vendor binaries stay as delivered. Everything is accepted on physical iPhones with your toolchain and your crash reporting. Objective-C-heavy code has its own page, Objective-C app security.
Native binary and framework coverage
A Swift app is rarely one binary. How each dependency is linked decides where it ends up and who can protect it.
| Dependency form | Where its code ends up | How Otukan treats it |
|---|---|---|
| Your app target | The main executable | Protected, including the Swift metadata of your types |
| Swift packages built from source | Linked statically into the target that imports them | Protected with that target, like your own code |
| Your own dynamic frameworks | A separate signed binary in the bundle | Protected, keeping the public interface other targets call |
| Vendor XCFrameworks and binary packages | A separate binary signed by the vendor | Left as delivered, so its signature stays valid |
| Code shared with extensions | Usually an embedded framework loaded by both | Protected once and covered wherever it loads |
What Swift leaves readable
Swift keeps more in the binary than many teams expect. Type descriptors carry type names. Mangled symbols encode module, type and function names. Reflection metadata lists stored property names so Mirror and debuggers can use them. String literals sit in plain form. Otukan hardens this surface in your modules and keeps the parts features rely on: Codable keys, @objc names used by storyboards and anything you declare as reached dynamically.
Objective-C interoperability and extensions
Most Swift apps still talk to the Objective-C runtime. Any class that inherits from NSObject, and any member marked @objc, is registered there and dispatched by message. Members marked @objc dynamic are dispatched through that runtime even when called from Swift.
Two dispatch paths, two kinds of hook
Pure Swift calls are resolved statically or through type tables, so an attacker has to patch code or rebind symbols to intercept them. @objc members can be swapped through the Objective-C runtime with a few lines of code. Otukan watches both paths for the functions you mark as sensitive and reports which one was used. Detection detail is on iOS hooking detection.
App extensions
Widgets, notification service extensions and share extensions are separate executables with their own entitlements and tighter memory limits. They often reach the same Keychain access group and App Group container as the app. Otukan covers the extensions you choose, and acceptance confirms that each protected extension runs within the memory limit iOS gives it.
Compiler compatibility, signing and crash diagnosis
Toolchain changes
Swift’s compiler changes how it lays out metadata and optimises code from one Xcode release to the next. Otukan treats a toolchain upgrade as a trigger for acceptance: the protected build is rebuilt, run on physical devices and compared with the unprotected one before your team adopts the new Xcode for release.
Build settings worth reviewing
A few Swift settings change what the binary exposes, and your team should know how they interact with protection. Whole-module optimisation changes which functions are inlined and which remain as separate symbols. Library evolution, used when you ship a framework to other teams, keeps extra metadata so clients stay compatible across versions. Reflection metadata settings decide whether Mirror can read property names. Otukan reviews these settings with your engineers during scoping, so the protected build keeps the behaviour your modules rely on and hardens everything else.
Signing
You archive and sign exactly as today. Protection fits your existing build and release pipeline, and your distribution certificate, provisioning profiles and private keys stay with your team. Each embedded framework and extension keeps its own valid signature after protection.
Crash diagnosis
A protected build produces dSYM files that match the binaries you ship. Your team forces a crash in a test build, confirms it symbolicates to original Swift function names, and confirms async stack frames still read correctly. Protected crash reports then flow into your existing tooling unchanged.
Return to iOS app security for the platform view, and see iOS app security guides for step-by-step material.