The Ars Technica article on this issue cuts to the heart of why this is so devastating: there is tons of software--software which was really interesting and I dare say "seminal" for this important era of computing; and which is not old or outdated by any sane standard--that this destroys access to going forward, for essentially no benefit.
Apple insisted that they get to curate something of critical value, but they don't comprehend the moral weight of that responsibility, and now want to just go around burning down their Apple-branded libraries. It is absolutely sickening, and is the kind of thing we probably need to solve using regulation (which, of course, is likely never going to happen, given how even companies we would have assumed were on our side often have lobbyists fighting for the ability to lock down ecosystems).
> The Ars Technica article on this issue cuts to the heart of why this is so devastating: there is tons of software--software which was really interesting and I dare say "seminal" for this important era of computing; and which is not old or outdated by any sane standard--that this destroys access to going forward, for essentially no benefit.
It's not zero benefit. Supporting multiple ABIs means that you need to have multiple copies of system libraries paged in at a time if they're used, which is not an insignificant amount of memory (which then has resulting power/price costs). It's possibly even bigger of a problem on iOS than Android, because Apple changed the floating point ABI between ARMv6 and ARMv7, so they have to support multiple different 32-bit ABIs.
Why do you and many others treat software as if it is a sacred artefact that must be kept and preserved and be able to be run for all future generations?
Humans are producing so much content right now in the form of software, art, movies, writing. Does it really matter if we leave some behind? Do we need to preserve every piece of information we generate?
I have software on the App Store that I cherish that unfortunately will never be updated past 32 bit (too much work). But I don't care, nor do I feel the need to preserve it.
You say there is no benefit to this move. But this move significantly reduces Apple's technical debt and support requirements and is likely to be worth the tradeoff for future developers and future software on the platform.
i wonder how long it is going to take for people to realize the importance of libre software. sure, strong copyleft can be inconvenient for developers, but that inconvenience must be borne to enable users to control their technology. otherwise we end up with the nonsense that we are discussing here: software people want/need, that they are no longer permitted to use because Apple said so.
How is this different from console manufacturers not making their software backwards compatible?
If you want to preserve old iOS software that you bought, do a local iTunes backup and your apps are on your hard drive. For the forseable future, you will be able to buy used 32 bit iOS devices - just as people buy used consoles to play old games.
That's the worse case, best case is that Apple keeps allowing older devices to run older versions of purchased software.
I recently charged up my 1st gen iPad (last update 5 OS versions ago) and I was able to download older versions of apps - Hulu, Netflix, Crackle, Plex, Amazon Video, kindle, Spotify and Google Drive, -- from the App Store.
The iPad 1 is too old and too low on memory (256Mb) to run Safari without crashing constantly, but the apps I mentioned still run well as does the built in mail and calendar apps.
It works with Bluetooth and Spotify doesn't force you to listen in shuffle mode on tablets if you're not a subscriber.
Said software can still be run using emulators, can it not? There is lots of (well, some) potentially useful software out there that only runs on machines no longer in production. A good solution is also to make source code freely available, then the best programs will not die.
Such is progress. And there is plenty of benefit: a cleaner, saner iOS, and software that's been updated can take advantage of the latest Apple technology.
Perhaps it would be more worthwhile to identify the apps/frameworks you value and bug their authors to modernize them to meet current technological standards. It's not like Apple is springing this one people. They're giving them ~18 months of warning.
> is the kind of thing we probably need to solve using regulation
No, no, no, no, no. This is absurd. Government has absolutely nothing to do with this. This kind of "regulate everything that exists" is why we have some of the problems we do today. You can't go up to someone or some organization and force them by gunpoint to do something like this by law.
I'm okay with Apple switching to 64-bit only. I wish Google did that a while ago, too. Now, the vast majority of low-end phones use Cortex-A53 (64-bit) chips anyway.
However, it's frustrating to see them prioritizing this move over the HTTPS-only one, which they've recently delayed. I'd much rather they push that through, whether developers like it or not, than this.
Software enthusiasts and power-users will still find a way, whether with unlocking, modding, or emulation. Communities will surely spring up that cater to those looking for old iOS / Android software and sandboxing tools will allow these to be safely run. Do not fret :)
Even without having read the article (the site is down for me) I can say this is a wise decision.
Currently the 64-bit arm cpu can also run 32-bit code. To support this it contains a 32-bit emulation layer that also exists in a few other places such as caches. By removing that, apple will be able to
1. Shrink the CPU, hence making room for more cores or bigger caches.
2. Reduce power usage by removing a significant number of gates.
3. Simplify the OS code significantly, which will probably improve performance and security.
I'm not sure that this means what the article says it means. Apple was selling the iPhone 5C in India until less than a year ago. Dropping support for the new OS that soon would be uncharacteristic for the iPhone.
Instead, they may simply be dropping support for 32 bit apps on a 64 bit CPU. Having to support 64 bit and 32 bit apps one a single device forces them to ship two versions of every shared library, and is probably annoying for them in various types of interprocess communication, because, for example, CGFloat and integer types are different sizes.
My guess is that they will release a 32 bit version of iOS and a 64 bit version, and each one will only run apps for the native processor word size.
They did something like this for the worst gen iPads. Two years and support was dropped. I believe they've also done it for Mac hardware too. So it wouldn't surprise me at all if they did it for an economy model of the iPhone.
So developers have roughly 9 months to update their apps or they won't run on 5 year old hardware? This doesn't sound as devastating as some of the tweets and headlines would imply (that seems to be common these days).
This really, really sucks for people who paid good money for 32bit apps. Or even expensive external hardware items that require ancient apps to be useful. Even if the apps are removed from the app store (and Apple has gone on a rampage removing old apps), existing customers always could keep the apps installed until now. If apps stop working and disappear, they will lose a whole lot of the trust that people had in the app store. I'm also curious about how this will affect the usually impressive rate of upgrades to the latest iOS version among active app-purchasing users.
> Ever launch an app on your iPhone and then get a pop-up warning that says the app may slow down your iPhone?
Noooooo :( Pleas say it ain't so...
"PDF Highlighter" by omz:software is one of my favorite apps on the iPad. The only PDF app that doesn't have a million things I don't need, and has a beautiful summary of all the highlights you make in your PDFS..plus Dropbox .. plus OCR. Oh, and highlight colors that don't look like they were put in by a 3 year old jesus. What's up with all those annotate aps using FF0 yellow or F00 red? What happened to design? Why do all these PDF apps have to suck so bad as a reading experience?
For Apple this must be a dream -- drop everything that's explicitly 32-bit. Make some compiler improvements easier, possibly drop some silicon costs, remove lots of #ifdef __LP64__, simplify the kernel, etc.
"This includes the iPhone 5, 5c, and older, the standard version of the iPad (so not the Air or the Pro), and the first iPad mini."
This implies there is still a "standard" iPad for sale. In fact, the iPad Air was simply the successor to the iPad 4, and the iPad Pro was the successor to the iPad Air 2. There is no "standard iPad" on sale anymore, and there hasn't been for years.
This won't directly affect any device Apple has sold in some time. The iPhone 5C is the last iPhone they released that was 32bit, and was likely to be dropped for software updates with the release of iOS 11 anyway.
In short, there's nothing to worry about, except if you want to run an app that hasn't been updated in 2+ years
I'm upset that all of my Llamasoft/Jeff Minter games will go by the wayside. Minter did not find it profitable to make iOS games, so he let his Apple Developer subscription lapse; there won't be a 64-bit recompile of Gridrunner for iOS.
I might have to get an Android device just for classic games, like his.
In x86, there is even an ABI for using 64-bit instruction set features (like more registers) while sticking with 32-bit pointers to keep the memory footprint small and fast. (This limits you to 4GB of ram per process, but there are a lot of applications where that's not particularly important.)
In practice only two architectures matter: x86 and ARM. Both brought cleaned-up ISAs, expanded the number of general-purpose registers, made some features required, and made other improvements during the transition.
So for all practical purposes: YES, the 64-bit transition has actual real benefits to end users besides the larger address space.
It's false - if you want to process many bits at once, you use SIMD instructions, which you have on 32-bit too.
Generally, other things equal, going from 32 to 64 bit word size makes things slower because pointers suddenly double in size, and you can fit fewer program objects in your caches.
In practice there are a slew of miscellaneous improvements in the new 64-bit revision of an instruction set that makes up for some of the slowdown. This is less pronounced on ARM, but was big on x86 because a big flaw, the register count, was fixed.
Not completely true, AArch64 performs better because it has more registers (means less fetch from memory), and more advanced instructions. Here is an article about this:
Yep. If it's just 32->64 there may even be a slow down as you need to pull bigger things through the various busses. However, Armv8 also brought a huge improvement to the instruction set, so recompiling with the proper optimizations will bring performance increases in a lot of programs.
Sure, but don't forget that there also exists aarch64 with ilp32 (int, long and pointers are 32bit) as opposed to the default lp64. Which is basically the new instruction set but restricted to 32bit memory space. In fact some of the specint benchmarks are faster with ilp32.
It would be good to start some kind of initiative to try to get in contact with developers of unmaintained apps and tu to convince them to do one last build. Or to release the software to open source or at least work with somebody to keep them going. Many will likely not respond but if there is a chance to salvage at least some of them it would be a win.
“One last build” generally isn’t enough because software might have many issues, including:
— Dependencies on other 32-bit libraries that have not changed.
— Dependencies on entire OS frameworks that have not migrated to 64-bit (and Apple has at least one of these).
— Having a “plug-in” feature, whereby cherished plug-ins have not all migrated to 64-bit so the user must then choose a 64-bit subset.
— Any number of problems in the code itself, such as improper assumptions made about the sizes of data structures or creative solutions that only made sense on 32-bit platforms. After a simple recompile, the code may crash in places or consume much more memory. Floating-point values may produce subtly different results, creating issues all over the place.
So basically 4.5 years support max. for your devices (iPhone 5 was September 2012; iPad 4 October 2012)? Also aren't there a lot of these "old" iPads out there with people "refusing to update"?
I think technically it makes a lot of sense but for customers this is pretty bad. Compared to Microsoft's 15 years of extended support for an OS (iirc. 5 is standard). Ubuntu LTS is 5 years. Sure there's a difference when you're the hardware vendor and the OS vendor but still I'm not sure this is a great move.
If this is bad for customers, pretty much every Android device except the Nexus must be a living hell. How many Android handsets (including "flagships") launch with an already outdated OS version and never get updated?
I still use an iPhone 4s and a first generation iPad. The devices I have are in perfect working condition, and they fulfill my needs. It's not a stubborn "refusing to update", but simply a "there's nothing about an iPhone 7 that's worth $649 to me".
MSFT can go 15 years of support because PCs pace of change is far slower than smartphones. I'm pretty sure MSFT dropped 286 support long ago.
And Windows compatibility with so much old software is a big reason why it sucks. There are too many apis that should have been deprecated and hacks to support specific apps that bloat it up.
One of the consequences of this move will be to flush out tens or hundreds of thousands of applications from the App Store.
Why?
It's a simple matter of economics: Creating apps for iOS is, and has been, for a long time, unprofitable for most developers. Last I looked, most can't earn a living, which means they are working for far less than what they could otherwise earn doing something else.
A good deal of the existing 32 bit apps are simply going to die off as developers abandon them.
This could be good, of course, as it might improve discoverability in certain categories. Time will tell.
The first apps I've bought for my iPhone were dictionaries. The owners of the dictionary material sold the right to the app developers, but didn't extend it, therefore the developer doesn't even have the right to publish an updated version, even if it would be only a recompile with the never compilers for them.
Which means that even if I've paid for the content, now I'll have to purchase it again from another developer only because some random limitation is introduced, and even that purchases can soon disappear again.
Does anyone have a comprehensive list of the advantages (and disadvantages besides: "Old software won't work anymore.") of this decision?
Does it reduce engineering/research effort, production costs, chip size, size of binaries, duration of compilation, programming effort and improve performance: If yes, by how much?
[+] [-] saurik|9 years ago|reply
Apple insisted that they get to curate something of critical value, but they don't comprehend the moral weight of that responsibility, and now want to just go around burning down their Apple-branded libraries. It is absolutely sickening, and is the kind of thing we probably need to solve using regulation (which, of course, is likely never going to happen, given how even companies we would have assumed were on our side often have lobbyists fighting for the ability to lock down ecosystems).
https://arstechnica.com/apple/2017/01/future-ios-release-wil...
[+] [-] jmgao|9 years ago|reply
It's not zero benefit. Supporting multiple ABIs means that you need to have multiple copies of system libraries paged in at a time if they're used, which is not an insignificant amount of memory (which then has resulting power/price costs). It's possibly even bigger of a problem on iOS than Android, because Apple changed the floating point ABI between ARMv6 and ARMv7, so they have to support multiple different 32-bit ABIs.
[+] [-] interpol_p|9 years ago|reply
Humans are producing so much content right now in the form of software, art, movies, writing. Does it really matter if we leave some behind? Do we need to preserve every piece of information we generate?
I have software on the App Store that I cherish that unfortunately will never be updated past 32 bit (too much work). But I don't care, nor do I feel the need to preserve it.
You say there is no benefit to this move. But this move significantly reduces Apple's technical debt and support requirements and is likely to be worth the tradeoff for future developers and future software on the platform.
[+] [-] xj9|9 years ago|reply
i wonder how long it is going to take for people to realize the importance of libre software. sure, strong copyleft can be inconvenient for developers, but that inconvenience must be borne to enable users to control their technology. otherwise we end up with the nonsense that we are discussing here: software people want/need, that they are no longer permitted to use because Apple said so.
https://www.fsf.org/
[+] [-] scarface74|9 years ago|reply
If you want to preserve old iOS software that you bought, do a local iTunes backup and your apps are on your hard drive. For the forseable future, you will be able to buy used 32 bit iOS devices - just as people buy used consoles to play old games.
That's the worse case, best case is that Apple keeps allowing older devices to run older versions of purchased software.
I recently charged up my 1st gen iPad (last update 5 OS versions ago) and I was able to download older versions of apps - Hulu, Netflix, Crackle, Plex, Amazon Video, kindle, Spotify and Google Drive, -- from the App Store.
The iPad 1 is too old and too low on memory (256Mb) to run Safari without crashing constantly, but the apps I mentioned still run well as does the built in mail and calendar apps.
It works with Bluetooth and Spotify doesn't force you to listen in shuffle mode on tablets if you're not a subscriber.
[+] [-] nstj|9 years ago|reply
[+] [-] numbsafari|9 years ago|reply
If those apps are so seminal, let's hope they are open source and available for study, porting, and upgrading.
[+] [-] Athas|9 years ago|reply
[+] [-] runjake|9 years ago|reply
Perhaps it would be more worthwhile to identify the apps/frameworks you value and bug their authors to modernize them to meet current technological standards. It's not like Apple is springing this one people. They're giving them ~18 months of warning.
[+] [-] cpeterso|9 years ago|reply
[+] [-] andrewmcwatters|9 years ago|reply
No, no, no, no, no. This is absurd. Government has absolutely nothing to do with this. This kind of "regulate everything that exists" is why we have some of the problems we do today. You can't go up to someone or some organization and force them by gunpoint to do something like this by law.
[+] [-] mtgx|9 years ago|reply
However, it's frustrating to see them prioritizing this move over the HTTPS-only one, which they've recently delayed. I'd much rather they push that through, whether developers like it or not, than this.
https://9to5mac.com/2016/12/21/apple-delays-requirement-for-...
[+] [-] unethical_ban|9 years ago|reply
I would be very hesitant to legislate Apple supporting 32bit apps. That sounds absurd on its face.
[+] [-] kakarot|9 years ago|reply
[+] [-] Reason077|9 years ago|reply
Apple already have a technical solution: bitcode.
In the future, this should mean the App Store can automatically recompile old binaries for new CPU architectures.
[+] [-] scott_s|9 years ago|reply
[+] [-] ordbajsare|9 years ago|reply
[deleted]
[+] [-] digi_owl|9 years ago|reply
[+] [-] bostand|9 years ago|reply
Currently the 64-bit arm cpu can also run 32-bit code. To support this it contains a 32-bit emulation layer that also exists in a few other places such as caches. By removing that, apple will be able to
1. Shrink the CPU, hence making room for more cores or bigger caches.
2. Reduce power usage by removing a significant number of gates.
3. Simplify the OS code significantly, which will probably improve performance and security.
[+] [-] cameldrv|9 years ago|reply
Instead, they may simply be dropping support for 32 bit apps on a 64 bit CPU. Having to support 64 bit and 32 bit apps one a single device forces them to ship two versions of every shared library, and is probably annoying for them in various types of interprocess communication, because, for example, CGFloat and integer types are different sizes.
My guess is that they will release a 32 bit version of iOS and a 64 bit version, and each one will only run apps for the native processor word size.
[+] [-] FollowSteph3|9 years ago|reply
[+] [-] djrogers|9 years ago|reply
[+] [-] 0x0|9 years ago|reply
[+] [-] johndoe4589|9 years ago|reply
Noooooo :( Pleas say it ain't so...
"PDF Highlighter" by omz:software is one of my favorite apps on the iPad. The only PDF app that doesn't have a million things I don't need, and has a beautiful summary of all the highlights you make in your PDFS..plus Dropbox .. plus OCR. Oh, and highlight colors that don't look like they were put in by a 3 year old jesus. What's up with all those annotate aps using FF0 yellow or F00 red? What happened to design? Why do all these PDF apps have to suck so bad as a reading experience?
Sigh.
https://appadvice.com/app/pdf-highlighter/400191310
[+] [-] azinman2|9 years ago|reply
[+] [-] ClassyJacket|9 years ago|reply
This implies there is still a "standard" iPad for sale. In fact, the iPad Air was simply the successor to the iPad 4, and the iPad Pro was the successor to the iPad Air 2. There is no "standard iPad" on sale anymore, and there hasn't been for years.
This won't directly affect any device Apple has sold in some time. The iPhone 5C is the last iPhone they released that was 32bit, and was likely to be dropped for software updates with the release of iOS 11 anyway.
In short, there's nothing to worry about, except if you want to run an app that hasn't been updated in 2+ years
[+] [-] Malic|9 years ago|reply
I might have to get an Android device just for classic games, like his.
http://minotaurproject.co.uk/blog/?p=376
[+] [-] valuearb|9 years ago|reply
[+] [-] markcerqueira|9 years ago|reply
Is this true? If I recall correctly, 32-bit to 64-bit doesn't always necessarily mean "end-user performance improvements."
[+] [-] elihu|9 years ago|reply
https://en.wikipedia.org/wiki/X32_ABI
https://lwn.net/Articles/456731/
[+] [-] xenadu02|9 years ago|reply
Technically it doesn't.
In practice only two architectures matter: x86 and ARM. Both brought cleaned-up ISAs, expanded the number of general-purpose registers, made some features required, and made other improvements during the transition.
So for all practical purposes: YES, the 64-bit transition has actual real benefits to end users besides the larger address space.
[+] [-] fulafel|9 years ago|reply
Generally, other things equal, going from 32 to 64 bit word size makes things slower because pointers suddenly double in size, and you can fit fewer program objects in your caches.
In practice there are a slew of miscellaneous improvements in the new 64-bit revision of an instruction set that makes up for some of the slowdown. This is less pronounced on ARM, but was big on x86 because a big flaw, the register count, was fixed.
[+] [-] ytch|9 years ago|reply
https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...
[+] [-] Sanddancer|9 years ago|reply
[+] [-] readittwice|9 years ago|reply
[+] [-] anonova|9 years ago|reply
[1]: https://www.archlinux.org/news/phasing-out-i686-support/
[+] [-] yoz-y|9 years ago|reply
[+] [-] makecheck|9 years ago|reply
— Dependencies on other 32-bit libraries that have not changed.
— Dependencies on entire OS frameworks that have not migrated to 64-bit (and Apple has at least one of these).
— Having a “plug-in” feature, whereby cherished plug-ins have not all migrated to 64-bit so the user must then choose a 64-bit subset.
— Any number of problems in the code itself, such as improper assumptions made about the sizes of data structures or creative solutions that only made sense on 32-bit platforms. After a simple recompile, the code may crash in places or consume much more memory. Floating-point values may produce subtly different results, creating issues all over the place.
[+] [-] magoghm|9 years ago|reply
[+] [-] kriro|9 years ago|reply
I think technically it makes a lot of sense but for customers this is pretty bad. Compared to Microsoft's 15 years of extended support for an OS (iirc. 5 is standard). Ubuntu LTS is 5 years. Sure there's a difference when you're the hardware vendor and the OS vendor but still I'm not sure this is a great move.
[+] [-] johncolanduoni|9 years ago|reply
[+] [-] swerner|9 years ago|reply
[+] [-] jug|9 years ago|reply
It feels surreal to read this line of complaints about this when Apple is in such a high regard when it comes to precisely smartphone support.
[+] [-] valuearb|9 years ago|reply
And Windows compatibility with so much old software is a big reason why it sucks. There are too many apis that should have been deprecated and hacks to support specific apps that bloat it up.
[+] [-] jmkni|9 years ago|reply
There is a definite opportunity for app developers here.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] rebootthesystem|9 years ago|reply
Why?
It's a simple matter of economics: Creating apps for iOS is, and has been, for a long time, unprofitable for most developers. Last I looked, most can't earn a living, which means they are working for far less than what they could otherwise earn doing something else.
A good deal of the existing 32 bit apps are simply going to die off as developers abandon them.
This could be good, of course, as it might improve discoverability in certain categories. Time will tell.
[+] [-] acqq|9 years ago|reply
Which means that even if I've paid for the content, now I'll have to purchase it again from another developer only because some random limitation is introduced, and even that purchases can soon disappear again.
[+] [-] mrmondo|9 years ago|reply
[+] [-] Traubenfuchs|9 years ago|reply
Does it reduce engineering/research effort, production costs, chip size, size of binaries, duration of compilation, programming effort and improve performance: If yes, by how much?