Apple releases updated iOS 9.3 to fix Activation Lock bug on older devices

AppleInsider

Apple on Monday pushed out yet another new build of its iOS 9.3 mobile operating system, attempting to fix issues related to an Activation Lock bug that presented itself on older iPhones and iPads.

Still identified as iOS 9.3, the new update is distinguished with a new build number, 13E237. Users who have been stuck on the Activation Lock screen since last week may need to restore their device via iTunes to upgrade to the new version and address the issue.

Apple stopped signing the previous, broken version of iOS 9.3 for older devices last week. The problem occurred in the password authorization phase of the iOS 9.3 setup process.

Apple confirmed that the problem affected iPhone 5s and earlier and iPad Air and earlier. AppleInsider was first to report on the issue, noting that certain device owners were unable to proceed past the password authentication stage after updating to iOS 9.3.

Some users found success in downloading iOS 9.3 through iTunes on a Mac and installing the firmware via a hardwired connection, suggesting there is an underlying issue on Apple's end. Others have found a full system restore also works, though the method is hit-or-miss.

A different iOS 9.3 build, 13E236, was released specifically for the iPad 2 last week to address the authentication issue as well.

Apple has also published a support document offering workaround suggestions. The company urges affected users to reset their password through iCloud, perform an iTunes-based installation and activation, or remove Activation Lock through iCloud.com. As reported on Tuesday, those who tried these methods have found limited success.

iOS 9.3 still has another significant, unrelated bug that causes apps to crash and freeze when attempting to open hyperlinks in Safari, Mail, and Messages, as well as third-party Web browsers like Google Chrome. The issue is apparently unpatched in the new iOS 9.3 update, and affects all devices, not just older ones.

rogifan_new

With all the betas 9.3 had how are there so many bugs right out of the gate?

melgross

This shows just how hard it is to do updates. With all of the time Apple spent on this one, and with all the developer betas that went out, including the many thousands of people on the beta program, apparently not one had this problem, which appeared instantly after the update went out to everyone.

yoyo2222

Of course there's a new problem (affecting my wife's plain vanilla iPad Air) with Safari locking up if a link is clicked in any search engine results page. See https://discussions.apple.com/thread/7505840?start=0&tstart=0 It doesn't affect Chrome.

As someone else noted above , what is the public beta program for if not to catch stuff like this? I have been an Apple advocate for years, and I own their stock, but I'm afraid someone is letting the ball drop with these updates. This problem is not one of a near obsolete iPad 2 with activation problems. This is an issue affecting their browser on their current (or near current) hardware.

lkrupp

melgross said:

This shows just how hard it is to do updates. With all of the time Apple spent on this one, and with all the developer betas that went out, including the many thousands of people on the beta program, apparently not one had this problem, which appeared instantly after the update went out to everyone.

While working as a central office technician for AT&T part of my job was to apply patches to the operating software of the digital telephone switch. You’d think connecting two subscribers together so they can talk to each other is a simple matter and you’d be wrong. Patches came in almost every day from the manufacturer, Nortel. Before digital switches there were electromechanical switches that we got physical rewiring orders for from Western Electric engineering. We literally rewired certain parts of the switch to fix issues. (yes, I’m that old). It was common knowledge that the best way to test a release was to make it live and let realtime live traffic hit the switch. Daily patch routines continue to this day. People who make critical statements about quality assurance simply don’t understand how complex software can be. For example Unix is how old now but flaws are still being found by security researchers. People also don’t remember the past very well when they long for the good old days when everything “just worked.” Nonsense, things never just worked. Remember OS 9 and the days of troubleshooting software conflicts? Remember Conflict Catcher? That outfit made millions with that app. Remember the OS release that disabled third party DRAM that didn’t meet Apple’s strict requirements. The wailing over that one was deafening. So deal with it people and stop your nonsensical caterwauling about QA. Just because you read it on the Internet doesn’t mean it’s true.

happilyretired

