If it was Microsoft, Google, Facebook, etc. most of those same people defending Apple now would be trashing everything those companies do as garbage.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.
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.
“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 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.
LOL Agile: We’re addressing that in the next release. HahaAgile: Promise the world. Deliver a half-baked solution.
Not sure what value your comments are adding either. They are hyperbolic and over the top. So here we are.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.
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'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.Well it's very clear Apples current crop of beta testers are hopless because too many bugs are slipping through the system.
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....ios 16 is turning iphones act like android. slow and wayyy buggy.
To be fair…. I like the idea. Just need to make sure execution is free of these sorts of totally avoidable and obvious scenarios.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.
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'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.
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.
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...
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.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
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!
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.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.
It’s NOT A BUG. It’s a workflow design oversight.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.
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.
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.
Give it time, at least in the UK as everything tanks....
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.
...
Outstanding explanation. Adds a lot to the thread. Thanks.
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.
You’re posts are honestly utterly a total waste of space and time here.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.