Sideloader brings iOS app installation to Linux, written in D

The Linux gap is why the GTK frontend came first

The project positions itself as an open-source replacement for Cydia Impactor, and the description names the alternatives it is meant to replace, Sideloadly, AltServer, SideServer and iOS App Signer. What makes it interesting is the platform story. The current state is a cross-platform CLI with most features working, a Linux frontend based on GTK 4 that was the priority because no real alternative existed before, a Qt frontend being made for Linux, Windows and macOS, and a SwiftUI macOS GUI that could be made, since the scaffolding code is in the tree, though the author says they have no Mac to work on. The language is D, and the source layout follows, with source/, frontends/, keyring/, resources/ and a swift/ directory for that Mac scaffolding. The audience is a developer or technically inclined user who wants to install an IPA on an iOS device from a machine that is not a Mac, which is the case the author cared about first.

The command set is the whole interface

The CLI is where the tool actually lives, and the help output is short enough to read in full:

$ sideloader -h
Usage: sideloader [-d] [--thread-count THREADCOUNT] [-h] <command> [<args>]

Available commands:
  app-id         Manage App IDs.
  cert           Manage certificates.
  device         Manage registered devices.
  install        Install an application on the device (renames the app, register
                 the identifier, sign and install automatically).
  sign           Sign an application bundle.
  trollsign      Bypass Core-Trust with TrollStore 2's method (CVE-2023-41991).
  team           Manage teams.
  tool           Run Sideloader's tools.
  version        Print the version.

Optional arguments:
  -d, --debug    Enable debug logging
  --thread-count THREADCOUNT
                 Numbers of threads to be used for signing the application
                 bundle
  -h, --help     Show this help message and exit

The install command is the one that matters and it does the whole job in one call, renaming the app, registering the identifier, signing and installing automatically. The rest are the pieces of that chain exposed separately, so certificates, devices, teams and app identifiers can be managed from the same place, and tool runs the bundled helper programs, which the documented workflow uses to produce a pairing file. Two of these entries deserve a note. trollsign is described as bypassing Core-Trust with the method from TrollStore 2, tracked as CVE-2023-41991, which is a different activity from ordinary sideloading and is present as a command in the tool rather than as its purpose. And the signing step is parallelisable, with a thread count for signing the bundle, which is the practical knob when you are signing large applications.

It fetches a development certificate the way Xcode does

The mechanism is the interesting part of the design. Sideloader works by fetching an iOS development certificate as Xcode would do if you were developing your own iOS application, and then using it to deploy a third-party application. That is why the tool does not require a Mac, does not require Windows, and does not require any Apple software to be installed, and it only needs libimobiledevice and libplist. The obvious corollary is that it does require an Apple account, because that account plays the role of the app developer in Apple's eyes. The project is careful to say that any account will do and that it does not have to be the Apple ID tied to the phone, and it recommends a burner account. The credentials handling is stated as a design property rather than a promise, with the claim that credentials are only ever sent to Apple servers and that you can verify that, and a warning not to trust a closed-source obfuscated application with them. The signing path is what makes a device accept the app, and it is the part that ties the tool to Apple's provisioning behaviour and its expiry rules.

The documented install route goes through SideStore and WireGuard

The step by step guide in the README is the practical part. You download the SideStore.ipa file from sidestore.io, download the most recent Sideloader build from the project's GitHub Actions page, and install it with:

sideloader install SideStore.ipa -i

Then you enable Developer Mode on the iPhone, and generate the pairing file and send it to the phone with:

sideloader tool run 0

The remaining steps are about the network path. You install the WireGuard VPN app from the iOS App Store, visit sidestore.io on the phone to download the WireGuard configuration file and share it to the WireGuard app, enable the VPN, and then open SideStore and sign in with the same Apple ID used to install it. Finally you refresh the Apps tab, tapping the green day counter or choosing Refresh All, and the documentation stresses that this is required after every install of SideStore, otherwise you may see SideStore expiring earlier than it should. The pairing file and the VPN tunnel are the two steps where the trust model of the whole chain lives, and skipping either leads to the kind of failure the guide is warning about.

Building from source needs dub, D, and a compiler GDC cannot satisfy

Building it yourself is a documented path rather than a package. The OpenSUSE Tumbleweed route is the most explicit: install the dependencies, clone the repository, enter the directory, build with dub, enter the bin directory, make the binary executable and run it.

sudo zypper in gcc dmd dub libharfbuzz-gobject0 libadwaita libphobos2-0_* libimobiledevice-1_0-6 git
git clone https://github.com/Dadoum/Sideloader
cd Sideloader
dub build
cd bin
chmod +x sideloader
./sideloader

On other distributions you need a recent ldc2 or dmd, with an installation script linked on dlang.org. The project states it is tested with D 2.104.2, which is LDC 1.34, and that it will probably compile with older compilers. One exclusion is explicit and worth knowing before you start. The GNU D compiler will not compile this code, because the cryptography library makes use of SIMD instructions that cannot be compiled by GDC yet. The runtime dependencies are libimobiledevice and libplist-2.X, with support attempted for both 2.2 and 2.3, and OpenSSL is currently also required, though only networking needs it, and the author plans to remove that dependency. On Windows the libraries need MSVC builds, and the Microsoft Visual C++ redistributable has to be installed.

No tagged release, so the builds live in the Actions tab

The distribution situation is the main weakness. The only builds available are downloaded through GitHub Actions, with CLI builds for every supported operating system and GTK builds with a GUI for Linux-based systems. When the project gets a first release there will probably be an easier download in the Release tab that does not require an account, and the author hopes it will be packaged as a Flatpak, while admitting they cannot currently see how to make that work. The release tags are all pre-releases from 2024, 1.0-pre2 on 2024-04-01, 1.0-pre3 on 2024-04-03 and 1.0-pre4 on 2024-10-01, and the last push was on 2026-09-18, so the code moves while the packaging does not. The licence is GPL 3.0, which matters here because a sideloader that handles Apple credentials and signing keys is the kind of program people are right to be able to audit, and the author says explicitly that they tried to make the code as readable as possible and would rather it not finish unmaintained. The Linux, Windows and macOS platform notes, and the acknowledgements and references section, are the parts of the README to read before you trust it with a certificate.

Editorial conclusion

Sideloader is worth following for anyone who wants to install iOS applications from a Linux machine, because the CLI does the certificate and signing work without a Mac, without Xcode and without the closed-source tools it names as alternatives, and the author is explicit about how your credentials are handled. It is not a product to depend on in a release process, since there is no tagged release, the only builds come from GitHub Actions runs, the D toolchain requirement is unusual, and the upstream service it depends on is Apple's. Before adopting it, read the notes on platform support and build it yourself with dub, confirm that the signing identity you will use is one you are entitled to use, and treat the pairing file and the WireGuard steps as security decisions rather than setup trivia.

Frequently asked questions

Official sources

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