Seems to me you're good updating devices until they're about 1 1/2 or maybe 2 years old. You keep updating them beyond that and the problems start creeping in. If you want the newest capabilities of the OS then after a certain point you just have to upgrade the DEVICE, not the software. Or be happy with what you have and leave it alone.

volcan

happilyretired said:

Seems to me you're good updating devices until they're about 1 1/2 or maybe 2 years old. You keep updating them beyond that and the problems start creeping in. If you want the newest capabilities of the OS then after a certain point you just have to upgrade the DEVICE, not the software. Or be happy with what you have and leave it alone.

Whether or not to provide updates for a device is completely Apple's decision. Adding support for older devices is both a marketing differentiation as well as a security issue. Apple knows how many older devices are in current use. If they decide to continue supporting them, they need to issue well tested compatible software and/or choose to omit certain features.

I suspect that many devs do not support older hardware as much as Apple does, thus they don't test the betas on older hardware. This is all up to Apple. If an individual chooses not to apply the update, they may be subjecting themselves to security risks, but it is their decision. When Apple drops support, you should definitely consider updating your hardware. As it is they are still supporting 4 year old iPad 2 so there is a reasonable expectation that it should work as advertised.

fallenjt

rogifan_new said:

With all the betas 9.3 had how are there so many bugs right out of the gate?

Look like some people in software QA won't get bonus this year.

happilyretired

volcan said:

happilyretired said:

Seems to me you're good updating devices until they're about 1 1/2 or maybe 2 years old. You keep updating them beyond that and the problems start creeping in. If you want the newest capabilities of the OS then after a certain point you just have to upgrade the DEVICE, not the software. Or be happy with what you have and leave it alone.

Whether or not to provide updates for a device is completely Apple's decision. Adding support for older devices is both a marketing differentiation as well as a security issue. Apple knows how many older devices are in current use. If they decide to continue supporting them, they need to issue well tested compatible software and/or choose to omit certain features.

I suspect that many devs do not support older hardware as much as Apple does, thus they don't test the betas on older hardware. This is all up to Apple. If an individual chooses not to apply the update, they may be subjecting themselves to security risks, but it is their decision. When Apple drops support, you should definitely consider updating your hardware. As it is they are still supporting 4 year old iPad 2 so there is a reasonable expectation that it should work as advertised.

Maybe then the best solution would be to institute an update system, that allows you to back up a mobile device to a computer and absolutely, completely save that version of the iOS before installing an update. Then, if there is a serious problem with an older device, enable the user to GO BACK to the previous version. At least temporarily. That's always what bugs me the most. The inability to go back to an older system. Which is why I hate that you no longer can get the OS for your Mac on disk. You can't even buy a newer version on disk. It's all downloads only and no provision to go back if so desired. I'd rather pay for a new OS on disk, so I have the option to do whatever I need or want to do than getting a new OS for free and be stuck with it after an update.

wonkothesane

Upfront: I do realise that bugs are a reality and that they will be for a foreseeable future. 

Now, stories like this one, or recently on the MacOS side related to wifi still do make me wonder to what extend any bigger software project is just a clusterf**k of code with basically no chance of catching everything and why is it like this? Last time I wrote somewhat serious code was when turbo pascal and c were fashion, so please bear with me here for a sec. 

A mechanical system has basically all analogue interfaces through the components physical properties/dimensions, and therefore basically an infinite number of states to be theoretically checked. 

in contrast, software is (usually) not "fuzzy" and comes with a finite state space. What makes it so hard to make bullet proof bug free software then? 
Or, over decades, why has - let's call it - insufficiently tested code not been replaced over time and piece by piece with "100%" sound code? 

Is it a question of effort versus quality and some pareto that would increase costs by a multifilament just to catch the last few bugs?

Or, is there a a fundamental and proven law/theorem that any code by force contains what we consider as bugs?

Maybe some of you professional software developers can provide some insight. 

winston2010

