iOS 16 CTCarrier deprecation

AFAICT serviceSubscriberCellularProviders is working as well as it ever did [1]. To understand what’s going on here, you have to look at the previous API, subscriberCellularProvider. That API never returned information about the currently installed SIM. Rather, it returned information about the most recently installed SIM. Consider this sequence:

1. On a device with SIM A installed, print the value. You get SIM A.

2. Eject that SIM and print the value. You still get SIM A.

3. Insert SIM B [2] and print the value. You get SIM B.

From that perspective, the current behaviour of serviceSubscriberCellularProviders kinda makes sense.

Why aren't developers allowed to know whether a SIM is present at all?

What do you plan to do with that info?

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

[1] Modulo the fact that it works in terms of CTCarrier and that’s now restricted.

[2] Assuming that SIM B is from a different carrier. When I say “SIM” in this post I really mean “SIM’s carrier”.

Hi,

We were using serviceSubscriberCellularProviders to display the carrier names of the active services on the phone. Example, one plastic SIM and one eSIM. Is this still possible somehow? Eventually we would like to list inactive service, like disabled eSIMs.

Thanks

to display the carrier names of the active services on the phone.

The real question is: why are you doing that? Is this an app whose whole purpose is to just list the carriers? Can the user act on this information in some way?

If you were writing a clear purpose string for a hypothetical authorization prompt for accessing this information, exactly what would it say?

Thank you for your quick feedback.

We have an app for an operator, and we want to get access to local subscriptions to manage its wallet of subscriptions.

• the user manages a family which can have several SIMs / eSIMs
• we want to differentiate SIMs present on the curent phone to other SIMs
• additionally, we'd like to get all relevant inputs for support

BR

We have an app for an operator

You mean a cellular carrier?

If so, you should escalate this via your carrier’s contact at Apple. Here on DevForums we can only discuss what’s in the public iOS SDK and, as you’ve seen, that’s getting increasingly locked (and it wasn’t that great to begin with :-).

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

Hi,

We are also facing the same issues, we used CTCarrier to identify carrier name, mobile country code (MCC), mobile network code (MNC) so we can modify the look and feel of our application. Is there any alternative API to obtain that information?

A feedback report ticket was created as well: https://feedbackassistant.apple.com/feedback/12184442

Thank you.

Hi.

What should we do if we used mcc and mnc to determine which features we should enable.

We develop authorization library and work with mobile operators. Some operators give us extended functionality. And we checked mcc and mnc to use these extended functions.

And now we’ll loose money.

Lemme repeat my advice from above: If you have a business relationship with a carrier, I recommend that you discuss this with your carrier so that they can discuss it with their contacts at Apple.

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

We're having a VoIP App that is potentially connected to a VoIP server in a different country (over VPN).

We use the CTCarrier mobileCountryCode to route emergency calls based on the users location to the system and not the remote VoIP server (in that other country, where that emergency number might have a totally different meaning).

This change can hurt people.

(still investigating how this deprecation got unnoticed on our side)

We use the CTCarrier mobileCountryCode to route emergency calls based on the users location

But note CTCarrier never guaranteed to give the real location in the first place. It was always the user’s home service provider, not the network they are actually on if roaming outside their home area.

Core Location would be the right way to determine actual location, both before the CTCarrier deprecation and now.

I use the MCC and MNC to map virtual networks to physical networks so I can display cell reception on a map. Having this information means I can enable users to filter the data on the map to show only data for the physical network they are on.

For example, here in the UK, if a user is on Lebara, VOXI, or Talkmobile, it means they are actually using the Vodafone physical network. So for users on any of these networks, my app can show them just the data for that physical network. (That way, they can see where they can get a signal for the network they're actually on.)

Does this mean I need to figure out a different way to map virtual to physical networks?

Thanks!

I added a "suggestion" in Feedback Assistant. Issue number FB12207878.

I wanted to note that libphonenumber-ios previously used CTCarrier.isoCountryCode to infer the country code to use when formatting phone numbers. The helper method was also public API so clients have presumably used it for other use cases too.

When it comes to stubbing this API out, it would probably break far fewer things to stub it with [[NSLocale currentLocale] objectForKey:NSLocaleCountryCode] or at least a real country code rather than the "--" mentioned in the deprecation notice.

We use it for our Emergency Preparedness app to decide what numbers to append to phone calls before sending to the native dialer.

Created bug FB12677611

How are applications expected to comply with FCC regulations, if this information is no longer available in the iOS platform.

47 CFR § 1.7006(b)(1)(iii) "The name of the provider;" and 47 CFR § 1.7006(e)(1)(iii) "A certification that the challenger is a subscriber or authorized user of the provider being challenged;"