# IOSSecuritySuite: jailbreak, debugger and hook detection in pure Swift

> IOSSecuritySuite is a Swift library that adds runtime checks for jailbreak, attached debuggers, emulators, reverse engineering tools and method hooking to iOS and iPadOS apps. It is small, dependency-free, and licensed under a company-size-based EULA rather than an open source licence.

**securing/IOSSecuritySuite** — iOS platform security & anti-tampering Swift library

- Repository: https://github.com/securing/IOSSecuritySuite
- Website: https://www.securing.biz/
- Stars: 2,737 · Forks: 347
- Language: Swift
- License: NOASSERTION
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/securing-iossecuritysuite

## What IOSSecuritySuite checks, and who needs those checks

The README frames the library around OWASP MASVS chapter v8, the resilience chapter that asks apps to detect and react to a compromised runtime. IOSSecuritySuite implements that chapter as a set of boolean and verbose Swift calls: jailbreak, attached debugger, emulator, reverse engineering tools, system proxy or VPN, and Lockdown Mode. A separate experimental group covers runtime hooking, symbol hook denial, MSHook detection and denial, and file integrity verification.

The audience is narrow and specific. It is an iOS or iPadOS app developer writing Swift, who wants the checks in-process rather than through a separate hardening SDK. The README states plainly that the library is meant for iOS and iPadOS and should not be used on Macs with Apple Silicon, which rules out Catalyst-style reuse or Mac targets.

What it is not is a server-side fraud signal. Every check runs on the device, in the same process an attacker controls. The value is in raising cost and collecting evidence, not in producing a verdict that cannot be forged.

## How the detection modules work

The jailbreak module is the most developed part. It returns a plain boolean through amIJailbroken(), a boolean plus a human-readable failMessage through amIJailbrokenWithFailMessage(), or a structured result through amIJailbrokenWithFailedChecks() that exposes an array of failed checks. The README shows the failMessage as a comma-separated string, with an example reading: "sileo:// URL scheme detected, Suspicious file exists: /Library/MobileSubstrate/MobileSubstrate.dylib, Fork was able to create a new process". Those three indicators point at three different mechanisms: URL scheme probing through canOpenURL(_:), filesystem existence checks on known jailbreak paths, and a fork test that tries to spawn a child process.

The structured variant is the one worth using. Because each failed check carries a case value such as .existenceOfSuspiciousFiles or .suspiciousFilesCanBeOpened, you can combine them. The README's own example treats a device as really jailbroken only when both suspicious files exist and suspicious files can be opened, which is a way to filter out devices that were jailbroken in the past and are now jailed.

The other modules are thinner. amIDebugged() and denyDebugger() cover the debugger case, with denyDebugger() described as denying the debugger outright rather than reporting it. amIRunInEmulator() covers emulator execution. amIReverseEngineered() and amIReverseEngineeredWithFailedChecks() follow the same simple and filterable pattern as the jailbreak module. amIProxied(considerVPNConnectionAsProxy:) takes a boolean that decides whether a VPN connection counts as a proxy. amIInLockdownMode() reports Lockdown Mode.

The experimental modules work at a lower level. amIRuntimeHook(dyldWhiteList:detectionClass:selector:isClassMethod:) takes a dyld whitelist, a class, a selector and a flag for class methods. denySymbolHook() takes a mangled symbol name, and the README's example passes the mangled name of NSLog and then calls NSLog. The MSHook modules deal in raw function addresses: you get a pointer with unsafeBitCast, pass it to amIMSHooked(_:), or pass it to denyMSHook(_:) and call the returned original through a @convention(thin) function type.

## Installing IOSSecuritySuite and running the first jailbreak check

The README lists four installation paths. You can copy the IOSSecuritySuite/*.swift files directly into a project, use CocoaPods, use Carthage, or use Swift Package Manager. The podspec and Package.swift both sit at the repository root, so all three package managers are supported from the same tree.

For Swift Package Manager, the README gives the package line as:

```swift
.package(url: "https://github.com/securing/IOSSecuritySuite.git")
```

For CocoaPods the pod name is IOSSecuritySuite:

```bash
pod 'IOSSecuritySuite'
```

For Carthage the line is the GitHub slug:

```bash
github "securing/IOSSecuritySuite"
```

After adding the library, the README says you must update the main Info.plist. The jailbreak module calls canOpenURL(_:), and Apple requires the queried schemes to be declared. The README gives four entries:

```xml
<key>LSApplicationQueriesSchemes</key>
<array>
    <string>undecimus</string>
    <string>sileo</string>
    <string>zbra</string>
    <string>filza</string>
</array>
```

Skip that step and the URL scheme indicator cannot fire, which quietly weakens the jailbreak result rather than producing an error.

The first real call is the simplest one. The README's example prints one of two strings:

```swift
if IOSSecuritySuite.amIJailbroken() {
	print("This device is jailbroken")
} else {
	print("This device is not jailbroken")
}
```

On a stock device you should see the second line. On a jailbroken device you should see the first, and switching to amIJailbrokenWithFailMessage() tells you which indicators fired.

## Where IOSSecuritySuite falls short

The first limitation is structural. Every check is client-side, in a process the attacker can instrument. The README does not claim otherwise, but it is easy to read the module list as a security guarantee. It is a set of signals, and the experimental status of the hook detection and denial modules is stated in the README itself.

The second limitation is the platform boundary. The README's Notice says the library should not be used on Macs with Apple Silicon. If your codebase shares a target between iOS and macOS, that boundary has to be enforced in build configuration, not just in documentation.

The third is the licence. The repository licence field is NOASSERTION, and the README's Pricing section describes a EULA with tiers: free for companies with 0 to 99 employees, 3k EUR/year for 100 to 1000, and 10k EUR/year above that. There is a separate 10k EUR/year tier if you want to sell a module that uses IOSSecuritySuite without using it directly in your app. That is a commercial arrangement, not an open source one, and it changes the calculus for anyone who picked the project up assuming a permissive licence.

The fourth is maintenance cadence rather than abandonment. The last push was on 2026-08-05, matching release 2.3.0. Before that, 2.2.0 landed on 2025-07-09 and 2.1.0 on 2024-05-20. The gaps are roughly a year, so plan upgrades around releases rather than expecting continuous churn.

Finally, the README does not document rollback or a downgrade path between versions, and it does not describe how the checks behave across iOS releases beyond the version tags in the release history.

## How IOSSecuritySuite differs from DTTJailbreakDetection and freeRASP

DTTJailbreakDetection is the older, narrower option: jailbreak detection as a focused check, without the debugger, emulator, proxy, Lockdown Mode or hook modules. If jailbreak is the only signal you need, the smaller surface is a legitimate reason to prefer it.

freeRASP takes the opposite approach in scope and packaging. It is positioned as a broader runtime application self-protection product, which means the checks, the reporting and the operational side arrive together rather than as a Swift source library you compile into your app. The trade-off is control and footprint against breadth.

IOSSecuritySuite sits between them. It is pure Swift, distributed as source or through the three standard package managers, and it exposes each check as an individually callable function with a filterable result type. That granularity is the actual differentiator: amIJailbrokenWithFailedChecks() lets you write your own policy over individual indicators instead of accepting one vendor's verdict. The cost is that you own the policy, the response and the false-positive tuning.

## Licence, upgrade cost and what to verify before shipping

The README points to the EULA for details and gives the tiers in plain numbers. The practical implication is that adoption is a procurement decision for any company above 99 employees, and the 10k EUR/year module-resale tier applies if IOSSecuritySuite is used indirectly. I am not giving legal advice; read the EULA and the LICENSE file at the repository root, since the licence metadata is NOASSERTION rather than a recognised identifier.

Upgrade cost is low in code terms. The public API is a flat set of IOSSecuritySuite static calls plus the denySymbolHook and denyMSHook functions, and the release history is short. The real cost is re-validating detection behaviour after each iOS release, because the indicators are tied to filesystem paths, URL schemes and process behaviour that Apple changes.

Before shipping, verify three things. That LSApplicationQueriesSchemes in your Info.plist contains the schemes you rely on. That your deployment target and device matrix exclude Macs with Apple Silicon, per the README's Notice. And that the experimental modules you call are ones you can accept as experimental, since the README groups runtime hook detection, symbol hook denial and MSHook handling under that heading.

## Conclusion

Adopt IOSSecuritySuite if you ship a native iOS or iPadOS app and need jailbreak, debugger or hook signals in-process without pulling in a third-party binary framework. Do not adopt it if you target Macs with Apple Silicon (the README says it should not be used there), if you need a permissive open source licence, or if you expect the client-side checks to survive a determined attacker on their own. Verify first that your Info.plist declares the LSApplicationQueriesSchemes entries the jailbreak module queries, that your team size matches the EULA tier you intend to use, and that the experimental modules you rely on are acceptable as experimental.

## FAQ

### How do I install IOSSecuritySuite in an iOS project?

The README lists four routes: copying the IOSSecuritySuite/*.swift files into your project, CocoaPods with pod 'IOSSecuritySuite', Carthage with github "securing/IOSSecuritySuite", or Swift Package Manager with the package URL. After adding it you must declare the queried URL schemes in LSApplicationQueriesSchemes in your main Info.plist.

### Can IOSSecuritySuite be used on Macs with Apple Silicon?

No. The README's Notice states that iOS Security Suite is meant to be used on iOS and iPadOS and should not be used on Macs with Apple Silicon.

### Is IOSSecuritySuite free to use?

The README describes a EULA with tiers based on company size: free for 0 to 99 employees, 3k EUR/year for 100 to 1000, and 10k EUR/year above that, with a separate 10k EUR/year tier for selling a module that uses it indirectly. The repository's licence field is NOASSERTION, so read the EULA and LICENSE file rather than assuming an open source licence.

## Sources

- [Issues](https://github.com/securing/IOSSecuritySuite/issues)
- [Project website](https://www.securing.biz/)
- [README](https://github.com/securing/IOSSecuritySuite/blob/master/README.md)
- [Releases](https://github.com/securing/IOSSecuritySuite/releases)
- [securing/IOSSecuritySuite on GitHub](https://github.com/securing/IOSSecuritySuite)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/securing-iossecuritysuite