Detect and implementation details for eSIM in iPhone

How to programmatically detect MCC and MNC code of eSIM in iPhone?

You can, for the moment, use Core Telephony for this. See the mobileCountryCode and mobileNetworkCode properties on CTCarrier.

CT will give you these values for all active SIMs. There’s no good way to determine which is a hardware SIM and which is an eSIM.

Also, it’s likely that a future version of iOS will stop returning meaningful values here. See deprecation comments in <CoreTelephony/CTCarrier.h>.

how can I identify whether internet mobile data is connected through

There’s no supported way to do that on the device itself. Indeed, it’s not hard to imagine a world where this question itself makes no sense, in that we might use different SIMs for different network destinations. [See Scott’s reply below.]

Are you working on behalf of a carrier?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

how can I identify whether internet mobile data is connected through [one ]SIM or [the other] SIM?

Is dataServiceIdentifier (link) what you need? It’s a key into the serviceSubscriberCellularProviders dictionary (and also serviceCurrentRadioAccessTechnology) for the one providing data.

Oh wow, I missed the memo on that one. Thanks for the pointer!

Despite the existence of dataServiceIdentifier, I’d still caution you about relying on that, for the reason I outlined above: It really is easy to imagine a world where multiple SIMs are used for data concurrently.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks, Scott and eskimo. I need another piece of info, is there any order of serviceSubscriberCellularProviders dictionary values? like if there is one Verizon physical SIM and AT&T eSIM. then which value will come as 1st value of the dictionary?

Our real-time experience is 1st value of physical SIM and 2nd value of eSIM. but on the internet, we saw many developers say they got eSIM value as 1st value and physical SIM as 2nd one. Please confirm the significance of ordering.

is there any order of serviceSubscriberCellularProviders dictionary values? 

Dictionaries have no concept of order. You can enumerate the entries in a dictionary, but the actual order in which they get enumerated is meaningless.

Our real-time experience is 1st value of physical SIM and 2nd value of eSIM. but on the internet, we saw many developers say they got eSIM value as 1st value and physical SIM as 2nd one.

This is expected behavior. When enumerating dictionary entries, the order is not only meaningless but it’s actually random across separate runs of the program.

And (noting this for completeness) there’s no significance to the actual strings used as keys in the serviceSubscriberCellularProviders dictionary. The next release could change them to "Jobs" and "Wozniak" and still be perfectly compliant with the published documentation.

So there’s truly nothing in the documented API that can tell you the difference between an eSIM and a nano-SIM.

is there approximate pointers to when CTCarrier will become actively deprecated and start to return --/65535.

As far as I know nothing has been announced.

Will there be an alternative available to CTCarrier for carriers when that happens?

If you’re working for a carrier, you should raise this concern via your carrier’s contacts at Apple.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

But note the existing CTCarrier functionality is critical to certain regular apps, specifically the kind that let you test your network speed. In return for giving you a speed result, often they collect your MCC/MNC and location, and use this data (aggregated and anonymized) on the back end to drive analytics, maps, reports, maybe sell it to interested parties such as carriers or cell tower companies. Often there’s an Android counterpart that can collect even more telephony data such as signal strength. (I used to work on such an app, but I don’t any more.)

Developers of such apps should submit feedback to plead for keeping the CTCarrier information available in some way. Here some are solutions I can think of:

• Make it available via a hard-to-get entitlement, as is now the case with the user-assigned device name.
• Tie it to the existing location authorization, as is now required to access Wi-Fi network information.
• Add a new authorization API (with system-provided alert, app-supplied purpose string, etc.) as in various other privacy-sensitive areas.
• Don’t actually remove the deprecated CTCarrier functionality.

Developers of such apps should submit feedback to plead for keeping the CTCarrier information available in some way.

Well, I dunno about the “plead” bit (-: but, yes, I wholeheartedly agree with this sentiment. One of the goals of a deprecation like this is to flush out the valid use cases.

If you do file a bug about this, please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"