Ksign: a Swift re-implementation of the Esign iOS signing workflow

The project exists because Esign stopped and the community had nowhere to go

Ksign is described in the README as yet another codesigning app, with the question of what would happen if Feather and Esign had a child. The premise in the Why section is concrete: Esign reached end of service, people moved to other signing apps, and Esign had been a large part of the community. With Feather as the base, the goal was to recreate Esign as closely as possible so that people would not have to learn a different app and switch between them.

That framing sets the expectation for the project. Ksign is not trying to be a better signing app with new capabilities. It is trying to be the app you already knew, rebuilt on a maintained base, so that the muscle memory of the old workflow still applies. The topic tags reflect that: apple, esign, ios, sideloading, signer, swift and zsign.

The primary language is Swift, which confirms the Feather lineage since Feather is a Swift project. The licence is GPL-3.0, and the last push was on 2026-07-14 with a beta build on the same date, the newest tagged release before that being v1.6 from 2026-05-24 and v1.5.1 from 2025-12-18.

The audience is narrow and clearly defined: iOS users who sign IPA files and install them on their own devices, and who are familiar with the Esign workflow.

There is also a second motivation that explains the distribution model. The README says the app was built specifically for Khoindvn, a product manager named in the acknowledgements, to share his certificates, which would let more people access sideloading without having to buy a certificate themselves.

A Swift app that pulls its signing machinery in as submodules

The repository layout explains the structure without needing the source code.

There is Ksign.xcodeproj/ and a Ksign/ directory, which is the application itself, and a makefile at the root for driving the build. Alongside them sit four directories whose names make the approach clear: AltSourceKit, IDeviceKit, NimbleKit and Zsign.

The .gitmodules file is present, so these are dependencies pulled in as submodules rather than vendored directories. IDeviceKit and NimbleKit are the usual pieces for talking to an iOS device over USB and for the app's runtime behaviour, AltSourceKit is the standard Swift package for pulling in third party libraries, and Zsign is the standalone signing implementation that the app builds on. A repo.json file at the root is the AltSourceKit manifest that ties those package references together.

The licence handling is more interesting than the layout. There are two licence files, LICENSE and LICENSE_ELLEKIT, plus a license_plist.yml. That second file is what an iOS app needs to declare the licences of the third party code it embeds, and having a plist in the repository means the attribution obligations for the borrowed components were taken seriously rather than ignored.

The practical picture is an Xcode project that produces a signed IPA, with a makefile as the entry point for the build, and the signing and device libraries arriving through submodules. Nothing in the visible documentation describes a configuration file, a CI pipeline or a headless mode, and that absence is itself informative: this is a Mac developer workflow, not a build service.

Installation is downloading an IPA, and the project warns about where not to get it

There is no install procedure in the traditional sense, and the distribution model is worth understanding properly before you use it.

The Download section is one line: go to the Releases page and download the newest ipa from there. There is no package manager, no Homebrew tap, no test flight, no app store listing.

The Disclaimer section then says something that most projects of this kind would not bother to write. This project is maintained here, on GitHub. Releases are distributed here, on GitHub. They do not currently have a project website outside of this repository. And the reader is asked to make sure to avoid any sites that host their software, because such sites are often malicious and are there to mislead users.

That paragraph is a genuine warning, and it reflects a real pattern in the sideloading world where fake download sites impersonate signing tools to distribute malware. The read is straightforward: the GitHub releases page is the only source, and a third party site with a plausible name is a risk rather than a convenience.

There is also a repository split worth knowing about. The README points for issues and feature requests at github.com/Nyasami/Ksign-public, while the code and releases live in this repository, nyasami/ksign. So the code repository and the public tracker are different places, and a problem you hit as a user belongs in the tracker rather than in the source tree.

For support there is a Discord, and the acknowledgements credit Feather by clarection, the product manager Khoindvn, and the users.

What the project does not document, and what that means for a build pipeline

The documentation is a community README rather than a developer guide, and the omissions are specific enough to name.

There is no documented build procedure. The makefile exists at the root and the Xcode project exists, but the README does not say which Xcode version, which SDK, which signing identity or which provisioning profile a developer needs to produce a working build. There is also no described configuration file for the app itself, so the settings for where certificates live, how profiles are managed and how the app picks a device are not documented anywhere in the repository.

There is no CI badge in the README and no mention of a build pipeline, so there is no visible evidence of an automated build producing the release artefacts. There is a CHANGELOG-adjacent release history in the tags, with a beta build tagged on 2026-07-14 and v1.6 from 2026-05-24, and a beta channel that is published alongside the stable line.

The practical consequence is that this is a project you consume rather than one you build. If your requirement is a signing setup that your team controls, with a documented process, a reproducible artefact and an audit trail of what was signed, this repository does not offer that, and the missing pieces are not small ones.

The submodules add a second layer of uncertainty. A checkout brings in four external codebases at whatever revision the submodule pointers name, and a developer building from source is building four things they did not write and that the README does not describe.

None of this is an argument against the project for its stated purpose. It is an argument for reading it as what it is, a maintained app that its author and its community use, rather than as a signing platform.

Where Ksign is the wrong tool

The first wrong-tool case is a development team that needs signing as a repeatable step in a release pipeline. A prebuilt IPA downloaded from a releases page, with an Xcode project whose build steps are not documented, is the opposite of what a CI system wants. A team that wants to sign its own builds on macOS with a managed profile set belongs with the platform tooling rather than here.

The second case is a user who needs signing profiles that last. Apple grants free development profiles for a limited period and paid accounts extend that, and the project does not describe any handling of expiry, renewal or multiple accounts beyond the certificate sharing arrangement it was built for. If your workflow depends on a long-lived profile, you need to know exactly what the app does about expiry, and the visible documentation does not say.

The third case is a user on a recent iOS release who has been put off by signing tools that break when the platform moves. The project was last pushed on 2026-07-14 and the newest tagged release is a beta build, so the cadence of platform compatibility is not something the documentation commits to. The README's own framing, a recreation of a retired app for a community that has already migrated once, suggests a tool that follows the platform rather than leading it.

The fourth case is anyone looking for a supported product. There is no project website outside the repository, no support contract, no security policy in the visible file list, and a Discord for contact.

On licensing, the GPL-3.0 grant is the term to read carefully. The project is GPL-3.0 licensed with a LICENSE file at the root, and it also carries LICENSE_ELLEKIT for the ElleKit component and a license_plist.yml for the bundled third party attribution. A GPL application that is distributed as a binary carries source availability obligations, and the README does not discuss how a redistribution should be accompanied by source, so anyone shipping it inside a product needs to resolve that rather than assume the licence file settles it.

Editorial conclusion

Ksign suits an iOS user who signs and installs their own applications and wants a tool that feels like the Esign workflow that many people already know. It does not suit a team that needs a reproducible signing pipeline, because the distributed artefact is a prebuilt IPA and the repository is a set of submodules rather than a documented build you control, and it does not suit anyone who needs a long-lived profile beyond what Apple grants. Before adopting, read the disclaimer and download only from the GitHub releases page, since the project states plainly that there is no official site outside the repository and that third-party sites hosting the app are usually malicious, and check what a new beta build changes relative to v1.6.

Frequently asked questions

Official sources

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