iLEAPP: parsing iOS extractions into HTML, TSV and timeline reports

What iLEAPP is for, and who actually needs it

iLEAPP parses iOS and iPadOS forensic extractions. The README describes the output as HTML, TSV, timeline, KML and LAVA, and states support for iOS/iPadOS 11 through current versions. That scope is the whole product: it reads an extraction you already have and writes reports.

The audience follows from that. A digital forensics examiner holding an iTunes or Finder backup, a full file system image, or a zipped extraction needs something that walks hundreds of app and system artifacts and produces a readable report. iLEAPP is built for that examiner. It is not an acquisition tool. Nothing in the README describes pulling data off a device, and the input types all assume the data already exists somewhere on disk.

The artifact coverage is the reason people pick it over writing their own scripts. The project points to a searchable artifact list at leapps.org/artifacts, filterable by LEAPP tool, rather than maintaining the catalogue in the README. That is a sensible split, but it means the README alone will not tell you whether a specific app is covered. You check the artifact site or you read `scripts/artifacts/`.

How a parse run works: input type, modules, output

The mechanism is a dispatcher over dynamically loaded modules. Artifact modules live in `scripts/artifacts/` and, per the README, are loaded dynamically at runtime. Each module declares search paths and an artifact info block; the parser matches those paths against files in the extraction and runs the matching modules.

Input type is explicit and controls how paths are resolved. The README lists six: `fs` for a folder of extracted files with normal paths and names, `zip`, `tar`, `gz`, `itunes` for iTunes/Finder backups with hashed paths and names, and `file` for a single file. The distinction matters because an iTunes backup does not store files under their real names. Choosing `fs` on a backup folder will not work the way choosing `itunes` does.

Output generation is module-driven. The contributing docs include a page on updating modules for automatic output generation and another on adding LAVA output to complex modules, which tells you output is not a single generic serializer applied to everything. A module decides what it contributes. The practical consequence is that a module can parse a file correctly and still produce a thin report if its output block was never updated.

Two standalone modes sit outside the parse flow. `-p` writes all artifact search paths to `path_list.txt` in the current directory, and `-c` runs an interactive wizard to create a `.ilprofile` or `.lcasedata` file. The README says to use these alone, without `-t`, `-i` or `-o`.

Installing iLEAPP and running a first extraction

The recommended path is a pre-built release, which the README says requires no Python installation. Downloads come from leapps.org/releases or the GitHub releases page. The README gives a platform table: Windows gets `ileappGUI-*-Windows_x64.zip` and `ileapp-*-Windows_x64.zip`; Apple Silicon and Intel macOS get separate `.dmg` (GUI) and `.zip` (CLI) builds; Linux gets an AppImage for both.

For the GUI, extract the download, run `ileappGUI`, then select input type, source path, output folder and modules. For the CLI, extract the archive and run from a terminal. The README is explicit that the output folder must already exist.

The Windows CLI example from the README looks like this:

ileapp.exe -t zip -i C:\path\to\extraction.zip -o C:\path\to\output\

On macOS and Linux, the README says to use the `ileapp` binary from the extracted archive instead of `ileapp.exe`. The README's own macOS and Linux example is:

ileapp -t zip -i /path/to/extraction.zip -o /path/to/output/

Encrypted iTunes and Finder backups are supported. The GUI prompts for a password when encryption is detected. On the CLI you pass it with `--itunes_password`.

If you want to limit which modules run, build a profile. The `-c` wizard creates a `.ilprofile` or `.lcasedata` file in a folder you name:

ileapp -c /path/to/output/folder/

Then load it on a parse with `-m`. The repository ships example profiles at the top level, including `zProfileExample.ilprofile`, `zProfileCallHistory.ilprofile` and `zProfileIOSArtifactGapReview.ilprofile`, so you can inspect the format before writing your own. Run `ileapp --help` for the built-in reference.

The output folder rule and other friction points

The output folder must already exist. That single line in the README is the most common way a first run fails, and the tool does not create the directory for you. Create it before invoking the CLI.

Source installs are the second friction point, and `requirements.txt` shows why. The file pins `numpy==1.26.4` below Python 3.13 and `numpy>=2.1` at or above it, pins `packaging==24.1` and `pathlib2==2.3.5`, and requires `standard-imghdr` on Python 3.13 or later because PGPy imports the stdlib `imghdr` module that PEP 594 removed. Windows on x64 gets `pyliblzfse` wheels pinned by machine as well as OS, with a comment explaining that Windows-on-ARM would otherwise try those wheels and fail, falling back to compiling from the sdist. The PGPy comment warns that the newest wheel is 0.5.4, which breaks on `cryptography>=38`, so wheel-preferring installs must stay off 0.5.4. This is a dependency set tuned for a frozen build, not for a casual `pip install` into an arbitrary environment.

