“Apple Acknowledges Bug Impacting Users”
![86A889B7-48EA-4D49-A716-44CE832502E3.jpeg]( "86A889B7-48EA-4D49-A716-44CE832502E3.jpeg")
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Acknowledges 'SIM Not Supported' Bug Impacting iPhone 14 Users
- Thread starter MacRumors
- Start date
- Sort by reaction score
Neither does WFH, but there you go.
It’s more that people rubbishing iOs like the release is a form of Armageddon.
What is thisAnd when we look at the alternative phone system, we see sooooo many more bugs
Google Issue Tracker
issuetracker.google.com
No one needs to file a class action here. But your apologist excuses are weak and thin. This sort of bug would NEVER have passed internal testing on any mobile device.
The fact they are “investigating the issue” means they don’t know what the heck is causing it. And the fact they acknowledged it publicly means enough users are affected that they need to do basic PR damage control.
Apple needs to get off their rear ends and fix their internal testing processes. Period end of story and please stop with the excuses.
Unless you’re an Apple Internal Tester and violating your corporate NDA then no you aren’t an actual beta tester. The OP is talking about Apple’s Internal Beta testers. Also known as QA Engineers or QA Testers.
This could also fall into the hands of Carrier’s Internal Testers but that process is really dicey and varies greatly from carrier to carrier so I would be utterly shocked to see Apple relying heavily on that. Though this sort of bug makes me think that they’re entirely asleep at the wheel on some areas of testing.
No matter how many bugs there are, there will always be people making excuses for Apple and saying "there will always be bugs," "life goes on," "don't be entitled," "first world problems," etc.
But perhaps we can practice what we preach a bit more -- no matter how many anti-Apple comments there are, life will go on. Big deal.
While I don’t agree with the OP on it mattering if the QA team is domestic or foreign… the Designed in California does not mean developed and QAed. It means designed and only designed. Because many many many Apple products for many years have been manufactured in China and Mexico and QA testing would be done in part there and in part in other places (sometimes in California).
It really doesn’t matter where you have your testing as long as your PROCESSES are complete and sufficient to catch these scenarios.
Really? Saying someone has apologist excuses means these bugs automatically go away?
Yes. Apple acknowledges a myriad of issues. They’ll fix it.
No, it means they acknowledged it and will ultimately fix it.
Every single iOS release has had a myriad of issues for the last x years and people say the same thing year after year. Bugs will happen.
Reality, not excuses.
Just like there are people criticizing apple to the ends of the earth S if it’s a heinous crime.
Life will go on. Not a fun bug…at least it doesn’t brick your phone /s
Ok just to put this out there I believe the bug being reported and discussed here is an eSIM related workflow issue.
There is a very real issue that occurs when a user adds an “unsupported eSIM” to a carrier locked eSIM only iPhone.
This can happen if the user is migrating from one carrier to another and purchased a carrier locked device or if they are on a carrier locked device and attempt to add a second eSIM from a competing carrier.
What ends up happening is the Phone OS polls the eSIM to validate radio functions and so on. When it encounters a non-supported eSIM (like one from another carrier on a carrier locked device) then the OS immediately delivers a pop-up notification that the SIM is unsupported.
The user is expected to remove and replace the SIM with a supported SIM or no SIM at all to avoid this message. Dismissing the message without removing or replacing the SIM results in another pop up immediately appearing requiring user interaction and blocking all other phone functions.
The PROBLEM with eSIM only is that the only way to remove an eSIM is through the OS user interface and if that is blocked then it creates this unbreakable logical process loop.
This is an OLD Workflow (mandated by most carriers) and a holdover from the pre-eSIM days. The issue is particularly nasty on carrier locked eSIM only phones because just adding a non-supported eSIM created an unbreakable loop that even a full device wipe cannot reliably solve.
(Depending on what options are chosen during the wipe the phone may or may not wipe eSIM data.)
So what they’re likely doing at the Apple Store is bypassing this lock restriction temporarily using some engineering software tools.
I haven’t personally experienced this bug as I have yet to receive my eSIM only carrier locked phone. (On Verizon)
Thankfully this will be a non-issue for most carriers that unlock their devices after 60 days but that process is extremely variable from one carrier to the next and some don’t do it automatically and the potential for users exploring what is possible with their devices are too great to assure someone won’t for what ever reason run into this boot loop problem.
This problem frankly sucks is an unnecessary workflow roadblock and they should just change this function by making it a notification, blocking radio functions and then allowing the user to remove unsupported eSIMs manually.
Or god forbid they should just STOP CARRIER LOCKING DEVICES!!!!!!!!!!
This archaic process has so many work arounds for extremely cheap from so many third parties it’s a tedious and useless gesture. But most non-technical users won’t have a clue how to even begin to approach this issue.
And yeah this issue has been reported on Reddit and I believe in a few low traffic YouTube channels.
It’s an embarrassing flaw and a major oversight in QA testing. This workflow issue would have been caught and dealt with pre-developer or public beta of an iOS revision on eSIM only devices.
But it’s such an old function that they probably just assumed there would be no issues with this change and didn’t even bother to examine the scenario.
Sad, just truly sad.
There is a very real issue that occurs when a user adds an “unsupported eSIM” to a carrier locked eSIM only iPhone.
This can happen if the user is migrating from one carrier to another and purchased a carrier locked device or if they are on a carrier locked device and attempt to add a second eSIM from a competing carrier.
What ends up happening is the Phone OS polls the eSIM to validate radio functions and so on. When it encounters a non-supported eSIM (like one from another carrier on a carrier locked device) then the OS immediately delivers a pop-up notification that the SIM is unsupported.
The user is expected to remove and replace the SIM with a supported SIM or no SIM at all to avoid this message. Dismissing the message without removing or replacing the SIM results in another pop up immediately appearing requiring user interaction and blocking all other phone functions.
The PROBLEM with eSIM only is that the only way to remove an eSIM is through the OS user interface and if that is blocked then it creates this unbreakable logical process loop.
This is an OLD Workflow (mandated by most carriers) and a holdover from the pre-eSIM days. The issue is particularly nasty on carrier locked eSIM only phones because just adding a non-supported eSIM created an unbreakable loop that even a full device wipe cannot reliably solve.
(Depending on what options are chosen during the wipe the phone may or may not wipe eSIM data.)
So what they’re likely doing at the Apple Store is bypassing this lock restriction temporarily using some engineering software tools.
I haven’t personally experienced this bug as I have yet to receive my eSIM only carrier locked phone. (On Verizon)
Thankfully this will be a non-issue for most carriers that unlock their devices after 60 days but that process is extremely variable from one carrier to the next and some don’t do it automatically and the potential for users exploring what is possible with their devices are too great to assure someone won’t for what ever reason run into this boot loop problem.
This problem frankly sucks is an unnecessary workflow roadblock and they should just change this function by making it a notification, blocking radio functions and then allowing the user to remove unsupported eSIMs manually.
Or god forbid they should just STOP CARRIER LOCKING DEVICES!!!!!!!!!!
This archaic process has so many work arounds for extremely cheap from so many third parties it’s a tedious and useless gesture. But most non-technical users won’t have a clue how to even begin to approach this issue.
And yeah this issue has been reported on Reddit and I believe in a few low traffic YouTube channels.
It’s an embarrassing flaw and a major oversight in QA testing. This workflow issue would have been caught and dealt with pre-developer or public beta of an iOS revision on eSIM only devices.
But it’s such an old function that they probably just assumed there would be no issues with this change and didn’t even bother to examine the scenario.
Sad, just truly sad.
I blame the Lightning port. Could've avoided this with a switch to USB-C/Thunderbolt. 🤭
Please…. If you’re referring to “Antenna Gate” it was such an easy thing to work around. Case or just adjust holding position of phone and problem is solved. Was it a design oversight? Yes. It was. And they resolved it in the next generation of devices. They handled the problem well with offering everyone a free case.
But this issue is in my opinion more embarrassing as it’s a very likely scenario with dual SIM users which are a rapidly growing population of users. Let alone the obvious carrier switching users.
it’s not embarrassing. If as you say it’s an odd workflow issue, it’s a classic case of too many cooks in the broth. But it causes unnecessary trips to the Apple Store.
There are many things in the world that are truly sad. This isn’t one of them.
No. I think they need a full size female USB-A port with a dongle to attach to the USB-C charger. That would be much more Apple of them to address USB-C.
Personally I like the process of using my 30 PIN to Lighting dongle to then go from Lighting to USB C using a cable. Really miss that svelt 30 pin dock connector. LOL
I said OLD workflow not odd. Meaning this workflow should have been changed YEARS AGO. It’s a tedious workflow loop that ONLY is resolved by removing an unSupported SIM. Which can only be done easily in a physical SIM scenario.
This problem was also occurring with the 13 and eSIM only activations. It was just happening in far lower volume because most users were still getting a physical SIM as their primary.
The issue should have been properly examined in workflow simulations. (If they bothered to test this scenario.). With they clearly don’t because the development process is rushed to meet deadlines and so on.
They need to take a deep breath, revise QA testing and start THINKING.
Personally I find that most managers slow down productivity rather than improve it.
GEE! It's almost as if making the phone eSIM only in the US while the rest of the world still has a physical sim slot for their iPhone 14s was a bad idea or something.