Still can't update 9.3, bricked my wife's iPad mini 2. Interestingly my iPad mini 2 updated last week without any problem. The only difference were that I had 32 gb black while my wife's was 16 GB white.

volcan

happilyretired said:

Which is why I hate that you no longer can get the OS for your Mac on disk. You can't even buy a newer version on disk. It's all downloads only and no provision to go back if so desired. I'd rather pay for a new OS on disk, so I have the option to do whatever I need or want to do than getting a new OS for free and be stuck with it after an update.

There is a recovery partition. I haven't had to fiddle with it for some time, but I made a bootable flash drive of Lion for a friend because there was no official install media but that was the last OS version her MBP was able to run and I wanted her to have a backup. You can search online for instructions. If you are an Apple Developer, there is a place to download old versions but you cannot install any version older than the one that originally came with your mac or in my friend's case newer than the last version that the computer could run.


As far as iOS is concerned you can thank jail breakers for the unsigning of older iOS versions.

greybeard

Finally updated my iPad mini2. It was the same like updating iPhone 5S. No difference.

yoyo2222

winston2010 said:

Still can't update 9.3, bricked my wife's iPad mini 2. Interestingly my iPad mini 2 updated last week without any problem. The only difference were that I had 32 gb black while my wife's was 16 GB white.

I read elsewhere that it was the GSM iPad-2 that were affected by the activation lock problem. Might that be the difference between your iPads?

yoyo2222

happilyretired said:

Seems to me you're good updating devices until they're about 1 1/2 or maybe 2 years old. You keep updating them beyond that and the problems start creeping in. If you want the newest capabilities of the OS then after a certain point you just have to upgrade the DEVICE, not the software. Or be happy with what you have and leave it alone.

It's not just the new capabilities. At some point your iOS device will conveniently download a large update file taking up space on your device and show a nagging red dot on your System Preferences icon.

This is all well and good until the update cripples the device. Then this information trickles out into the general media and all of a sudden Apple doesn't look so shiny. At some point this results in a hit in sales/profits.

mnbob1

wonkothesane said:

Upfront: I do realise that bugs are a reality and that they will be for a foreseeable future. 

Now, stories like this one, or recently on the MacOS side related to wifi still do make me wonder to what extend any bigger software project is just a clusterf**k of code with basically no chance of catching everything and why is it like this? Last time I wrote somewhat serious code was when turbo pascal and c were fashion, so please bear with me here for a sec. 

A mechanical system has basically all analogue interfaces through the components physical properties/dimensions, and therefore basically an infinite number of states to be theoretically checked. 

in contrast, software is (usually) not "fuzzy" and comes with a finite state space. What makes it so hard to make bullet proof bug free software then? 
Or, over decades, why has - let's call it - insufficiently tested code not been replaced over time and piece by piece with "100%" sound code? 

Is it a question of effort versus quality and some pareto that would increase costs by a multifilament just to catch the last few bugs?

Or, is there a a fundamental and proven law/theorem that any code by force contains what we consider as bugs?

Maybe some of you professional software developers can provide some insight. 

The hardware components in this case along with the 3rd party applications and system settings make this a very complex issue as far as system updates. Apple has created an OS update that can be done OTA. This makes it fast and easy for the end user but much more complex in designing the correct downloads for each device. The problem could probably be solved by requiring the user to connect their device to a computer and using iTunes to back it up, erase it and then restore it. That's how we did it in the early days of iOS. Who wants to go back there?  Bugs happen. I don't know of any software that doesn't have them. I was a public beta tester with my iPad mini and iPhone 6 Plus. I never encountered this problem and reading the article it appears that it wasn't present on all older iPads. The other thing we need to remember is that as a product goes through its manufacturing life stage changes can be made to circuit boards and components on a frequent basis. Although it shouldn't make a difference to the OS it's just another unknown. I have respected Apple for their hard work in keeping devices updated and secure. I have owned an iPhone since it was just named "iPhone". 

foggyhill

happilyretired said:

volcan said:

