Feather: an on-device iOS sideloader built on Apple Developer Program certificates

The certificate-paired sideloading gap Feather fills

Sideloading an iOS app normally means moving the IPA to a computer, running a signing tool there, and pushing the result back to the device. Feather inverts that: the README describes it as a "Sideloading app meant for developer certificates," and the signing happens on the iPhone or iPad itself. The audience is narrow by design. You need a certificate that is part of the Apple Developer Program, which the repository description states plainly. That rules out anyone hoping to install arbitrary apps without a developer account.

The project's own licence rationale is unusually direct. The README says GPL-3.0 was chosen because the author "wanted to make a project that is transparent to the user thats related to certificate paired sideloading, before this project there weren't any open source projects that filled in this gap." Read that as a statement about the field at the time, not a claim about every tool that exists now. The practical consequence for a team is that the signing path is inspectable, which matters when the thing you are trusting is a certificate.

Zsign on-device and the IDeviceKitten backend

The signing engine is Zsign, listed in the acknowledgements as "Allowing to sign on-device, reimplimented to work on other platforms such as iOS." That reimplementation is the core of the project. Zsign is a C++ signing tool; making it run inside an iOS app bundle is why the repository carries a Zsign directory at the top level, alongside AltSourceKit and NimbleKit.

Installation to the system is a separate concern from signing. The acknowledgements credit idevice as the "Backend for builds with this included, used for communication with installd," and the top-level IDeviceKitten entry is that backend's place in the tree. So the flow is: pick an IPA, sign it with a certificate you supply, then hand it to installd through the device communication layer. The README does not document what happens when installd rejects the result, and there is no rollback procedure described.

Two supporting pieces are worth naming. The Makefile pulls a certificate bundle from https://backloop.dev/pack.json and splits it into deps/server.crt, deps/server.pem and deps/commonName.txt. The acknowledgements explain why: "*.backloop.dev - localhost with public CA signed SSL certificate." That is the HTTPS layer the app's embedded server needs. Vapor, the server-side Swift framework, and code borrowed from Asspp for setting up the HTTP server, are what serve the install payload. AltSourceKit is the AltStore repository reader, which is why the README can advertise support for AltStore app sources.

Building Feather from source with the Makefile

The README's Download section does not give build instructions. It points at the releases page for the latest .ipa and at an AltSource URL, https://raw.githubusercontent.com/claration/Feather/refs/heads/main/app-repo.json, for adding Feather to AltStore-compatible clients. If you want to build it yourself, the Makefile is the entry point. It targets two platforms, iphoneos and maccatalyst, and the deps target fetches the backloop certificate material before any build runs.

The build itself shells out to xcodebuild against Feather.xcodeproj with the Feather scheme, Release configuration, and CODE_SIGNING_ALLOWED=NO, then ad-hoc signs the assembled app and packages it. A full run looks like this:

Signing options and tweak injection in practice

The README lists configurable signing options "mainly for modifying the app, such as appearance and allowing support for the files app," and says this includes "patching apps for compatibility and Liquid Glass." The Liquid Glass reference is an iOS UI change, so the patching exists to keep older or differently built apps rendering correctly on newer systems. The README does not enumerate the individual flags, so treat the in-app UI as the source of truth for what each toggle does.

For advanced users there is tweak injection using Ellekit, with support for injecting .deb and .dylib files. This is the part of Feather that behaves least like an installer and most like a build tool. Injecting a tweak changes the app you are signing, and the README offers no compatibility matrix for which tweaks work with which apps. If a signed app misbehaves after injection, the signing options are the first place to look, and the README gives no diagnostic guidance beyond that.

Two claims in the feature list are worth separating. "No tracking or analytics, ensuring user privacy" is a design statement about the app. "Actively maintained: always ensuring most apps get installed properly" is a claim about cadence; the repository's own history is the better evidence, and the last push was on 2026-09-22, with v2.9.0 released on 2026-07-05.

Where Feather is the wrong tool

Feather assumes you hold a developer certificate and understand what that means. Anyone without an Apple Developer Program certificate cannot use it as described. That is not a bug to work around; it is the premise.

The second limitation is scope. Feather signs and installs. It does not manage a fleet, it does not push configuration profiles, and the README describes no MDM integration or enterprise distribution path. A team that needs to roll out an internal app to hundreds of managed devices is looking at the wrong category of tool, regardless of how well the signing works.

The third is support surface. The README documents features but not failure modes. There is no troubleshooting section, no statement about what happens when a certificate expires mid-install, and no rollback described for a failed install. The acknowledgements mention LiveContainer for "Fixes/some help," which suggests some problems are solved by looking at a sibling project rather than at Feather's own documentation. Budget for that. If you need a tool with a written recovery path for every failure, Feather's README will not give it to you.

How Feather differs from AltStore and desktop signers

AltStore is the closest reference point, and the relationship is not purely competitive. Feather supports AltStore repositories, so the two can share a source format. The difference is where the work happens. AltStore's model pairs a device with a computer running AltServer, which handles the signing and refresh over the local network. Feather moves the signing onto the device, which is why Zsign had to be reimplemented for iOS in the first place.

That shift changes the failure surface. With a desktop-assisted tool, the computer is a second machine you can inspect and rerun. With Feather, the signing, the embedded HTTPS server, and the installd handoff all happen on the same device. When something goes wrong there is no second machine to fall back on. The trade is convenience for diagnosability.

Against a plain desktop signer, the difference is narrower but real: no cable, no separate signing step, and the AltStore source format as an input. What you give up is the desktop's larger toolchain and the ability to script the signing step outside the app.

Licence, contributions and what a fork inherits

Feather is GPL-3.0. The README states that by contributing you agree to license your code under GPL-3.0 as well, "including agreeing to license exceptions." That phrase matters more than it looks. If you fork Feather and ship a modified build, the copyleft terms travel with it. If you are building a closed product around Feather's signing path, the licence is the first thing to read, and the second thing to ask a lawyer about. Nothing here is legal advice.

Upgrade cost is modest at the source level. The Makefile pins one external input, CERT_JSON_URL, to https://backloop.dev/pack.json, and the deps target regenerates the certificate files on every build. That means a rebuild always picks up whatever backloop.dev currently serves, which is convenient and also a moving part outside your control. If that endpoint changes shape, the jq extractions for .cert, .key1, .key2 and .info.domains.commonName are what break first.

Localization is a lower-cost contribution path. The README notes that localizations live in Feather/Resources/Localizable.xcstrings and that new languages are added through Xcode's interface, with the contributing guide covering how to test them.

Editorial conclusion

Adopt Feather if you already hold an Apple Developer Program certificate and want to sign and install IPAs on the device itself, without a desktop tool in the loop. Skip it if you need an App Store distribution path, a managed enterprise deployment, or a tool your non-technical users can run unattended. Before you build or install, verify that your certificate and provisioning profile cover the bundle identifiers you intend to sign, check the app-repo.json source URL if you plan to use AltStore repositories, and confirm the current release tag on the releases page, since the README's download section points only there.

Frequently asked questions

Official sources

1. claration/feather on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases