# Irisin: a package manager for jailbroken iPhone and iPad

> Irisin installs, updates and signs in to paid packages on jailbroken iOS and iPadOS 15 or later, working with both rootless layouts such as Dopamine and roothide. It is a good fit for jailbreak users who want a modern store, and it does nothing for a stock device.

**Lakr233/Irisin** — Modern. Fast. Beautiful.

- Repository: https://github.com/Lakr233/Irisin
- Website: https://lakr233.github.io/Irisin/
- Stars: 871 · Forks: 75
- Language: C
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/lakr233-irisin

## Two packages, one per jailbreak layout, and the app refuses the wrong one

Irisin is a package manager for jailbroken iPhone and iPad on iOS and iPadOS 15 or later. It supports both rootless jailbreaks such as Dopamine and roothide, and those two environments need different builds.

The mapping is short. For roothide you install the package named iphoneos-arm64e. For a rootless jailbreak under /var/jb you install iphoneos-arm64. Those names come from the build flavour in the project's Makefile, where the roothide flavour ships files at rootful paths that roothide's dpkg relocates into the randomized bootstrap root, while the rootless flavour ships files under the fixed rootless prefix /var/jb with Dopamine and palera1n rootless named as examples.

The failure mode is handled rather than left to the user. Irisin checks your jailbreak when it opens, and if you installed the wrong package it names the architecture it was built for and the one your device uses, asks you to install the matching package, and does not open. That is a better answer than a crash on launch, and it means the architecture mistake is a two line message rather than a debugging session.

The application bundle identifier and package identifier are both wiki.qaq.irisin, and the Makefile builds a separate daemon binary and install helper alongside the app bundle, with the derived data directory deliberately kept out of /tmp because Xcode and FileManager spell that path differently and some package manifests strip checkout paths by string match.

## The Bootstrap Install path exists because package configuration can deadlock

The most interesting engineering in this project is the handling of a genuine circular dependency in package configuration. On a fresh custom firmware bootstrap, an early package may need a program from a later package before that later package can be configured. The README gives the concrete example: debianutils may need bash to run its configuration script, while bash needs debianutils configured first.

Ordinary package managers resolve this by ordering, and ordering cannot resolve a cycle. Irisin takes a different approach. You add the packages to the queue, long-press Execute and choose Bootstrap Install. Irisin then extracts the files from every package in that queue first, and only afterwards runs the normal unpack, maintainer script and configuration sequence. That makes bash available to the early script without skipping package checks or letting script failures pass silently.

The conditions are narrow and worth knowing. The option appears only for a queue of new packages with no removals, and after the initial preparation you use the regular Execute button. On a system where dpkg is not installed yet, Execute asks first and offers Bootstrap Install there too.

There is a second, more dangerous option in the same area. Install Anyway lists the packages that run maintainer scripts before anything is installed, since those scripts are likely to fail without a bootstrap. The presence of this option tells you the project expects maintainer scripts to fail on an unbootstrapped system, and it gives you the list rather than letting you discover the problem after the fact.

## Repositories, version pinning, blocked updates and paid package sign-in

The feature list reads like a store, because that is what it is. A welcome page on first launch recommends repositories for your jailbreak, and a repository can be added from a link. The repository list can be exported or imported to move it to another device, which matters on a platform where reinstalling means re-adding every source by hand.

Search covers packages, repositories and authors at once, and any package list has its own search bar for narrowing. Package pages follow the light and dark mode of the system, which is a small thing that people notice immediately when a package manager does not do it.

The two management features that go past a plain store are version selection and update blocking. You can install any version a repository offers, and you can block updates for packages you want to keep exactly as they are. On a jailbroken device, where a package upgrade can break a tweak that depends on a specific version, having both of those controls is the difference between a tool you trust and one you flinch before using.

There is commercial handling too. Irisin can buy paid packages and sign in to your vendor accounts, which is a feature the README lists plainly without further explanation. On roothide it can install rootless packages in Compatibility Mode, and that mode refuses a package it cannot convert safely rather than attempting a conversion it is not sure about.

Maintenance is handled inside the app: you can rebuild icons and reload the Home Screen from Settings, and you can update Irisin from inside Irisin. The interface is available in 19 languages.

## Building from source means an Xcode workspace and a Makefile with three targets

The build instructions are short because the project puts the work in the Makefile. You open Irisin.xcworkspace in Xcode, then use three make targets:

```bash
make harness      # run the tests on the Mac
make deb-all      # build the roothide and rootless packages
make install      # update a device connected through `iproxy 2333 22`
```

The first target runs the test suite on the Mac, which is the fast loop. The second builds both jailbreak packages in one go, which is the flavour switch described above. The third pushes to a device reachable through iproxy on port 2333, which is how you get a build onto hardware without a full jailbreak environment on the Mac.

