Checkpoint: Reconstructing iloader's Operating Model
iloader's value becomes clearest when the account, device, native state, and user-facing operation are considered together. The focus here is the minimum set of conditions that lets iloader move from setup into an install, and the judgment those conditions support: which state can be reused, which capability must be live, and which choice still belongs to the user. With that model, a progress dialog becomes a map of responsibility rather than a promise that every external dependency will cooperate.
An iloader action needs live capabilities and remembered state
Consider the apparently ordinary goal of installing SideStore. The first half of the process has established two different kinds of readiness. The account path has produced a developer session and a sideloader in the running native process. The device path has produced a selected device whose metadata and pairing bytes have been committed together. Neither result is sufficient alone. A developer session without a reachable, trusted device has nowhere to install; a selected device without an authenticated sideloader has no account state with which to perform the delegated install.
The minimum state is therefore a conjunction, not a checklist whose items are interchangeable. iloader needs a live account capability, a live device connection, and the pairing material associated with that device before a bundled installation can progress through its full path. It also needs an input asset—either a selected IPA or one of the product-specific release choices. Even when those conditions are met, an account resource limit or a later app-container failure can interrupt the operation. “The screen shows an account and a phone” is only a rough visual approximation of readiness.
The distinction between state types makes the model more precise. Some information can persist across restarts. A saved email gives the interface a remembered account label. A saved password can let native code reconstruct the login path through the operating-system keyring. Pairing storage can preserve device-specific RPPairing material, and preferences can preserve choices such as the anisette server. These values reduce repeated work, but they do not by themselves authenticate a session or reconnect a missing phone.
Other state is live. The authenticated account and developer session are held by the sideloader in the current process. The selected device is meaningful because the host can still reach it and because selection completed the pairing work required by the current path. A temporary operation also has live ownership: while a command has taken the sideloader for mutable work, another command cannot assume that object is available. Live state can be informed by persisted material, but it is not equivalent to persisted material.
A third category consists of user decisions. The person must accept a Trust prompt when the device asks for it. They choose whether to save credentials, which anisette endpoint to use, whether to revoke certificates when a limit is reached, and whether to export a pairing file despite the warning to place it directly. These choices are not missing automation. They are points where the application cannot safely infer the user's intent or should not silently take a consequential action.
A fourth category is transient control state. The pairing cancellation token exists to stop an in-flight pairing path. The frontend's request number identifies which selection still represents the user's current intent. Operation events record which phase has started or completed. None of these should be confused with a durable device relationship or an account capability. They shape what happens now and may disappear when the action ends.
This produces a useful test for a failed setup.