The Impact of Offline IPA Decryption on iOS App Protection

Organizations that utilize iOS mobile applications in their products, often make an assumption that the mobile app’s code will remain unknown to attackers and therefore it will be safe from tampering. An attacker’s ability to make alternative apps, bots, or clones depends on this constraint.

There are many ways to reinforce this requirement, each with their own varying degree of reliability. One of them is Apple’s mobile application encryption, done with the help of Fairplay DRM (digital rights management). In a nutshell, the application’s .ipa file is encrypted on the mobile device. This DRM capability is largely responsible for the myth that iOS apps have bulletproof security.

Recent changes in offline iOS application decryption prove one thing: iOS DRM protection is not sufficient on its own. Instead, a multilayered protection approach is necessary to reliably enforce the usage of the original app.

What changed?

In the past, both security researchers and bad actors looking to reverse engineer an app used on-device application decryption. Tools like Clutch operate on a jailbroken mobile device and dump the memory to the disk, reconstructing the decrypted executable. Such tools mostly work well, but are not easy to operate and their use does not scale efficiently, since they rely on a real jailbroken hardware device.

Now, there’s a different way to defeat Fairplay DRM. Unfairplay tool (introduced on October 25, 2026) takes advantage of the fact that iOS mobile applications can be run on Macs. On a Mac, the DRM implementation is done in software, and that software implementation can be attacked–which Unfairplay successfully accomplishes. This decryption can be done on any machine, even Linux or Windows. The only step where a Mac with an AppStore account is required is the initial application collection.

This change opens up possibilities for easy, fast, and undetectable iOS application decryption, which removes a lot of complexity for reverse engineers who want to get decrypted iOS apps.

What is the consequence?

As impactful as it is in terms of attack efficiency, Unfairplay does not introduce any major changes to the mobile application security responses that you should be planning. Rather, the old misconception that iOS operating system security is sufficient on its own becomes more evident.

If your service relies on the original mobile application being used for any reason (for example, phishing safety, monetization, or resisting cheating and enforcing fair play), it takes a multilayered protection system to effectively resist attacks.

What absolutely does not work

Naive protection methods–such as baking secrets into the application in an attempt to prove their genuineness or using simple client-side decision-making to enforce endpoint security–will not work.

Obtaining decrypted versions of mobile applications is easy, and so is reverse engineering and making local modifications. Baked-in secrets will be lifted from the application and reused in bots’ code or fake apps. Local code to enforce security policies will be patched out to ignore the policies, signatures will be spoofed, and so on.

Effective protection methods must create a significant imbalance between the low protection effort and the prohibitively high effort required to attack. Fairplay DRM is a good example of a situation where such balance is not created anymore. If the decryption can be automated and scaled, then getting a decrypted version of the iOS application will take just a few seconds for the attacker, introducing only a negligible barrier in their way.

What still works

No single method of endpoint protection is good enough on its own. Through our experience in mobile application security (cumulative decades of human security research work), we know that only a multilayered, cascading system of diverse countermeasures is able to resist modern attackers.

Next to the operating system DRM, we add one-directional code obfuscation that erases semantic information from the code, deterring both humans and machines from analyzing it and understanding its purpose. In other layers, we apply runtime application self-protection (RASP) that resists running in attacker-controlled environments and subsequent dynamic analysis, such as interactive debugging.

Finally, instead of relying on static secrets, we perform backend security validation through Guardsquare mobile application attestation. This server-side validation helps you ensure that it’s still your original application talking to your backend APIs.

All of these layers combined create a defense that puts a disproportionate amount of effort on the attacker side, and a negligible amount of effort on you to maintain protection and keep it effective for prolonged periods of time.

In conclusion

The recent change in iOS mobile application decryption is of a quantitative, not qualitative, nature. Attacks are now faster, more efficient, and more scalable, but their nature does not change. The recipe for effective endpoint security is to apply defenses in layers that constantly evolve to keep up with attacks. Only a multilayered system can effectively resist the diverse arsenal that the attackers are now equipped with.

Learn more about what makes for a comprehensive, defense-in-depth approach to mobile app security.