IPA Sealing
IPA Sealing protects an already-built iOS app. You upload the compiled .IPA to the Developer Console, DoveRunner injects RASP (Runtime Application Self-Protection) and anti-tampering defenses directly into the binary, and you download the protected build.
Nothing in your source code or app logic changes — the process operates on the compiled binary.
Signing: Why It Matters
Section titled “Signing: Why It Matters”Injecting protections modifies the app executable, which invalidates the original code signature. A sealed IPA must be re-signed before iOS will install or run it. You have two ways to handle that:
| Approach | What you upload | Result |
|---|---|---|
| DoveRunner re-signs for you | IPA + provisioning profile + .p12 certificate + certificate password | The downloaded IPA is signed and ready to install or submit. |
| You re-sign yourself | IPA only | The downloaded IPA is unsigned. You must re-sign it with your own tooling before it can be installed or submitted. |
Required Assets
Section titled “Required Assets”Only the application binary is required to start sealing. The other three assets are needed only if you want DoveRunner to re-sign the output for you.
| Artifact | Format | Required | Purpose |
|---|---|---|---|
| Application Binary | .IPA | Yes | The unprotected compiled iOS application, built with Xcode or your CI/CD pipeline. |
| Provisioning Profile | .mobileprovision | Only for re-signing | Defines allowed installation targets, App ID capabilities, and entitlements. |
| Signing Certificate | .p12 (PKCS#12) | Only for re-signing | Contains the private key and the Apple-issued distribution or development certificate. |
| Certificate Password | Plain text | Only for re-signing | Decrypts the password-protected .p12 private key container. |
Application Binary (.IPA)
Section titled “Application Binary (.IPA)”- Source — Exported directly from Xcode as an
.IPA, or generated by your automated build system. - Architecture — Must target standard iOS devices (ARM64).
- Decrypted build — The IPA must be a decrypted build. An app downloaded from the App Store carries FairPlay encryption and cannot be sealed directly.
- Bitcode — Disable Bitcode during export. DoveRunner requires standard compiled ARM64 binaries, and Apple has deprecated Bitcode in recent Xcode releases.
- Integrity — Make sure the binary is compiled and working before protecting it. The original signature is replaced during sealing.
Provisioning Profile (.mobileprovision)
Section titled “Provisioning Profile (.mobileprovision)”- Bundle ID matching — The profile’s App ID must match the app’s primary Bundle ID exactly, or use an authorized wildcard App ID.
- Entitlements parity — Every capability the app uses (App Groups, Push Notifications, Associated Domains, Keychain Sharing, and so on) must be explicitly included in the profile.
- Distribution method — Match your intended deployment target: Development, Ad-Hoc, Enterprise In-House, or App Store.
Signing Certificate (.p12) and Password
Section titled “Signing Certificate (.p12) and Password”- Format — A
.p12(PKCS#12) file containing both the certificate and its matching private key. - Validity — Must be unexpired and issued by Apple (Apple Development or Apple Distribution).
- Source — Exported from macOS Keychain Access under My Certificates.
- Password — The passphrase you chose when exporting the
.p12.
Exporting a .p12 from Keychain Access
Section titled “Exporting a .p12 from Keychain Access”-
Open Keychain Access on your Mac (Spotlight, or Applications → Utilities).
-
In the sidebar, select login under Keychains and My Certificates under Category.
-
Find your active Apple Distribution or Development certificate — for example
iPhone Distribution: Company Name (Team ID). -
Expand the certificate entry and confirm the private key appears underneath it.
-
Select both the certificate and the private key, right-click, and choose Export 2 items….
-
Set the file format to Personal Information Exchange (.p12) and click Save.
-
Assign a strong password and keep it — you will need it in the Developer Console.
Always-On Protections
Section titled “Always-On Protections”Every IPA-sealed app gets the protections below. They are always enabled and require no coding. Step 1 of the wizard lists them under Inherent Features.
Always On Security
Section titled “Always On Security”| Protection | Description |
|---|---|
| Javascript Bytecode Encryption (React Native only) | Encrypts React Native JavaScript bytecode to prevent reverse engineering of business logic. |
| Code Encryption Flag | Applies code encryption flags to harden the binary against static analysis tools. |
| Certificates / Certificates check | Validates app signing certificates to ensure the app has not been re-signed by an unauthorized party. |
| Jailbreak Detection | Detects jailbroken devices and can prevent the app from running in a compromised environment. |
| Cheat Tool Detection | Detects common cheat tools, game hacking utilities, and unauthorized automation tools. |
| Files Integrity check | Verifies the integrity of app files — excluding Assets.car, frameworks, and whitelisted files — to detect unauthorized tampering. |
Anti Debugging & Runtime Attack
Section titled “Anti Debugging & Runtime Attack”| Protection | Description |
|---|---|
| Method Swizzling / Hook Detection | Detects and blocks Objective-C method swizzling used by tools like Frida and Cydia Substrate to inject malicious code at runtime. |
| Debugging / Attach Detection | Detects when a debugger is attached to the app’s process and closes the app. |
| Frida framework | Detects the Frida framework — a popular tool for debugging, hooking, and injecting scripts — on multiple layers. |
Sealing Workflow
Section titled “Sealing Workflow”Open iOS Mobile App Security → IPA Sealing → Apply AppSealing. The wizard has three steps:
| Step | Name | What it covers |
|---|---|---|
| 1 | Upload File | Upload the .IPA, and review the always-on protections |
| 2 | Basic Configuration | Framework declaration, distribution option, and — when you want DoveRunner to sign for you — the provisioning profile, .p12, and certificate password |
| 3 | Environment Detection | How the app reacts to a compromised or untrusted runtime environment |
Step 1 — Upload File
Section titled “Step 1 — Upload File”Select or drag your unprotected .IPA into the upload area. The panel beside it lists the always-on protections described above.
Step 2 — Basic Configuration
Section titled “Step 2 — Basic Configuration”| Option | Description |
|---|---|
| This app is built with React Native | Check this for React Native apps. React Native apps need the Hermes engine matching your exact React Native version to properly decrypt and run encrypted JavaScript. Checking it reveals Framework Version, where you select your React Native major and minor version. |
| AppSealing Version | The sealing version applied to the build. It is fixed to the current IPA sealing version and is not selectable. |
| Allow distributing without using the App Store & TestFlight. | Enable this if your app is distributed outside the App Store or TestFlight — for example, enterprise distribution or direct IPA installs. Leave it unchecked for standard App Store submissions. |
| Provisioning Profile (.mobileprovision) | Required for re-signing the sealed IPA. Skip it if you plan to re-sign yourself. |
| P12 Certificate | Required for re-signing the sealed IPA. Used for Ad Hoc and App Store distribution; it must contain both the certificate and the private key required for code signing. |
| P12 Password | The password set when exporting the .p12 from Keychain Access. |
Step 3 — Environment Detection
Section titled “Step 3 — Environment Detection”Configures how the sealed app responds to potentially compromised or untrusted runtime environments.
| Option | Values | Default | Description |
|---|---|---|---|
| Hooking | Block / Allow | Block | Blocks runtime hooking frameworks that inject code into the app. |
| Method Swizzling | Block / Allow | Block | Blocks Objective-C method swizzling used to replace app behavior at runtime. |
| Secure Storage | Enable / Disable | Enable | Protects app data held on the device. |
| Screen Capture | Block / Allow | Block | Prevents the app’s screen from being captured or recorded. |
| Do not terminate the App on detecting Threat. | Checkbox | Off | When checked, DoveRunner does not automatically terminate the app on detection, so you can handle the response yourself. Register a callback for each threat type — do not leave detections unhandled in production. |
Finish
Section titled “Finish”-
Click START APPSEALING to run binary injection, anti-tampering protection, and, if credentials were supplied, re-signing.
-
Download the sealed
.IPA. If you did not supply signing credentials, re-sign it yourself before distributing.
Past runs are listed under Historical Information, and per-app service settings under Configurations.
Credential Handling
Section titled “Credential Handling”- Ephemeral handling — Signing credentials are processed in isolated, ephemeral build environments.
- Not stored — Your
.p12file, certificate password, and provisioning profile are never stored permanently. They are destroyed as soon as the sealing session completes. - Anti-tampering seal — RASP, integrity checks, and anti-debugging mechanisms are bound to the binary signature, so any modification after sealing renders the binary non-executable.
Troubleshooting
Section titled “Troubleshooting”| Error | Cause | Resolution |
|---|---|---|
| Certificate decryption failed / invalid password | The password does not match the passphrase set when exporting the .p12, or the file is corrupted. | Re-export the certificate and private key together from Keychain Access with a simple plain-text passphrase. Verify it by importing the .p12 back into Keychain Access, then re-upload. |
| Bundle ID mismatch | The app’s Bundle ID does not match the App ID inside the .mobileprovision. | Check the Bundle ID in Xcode. Make sure the profile targets that exact Bundle ID or an authorized wildcard App ID (com.company.*). |
| Missing entitlements parity | The IPA uses capabilities (Push Notifications, App Groups, Keychain Sharing, …) that are missing from the uploaded profile. | Edit the provisioning profile in your Apple Developer account to enable every required capability, re-download it, and seal again. |
Private key missing from .p12 | Only the public certificate was exported. | In Keychain Access, expand the certificate entry, select both the certificate and the private key, then Export 2 items…. |
| App crashes on launch after sealing | The profile’s distribution type does not match the target environment — for example a Development profile used for a TestFlight build, or an unregistered device on an Ad-Hoc profile. | Confirm the .mobileprovision matches your distribution path. For Ad-Hoc testing, add the device UDID to the profile before generating it. |
Does sealing change my app’s functionality or source code? No. DoveRunner works on the compiled binary and injects RASP defenses and anti-tampering guards without touching your source code or app logic.
Can I submit a sealed .IPA directly to the App Store?
Yes. As long as the build is signed with an active Apple Distribution certificate and a production App Store provisioning profile — either by DoveRunner during sealing, or by you afterwards — the output is valid for App Store submission and TestFlight.
Why does DoveRunner need my .p12 private key and password?
Only when you ask DoveRunner to re-sign for you. Injecting protections breaks the original signature, and re-signing the modified binary requires the private key. If you prefer not to share it, upload only the IPA and re-sign the output yourself.
Are my signing credentials stored on DoveRunner servers?
No. Uploaded .p12 files, passwords, and .mobileprovision profiles are handled in ephemeral containers and destroyed as soon as the sealing session finishes.
Does DoveRunner support Bitcode builds? No. DoveRunner requires standard compiled iOS ARM64 binaries, so disable Bitcode during export.