Two external tools are required: ldid and dpkg from your preferred package manager. The Makefile is explicit about being a shell script in effect, setting SHELL to /bin/bash with .SHELLFLAGS of -eu -o pipefail -c, and it declares .NOTPARALLEL: because shared Xcode products must not be rebuilt while another flavour copies them. The workspace holds the project and each package under Packages/, and a package there stands in for a remote one of the same name anywhere in the graph, with Runestone and MarkdownView named as vendored cases.

The repository layout is a Swift project with a distinct daemon, an install helper, a unit test target, a Packaging directory, a Scripts directory and a Configuration directory, plus AGENTS.md for contributors and manifest.json at the root. The project is written by OwnGoal Studio and released under the MIT License.

## Reports need a log, and the log needs reviewing before you share it

The support path has two routes: choose Report Issue in Settings, or open an issue on GitHub, and the README asks you to search the existing issues first to avoid duplicates.

The second instruction is the one that matters most for anyone filing a bug. If Irisin crashes or an installation fails, you are asked to include the log from View Logs in Settings. The README then warns that the log may contain your searches and repository addresses, so it should be reviewed before you share it. That is a privacy note about a diagnostic file, and it is the kind of detail that gets skipped in a rush to get a bug fixed.

The acknowledgements section states that the product includes software developed by the Sileo Team, which identifies the lineage of the interface rather than claiming it. The project also names a sponsor, LookInside, a tool for inspecting the interface of a running iOS or macOS app from a Mac.

One more piece of housekeeping is worth copying into your own habit. On the Home Screen side, the app can rebuild icons and reload the Home Screen from Settings, which is the standard remedy after a package install changes a bundle. If icons look wrong after an installation, that button is the first thing to try.

## Where Irisin is the wrong tool

The obvious wrong case is a device that is not jailbroken. Irisin exists to place packages into a jailbreak bootstrap, so on a stock iPhone or iPad there is no environment for it to install into, and no version of the app changes that.

The second wrong case is a jailbreak the project does not support. It targets rootless layouts such as Dopamine and roothide, and the packages are architecture specific, so a roothide build on a rootless device is refused at launch. The README describes both supported families; it does not describe a classic rootful jailbreak, and the Makefile comments only name roothide and rootless flavours. Anyone on an unsupported layout is outside the project, not just misconfigured.

A third is the expectation of a desktop class package manager. Irisin is an on-device store for a jailbroken phone. It does not have a documented headless mode, no repository mirror of its own, and no command line for scripted package management, so a fleet of devices to be provisioned automatically is outside what the project offers.

The release cadence, at least, is not a concern. The repository is not archived, the last push was on 2026-10-18, and three releases landed within two days: v4.7.0 on 2026-10-17, then v4.7.1 and v4.7.2 on 2026-10-18. That is a project being shipped on.

## Conclusion

Irisin suits a jailbreak user on iOS or iPadOS 15 or later who wants repositories, search, version pinning, paid package purchases and in-app updates from one place, and it does not suit anyone on a stock device or without a jailbreak, since there is nothing for it to install into. Before you install it, confirm you downloaded the package matching your jailbreak, because Irisin refuses to open on the wrong architecture, and read the Bootstrap Install note on a fresh custom firmware, where the first package may need a program from a later package before it can be configured.

## FAQ

### Which Irisin package do I install for my jailbreak?

For roothide you install the iphoneos-arm64e package, and for a rootless jailbreak under /var/jb you install iphoneos-arm64. Irisin checks the jailbreak on launch and, if the package does not match, names both architectures and refuses to open until you install the right one.

### What is Bootstrap Install in Irisin for?

It handles a circular dependency on a fresh custom firmware bootstrap, where an early package needs a program from a later package before it can be configured, such as debianutils needing bash. Long-press Execute and choose Bootstrap Install to extract all queued package files first, then run the normal unpack, maintainer script and configuration sequence.

### Can I stop Irisin from updating a package?

Yes. You can install any version a repository offers and block updates for packages you want to keep as they are. You can also buy paid packages and sign in to your vendor accounts directly in the app.

### How do I build Irisin from source?

Open Irisin.xcworkspace in Xcode and use the Makefile targets: make harness to run the tests on the Mac, make deb-all to build the roothide and rootless packages, and make install to update a device connected through iproxy 2333 22. You need ldid and dpkg installed.

## Sources

- [Lakr233/Irisin on GitHub](https://github.com/Lakr233/Irisin)
- [License: MIT](https://github.com/Lakr233/Irisin/blob/main-4.0/LICENSE)
- [Project website](https://lakr233.github.io/Irisin/)
- [README](https://github.com/Lakr233/Irisin/blob/main-4.0/README.md)
- [Releases](https://github.com/Lakr233/Irisin/releases)

---

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