Application security feature

iOS app anti tampering

Otukan identifies unauthorised changes to an iOS app by checking its code, bundle, load commands and signing identity against the release you approved.

  • iOS
Patched and resigned IPA is met at the release fingerprint boundary before it reaches the appPatched and resigned IPARelease fingerprintYour app
  • A fingerprint of your release

    Otukan records what your approved build looks like and compares the installed app with it on the device.

  • Every channel you ship

    App Store, TestFlight, enterprise and ad hoc builds each carry their own legitimate identity, and you approve each one explicitly.

  • Evidence your server can use

    A tamper event names what changed and travels to your backend, which can refuse tokens to the altered copy.

iOS tampering Otukan identifies

Pick a change to see how Otukan spots it on the device, how the app reacts and what your backend learns.

Patched executable code

  1. Detect

    Otukan compares protected regions of the executable with the values recorded at build time.

  2. Respond

    The app applies your tamper response before the flows that depend on the patched code continue.

  3. Report

    The event identifies a code modification, separate from resource or identity changes.

Added load command

  1. Detect

    Otukan checks the executable's list of libraries to load against your release and spots entries someone added.

  2. Respond

    The app treats a repackaged copy that pulls in foreign code as altered from the first launch.

  3. Report

    Your team sees that a library was wired into the binary itself, not injected at run time.

Resigned by another team

  1. Detect

    Otukan reads the signing team and bundle identifier at run time and matches them with your approved list.

  2. Respond

    A copy signed by an unknown team is restricted before sign-in.

  3. Report

    The event carries the unexpected identity for your investigation.

Edited resources and settings

  1. Detect

    Info.plist, bundled configuration and assets are checked against their recorded state.

  2. Respond

    Edited configuration counts as tampering, and the app applies your response before it relies on those values.

  3. Report

    Your backend learns which part of the bundle was edited.

Swapped extension or framework

  1. Detect

    Otukan verifies the embedded frameworks and app extensions you protect, each as its own binary.

  2. Respond

    The flows that rely on the replaced component follow your tamper response.

  3. Report

    The event names the component that no longer matches.

What Otukan checks in an iOS app

Each check watches a different boundary, so an altered copy has to defeat several of them to pass as yours.

  • Code region integrity

    Compares protected parts of the executable with build-time values, catching byte patches to your logic.

  • Encryption state check

    Notices an App Store or TestFlight executable that has been decrypted, a usual first step before an IPA is patched and resigned.

  • Load command inspection

    Spots libraries added to the executable's load list, the usual way a repackaged IPA brings in extra code.

  • Signing identity match

    Checks team and bundle identifiers against the identities you approved for each channel.

  • Bundle and component integrity

    Covers Info.plist, bundled configuration, assets, your own frameworks and the app extensions you choose.

  • Tamper events

    Sends a typed event to your backend, which can refuse tokens or flag the account.

You choose the response

Set a response for each user flow. Start by observing, then tighten flow by flow as the signals prove themselves.

Observe

Signal sent to your backend

Rolling out a new policy and measuring real-world signals.

Warn

This device looks modified. Continue with care.

Conditions some genuine users create, such as developer settings.

Restrict

Payments are unavailable on this device.

Payments, stored data and account changes.

Terminate

Session closed for your security.

Clear tampering on a high-risk flow.

How it works

  1. List approved identities

    Name the team, bundle identifiers and channels you legitimately ship through.

  2. Record the release

    Otukan fingerprints the protected build within your existing pipeline; signing stays with your team.

  3. Check on device

    The installed app compares itself with that fingerprint at launch and before sensitive flows.

  4. Act on the server

    Tamper events reach your backend, which decides what an altered copy may do.

Free for app publishers

Check your app's exposure

A passive review of your published app by an Otukan engineer. No files, no access to your systems. Findings go by email to the verified publisher.

You finish the request on the next page.

Otukan identifies unauthorised changes to an iOS app by comparing the installed copy with the release you approved. At build time it records a fingerprint of protected code regions, the executable’s load commands, bundle resources and the signing identities you ship under. On the device, the app checks itself against that fingerprint at launch and before sensitive flows, and reports what changed to your backend. It covers the main executable, your own frameworks and the extensions you choose, on every channel you distribute through. Tampering stays possible for a patient attacker; Otukan makes it visible and costly to use.

Integrity checking across platforms is covered on mobile app anti tampering.

Binary, bundle and signature boundaries

A repackaged iOS app usually follows the same route: decrypt the App Store binary on a jailbroken device, edit it, add a library, then resign it with another certificate. Each step crosses a boundary Otukan watches.

BoundaryTypical changeHow Otukan notices
Executable codeByte patches that skip a check or change a valueProtected regions no longer match build-time values
Load commandsA library added to the list the loader readsAn entry your release never contained
Encryption stateAn App Store executable that has been decryptedA decrypted binary where an encrypted one belongs
Signing identityA different team or bundle identifierNo match with your approved list
ResourcesEdited Info.plist, configuration or assetsRecorded state differs
ComponentsA replaced framework or extensionThe component’s own record differs

Code signing still does its job on a normal iPhone: it refuses code with an invalid signature. What it cannot tell is whether a valid signature belongs to you. Otukan fills that gap from inside the app.

Approved signing and distribution variants

Legitimate identities

A single app often ships through several channels, and each looks slightly different on the device:

  • App Store and custom apps. Apple re-signs the build and delivers an encrypted executable under your team identifier.
  • TestFlight. Apple signs and encrypts beta builds for your testers, again under your team identifier.
  • Enterprise in-house. Signed with your enterprise certificate for your own staff.
  • Ad hoc and development. Tied to registered devices and carrying a provisioning profile inside the bundle.

Otukan’s approved list names the team and bundle identifiers for every channel you use, including extensions with their own identifiers. A build signed under any other identity is treated as altered.

Keeping the list accurate

Certificates expire and teams change. When you add a channel or move to a new enterprise certificate, update the approved list in the same release. Acceptance on each channel confirms that a clean build raises nothing, so a routine renewal never turns into a false alarm for real users.

Tamper events and backend response

What the app does

Each flow applies the response you set: observe, warn, restrict or terminate. Many teams let an altered copy open but block sign-in, since that is where stolen sessions and fraud begin. Others choose observe for a first release, so they can measure how many altered copies exist before any user sees a change. Either way, the choice is yours per flow and can differ between a balance screen and a payment.

What your server receives

The event names the kind of change, such as code, load command, identity, resource or component, and travels with the next request. Your backend can refuse new tokens, block payments while keeping read-only access, or flag the account. Pairing the event with App Attest lets the server confirm the request comes from a genuine app instance. Attestation detail is covered on iOS app attestation.

Channel-by-channel acceptance

Each check is accepted with your engineers on physical devices. Build a lab-modified copy for each boundary and record the expected event, then install the approved build from each channel and confirm silence. Regression covers install, update from the previous release, sign-in and your most sensitive flow, with iOS versions, results and the reviewer recorded. Release guidance for protected iOS apps is in iOS app security guides.

Otukan’s full iOS offer is on iOS app security. For an outside view of your current App Store build, request a free App Exposure Check.

Common questions

  • Doesn't iOS code signing already stop modified apps?

    On a normal iPhone, iOS refuses to run code that does not match a valid signature. The gap is resigning: someone can modify your app and sign it again with their own certificate, then install it on their devices or a jailbroken one. The signature is valid, just not yours. Otukan checks that the identity and content match your release, not only that a signature exists.

  • Will App Store re-signing trigger a false alarm?

    Not when the approved list is set up for it. Apple re-signs App Store builds for delivery while keeping your team identifier, and Otukan's approved list is built around that. TestFlight, enterprise and ad hoc builds each have their own legitimate details, and you list the channels you use. Acceptance on each channel confirms a clean build raises nothing.

  • Is anti-tampering the same as jailbreak detection?

    They answer different questions. Jailbreak detection asks whether the device can be trusted; anti-tampering asks whether the app is still the one you shipped. A patched copy can run on a non-jailbroken device after resigning, and a genuine app can run on a jailbroken one. Most teams use both, and Otukan reports them as separate signals.

  • What should the backend do with a tamper event?

    Treat the session as coming from an unknown client. Common choices are refusing new tokens, blocking payments while keeping read-only access, and flagging the account for review. Because the event names what changed, your fraud team can also spot a repackaged copy circulating outside the App Store.

On the mobile engineering team?

How protection fits your build, signing and release, platform by platform.

Know when your iOS app has been changed

Tell us which distribution channels you use, how many bundle identifiers and extensions the app has, and what your backend should do with an altered copy. Keep your certificates, provisioning profiles, IPA files and source code to yourself; we never ask for them.

Or request a technical demo