But instead published after the fact as an additional update:
https://lists.apple.com/archives/security-announce/2017/Sep/... and https://support.apple.com/en-us/HT208112
Why delay the announcement? And why remove the original "APPLE-SA-2017-09-19-1 iOS 11" with "Date: Tue, 19 Sep 2017 -0700" from the apple-security email archive?
Also, are Macbooks vulnerable to the same bug until next monday when macOS 10.13 drops?
Also, there are about 6 other similar issues recently posted to Google Project Zero: https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...
That's also the only time I can remember security updates being pushed after a device model being end-of-life'd.
Not sure if they can/do update independent components though
If they are "bankrupt, disbanded, in some cases deceased" then maybe insisting on using those apps are not the best course for the user either...
Sometimes the apps are the only way to access something else, in this case a car remote unlock.
Sometimes someone has paid actual money for an app, more than the $1 baseline; some music apps are in triple figures.
What good is degraded performance because some BS game/app who on top of it is abandoned from its developer for years, and it will stop working anyway sooner or later, needs 32-bit mode? Especially when you can find 200 replacement that work fine in 64-bit and are upgraded regularly.
If Apple wants to force apps to do something, they can force developers to create interoperable data that can be migrated without the developer's consent or continued existence. Until then, Apple has more resources than Microsoft and Linux, which both provide backward compatibility for old apps on new platforms. This is a solved problem.
Why penalize iOS platform customers who were the earliest adopters and had the highest chance of creating data which is now orphaned in abandoned-but-functional offline apps? Let's not get into the Apple's mis-steps on the App Store, which is what caused many iOS developers to go out of business or stop supporting apps.
The main difference though is that you’d expect a device like an iPhone or iPad to last a maximum of about 3 to 5 years while you’d expect a car to last 10 to 25 years. Accordingly it would be wise to use future proof parts, not proprietary parts that go out of style every few years.
Besides are you planning on keeping the same IOS device forever? The newest processors are 64 bit only. I doubt that Apple will ever release a new device that will support 32 bit devices - except for maybe a new iPod Touch or iPhone SE.
If the developer does not have any interest in updating their own app, do I as a user care about their apps?
A developer's primary interest in their app is to earn an income. A user's interest is in using the app for whatever functionality it provided. There's no symmetry here.
There are almost 0 cases where I would withhold an OS update in order to keep using an specific app, let alone change my device, and I’m completely on Apple’s side for finally killing 32-bit.
If they only supported it on the 7 and below then it might be confusing to users why some people get to use older apps and others don’t. On the other hand if they wanted to support it on the 8 and X then they would have to have an entire processor emulator that would only exist to support apps that hadn’t been updated in years.
Don’t forget that Apple keeps tons of usage statistics from people who are willing to give them. Chances are they know pretty exactly what percent of people use 32 bit apps with any regularity and how much total time to use them for. If they were willing to make these decisions my guess is those numbers are very low.
People here on HN are concerned about it and there have been some articles on websites about it but I’m willing to bet that this whole thing is almost a non-issue.
I was actually thinking of when they left 68K and PowerPC though. I had PowerPC apps that worked through Rosetta for a while and then that was removed when Apple decided it was “time“.
I say broken as I've yet to see good code come from Broadcom.
In general, you can assume that if you can't audit it, it's absolute crap. This is true for hardware and software.
I am not sure if there are any real alternative to Broadcom WiFi and Ethernet, apart from Apple making one themselves.
( The W1 and W2 may be part of this )
In the current grand scheme, Apple and Qualcomm are also currently suing each other and I'm pretty sure part of that is Apple withholding billions in payments.
Yes, at a different level of business, Apple has an open lawsuit against Qualcomm, but that's not the scope that we're here to discuss. Mentioning it is fine, linking to a recent HN post about it would be stellar!, but "It means nothing in the grand scheme" is dismissive and wrong.
Your concerns are clearly expressed, but insulting others for choosing to discuss a topic not relevant to your concerns is no excuse to shut them down verbally. That approach is not welcome here.
EDIT: I'm not a mod or anything.
Especially now that iOS 11's wifi-off button in the control center no longer actually disables the radio, but merely disassociates from the current access point.
I still can’t belive this decision. I keep my Bluetooth and Wi-Fi off as much as possible and it’s now difficult to to as a result of this change is ios11. Really bothers me.
Since Apple keeps detailed usage statistics (from the people who opt in) my guess is they know how common such a behavior is and it’s obviously low enough they don’t think this change is a problem.
I agree with some of the other comments I’ve seen that this probably accomplishes what the user is trying to do (ignoring a Wi-Fi network that’s temporarily behaving poorly) and possibly protecting them (forgetting to turn it back on it running up a huge cell bill). I know I’ve heard complaints from people who accidentally did that a number of times.
And also being hassled about location services not working, etc.
You can still actually disable both through the settings up, just not with the quick access.
For everyone else, the new behavior allows users to disconnect from bad Wi-Fi in Control Center while improving their battery life in case they forget to turn Wi-Fi back on.