Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
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.
If it was Microsoft, Google, Facebook, etc. most of those same people defending Apple now would be trashing everything those companies do as garbage.
 
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.

Why are you even COMMENTING on this topic? You offer NO VALUE to this conversation.

You aren’t talking about the issue and you aren’t offering any work arounds.

If you want to start a Church of Apple go and preach to your flock about “hoping and praying” and “trusting in the Gods at Apple” to fix it somewhere else.

Your comments are just as valueless as the sort of platitudes that priests offer to the bereaved. This is a fixable scenario and telling people to just ignore the issue and wait for fixes is stupid and irresponsible.

Nothing ever gets solved by just ignoring an issue. Hence why this OLD OLD OLD workflow roadblock has gone from an annoyance to a problem.
 
Last edited:
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.
“You’re holding it wrong” is a classic case. As these systems get more complex and more hands are in the pot “proper” testing becomes more difficult.

I’m happy to see psim go. This push with the iPhone 14 by apple will help. Eventually this will all be ironed out.
 
Why are you even COMMENTING on this topic? You offer NO VALUE to this conversation.

You aren’t talking about the issue and you aren’t offering any work arounds.

If you want to start a Church of Apple go and preach to your flock about “hoping and praying” and “trusting in the Gods at Apple” to fix it somewhere else.

Your comments are just as valueless the sort of platitudes that priests offer to the bereaved. This is a fixable scenario and rather than telling people to just ignore the issue and wait for fixes is stupid and irresponsible.

Nothing ever gets solved by just ignoring an issue. Hence why this OLD OLD OLD workflow roadblock has gone from an annoyance to a problem.
Not sure what value your comments are adding either. They are hyperbolic and over the top. So here we are.

It’s a friggin’ bug, that’s all it is. Not the end of the world. More faux outrage is not needed.
 
  • Like
