Initially, I was thinking the same thing. Given how fast the average Apple consumer updates to major iOS releases, I imagine that rolling it out over a point release is actually part of the plan.
Presumably, if something does go wrong on the individual level, the support burden on the genius bars will be lower (since major iOS releases have traditionally come alongside hardware releases), and if a major bug is found, the number of devices affected will also likely be smaller.
It stills feels wrong on a gut level, and semver folks might not be happy with it, but it seems to make some real sense.
edit: Also, if it went out with 11.0, coordinating all the bug fixes for a 11.0.1 would almost definitely take longer than whatever will be in 10.3.1 release, letting any APFS issues get tweaked faster.
Rolling it out first on iOS at all doesn't seem like the right approach.
If I were somehow in charge of it, I imagine I'd want to do it like: 1) ship it as officially supported on the Mac, but off by default. 2) a year or two later, ship it as officially supported on the Mac, on by default, but still allow HFS+ as an option. 3) A year or two after that, if all has gone well, then introduce it into iOS (where presumably it's not reasonable to make it optional).
It's really weird to me that Apple is rolling it out to hundreds of millions of devices all at once, when it's not even a bootable filesystem on any of their platforms yet. Seems like the kind of thing where you'd want to take a more gradual approach.
I get that HFS+ is super old and I see why Apple wants to switch to APFS. But I don't get why they're in such a hurry.
Here's hoping their approach works well, in any case!
The iOS filesystem environment is WAY more controlled than OS X. Updating OS X first would be fewer machines but is the much more difficult task. This would also be one hell of a production test. They obviously think they're ready.
>If I were somehow in charge of it, I imagine I'd want to do it like: 1) ship it as officially supported on the Mac, but off by default. 2) a year or two later, ship it as officially supported on the Mac, on by default, but still allow HFS+ as an option. 3) A year or two after that, if all has gone well, then introduce it into iOS (where presumably it's not reasonable to make it optional
The plan doesn't make much sense. For one, the Mac has way more edge cases than iOS (in that people do more, and in more low- and -high level ways) with the filesystem, including running all kinds of unix userlands, exchanging files with other filesystems, etc. In iOS all fs APIs and access are tightly controlled, and there's no mounting of disks, no touching outside the sandbox, no disk management apps, etc.
So iOS is a much better target for first launch than OS X.
Second, with this plan it would take 3-5 years to ever arrive. Why so late? Apple has been developing it for a while, and probably have thousands of tests it has to pass. And they have been running it on 1 million or more devs on the 10.3 beta program on actual devices for feedback for 2 months.
3-5 years seems to be pretty typical for a filesystem to go from merely available to being battle tested enough to use without thinking about it. Bugs could destroy people's data (and the cloud won't necessarily help if the bugs corrupt data rather than erase it). What's the hurry?
>Bugs could destroy people's data (and the cloud won't necessarily help if the bugs corrupt data rather than erase it).
There's no reason to expect bugs if you have a comprehensive test suite and extensive internal and beta testing (like with a million of registered iOS developers running it for months).
Doubly so if you control most of the APIs and interactions with the OS tightly in your platform (as iOS does).
It has no show stopper bugs, and is used by close to a billion everyday just fine.
And the "rest of the iOS" (kernel, userland, etc) is orders of magnitude more LOC than the filesystem. And with all kind of interactions between components, not just a constrained API that all sandboxed apps use, as is the case with an FS. It has way bigger test surface and (presumably) way smaller test suites than an FS would.
What's the reason to assume an FS which is under production for 2 years now at least (it didn't appear magically formed a day before last WWDC) will have not just some obscure or infrequent bugs, but data killing bugs?
(And why they'd be more than with the frequent new features and changes that Apple made/retrofitted to HFS over the years? Because they've started from scratch?)
Because software has bugs, filesystem software has data corruption bugs, and two years of development with only a couple of months of serious real-world testing is tiny for something like that.
What other filesystems have gone from zero to being the only supported option on their platform in such a short time? ZFS took almost five years. HFS+ was supported in parallel with HFS for a long time.
"And why they'd be more than with the frequent new features and changes that Apple made/retrofitted to HFS over the years? Because they've started from scratch?"
Once again I have to wonder: have you written software before? Of course a brand new from-scratch effort will be buggier than something with a long history.
>Once again I have to wonder: have you written software before?
Yes, for several decades -- though not filesystems.
And I trivially know that software can always have bugs. I also know software has to ship at some point, and that is a different point than the "we're 100% sure it has 0 bugs" point -- which is not possible anyway.
I also don't believe in some cargo cult "optimal necessary period of testing" to make sure a given piece of software has or doesn't have bugs.
I also know that it's perfectly possible to have 10x the testing in 1/10 the time other teams/companies might take for their tests -- (e.g. by having far heavier test suites, more intelligent tests, better fuzzing, more systems to test on in your labs, more QA engineers thrown at the problem, or even formally proving your software's behavior) .
Finally, I can make ad hominem arguments too: have you wrote and deployed any filesystems before? If the domain experts designing AFS are confident to put it in use why we should trust you? Because of your scientific observations of checking how long other companies took to deploy their new filesystems and extrapolating some BS "optimal deployment time" from that?
In any case, maybe visit back this thread in 1 month? If the sky hasn't fallen for iOS 10.3 users (except, at worse, for some edge cases affecting tiny minorities/uncommon setups), maybe you'll be ready for your serving of crow?
Why should you believe me instead of the people writing APFS? You shouldn't. I'm stating my opinion on the matter. I'm allowed to disagree with them, and you're allowed to disagree with me, but "Apple thinks it's OK" is not going to convince me. If it was, then I wouldn't have formed a contrary opinion in the first place, since it's so obvious.
Further, we don't even know if the experts are confident. It's entirely possible this decision was made above them and forced on them. It's also entirely possible it wasn't, we just don't know.
In any case, if everything goes smoothly (and I hope it will), that doesn't disprove me. It could mean that you're right, or it could mean that I'm right and they got lucky. It could also mean that some people are losing data, but not visibly enough and not in large enough number to make the news.
You say "except, at worse, for some edge cases affecting tiny minorities/uncommon setups" as if that would justify Apple's approach. That's exactly the kind of thing I'm worried about here. I have no doubt it'll work for the common case. 99.9% of users will not suffer any problems. But I don't see why pushing APFS now as opposed to in a few years is worth the risk of that 0.1%.
>In any case, if everything goes smoothly (and I hope it will), that doesn't disprove me.
Doesn't that make your case an empty statement that basically amounts to "you can never be too careful" (and which is always right, no matter the outcome)?
>But I don't see why pushing APFS now as opposed to in a few years is worth the risk of that 0.1%.
Because it improves lots of things with the 99.9% -- SSD utilization, better Time Machine, etc.
iOS has always used case-sensitive HFS, while macs usually need case-insensitive HFS. Since it looks like APFS will drop support for the case-insensitive file system mode, it makes sense to do the forced upgrade on the system that already uses a case-sensitive file system (= iOS).
Plus, it's more straightforward recovering from a broken FS upgrade on iOS since many customers will have iCloud backups enabled, or at least their data stored on iCloud drive, while a mac filled to the brim with all sorts of strange applications and files spread all over the filesystem, likely never been backed up properly, is a tougher call.
I don't have a source, and too tired to look it up. But I thought I saw someone back away who found some tucked away support in APFS for case insensitive file support on macOS.
Maybe misremembering. But someone had hacked it to run as a boot drive, and in doing so, found the setting.
I'm far from an expert on file systems or semantic versioning, but the one thing I've heard is that APFS changes the way filenames are written to and read from disk. HFS+ (the old file system Apple OSes used) would automatically normalize file names so you couldn't have two files with names that look the same to a user but are represented with different byte sequences. APFS does not do this on the file-system level. (I heard thirdhand that some APIs might still do the normalization, but I don't have any links or details on that and don't want to spread bad info.)
> It stills feels wrong on a gut level, and semver folks might not be happy with it, but it seems to make some real sense.
If you maintain the public API, it's perfectly valid to radically change the implementation details in a point release.
If you're not going to respect the encapsulation of that kind of working knowledge behind an API, then you might as well just demand the very release of everything should be a Major version release.
Additionally, it may be a way of hedging their bets. If it all goes smoothly, great. However, if it turned into a big flaming dumpster fire, an iOS point release has a lot less to lose than a major release (and the associated new hardware that comes with one).
"iOS Update Causes Widespread Outages" plays a lot differently with the average person on the street (who already distrusts software updates in general) than "New iPhone Fundamentally Flawed". Feel free to craft your own hyperbolic headlines, but hopefully you get the idea.
If there is any way to link software issues with an iPhone launch, media outlets will do it to grab views from people considering a purchase (i.e., damage to the product launch). The same isn't true of an update; it damages the perception of the ecosystem, but most people don't even know what a software ecosystem is.
Of course they know... They always get buggy upgrade on games and ironically, thanks to them, people are more or less used to buggy upgrades and may not freak out in those events.
That deals with responding to reviews of your app, not an ability to leave a review for iOS itself. Either way, I don't think the average consumer will understand that they've lost data because of a bug in a new filesystem.
And if you are an app with appreciable market share and something goes wrong, I doubt one would be able to mitigate a crush of negative reviews.
haha, I knew that "actually..." was coming. I deserved that.
Whether our customers will be mollified by me replying "Actually, it's Apple's fault, you see..." remains to be seen. It has not been my experience that they're real forgiving of that kind of thing. I've been through this before.
My white knuckle grip on my chair is loosening a little though-- we might get through this bit of turbulence ok. Knock on wood. ;)
That is why Apple has had 10.3 in beta, so that developers could test their apps and report breakages before anything goes public. Seems like business as usual to me.
I've been running the beta for quite some time and didn't even notice that it had changed. Honestly, I think it's the best possible way that they can roll this out - iOS is much more restricted and has fewer devices to worry about, so is worlds easier than macOS, and internal dogfooding/the beta program gives them good coverage before hitting the whole population. Doing it in a dot release or major version doesn't seem particularly interesting one way or the other.
You've got to imagine they're doing a slower rollout than usual for this somewhat major change.
The first .01% requests might get it until they know there aren't 11th hour "in the wild" problems, then they'll jump it to .1, 1%, 10%, and eventually 100%.
Sounds sane. Otherwise upgrade scripts would have to be exhaustive for beta1->GM, beta2->GM etc. So now there's 10.2->10.3 and beta7->10.3, much more manageable.
I had the same issue but a manual reinstall wasn't necessary. I believe the problem was that in the developer > profiles menu there is a certificate for beta updates that needs removed. Something along those lines.
I'm excited about exposing to app developers a way to ask for ratings. Specifically, the ability to opt out of them.
I think this doesn't address the real problem though, which is that ratings reset after every app update. This means that app developers have to constantly ask for reviews, which is exhausting as a user.
What's the reasoning behind this? On Android, reviews for prior versions have a "This review was left for a previous version." banner at the top of them, but the star aggregates are all still there. How do apps keep reviews if they're wiped out every time an app updates?
This is true, and also, when searching the app store the star ratings displayed next to each app are based on the "current version", so if an app is recently released it might say "0 reviews" even though it previously had thousands.
I guess as a developer this approach is useful if your first version is bug ridden, gets terrible reviews and you quickly push an update that fixes them all. Your product is doomed. Maybe after 5 updates or something to an app it should show the 'all ratings' as defaults but before that show 'current version'.
This also really effects ratings outside the US (where the userbase both iOS and for many apps is a lot lower). The per-country rating stuff is mad.
As an example: For my country (which is all I can see) Instagram has ONE rating on the current version and WhatsApp has none. For all versions, they have just 21k and 17k respectively. There are probably amongst the most popular apps, so their star-rating in the lists are based on one or less ratings.
I've been running the beta for a few weeks now. The thing that stands out the most? They changed the filesystem, and I haven't noticed a thing - the upgrade time wasn't even significantly longer. If anything, the beta has been more stable than 10.2 releases.
The fact they've pulled it off so seamlessly is pretty impressive. Heck, the majority of users won't have a clue that their filesystem has changed, and that's the way it should be - users shouldn't be required to know about technical implementation.
As a counterpoint, my springboard has been sporadically crashing since I installed 10.3, and I have no idea why, but the FS change seems like an obvious culprit. Doubtful it will go away with the official release.
I've been on 10.3 beta and have had few crashes (fewer than since 9.x). It has been an amazingly stable beta experience for me (polar opposite from iOS5 beta which was unusable/dangerous)
> the upgrade time wasn't even significantly longer
I wonder if it works like FileVault, where there's a notion of a "partially converted" volume and blocks are slowly converted as a background-idle task after the update completes.
Could be, it may be more like the ext3/4 -> BTRFS conversion process[1], where metadata for the new filesystem is written in the free space, but with pointers to the original data which isn't moved or re-written.
The whole OS seems more snappy to me. Wonder if they have somehow figured out how to file access latency? Perhaps less of the filesystem metadata needs to be accessed on each file access.
HFS+ has a global lock so only one process can access the file system at a time. I would imagine having APFS clear out that limitation speeds things up dramatically.
I've been running the beta without issues for a while but I've PSA'd for my extended circle to say "definitely do a backup". I fully expect this to be a smooth transition but it's definitely an impactful change.
If you have less tech savvy members of your family with iPhones you might want to just remind them how to do a backup (to save having to explain why it's gone wrong).
Notably, ten kernel arbitrary code execution bugs, seven from Google Project Zero and two from Qihoo 360's research team. There are also a few WebKit RCEs, so it seems like it's prudent to update as soon as possible, lest a malicious website silently jailbreak your phone.
Don't upgrade immediately unless you're willing to deal with problems. If these security updates were critical they'd be made available in a 10.2.x point release.
I just updated and was greeted with an Analytics screen asking to send usage and other telemetry data back to Apple. The first option to opt in was in large text while the second option to opt out was in very small text. Is this new? I don't recall seeing this screen before.
How do you know it isn't the placebo effect? I once had one of my customers saying that a certain feature in my product was faster after an upgrade, but I hadn't actually touched that feature...
Biggest change to me in this release is that iOS now switches language immediately with hardware keyboard rather than after the switcher animation ended.
This problem is not very noticable if you do not use non-Latin input method. However for some languages (Thai in my case), in iOS 10.2, it means you will have to wait a little moment until the language switcher faded out until you can type in the target language, otherwise it will still stuck at previous language. I'm really glad to see this fixed.
(Previously I workaround this problem by using Capslock, which seems to be able to make iOS go into latin input mode.)
Thanks. Didn't know. Had never had it happen before, but I also don't think I ever upgraded so soon after release. We must have got this one within an hour of it coming out.
Night Shift is cool but I wish to have a quick shortcut to toggle it or disable for some apps (like f.lux). Any idea how to control Night Shift via AppleScript?
Notifications menu on the very top(need to scoll up a bit for the hidden toggle switch to appear).
Super easy and smooth way to toggle Nightshift: I have the multi-touch gesture to open the Notifications menu with two-finger swipe from the right edge. Then I scroll up and turn on/off Night Shift.
I dont know whom to blame? I need Google Maps in Apple Car play and without that its not worth at all for me (countries where Apple Maps is not supported and Google maps is superior)
Just upgraded to 10.3 last night on my iPhone 7. Nothing works! iMessage doesn't work anymore, I can't even swipe up to toggle wifi/bluetooth, the menu pops up about 1/3 of the way and just freezes.
Twitter hangs when it starts to fetch new data.
Anyone else had these issues after upgrading to 10.3?
102 comments
[ 2.8 ms ] story [ 156 ms ] threadPresumably, if something does go wrong on the individual level, the support burden on the genius bars will be lower (since major iOS releases have traditionally come alongside hardware releases), and if a major bug is found, the number of devices affected will also likely be smaller.
It stills feels wrong on a gut level, and semver folks might not be happy with it, but it seems to make some real sense.
edit: Also, if it went out with 11.0, coordinating all the bug fixes for a 11.0.1 would almost definitely take longer than whatever will be in 10.3.1 release, letting any APFS issues get tweaked faster.
If I were somehow in charge of it, I imagine I'd want to do it like: 1) ship it as officially supported on the Mac, but off by default. 2) a year or two later, ship it as officially supported on the Mac, on by default, but still allow HFS+ as an option. 3) A year or two after that, if all has gone well, then introduce it into iOS (where presumably it's not reasonable to make it optional).
It's really weird to me that Apple is rolling it out to hundreds of millions of devices all at once, when it's not even a bootable filesystem on any of their platforms yet. Seems like the kind of thing where you'd want to take a more gradual approach.
I get that HFS+ is super old and I see why Apple wants to switch to APFS. But I don't get why they're in such a hurry.
Here's hoping their approach works well, in any case!
The plan doesn't make much sense. For one, the Mac has way more edge cases than iOS (in that people do more, and in more low- and -high level ways) with the filesystem, including running all kinds of unix userlands, exchanging files with other filesystems, etc. In iOS all fs APIs and access are tightly controlled, and there's no mounting of disks, no touching outside the sandbox, no disk management apps, etc.
So iOS is a much better target for first launch than OS X.
Second, with this plan it would take 3-5 years to ever arrive. Why so late? Apple has been developing it for a while, and probably have thousands of tests it has to pass. And they have been running it on 1 million or more devs on the 10.3 beta program on actual devices for feedback for 2 months.
There's no reason to expect bugs if you have a comprehensive test suite and extensive internal and beta testing (like with a million of registered iOS developers running it for months).
Doubly so if you control most of the APIs and interactions with the OS tightly in your platform (as iOS does).
This statement makes me wonder, have you written any software before?
It has no show stopper bugs, and is used by close to a billion everyday just fine.
And the "rest of the iOS" (kernel, userland, etc) is orders of magnitude more LOC than the filesystem. And with all kind of interactions between components, not just a constrained API that all sandboxed apps use, as is the case with an FS. It has way bigger test surface and (presumably) way smaller test suites than an FS would.
What's the reason to assume an FS which is under production for 2 years now at least (it didn't appear magically formed a day before last WWDC) will have not just some obscure or infrequent bugs, but data killing bugs?
(And why they'd be more than with the frequent new features and changes that Apple made/retrofitted to HFS over the years? Because they've started from scratch?)
What other filesystems have gone from zero to being the only supported option on their platform in such a short time? ZFS took almost five years. HFS+ was supported in parallel with HFS for a long time.
"And why they'd be more than with the frequent new features and changes that Apple made/retrofitted to HFS over the years? Because they've started from scratch?"
Once again I have to wonder: have you written software before? Of course a brand new from-scratch effort will be buggier than something with a long history.
Yes, for several decades -- though not filesystems.
And I trivially know that software can always have bugs. I also know software has to ship at some point, and that is a different point than the "we're 100% sure it has 0 bugs" point -- which is not possible anyway.
I also don't believe in some cargo cult "optimal necessary period of testing" to make sure a given piece of software has or doesn't have bugs.
I also know that it's perfectly possible to have 10x the testing in 1/10 the time other teams/companies might take for their tests -- (e.g. by having far heavier test suites, more intelligent tests, better fuzzing, more systems to test on in your labs, more QA engineers thrown at the problem, or even formally proving your software's behavior) .
Finally, I can make ad hominem arguments too: have you wrote and deployed any filesystems before? If the domain experts designing AFS are confident to put it in use why we should trust you? Because of your scientific observations of checking how long other companies took to deploy their new filesystems and extrapolating some BS "optimal deployment time" from that?
In any case, maybe visit back this thread in 1 month? If the sky hasn't fallen for iOS 10.3 users (except, at worse, for some edge cases affecting tiny minorities/uncommon setups), maybe you'll be ready for your serving of crow?
Why should you believe me instead of the people writing APFS? You shouldn't. I'm stating my opinion on the matter. I'm allowed to disagree with them, and you're allowed to disagree with me, but "Apple thinks it's OK" is not going to convince me. If it was, then I wouldn't have formed a contrary opinion in the first place, since it's so obvious.
Further, we don't even know if the experts are confident. It's entirely possible this decision was made above them and forced on them. It's also entirely possible it wasn't, we just don't know.
In any case, if everything goes smoothly (and I hope it will), that doesn't disprove me. It could mean that you're right, or it could mean that I'm right and they got lucky. It could also mean that some people are losing data, but not visibly enough and not in large enough number to make the news.
You say "except, at worse, for some edge cases affecting tiny minorities/uncommon setups" as if that would justify Apple's approach. That's exactly the kind of thing I'm worried about here. I have no doubt it'll work for the common case. 99.9% of users will not suffer any problems. But I don't see why pushing APFS now as opposed to in a few years is worth the risk of that 0.1%.
Doesn't that make your case an empty statement that basically amounts to "you can never be too careful" (and which is always right, no matter the outcome)?
>But I don't see why pushing APFS now as opposed to in a few years is worth the risk of that 0.1%.
Because it improves lots of things with the 99.9% -- SSD utilization, better Time Machine, etc.
Plus, it's more straightforward recovering from a broken FS upgrade on iOS since many customers will have iCloud backups enabled, or at least their data stored on iCloud drive, while a mac filled to the brim with all sorts of strange applications and files spread all over the filesystem, likely never been backed up properly, is a tougher call.
Maybe misremembering. But someone had hacked it to run as a boot drive, and in doing so, found the setting.
FileVault can take advantage of the transparent encryption feature of APFS and TimeMachine can simply backup a snapshot of the file system.
I don't know if Apple (who likes to drop things) will support both concepts.
Also the reason why I assume that APFS will be coming to macOS in the next major release and not in a point release.
Wouldn't this be valid semver if the APIs or general functionality hasn't changed? Or isn't expected to?
http://mjtsai.com/blog/2017/03/24/apfss-bag-of-bytes-filenam...
If you maintain the public API, it's perfectly valid to radically change the implementation details in a point release.
If you're not going to respect the encapsulation of that kind of working knowledge behind an API, then you might as well just demand the very release of everything should be a Major version release.
"iOS Update Causes Widespread Outages" plays a lot differently with the average person on the street (who already distrusts software updates in general) than "New iPhone Fundamentally Flawed". Feel free to craft your own hyperbolic headlines, but hopefully you get the idea.
If there is any way to link software issues with an iPhone launch, media outlets will do it to grab views from people considering a purchase (i.e., damage to the product launch). The same isn't true of an update; it damages the perception of the ecosystem, but most people don't even know what a software ecosystem is.
If Apple fucks something up, and your app don't run no more, it's your fault and it's now your problem.
But you can absolutely throw a brick through my front window.
Doesn't cover all instances, but should help with any MAJOR bugs that would come up.
Whether our customers will be mollified by me replying "Actually, it's Apple's fault, you see..." remains to be seen. It has not been my experience that they're real forgiving of that kind of thing. I've been through this before.
My white knuckle grip on my chair is loosening a little though-- we might get through this bit of turbulence ok. Knock on wood. ;)
Seriously, for a major change in the underlying system, surely it's better to do that along with as few other fundamental changes as possible?
Rebooted several times. My iPhone 7s, and two older iPhones upgraded to 10.3, as well as another iPad. Why is the iPad Pro different?
The first .01% requests might get it until they know there aren't 11th hour "in the wild" problems, then they'll jump it to .1, 1%, 10%, and eventually 100%.
If you had stayed on the beta program, you would now be upgraded to 10.3 automatically.
https://beta.apple.com/sp/betaprogram/restore#ios
You only need to restore if you want to downgrade to a release version when you are on a later beta.
I think this doesn't address the real problem though, which is that ratings reset after every app update. This means that app developers have to constantly ask for reviews, which is exhausting as a user.
What's the reasoning behind this? On Android, reviews for prior versions have a "This review was left for a previous version." banner at the top of them, but the star aggregates are all still there. How do apps keep reviews if they're wiped out every time an app updates?
As an example: For my country (which is all I can see) Instagram has ONE rating on the current version and WhatsApp has none. For all versions, they have just 21k and 17k respectively. There are probably amongst the most popular apps, so their star-rating in the lists are based on one or less ratings.
The fact they've pulled it off so seamlessly is pretty impressive. Heck, the majority of users won't have a clue that their filesystem has changed, and that's the way it should be - users shouldn't be required to know about technical implementation.
I wonder if it works like FileVault, where there's a notion of a "partially converted" volume and blocks are slowly converted as a background-idle task after the update completes.
[1] https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3
The comment I replied to, sorry for my bluntness here, is pretty much "This file system hasn't give me any trouble in five or six weeks."
Even if they actually verified all the files on disk, to ensure none of them are corrupt, it wouldn't signify all much, given the short duration.
I thought it was reasonable (maybe even self-evident) but we'll probably have to agree to disagree on that.If you have less tech savvy members of your family with iPhones you might want to just remind them how to do a backup (to save having to explain why it's gone wrong).
Notably, ten kernel arbitrary code execution bugs, seven from Google Project Zero and two from Qihoo 360's research team. There are also a few WebKit RCEs, so it seems like it's prudent to update as soon as possible, lest a malicious website silently jailbreak your phone.
This problem is not very noticable if you do not use non-Latin input method. However for some languages (Thai in my case), in iOS 10.2, it means you will have to wait a little moment until the language switcher faded out until you can type in the target language, otherwise it will still stuck at previous language. I'm really glad to see this fixed.
(Previously I workaround this problem by using Capslock, which seems to be able to make iOS go into latin input mode.)
Going to see if I can extract data. They didn't have itunes backups.
Super easy and smooth way to toggle Nightshift: I have the multi-touch gesture to open the Notifications menu with two-finger swipe from the right edge. Then I scroll up and turn on/off Night Shift.
Twitter hangs when it starts to fetch new data.
Anyone else had these issues after upgrading to 10.3?