Whether or not to provide updates for a device is completely Apple's decision. Adding support for older devices is both a marketing differentiation as well as a security issue. Apple knows how many older devices are in current use. If they decide to continue supporting them, they need to issue well tested compatible software and/or choose to omit certain features.

I suspect that many devs do not support older hardware as much as Apple does, thus they don't test the betas on older hardware. This is all up to Apple. If an individual chooses not to apply the update, they may be subjecting themselves to security risks, but it is their decision. When Apple drops support, you should definitely consider updating your hardware. As it is they are still supporting 4 year old iPad 2 so there is a reasonable expectation that it should work as advertised.

Maybe then the best solution would be to institute an update system, that allows you to back up a mobile device to a computer and absolutely, completely save that version of the iOS before installing an update. Then, if there is a serious problem with an older device, enable the user to GO BACK to the previous version. At least temporarily. That's always what bugs me the most. The inability to go back to an older system. Which is why I hate that you no longer can get the OS for your Mac on disk. You can't even buy a newer version on disk. It's all downloads only and no provision to go back if so desired. I'd rather pay for a new OS on disk, so I have the option to do whatever I need or want to do than getting a new OS for free and be stuck with it after an update.

Going back could be use to hack into a phone with a open security bug; that's the main reason they don't do it.
They could do it if the phone is completely wiped and thus don't gain anything from going back.

Enabling a backup, going back to a old buggy release and then putting the data back would be a good way to crap phones if it was allowed; It is not.

foggyhill

wonkothesane said:

Upfront: I do realise that bugs are a reality and that they will be for a foreseeable future. 

Now, stories like this one, or recently on the MacOS side related to wifi still do make me wonder to what extend any bigger software project is just a clusterf**k of code with basically no chance of catching everything and why is it like this? Last time I wrote somewhat serious code was when turbo pascal and c were fashion, so please bear with me here for a sec. 

A mechanical system has basically all analogue interfaces through the components physical properties/dimensions, and therefore basically an infinite number of states to be theoretically checked. 

in contrast, software is (usually) not "fuzzy" and comes with a finite state space. What makes it so hard to make bullet proof bug free software then? 
Or, over decades, why has - let's call it - insufficiently tested code not been replaced over time and piece by piece with "100%" sound code? 

Is it a question of effort versus quality and some pareto that would increase costs by a multifilament just to catch the last few bugs?

Or, is there a a fundamental and proven law/theorem that any code by force contains what we consider as bugs?

Maybe some of you professional software developers can provide some insight. 

Actually, the "finite state space" is nearly infinite when you consider all the code paths and the interaction with the outside. You try to break down the code it little blocks which can be tested individually and in theory when you reassemble thing they will still work. You take a few of those blocks, build something bigger, provide tests, build something bigger from those things, text, etc.

But, those tests often cannot really run on end devices, for practical reasons. It's when they get out of their neat little sandbox that the fun really occurs.
Testing also fail because people that build software fail in imagining how people could actually use it badly, or not in the way devised to provide the service they programmed.

Good QA should probably be paid more because breaking software in a non obvious way often takes more work than to create it.

Just imagine the immense variants that come from simply what the user can do in settings!

When you reach real devices, users, the environment, variations in manufacturing, variations in the software on the device, variations in configurations, variations in hardware it connects to and their configutration (routers, telecom switches, carriers, bluetooth devices), variation in the configuration of other Apple device it must coordinate its services with and their own bug. Timing issues, heat issues, resource issues, race conditions, silent bugs (bugs that only occur when you set out to make them happen, like someone trying to overflow a buffer). Then there's the whole interacting with external services in a speedy and secure way.

Often, bugs, especially security ones, work in chains, one bug enabling another.

Considering how complex modern operating systems are, it is a miracle that they are not more buggy.

wonkothesane

mnbob1 said:

wonkothesane said:

Upfront: I do realise that bugs are a reality and that they will be for a foreseeable future. 

