SignTools: A Self-Hosted iOS Sideloading Service With a macOS Builder Split

What SignTools Actually Removes From the Sideloading Workflow

Sideloading an unsigned IPA normally means a desktop: a cable, a signing utility, and a Mac or a workaround for not having one. SignTools targets the step after the initial setup, where the README states that no computer is required. The service exposes a web interface for uploading, signing, and downloading apps, and it can push a signed build straight to an iOS device over the air. The stated audience is people running homebrew apps or tweaks on their own devices. The README's disclaimer is explicit that the project offers no catalogue of applications and does not support piracy, so the intended use is your own builds, not a distribution channel for other people's software.

The Service and Builder Split, and Why It Costs a Mac

SignTools is not a single binary. The README describes two components: a service and a builder. The builder is a macOS machine that performs signing using official Apple software. The service is this repository, written in Go, and it can be hosted anywhere. When a signing job arrives, the service hands it to the builder where necessary, then serves the signed result back through the web interface. That design is the whole argument for the project. Because signing runs through Apple's own tooling on real macOS rather than a reimplementation, the README attributes high reliability and compatibility to it. The cost is architectural: you cannot run the complete system on a Linux VPS alone. The service is portable, the builder is not, and the builder is the part that needs a machine you own and keep reachable.

Getting It Running: Docker, a Mac, and the Install Doc

The repository does not inline its setup steps. Installation is delegated to INSTALL.md, and the README links it alongside FAQ.md. What the README does state is that the service is distributed as a Docker image, published under the signtools/signtools name, and that it can be hosted anywhere. So the practical shape of a deployment is a container for the service plus a separate macOS host for the builder, with the two configured to talk to each other. The feature list names the configuration surface you will be working with: provisioning profiles and developer accounts, configurable signing including entitlements, and multiple signing profiles selectable per app. Those are the settings that decide whether a given IPA signs successfully, and they live in the builder's Apple toolchain rather than in the Go service. The README also notes tweak injection at signing time, which means the builder is doing more than a straight re-sign.

Where the Documentation Stops and You Start

This is a thin README, and it is worth being blunt about that. There is no configuration reference in the material supplied, no list of environment variables, no description of how the service authenticates to the builder, and no explanation of what the builder exposes as an interface. The README points at INSTALL.md and FAQ.md for the answers, which is a reasonable place to put them, but it means you cannot judge the operational difficulty of this project from the repository front page alone. The screenshots show a mobile-friendly interface, and the feature list claims a minimalistic one, but the actual signing configuration is described only at the level of categories: profiles, accounts, entitlements. If you need to know exactly which entitlement keys are pass-through and which are rewritten, that answer is not in this README.

The macOS Builder Is the Real Constraint

The design choice that gives SignTools its compatibility is also its main failure mode. A macOS builder is a physical or virtual Apple machine that must be available when a signing request arrives, kept on a supported OS version, and maintained with whatever Apple's signing toolchain requires at the time. If that machine goes down, the service still serves its interface but cannot complete the job that matters. There is a second, quieter limitation: the project depends on Apple's rules about developer accounts and provisioning profiles. The README lists developer accounts as a supported feature, which means the signing you get is bounded by what your account is permitted to sign and how many devices a profile covers. SignTools does not change those limits. It moves the workflow to a browser. Anyone expecting it to bypass account restrictions has misread what the builder does.

How This Differs From a Local Sideloading Utility

The obvious alternative is a desktop sideloading application that runs on the machine you already own, signs the IPA locally, and installs over a cable or a local server. The difference is where the state lives. A desktop tool keeps everything on one computer and dies with it: no shared interface, no remote upload, no over-the-air install link you can open on the phone. SignTools inverts that. The signing capability sits on a builder that stays put, and the interface is reachable from any browser, which is what makes the no-computer claim possible after setup. The price is that you now operate two things instead of one, and the more fragile of the two is the one you cannot containerise. If your signing needs are occasional and you are already sitting at a Mac, a local utility is less machinery for the same result.

Licence, Maintenance, and What AGPL-3.0 Means Here

SignTools is licensed under AGPL-3.0, and the README states that this covers the project and all of its unlicensed dependencies under the SignTools organisation. The AGPL's network clause is the part that matters for a self-hosted web service: if you modify the code and let users interact with it over a network, the licence's source-availability obligation can attach to your modified version. That is a general property of AGPL-3.0, not legal advice, and if you plan to modify and expose SignTools to others you should read the licence text in the repository rather than rely on a summary. The README also notes that you can raise an issue if you are interested in exclusive licensing, which signals that the maintainers are open to a different arrangement for commercial use. On maintenance, the release cadence visible in the material is uneven: v3.0.12 in July 2026, v3.0.11 in January 2026, v3.0.10 in June 2025. That is roughly one release every six to seven months, with the most recent push to master in September 2026. Plan for a project that moves slowly and for the macOS side of your deployment to need attention on Apple's schedule, not the project's.

Editorial conclusion

Adopt SignTools if you already control a macOS machine that can stay on and you want a web interface for signing and OTA installs rather than a desktop tool. Do not adopt it if you have no Mac to dedicate, or if you need a hosted service that someone else operates, since the README states plainly that this project is self-hosted and is not a public service. Before committing, verify the builder setup in INSTALL.md against your macOS version, confirm which signing profiles and entitlements your account can actually produce, and read FAQ.md for the installation constraints the README defers to.

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. SignTools/SignTools on GitHub