---
title: "IPA Sealing"
description: "Protect a compiled iOS app by uploading the .IPA to the Developer Console — no SDK integration or code changes required."
---
> For the complete documentation index, see [llms.txt](/llms.txt).

import { Aside, Steps } from '@astrojs/starlight/components';

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.

<Aside type="note">
This is the alternative to [SDK Sealing](../sdk-sealing/), which integrates a downloaded SDK into your build pipeline. Use IPA Sealing when you would rather protect a finished build than change how it is built. If **IPA Sealing** does not appear in the iOS menu of your Developer Console, contact the [Help Center](https://support.doverunner.com).
</Aside>

## 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

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`)

- **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`)

- **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

- **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

<Steps>

1. Open **Keychain Access** on your Mac (Spotlight, or **Applications → Utilities**).

2. In the sidebar, select **login** under *Keychains* and **My Certificates** under *Category*.

3. Find your active Apple Distribution or Development certificate — for example `iPhone Distribution: Company Name (Team ID)`.

4. Expand the certificate entry and confirm the private key appears underneath it.

5. Select **both** the certificate and the private key, right-click, and choose **Export 2 items…**.

6. Set the file format to **Personal Information Exchange (.p12)** and click **Save**.

7. Assign a strong password and keep it — you will need it in the Developer Console.

</Steps>

<Aside type="caution">
If you export only the certificate without the private key, sealing fails with a missing-private-key error. Always expand the entry and select both items.
</Aside>

## 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

| 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

| 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

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

Select or drag your unprotected `.IPA` into the upload area. The panel beside it lists the always-on protections described above.

<Aside type="caution">
Firebase Crashlytics and other crash-reporting SDKs must keep their original class names without obfuscation to be supported by DoveRunner.
</Aside>

### 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

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

<Steps>

1. Click **START APPSEALING** to run binary injection, anti-tampering protection, and, if credentials were supplied, re-signing.

2. Download the sealed `.IPA`. If you did not supply signing credentials, re-sign it yourself before distributing.

</Steps>

Past runs are listed under **Historical Information**, and per-app service settings under **Configurations**.

## Credential Handling

- **Ephemeral handling** — Signing credentials are processed in isolated, ephemeral build environments.
- **Not stored** — Your `.p12` file, 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

| 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. |

## FAQ

**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.