What Happens When an IPA Is Installed
For iloader, “install” names several different phases, and the distinction matters when the result is only partly successful. This chapter traces what iloader does with a bundled SideStore or LiveContainer build and what changes when a user imports an arbitrary IPA. The goal is to identify the boundaries around release download, delegated signing and installation, app discovery, and pairing delivery—especially the difference between what iloader coordinates and what its sideloading dependency owns.
The bundled path separates download, installation, and completion
A bundled install begins only after the interface has a logged-in account and a selected device. The user then chooses among product-specific options: stable or nightly SideStore, or a stable or nightly combination of LiveContainer and SideStore. These choices are not merely labels. They select different release assets and determine what iloader will look for on the device after installation.
The native operation starts by marking the download phase. In the inspected snapshot, the selected asset is fetched from a GitHub release URL with an HTTP client. iloader checks whether the response status is successful, reads the response bytes, and writes them into the Tauri temporary directory under a name appropriate to the selected build. It does not expose a download percentage to the interface. The code also contains a note that version checking and download caching are future work, so the normal path obtains the asset again rather than relying on a project-managed local cache.
That behavior has a useful operational consequence and a security consequence. A phase label tells the user that the failure occurred before signing, but it does not tell them how much data was transferred or allow a visible resume. And because the stable choices point to moving release locations rather than a version pinned in the operation, the same choice can resolve to different bytes at different times. That is convenient for obtaining a current build, but it makes the release endpoint part of the trust and reproducibility story.
The download check is also intentionally narrow. iloader rejects a failed HTTP response and reports a download error, but the shown code does not calculate a checksum or verify a release signature before writing the IPA and passing it onward. This is not proof that the downstream sideloading library performs no validation; its internals are outside this repository. It is a precise statement about the boundary visible in iloader: the orchestrator establishes that an HTTP request succeeded, not that the returned package has been independently authenticated by this code path.
After the temporary file is available, iloader obtains the selected device and invokes the sideloading library's installation method. The native code passes the device provider, the file path, and install options into isideload. The dependency is responsible for the actual sideload implementation, including work that the repository does not show in detail such as signing and entitlements. iloader's role is to supply the right account-backed sideloader and device connection, surround the call with operation events, and decide what must happen after it returns.
That separation prevents an important category error. A source-level inspection can establish that iloader calls installapp; it cannot establish the complete semantics of signing, provisioning, entitlements, or verification inside isideload. The user experiences the whole operation as iloader, but the evidence belongs to different layers.