Now, stories like this one, or recently on the MacOS side related to wifi still do make me wonder to what extend any bigger software project is just a clusterf**k of code with basically no chance of catching everything and why is it like this? Last time I wrote somewhat serious code was when turbo pascal and c were fashion, so please bear with me here for a sec. 

A mechanical system has basically all analogue interfaces through the components physical properties/dimensions, and therefore basically an infinite number of states to be theoretically checked. 

in contrast, software is (usually) not "fuzzy" and comes with a finite state space. What makes it so hard to make bullet proof bug free software then? 
Or, over decades, why has - let's call it - insufficiently tested code not been replaced over time and piece by piece with "100%" sound code? 

Is it a question of effort versus quality and some pareto that would increase costs by a multifilament just to catch the last few bugs?

Or, is there a a fundamental and proven law/theorem that any code by force contains what we consider as bugs?

Maybe some of you professional software developers can provide some insight. 

The hardware components in this case along with the 3rd party applications and system settings make this a very complex issue as far as system updates. Apple has created an OS update that can be done OTA. This makes it fast and easy for the end user but much more complex in designing the correct downloads for each device. The problem could probably be solved by requiring the user to connect their device to a computer and using iTunes to back it up, erase it and then restore it. That's how we did it in the early days of iOS. Who wants to go back there?  Bugs happen. I don't know of any software that doesn't have them. I was a public beta tester with my iPad mini and iPhone 6 Plus. I never encountered this problem and reading the article it appears that it wasn't present on all older iPads. The other thing we need to remember is that as a product goes through its manufacturing life stage changes can be made to circuit boards and components on a frequent basis. Although it shouldn't make a difference to the OS it's just another unknown. I have respected Apple for their hard work in keeping devices updated and secure. I have owned an iPhone since it was just named "iPhone". 

So we share a few things. Also I do respect Apple, own iPhone since the first gen, have done beta testing etc. 

I am also not denying that it's a complex issue. By far not. 

The point I am asking about is on a generic level, independent of Apple and the current issue. 

I m perfectly aware that "all software has bugs". The question is why? Is it inevitable? If yes, because of an economic decision that you put a natural limit to the testing resources? Or because from a system theory POV there cannot be bug free software?

I guess, I am more on Apple's side than many, and I realise that bugs do happen. And that they do happen even after n beta releases. I'm not denying or belittling their effort, or the effort of any decent software developer. And for sure I'm not belonging to a group of people shouting out loud "what a poor QS they have! again more proof of their decaying quality blablabla". 



I simply like to understand. 

wonkothesane

foggyhill said:

wonkothesane said:

Upfront: I do realise that bugs are a reality and that they will be for a foreseeable future. 

Now, stories like this one, or recently on the MacOS side related to wifi still do make me wonder to what extend any bigger software project is just a clusterf**k of code with basically no chance of catching everything and why is it like this? Last time I wrote somewhat serious code was when turbo pascal and c were fashion, so please bear with me here for a sec. 

A mechanical system has basically all analogue interfaces through the components physical properties/dimensions, and therefore basically an infinite number of states to be theoretically checked. 

in contrast, software is (usually) not "fuzzy" and comes with a finite state space. What makes it so hard to make bullet proof bug free software then? 
Or, over decades, why has - let's call it - insufficiently tested code not been replaced over time and piece by piece with "100%" sound code? 

Is it a question of effort versus quality and some pareto that would increase costs by a multifilament just to catch the last few bugs?

Or, is there a a fundamental and proven law/theorem that any code by force contains what we consider as bugs?

Maybe some of you professional software developers can provide some insight. 

Actually, the "finite state space" is nearly infinite when you consider all the code paths and the interaction with the outside. You try to break down the code it little blocks which can be tested individually and in theory when you reassemble thing they will still work. You take a few of those blocks, build something bigger, provide tests, build something bigger from those things, text, etc.

But, those tests often cannot really run on end devices, for practical reasons. It's when they get out of their neat little sandbox that the fun really occurs.
Testing also fail because people that build software fail in imagining how people could actually use it badly, or not in the way devised to provide the service they programmed.

