minimuxer is the lockdown muxer used by SideStore. It runs on device through em_proxy.
make build # builds static libs
make xcframework # builds an xcframework
make zip # same as `xcframework`, and zips the final product for upload to GitHub release
We use a github action to generate a .xcframework
for use in Swift PM or Xcode.
This overwrites the last build on the tag Build
.
Either push a commit with [build]
as the prefix for the commit message or push an empty commit with:
git commit --allow-empty -m "[build]"
While minimuxer is built to run on device, it is recommended to test from your computer through USB to speed up the development process. (Obviously, you should still test on device; see On device for more info)
To test off device, open tests.rs and use the make_test
macro to make a test (this ensures logging and other things are initialized). You can then use
cargo test <test function name> -- --nocapture
to run it. (-- --nocapture
allows for logs to be shown, which are essential for debugging and knowing if a test did what it was supposed to do)
Since libimobiledevice logging can be quick verbose, you can filter it to only minimuxer logging with this command:
cargo test <test function name> -- --nocapture 2>&1 | grep -e minimuxer:: -e tests.rs
After implementing your feature, you should also run
cargo clippy --no-deps
to lint your code.
If you want some of the lints to auto fix, you can use
cargo clippy --no-deps --fix
(make sure to commit your changes beforehand).
Note: tests currently don't automatically mount the developer disk image, you must do that yourself with ideviceimagemounter
or open SideStore on device and let the auto mounter mount it (check
minimuxer logs in View Error Logs to see if it did so successfully).
SideStore communicates with minimuxer through Swift and C bindings generated by swift-bridge. swift-bridge makes it very easy to pass arguments to
functions, especially types like Vec
, and it also makes returning Result
very easy.
As of February 20th, minimuxer is included in SideStore as a prebuilt static library, built by GitHub Actions. Previously, it was included in SideStore as an Xcode project using cargo-xcode, but this made build times very long.
Unless otherwise stated, references to AltServer implementations are referring to AltServer/Devices/ALTDeviceManager.mm
Once you've made your function, added it to the tests and verified that it works, you can add it to swift-bridge/ffi to allow Swift to use it.
- Import your function in the
ffi imports
section oflib.rs
- In
mod ffi
->extern "Rust"
, add your function to the section for the file you added it to.
When making your function, you might have something similar to this:
pub fn install_provisioning_profile(profile: &[u8]) -> Result<()> { ... }
You can use crate::Res
as a shorthand to Result<T, crate::Errors>
. (Most files already use
this)
When exposing your function to the ffi
module, we unfortunately can't use the crate::Res
type alias. Instead, do this:
Result<[the type your function returns. in the case of install_provisioning_profile, it is ()], Errors>
AltServer implementation: search installProvisioningProfiles
and installProvisioningProfile:(