CarrierSIM changes the bundle selected for your SIM
CarrierSIM associates an iPhone's SIM identity with a carrier bundle already present on the device. The project targets Wi-Fi calling in Russia and Belarus, with possible changes to EVS voice coding and some cellular bands. Its README and technical guide are in Russian, and the repository doesn't provide an English guide. This is a narrow device-configuration tool for someone prepared to investigate their exact carrier and iOS combination.
The default mapping uses Vodafone_hu, with a separate Vodafone_ro entry for MTS Russia in bundle.yaml. The script changes links in the user carrier directory rather than editing Apple's signed system bundles. That's a useful distinction, because the available settings still depend on the donor bundle and the network. Our 307 MB Python environment cannot establish whether a particular operator will register Wi-Fi calls or preserve every feature of the original profile.
What happened when we ran it
Our CarrierSIM install succeeded in 19 seconds, adding 124 packages and occupying 307 MB, and the build step passed in 1 second. We ran commit feb9e2f on October 15, 2026, in a fresh Debian container with Python 3.12, 3 CPUs, 8 GB of RAM, and no secrets or elevated privileges. Pip-audit reported 0 known vulnerabilities. These results cover the source environment, without establishing a successful operation on a phone.
The test command failed with exit code 3 after 6 seconds. Its tail shows an internal error while xonsh initializes prompt fields: pwd.getpwuid(os.getuid()).pw_name raises a KeyError because UID 1000 isn't found. The visible failure is a username lookup during initialization. The tail doesn't provide a count of completed tests or establish a defect in carrier-profile writing. It also doesn't justify silently treating the suite as passed.
Our scan found 4 CI workflow files and a tests directory, with no Dockerfile. Those files show that upstream has automated-check infrastructure, but our full test command still failed. Neither the successful build nor the audit measures recovery after an interrupted device operation. If that behavior matters to your deployment, you'll need evidence from the relevant phone and operating-system combination in addition to a working Python environment.
iOS 27.2 beta 3 closes the documented write method
The v7 release, published October 7, says iOS 27.2 beta 3 blocks the AirTraffic file movement used by CarrierSIM. The README distinguishes that change from earlier beta builds and says an existing installed profile remains after an update. It also says installing, changing, or removing the profile through this method is blocked on the affected build. Read that compatibility boundary before choosing a release archive.
The same documentation says resetting network settings won't remove the profile. Its recovery instructions therefore deserve attention before you alter a phone you rely on. Cellular iPads are another boundary: the README says installation hasn't been verified on a device, while Wi-Fi-only models lack the required modem. A cross-platform desktop launcher doesn't turn those device-specific limitations into general iPhone or iPad support.
Linux needs usbmuxd, and Windows needs Apple's runtime
Python 3.11 or newer is the source requirement, with 3.12 recommended. Linux needs the system usbmuxd service. Windows needs Apple's device services and the documented iTunes runtime, while the README cautions that Microsoft Store and Apple Devices arrangements may not fit. The ready-made archives remove the separate Python requirement, but they don't remove those host dependencies. The macOS archives are unsigned, which also creates an explicit launch step.
The initial phone connection requires USB, an unlocked device, and the Trust prompt. Wireless operation needs an existing pairing and a local network that permits Bonjour discovery. On macOS, AirTraffic additionally needs local-network permission for the terminal or application. These requirements explain why the 19-second dependency install is only a small part of setup. A headless remote shell isn't equivalent to the documented local interactive workflow.
A donor profile can alter data and activation behavior
The README warns that changing a bundle can introduce the donor carrier's APN, affecting mobile data or MMS. It also describes bundles whose activation number or roaming preferences may be unsuitable for your SIM. The profile-selection instructions expose those differences rather than claiming that one choice works everywhere. I'd inspect the read-only status and proposed mapping before considering any write, then retain the session's recovery files.
Those recovery files need care too. The v7 notes describe masking phone identifiers in logs, while the README explicitly says ZIP backups are not anonymized and can contain IMSI information. A sanitized report and an entire run directory aren't interchangeable attachments. Our 0-known-vulnerability audit says nothing about disclosure through an archive you upload yourself. That is a documented workflow issue, separate from package advisories or the sandbox's test initialization failure.
October releases show maintenance without universal compatibility
GitHub recorded a last push and v7 release on October 7, 2026, with 252 stars and 7 open issues and PRs combined. Issue activity continued afterward, including a closed script report updated October 14. That supports a finding of current maintenance, while the explicit iOS block still limits adoption. For developers investigating the transport, AirLift is a protocol reference; pymobiledevice3 is a broader device-interaction alternative. Neither promises CarrierSIM's ready-made carrier mapping workflow.