What eSIM Transfer Actually Does at the Protocol Level
eSIM transfer is not a true profile migration. When you "transfer" an eSIM, the original profile is deleted and a new profile is provisioned to the target device's Embedded Universal Integrated Circuit Card Identifier (EID) via the carrier's Subscription Manager Data Preparation (SM-DP+) server. Apple's eSIM Quick Transfer automates this for same-ecosystem moves, but Android has no equivalent cross-device API—you must use your carrier's app or request a new QR code.
According to Apple's support documentation, an eSIM is a digital SIM built into your device. Each eSIM has a unique EID that cryptographically binds profiles to specific hardware. A profile provisioned to EID A cannot execute on EID B. What users perceive as "transfer" is actually:
- Authentication of the transfer request with the carrier
- Deletion of the profile from the source device's eUICC
- Generation of a new profile bound to the target device's EID
- Download and installation via the Remote SIM Provisioning (RSP) protocol
This architecture explains why you cannot simply copy an eSIM file between devices. The profile contains carrier credentials encrypted for a specific EID, and the SM-DP+ server enforces this binding.
Apple's eSIM Quick Transfer: Carrier-Mediated Profile Swap
Apple's eSIM Quick Transfer automates the deletion-and-reprovisioning sequence for iPhone-to-iPhone transfers. The mechanism requires:
- Both devices signed into the same Apple Account
- The previous iPhone unlocked with its device passcode
- Both devices nearby with Bluetooth enabled
- Carrier support for eSIM Quick Transfer
During setup of a new iPhone, the system detects nearby devices with transferable profiles. When you select a line to transfer, the new iPhone communicates the transfer request to Apple's servers, which coordinate with the carrier's SM-DP+ server. The carrier validates the request, generates a new profile bound to the new device's EID, and pushes it via the Local Profile Assistant (LPA) on the new iPhone.
According to Apple's support documentation, "the cellular plan on your new iPhone deactivates your previous SIM when it activates." This is not instantaneous profile migration—the old profile is deleted as part of the activation sequence.
Some carriers require an additional step. If a banner appears stating "Finish Setting Up Your Carrier's Cellular Plan," the transfer is incomplete. Tapping the banner redirects you to the carrier's webpage to authorize the profile generation. This indicates the carrier has not fully automated their SM-DP+ integration with Apple's transfer API.
You can also convert a physical SIM to an eSIM on supported carriers using the same Quick Transfer interface, selecting "Convert to eSIM" instead of a device-to-device transfer.
Android eSIM Handling: No Cross-Device Transfer API
Android implements the GSMA RSP specification for profile download and management but provides no native API for device-to-device transfer. On Pixel devices, Pixel 3a and later support one physical SIM plus one eSIM, with Dual SIM Dual Standby (DSDS) allowing both to remain active simultaneously.
To move an eSIM to a new Android device, you must:
- Install your carrier's official app on the new device
- Authenticate with your account credentials
- Navigate to device management or line activation
- Provide the new device's IMEI or EID (found in Settings → About phone → SIM status)
- Authorize the transfer, typically via SMS to the old device
This workflow is carrier-specific. T-Mobile uses the T-Life app, Verizon uses My Verizon, AT&T uses myAT&T. Each implements its own UI for triggering SM-DP+ reprovisioning. The carrier's backend deletes the old profile and generates a new QR code or pushes a profile directly to the new device's EID.
Google's DSDS implementation allows two profiles to remain active simultaneously, but this is a radio-level feature, not a transfer mechanism. You still provision each profile independently.
Cross-Platform Transfer: Why Android-to-iPhone Works Differently
Apple's support documentation lists "Transfer an eSIM from an Android or other non-Apple device" as a distinct method from iPhone-to-iPhone Quick Transfer. Cross-platform transfer cannot use Apple's automated flow because Android devices do not participate in Apple's device-proximity protocol.
The process requires full carrier involvement:
- On the iPhone, navigate to Settings → Cellular → Add eSIM
- Select your carrier from the list (if available) or choose "Use QR Code"
- The carrier's activation flow will require authentication
- The carrier's SM-DP+ server provisions a new profile to the iPhone's EID
- The Android device's profile is deactivated by the carrier backend
This is functionally identical to activating a new line—the carrier treats the iPhone as a new device requesting service. The Android device does not participate in the transfer beyond potentially receiving an authorization SMS.
Some carriers provide a web portal where you can initiate the transfer by entering both devices' EIDs. This triggers the same backend sequence: delete the old profile, generate a new one, push it to the target EID.
GSMA RSP Architecture: What the Spec Defines and What It Doesn't
The GSMA's SGP.21 and SGP.22 specifications define the architecture and technical implementation of Remote SIM Provisioning. Multiple specification versions remain active simultaneously for backward compatibility.
These specifications standardize:
- The SM-DP+ server's role in profile generation and encryption
- The LPA's role in profile download and installation on the eUICC
- Profile lifecycle states (enabled, disabled, deleted)
- The ES8+ interface between SM-DP+ and eUICC
- Profile metadata and notification mechanisms
What the specifications do not standardize:
- Device-to-device transfer protocols
- User interfaces for transfer initiation
- Cross-platform transfer workflows
- Automatic profile migration on device replacement
The GSMA RSP architecture assumes that profile provisioning is always a server-driven operation. The SM-DP+ server is the source of truth. Device-to-device transfer is not a peer-to-peer operation—it is a coordinated delete-and-reprovision orchestrated by the carrier's backend.
This explains why Apple's Quick Transfer and carrier-specific Android apps implement transfer so differently. The GSMA spec provides the primitives (profile deletion, profile download, EID binding) but leaves the user-facing workflow to platform vendors and carriers.
Dual-SIM Configurations and Profile Limits
Apple's implementation allows an iPhone XS, iPhone XR, or later to store eight or more eSIMs, but only one can be active at a time unless the device supports dual-SIM operation (one physical SIM plus one eSIM, or two eSIMs on iPhone 13 and later in regions where physical SIM trays are absent).
On Android, Pixel 4a (5G) and later models with dual-SIM support can connect to 5G networks, but 5G availability depends on carrier provisioning and network compatibility. Some carriers restrict 5G to the primary SIM slot.
Storage limits are eUICC hardware constraints. When you attempt to download a new profile to a full eUICC, the LPA will prompt you to delete an existing profile. Deleted profiles can be re-downloaded from the carrier's SM-DP+ server if the carrier retains the profile data, but this is not guaranteed. Some carriers generate single-use profiles that cannot be re-downloaded after deletion.
Troubleshooting Transfer Failures: Implementation Gaps
Transfer failures typically occur at the carrier integration layer, not the device layer. Common failure modes:
"Finish Setting Up Your Carrier's Cellular Plan" banner: The carrier's SM-DP+ server generated a profile but requires additional authentication. This banner indicates a carrier webpage redirect is required. The carrier has not fully automated their activation flow with Apple's API. You must complete the web-based activation to finalize the profile installation.
"Transfer Failed" during Quick Transfer: The carrier's backend rejected the transfer request. Possible causes:
- The source device is not unlocked or the passcode was not entered
- The carrier account has restrictions (unpaid balance, fraud hold)
- The carrier does not support eSIM Quick Transfer for your plan type
- The target device's EID is not in the carrier's device whitelist
Transfer requires the previous iPhone to be unlocked with the device passcode because the LPA must authenticate the deletion request. If the device is locked, it cannot confirm profile removal to the carrier's SM-DP+ server.
QR code scan fails on Android: The QR code encodes an SM-DP+ server address and activation code. Scan failures occur when:
- The QR code has expired
- The device's LPA cannot reach the SM-DP+ server (network issue)
- The activation code has already been used
Generate a new QR code from the carrier's portal or app. Activation codes are single-use tokens.
Profile downloads but does not activate: The profile installed successfully but the carrier's Home Location Register (HLR) has not updated. This is a carrier backend issue. Wait several minutes for HLR propagation, then toggle Airplane Mode to force a network re-registration. If the issue persists, contact the carrier—the profile is installed but not authorized on the network.
What Developers Should Know
If you are building an app that interacts with eSIM provisioning:
On iOS, use the CTCellularPlanProvisioning API to trigger profile downloads. You cannot implement device-to-device transfer—that requires carrier integration with Apple's backend. You can, however, provide a QR code or activation code that the user scans via Settings → Cellular → Add eSIM.
On Android, use the EuiccManager API to list installed profiles, download new profiles, and switch between profiles. The downloadSubscription method accepts an activation code from your carrier's SM-DP+ server. You cannot access another device's profiles or implement peer-to-peer transfer.
For carrier integrations, implement the GSMA SGP.22 ES2+ interface between your SM-DP+ server and the device's LPA. Support both QR code activation (for manual setup) and push provisioning (for automated flows). If you want to support Apple's Quick Transfer, work with Apple's carrier engineering team to integrate your SM-DP+ server with their transfer API.
For cross-platform apps, assume that eSIM transfer requires user interaction with your carrier portal or app. Provide clear instructions for obtaining a new QR code or activation code. Do not promise seamless transfer—the GSMA architecture does not support it, and platform implementations vary.
When a user reports that they "cannot transfer" an eSIM, the issue is almost always carrier policy or backend configuration, not device capability. The device can download and install any profile the SM-DP+ server provides. If the carrier's backend does not support reprovisioning to a new EID, no amount of device-side troubleshooting will resolve it.
Top comments (0)