Reactions: LinusR and Malbrute
yeah, I don't quite understand this either -- if it's a software issue, I'd think it would be easier just to wait until a software fix is release. Don't get going to the Apple Store for help. (especially since I don't have one nearby).

Is this some sort of problem with phones worldwide? Or just with those USA e-SIM only phones?

I would be willing to bet this is US-Only Plastic Block SIM models.
 
...ios 16 is turning iphones act like android. slow and wayyy buggy.
Android user here. Just curious what "bugs" and "slowness" you have experienced? Because honestly, I think you are talking out your rear. Now maybe if you said, "in the early years of android" or "any recent Oneplus phone with their terrible skin", but as far as Pixel and Samsung go (which are the majority of the android market here in the US), ive never come across any bugs. And as far as "slowness" is concerned, i find it laughable considering the non pro iphone 14 are still using 60 hrtz screens. Even Samsungs "budget friendly" A-series are using 120 hrtz as a standard now.
 
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.
To be fair…. I like the idea. Just need to make sure execution is free of these sorts of totally avoidable and obvious scenarios.

Or at the very least provide clear instruction on proper use and warnings. Like the “don’t stick a fork or your finger in the light socket.” Cause there will be people who do and then will blame whom ever for their experience doing that. LOL

But that is exactly the sort of thing that a properly enabled QA engineer or architect is expected to consider.

You should be trying to break the phone with practical and even hypothetical scenarios.

Sorry but I started my career as a QA auditor and process designer so this is a subject that is near and dear to my heart. LOL
 
I've submitted dozens of bug reports as a beta tester and never heard back. Not even a "this is a duplicate of bug #xxxx". Nothing. Dead silence.

I'm convinced nobody is reading our bug reports.
It all gets dumped into a ticket queue and is then reviewed and prioritized in the background. If you’re a developer and reporting a development / program execution bug then you will more often see some sort of response. But I don’t think they have the staffing to address the volume of reports received from Public beta testing.

I agree it’s not an ideal user experience but to be fair IDK that there could be cost efficient approach to handling every bug report personally. But even a canned response would be a great start.

And yeah I think their prioritization process could use improvement. (But I could say that about every single manufacturer’s processes.)

This particular issue is just infuriating since it’s a workflow roadblock that’s been there since the early days of iOS.
 
Apple says it's "investigating" the issue and notes it's not a hardware problem, adding that customers should keep their software up to date.

Isn't keeping your software up-to-date the root of the problem though? iOS 16 sucks.

Too bad iPhone 14 can't run iOS 15
 
  • Love
Reactions: arkitect
So it doesn't know it doesn't ahve the ability to use a real SIM chip? Is it choking on the eSIM?

Wow...

Come on Apple, you used to be so much better. Wow...

Yeah. The workflow is the same regardless if it’s eSIM or physical SIM. Which is the scenario specific problem.

But if they would just make this a notification that appears once and simply disabled radio functions until the sim is removed (physically or digitally) then the problem would be solved with an obvious user driven workaround or workflow.
 
This does concern me not because I don’t expect bugs but because some of us don’t live near or aren’t able to get to an Apple Store or reseller. Not good for such people to have that as the only given solution!

Yeah, a physician or lawyer can't just drop everything and rush to the Apple Store. They *might* have staff that could do it, but hospitals are already having major staffing issues, so imagine having to be without your right hand device because of a stupid bug and have no way to get it fixed and you rely on that device like it's your secretary.

Are bugs like this going to push more people to alternatives? I think yes. The closest service provider is the Jerk Squad, with the 'nearest Apple Store' over an hour away, closer to two hours with busy traffic.

Now the depressing question: How many more bugs are just not being reported on yet. I haven't heard of this bug yet. Come on Apple, you used to be better than this.
 
Last edited:
If it's a software bug and not hardware then just how exactly is going to an Apple store or ASP going to get the 'issue resolved'. If there is a workaround then why doesn't Apple disclose it instead of asking affected owners to go to an Apple store or a ASP.
Submitting an RTA and having Engineering tell you, “keep your device up to date,” is solving the problem, because the contact with Apple Support is able to be marked as “resolved,” thus keeping their completion numbers up. It isn’t about actually solving problems but ensuring their metrics are good.
 
Not sure what value your comments are adding either. They are hyperbolic and over the top. So here we are.

It’s a friggin’ bug, that’s all it is. Not the end of the world. More faux outrage is not needed.
It’s NOT A BUG. It’s a workflow design oversight.

Everything is functioning exactly as it was designed to. Nothing is breaking.

The workflow is poor and the design is lacking. Very simple. A bug is when something doesn’t work AS EXPECTED OR DESIGNED.

This was “unanticipated” and an embarrassing user interface design flaw. Period. (FYI. I’ve intercepted and worked with development teams to correct flaws like these countless times in my career at many different hardware and software companies. So I am not picking a bone with Apple. It’s just an embarrassing flaw regardless who’s brand is associated with it.)

It is a problem and people need to know they should NOT attempt to add an alternate carrier eSIM to a carrier locked device or their device will go into an endless process loop requiring a visit to the Apple Store to get it resolved!!!

Nothing hyperbolic here. (Unlike the valueless hot air you insist on spewing into this discussion.)
 
  • Like
Reactions: arkitect
Yeah. The workflow is the same regardless if it’s eSIM or physical SIM. Which is the scenario specific problem.

But if they would just make this a notification that appears once and simply disabled radio functions until the sim is removed (physically or digitally) then the problem would be solved with an obvious user driven workaround or workflow.

But it *shouldn't* be happening! I *did* have a message similar to that years ago, took it to the AT&T store, they just popped it out, wiped it off, put it back in, no more problems. I was shocked. Apparently those electrons needed a clean room to play in. Maybe if they cleaned up after themselves a little.

But seriously, you can't just pop out an eSIM, and on those iPhones (unless purchased out of country) CAN'T have a real SIM for even a backup!

So is the rule here to buy your iPhone from Canada, or Mexico, or some place that DOES support physical SIM cards?
 
  • Like
Reactions: brgjoe and arkitect
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.

Outstanding explanation. Adds a lot to the thread. Thanks.
 
...
What I honestly can’t get in my head is that it’s potentially a cultural issue. In the UK and EU we don’t have the same poor treatment of employees as is found across most of NA.
...
Give it time, at least in the UK as everything tanks.
 
  • Love
Reactions: arkitect
It all gets dumped into a ticket queue and is then reviewed and prioritized in the background. If you’re a developer and reporting a development / program execution bug then you will more often see some sort of response. But I don’t think they have the staffing to address the volume of reports received from Public beta testing.

I agree it’s not an ideal user experience but to be fair IDK that there could be cost efficient approach to handling every bug report personally. But even a canned response would be a great start.

And yeah I think their prioritization process could use improvement. (But I could say that about every single manufacturer’s processes.)

This particular issue is just infuriating since it’s a workflow roadblock that’s been there since the early days of iOS.

I can only I imagine how many garbage tickets are reported by public beta testers. I bet they have a completely seperate issue tracker for these comments.
 
iOS 16 is great. Works flawlessly on my iPhone 14 PM. There are clearly two different classes of experiences with iOS 16. Same as every other release.
You’re posts are honestly utterly a total waste of space and time here.

No one cares that it’s working for you. Go call Apple and tell them you love them and have them praise you and thank you for your business.

This thread is about an issue that is being reported and acknowledged. The assumption is if you aren’t reporting the problem then you aren’t encountering it. Nothing to discuss.

Also no one is talking about iOS 16. This is a workflow issue that has been there since the Beginning of iOS. Version 1.0 behaved the same way.

But the move to eSIM only is when this suddenly became a problem that the user cannot work around.
 
  • Like
Reactions: brgjoe and arkitect
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.