Good QA should probably be paid more because breaking software in a non obvious way often takes more work than to create it.

Just imagine the immense variants that come from simply what the user can do in settings!

When you reach real devices, users, the environment, variations in manufacturing, variations in the software on the device, variations in configurations, variations in hardware it connects to and their configutration (routers, telecom switches, carriers, bluetooth devices), variation in the configuration of other Apple device it must coordinate its services with and their own bug. Timing issues, heat issues, resource issues, race conditions, silent bugs (bugs that only occur when you set out to make them happen, like someone trying to overflow a buffer). Then there's the whole interacting with external services in a speedy and secure way.

Often, bugs, especially security ones, work in chains, one bug enabling another.

Considering how complex modern operating systems are, it is a miracle that they are not more buggy.

Thanks for the elaborate reply. 

Let me comment on that: I am aware of the complexity that's coming through he countless blocks of interacting code and then hardware plus environment. 

Actially, professionally I am dealing with solving complex technical issues on large scale for again complex products such as automotive and aerospacesuch as product failures leading to recalls, unacceptable scrap rates etc.  

When identifying the root cause for an issue in such a mechanical / electric / mechatronic etc system in most cases it is an oversight in terms of a dimension on a component that was eg not specified correctly. (Less it's stuff actually out of spec) You might consider this a "bug" and it's affecting people usually in a ppm order of magnitude. The fundamental reason behind this is that you cannot possibly test all state space, not even at new part level (I.e. Ignoring wear and tear) in a physical manner. And simulation as well can't cover all, as it is a) a simplification of reality and b) can only check a substance of continuous variables, such as environment temp.  Usually what you do is boundary checks. 

On the software side of things i always feel developers are in a much more comfortable situation as it is a) everything much more black and white. A setting in an iPhone eg is either digital (on or off) or discrete (eg has ten well defined levels) as opposed to let's say a clearance in a bearing which has infinite levels. b) you can test much faster because you simulate all rather than having to manufacture parts. Assemble them and see the result. 

Therefore I always have this idea that - if one really wanted - you can make a 100% test. At least of features where analog parameters such as temperature do not matter. For example the beauty of a software update - when compared to we a car release - is that each and every unit of a product number receives exactly the same bits and bytes (provided the download was successful which should be caught by the verification step). Not almost the same. The very identical same. Compare this to the possible and real physical variations of a specific car engine model. 

And let's take the example of a small code fragment, eg one method of a class. It is supposed to receive input from let's say two variables of a certain type and within a certain range. Then perform a defined action upon both and return an output. You can check all prerequisites beyond doubt can you not? And if they are violated throw an exemption to handle this properly. Therefore, it should be impossible for this small block of code to go haywhere, at least from a technical POV. Now from a functional point of view (not sure I'm using the right terminology here) let's assume the input variables are representing physical dimensions. Therefore you must ensure that the units of receiving code and sending code are the same and avoid such beautiful errors like in that space mission where the whole thing went south because one function expected centimetres but received inches. This should be manageable as well, no? 
Next up I know I'm allocating memory wishing this method. And hey, I am on an old code base or compiler where this specific function is prone to stack overflow. Actually found through bug tracking. Cool. I fix the foundation and never use that old allocation routine again. 

Too simple?


Maybe im wrong and both worlds, the mechanical and the software one, are much closer to each other than I think. 

baconstang

happilyretired said:

Seems to me you're good updating devices until they're about 1 1/2 or maybe 2 years old. You keep updating them beyond that and the problems start creeping in. If you want the newest capabilities of the OS then after a certain point you just have to upgrade the DEVICE, not the software. Or be happy with what you have and leave it alone.

Really?
I just did a successful and uneventful update of my mid'07 iMac.  Originally shipped with 10.4, it is now happily running 10.11.4 at my shop.
I don't think it would be as useful running Snow Leopard these days.
Oh, and I do have a new 5K here at home.