There is also a vendored `scripts/blackboxprotobuf` and an explicit instruction not to add the PyPI package of the same name, because it pins `protobuf==3.10.0` and would reintroduce patched CVEs. `protobuf==5.29.6` is named as the minimum that clears three specific CVEs. Anyone repackaging iLEAPP needs to respect that, because the constraint is a security decision, not a style preference.

One more boundary: the README does not document rollback, and it does not describe a schema version for output files. If you build downstream tooling on the TSV or HTML output, verify the format against your pinned build rather than assuming stability across releases.

When iLEAPP is the wrong tool

iLEAPP does not acquire data. Every input type it accepts is something you already possess: a folder, an archive, a backup, or a single file. If the task is getting data off a locked or damaged device, iLEAPP is not part of that workflow, and no flag in the README changes this.

It is also a poor fit when you need one specific answer and nothing else. A full run loads every matching module and writes a report tree. If you want a single SQLite table parsed, a targeted query against the extraction is faster and easier to defend. The profile mechanism narrows the run, but building a profile is itself work, and the README does not describe how profiles interact with modules that depend on other modules' output.

Android is out of scope entirely. The project name is iOS-specific, and nothing in the README suggests Android artifacts are handled. Teams covering both platforms run separate tools, which is why the LEAPP family exists as a set of tools rather than one binary.

Finally, the README gives no accuracy guarantees per artifact. A module that parses a plist produces what the plist contains. Whether that reflects user behaviour is an interpretation question the tool does not answer, and the report will not warn you that a given artifact is sparse on a particular iOS version.

iLEAPP against ALEAPP: same family, different target

The natural comparison is ALEAPP, the Android counterpart in the same LEAPP family. Both are listed on the same release page, and both are filters on the same artifact catalogue at leapps.org/artifacts. The architectural approach is shared: Python, dynamically loaded artifact modules, report output generated per module.

The difference is the target and everything that follows from it. iLEAPP resolves iOS-specific input layouts, including iTunes and Finder backups, where files are stored under hashed names and the `itunes` input type exists precisely to handle that. ALEAPP has no reason to implement that path. Conversely, the artifact modules are not shared, because the underlying files are not the same. Choosing between them is not a preference question; it is determined by the extraction in front of you. A case with both an iPhone and an Android device means running both tools, and the shared LEAPP conventions (profiles, case data files, module structure) are what make that less painful than running two unrelated parsers.

Licence, maintenance and upgrade cost

iLEAPP is MIT licensed. In practical terms that permits commercial and internal forensic use, modification, and redistribution provided the copyright notice and permission notice are retained. This is not legal advice; if you redistribute iLEAPP inside a product or a service, have counsel confirm what your distribution actually ships, particularly the vendored `scripts/blackboxprotobuf` directory and the bundled wheels under `whl_files/`.

The repository is not archived, and the last push was on 2026-08-27, which is recent. Three releases landed in August 2026: v2026.3.0 on 2026-08-14, v2026.3.1 on 2026-08-18, and v2026.3.2 on 2026-08-27. The version scheme is date-based, which makes it easy to see how far behind a frozen build is.

Upgrade cost depends on how you consume it. If you use the pre-built binaries, upgrading means downloading a new archive and re-pointing your scripts at it; the CLI surface in the README is small and stable enough that this is usually a path change. If you build from source, every upgrade means re-resolving the pinned dependency set, and the comments in `requirements.txt` show that this set is deliberately narrow. If you write custom modules under `--custom_artifacts_path` or maintain profiles, test them against the new build before rolling it out, because the README does not promise that module interfaces are frozen between releases.

Editorial conclusion

Adopt iLEAPP if you already hold an iOS extraction (fs, zip, tar, gz, itunes or a single file) and need readable reports without standing up a Python environment; the pre-built CLI and GUI cover that case. Do not adopt it if you need acquisition, since iLEAPP only parses what you already have, and do not treat a clean report as proof that nothing happened. Before relying on it, run `ileapp --help` against your build, confirm the output folder exists, and check which modules your profile actually loads.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes