Reveil: a SwiftUI rebuild of the iOS system analysis app Unveil

A successor to Unveil, built because the original stopped

Reveil is a replication of Unveil, the iOS system and security analysis app, written in pure SwiftUI. The reason for the rewrite is stated plainly in the README: Unveil, described there as the most advanced system and security analysis tool, never received updates after its initial release.

The author and contributor behind it decided to bring the idea back to life and open source it. The technical pitch is narrower than the marketing of the original, and more interesting. The README says Reveil uses complex and innovative techniques to detect possible software modifications or security threats inside the iOS application sandbox without relying on exclusive libraries.

That last clause is the design constraint. An app that inspects an iOS device from inside the sandbox has to make do with the public API surface and whatever the runtime exposes indirectly. Reveil works within that rule rather than around it, and the limitation list later in the README is a direct consequence of it.

The audience is narrow and specific: iOS developers and reviewers who want device telemetry and a modification check on hardware they are holding. It is a diagnostic companion, not a monitoring agent. The repository holds an Xcode project, a main Reveil target, a ReveilHelper target, a library-stub directory and a Certificates directory, with an MIT licence covering copyright from 2023 to 2024.

Reading the device through public APIs, not private ones

The architecture is visible in the repository layout rather than documented in prose. Reveil.xcodeproj sits at the root beside the Reveil application sources, the ReveilHelper target and library-stub. The helper target suggests the work is split between the app and a companion component, and the stub directory suggests the project links against stand-ins for system libraries rather than shipping private headers, which is the usual way to keep an analysis tool inside the sandbox rules and reviewable by App Store policy.

The data sources match what the public API permits. Process and system information comes from the standard kernel and system information interfaces, storage and mounted file system figures come from the file system APIs, and network figures come from the network framework and the counters attached to interfaces. The .bartycrouch.toml file at the repository root suggests the project is also packaged with tooling aimed at jailbroken environments, which fits the audience but is not explained in the README.

The security analysis side is the part with the most interesting constraint. Detecting that the sandbox has been modified without an exclusive library means working from observable signals available to any app, and the README frames the goal as spotting possible software modifications or security threats rather than confirming a specific jailbreak. That is the honest framing for a heuristic check. It should be read as an indicator, not a verdict.

Building it needs Xcode 15 and an iOS 15 target

There is no install script or package to run. Reveil is a native iOS app, and the README describes the requirements rather than the steps: Xcode 15 or later, and iOS 15.0 or later as the deployment target. For anyone on Xcode 14 or targeting iOS 14, the project points at a separate backport/ios-14 branch.

The practical tutorial is therefore a normal Xcode workflow. Clone the repository, open Reveil.xcodeproj, select the appropriate target and scheme, and run it on a connected device. A simulator will show the interface but will report different hardware characteristics, so the CPU and memory dashboards should be read on real hardware.

Two things are worth knowing before you build. The Certificates directory at the root is there for a reason, and Reveil will not have a usable signing identity if you try to sidestep it. And the repository carries two GitHub Actions workflows, Build and Analyze and Build Archive, so CI builds exist for the project even though the README does not describe their triggers.

If your team is on Xcode 14 or must support iOS 14, stop here and switch to the backport/ios-14 branch. The README is explicit that this is the path for those cases, and trying to lower the deployment target in the main branch is not something the documentation supports.

Dashboards for CPU, memory, storage and every network interface

The feature list is where Reveil shows what an analysis app is for. CPU usage is visualised with a total, user and idle breakdown, alongside the CPU specifications and average load. Memory usage is visualised with the memory specifications and a classification of allocations. Storage usage is visualised together with the technical storage figures behind it.

The system section reports the system version, the BootROM version, the kernel version, uptime and other kernel information, which is the sort of data that matters when you want to know exactly what a device is running.

The file system view lists mounted file systems with type and attribute detail, and the network view is the most granular part of the app. Internet usage is visualised and attributed to specific data sources such as WiFi or Ethernet, a cellular connection, or a personal hotspot. Network interfaces are listed with kind (wired, wireless, cellular, access point, IPSec tunnel) and per-interface statistics including MTU, line speed, downloaded bytes and uploaded bytes.

The security analysis is listed first among the features, as state-of-the-art security analysis. The screenshot in the README shows a dashboard layout with a macOS-like arrangement of panels, and the design credits the original Unveil app by @Pwn20wnd for the UX and UI inspiration.

The unavailable counters are a design choice, not a bug

The most useful section of the README is the limitations list, because it defines the ceiling of the whole tool. Reveil does not break any sandbox rules, so it cannot fetch certain information: CPU frequency, CPU temperature, battery temperature, installed applications and installed tweaks. The list ends with an ellipsis and the note that the omissions go beyond those five.

Each item on that list is exactly what a jailbreak-focused user might want most. Knowing which tweaks are installed tells you a great deal about the state of a device, and CPU frequency and temperature are the numbers a hardware diagnostic would show. Deciding to leave them out is a deliberate choice: the app stays inside the sandbox instead of relying on exploits or injected libraries, which is what lets it run on stock devices and on ordinary hardware without a jailbreak.

There is a cost to that decision, and it is a real one. The security analysis therefore cannot report on the very modifications that most concern someone auditing a device, since the presence of installed tweaks is off the table. What remains is a check that works from inside a normal application sandbox. The README also credits code from IOSSecuritySuite by @_r3ggi, which is where much of the detection technique comes from.

Release numbering is out of step and the app is still early

The project describes itself in the README as currently in early development, with the authors working to improve it. That framing matters when you read the release list, because the tags are not in numeric order. v3.3.2 is dated 2025-06-07, v3.3.3 is dated 2025-12-14, and v3.4 is dated 2026-04-22.

The last push to the repository was on 2026-04-22, the same day as the v3.4 tag, so the published tag reflects the tip of the branch rather than trailing it. There is no release after that date in the listing, which means a build from the branch may contain work that the v3.4 tag does not.

For a tool in this category, the upgrade path is a rebuild rather than an app store update, and the risk sits in the compatibility between the app and the OS version on the device. The README's own advice covers the OS side with the backport/ios-14 branch, and the repository has a CHANGELOG.md that will tell you what changed between builds.

Distribution is handled outside the App Store. The README links the project to a package page on Havoc, a marketplace for jailbroken-device software, which is where a developer would obtain a signed build. The MIT licence means the source can be inspected, modified and redistributed under its terms, and it applies to the code as published, so read the LICENSE file if you plan to ship a modified build.

Editorial conclusion

Reveil suits iOS developers and security reviewers who need a quick read on device telemetry and a first pass at jailbreak-style modification detection on hardware they control, and it suits people who liked Unveil and want a maintained version of it. It does not suit anyone who needs CPU frequency, temperature, battery temperature or a list of installed applications and tweaks, because the app states it cannot cross the sandbox to read them. Check three things before adopting it: that your Xcode is 15 or later and your deployment target is iOS 15.0, since earlier systems need the backport/ios-14 branch, that your device still permits the apps and tweaks you want to examine, and that you accept an early-stage tool whose own README says it is in early development. The most recent tagged release is v3.4 from 2026-04-22 and the last push to the repository was on the same date.

Frequently asked questions

Official sources

1. Issues
2. Lessica/Reveil on GitHub
3. License: MIT
4. README
5. Releases