The Future of iOS is 64-Bit Only -- Apple To Stop Support For 32-Bit Apps (computerworld.in)

Your ability to run 32-bit apps on an iOS device is coming to an end. As several other Apple news sites have reported, Apple has updated the pop-up warning in the iOS 10.3 beta to say that the 32-bit app you're running "will not work with future versions of iOS." The warning goes on to say that the "developer of this app needs to update it to improve its compatibility." From a ComputerWorld article (edited for clarity): In October 2014, Apple told developers that all new apps created after February 1, 2015 must have 64-bit support. Shortly after, Apple announced that all updates to apps must also be 64-bit compatible. Any 32-bit apps submitted to Apple after June 2015 would be rejected. Last September, Apple announced that it was going to remove apps from the App Store that did not "function as intended, don't follow current review guidelines, or are outdated." Presumably, this would include apps that did not meet the 64-bit requirement. Apple does not state which version of iOS will be 64-bit only, but since this is a major development, you can probably assume that this will happen in iOS 11. An announcement will likely be made during Apple's Worldwide Developer Conference this summer. The switch to 64-bit only support means that older iOS devices built on 32-bit architecture will not be able to upgrade to the new iOS. 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.

Comments

Assumption

[mccalli]

Apple has said no such thing and this is assumption based on extrapolation of some dialog text. I think it is likely, but this is being presented as fact when it's still assumption at this point.

Re:Assumption

[NatasRevol]

Well, did you see the ComputerWorld artilce copied in TFS? Because it says Apple did say that.

Re:Assumption

[mccalli]

It doesn't. Apple have said you must support 64bit. They haven't said you must drop 32bit. Universal apps could still be supported.

Re:Assumption

[NatasRevol]

So in your world, 'must support 64bit' isn't 'must drop 32bit'?

Re:Assumption

[Anonymous Coward]

So in your world, 'must support 64bit' isn't 'must drop 32bit'?

https://en.wikipedia.org/wiki/Mutual_exclusivity

Re:Assumption

[mccalli]

Correct. Universal apps, or fat binaries or whatever you want to call them, are the norm in Appleland and have been for quite some time. You distribute a single application and the system picks which binary to actually run.

Re:Assumption

[TheRaven64]

Correct. Previously you were allowed 64-bit only, 32-bit only, and 32- or 64-bit universal. Now you are not allowed 32-bit only. That said, 64-bit does have some quite significant advantages for iOS, so I don't imagine Apple wanting to keep the 32-bit code around in the OS for longer than they have to. If you've got an iOS device with a 32-bit processor, your days of updates are probably numbered.

Re:Assumption

[Anonymous Coward]

Note how, unlike the warning that was reinstated with iOS 10.1, this alert clearly states that "this app will not work with future versions of iOS" as opposed to "may slow down your iPhone".

Re:Assumption

[squiggleslash]

The flaw in your argument is that supporting 64 bit and 32 bit binaries on OS X derived operating systems is not mutually exclusive. Indeed, at one point (one small point, lasting a year or two during the transition to Intel) most desktop apps on OS X were shipped supporting 32 bit PPC, 64 bit PPC, 32 bit ix86, and 64 bit amd64 architectures - all in the same package.

OS X derived OSes use a system called "fat binaries" that contain two or more binaries compiled - usually from the same source code - for each CPU architecture the app supports. The operating system chooses which to run. Interestingly I believe ELF has the same capability, but nobody ever uses it.

Don't worry, I suspect your misapprehension is common and is why the article is misleading to begin with...

Re:Assumption

[hattig]

An old (as updated apps have mandated a 64-bit binary alongside the 32-bit one for a while now) 32-bit app would still work if the OS supported 32-bit apps.

Therefore, logically, support for 32-bit-only apps is going. This may be an iOS 11 thing, or it may be an Apple A11 thing (remove AArch32 support in hardware).

It's likely an OS thing - maintaining two sets of OS APIs must have quite some overhead, when there are so many.

Re:Assumption

[Khyber]

"That said, 64-bit does have some quite significant advantages for iOS, so I don't imagine Apple wanting to keep the 32-bit code around in the OS for longer than they have to."

64-bit is nothing but extended 32-bit x86 (at least, as far as Intel/AMD goes.) There's literally no reason for essentially basic x86 code to not fucking run. There are tons of programs that simply do not benefit from having a 64-bit address space and forcing them to code for it is just adding unnecessary bloat and vulnerability.

Re:Assumption

[Half-pint HAL]

This article is about iOS, not Mac OS/OS X. There are no fat binaries on iOS -- it is an either/or proposition.

Re:Assumption

[Anonymous Coward]

From the article, "Presumably, this would include apps that did not meet the 64-bit requirement." The key word there is "presumably," which means the article author made it up, not Apple.

Re:Assumption

[Archibald Buttle]

iOS devices are not x86 based - they're ARM - so no "basic x86 code" will run on them at all.

The only place that iOS runs on x86 is in the simulator on OS X and such x86 code is not included in builds for iOS devices.

64-bit ARM is different from 32-bit ARM, and not even remotely like "extended 32-bit x86".

Re:Assumption

[MachineShedFred]

No, it isn't. Have you heard of a "fat binary" that can contain both 32-bit and 64-bit versions of the app? Does that concept not exist in "your world", as you put it?

it's only been a thing for like 10+ years now in the rest of "our world." Such a package would "support 64-bit" while not dropping 32-bit.

Re:Assumption

[Khyber]

Okay, so basic 32-bit ARM code doesn't run on 64-bit ARM hardware.

Way to kill ARM's usefulness, Apple. Meanwhile, on my Android phone, I can run whatever the fuck I want without issue.

Further proof that Apple isn't about giving people what they need, only what they want, and they take advantage of it to the degradation of the computing community.

Re:Assumption

[MachineShedFred]

Article is still talking about iOS here, which is not x86 in any way. It's ARM.

Re:Assumption

[TurboStar]

\There's literally no reason for essentially basic x86 code to not fucking run.

You believe that because you don't understand how powerful an MMU can be when coupled with non-volatile storage and how difficult and resource intensive maintaining a 32-bit compatibility layer can be.

Re:Assumption

[Dog-Cow]

You are completely ignorant. Developers have been shipping fat binaries on iOS for years. Even before the 5s added 64bit support. Virtually every iOS ships with three slices today: armv7, armv7s and arm64.

Re:Assumption

[squiggleslash]

FFS, why do you think I used the term "OS X derived operating system" throughout my comment? Or do you think iOS isn't derived from OS X?

And yes, there are fat binaries in iOS. There always have been. You think Apple thought "Nah, we're never going to use anything but 32 bit ARM for our iDevices?" when they built iOS and wasted huge amounts of time removing the functionality? How do you think developers handle the situation today? Do they just ship 32 bit executables, because if they ship 64 bit executables then anyone with an older device will be unable to use their apps?

Re:Assumption

[Anonymous Coward]

Don't you remember the compatibility and stability mess that was Windows back when it had to deal with 16-bit and 32-bit code simultaneously? That clusterfuck is why Apple is wise to abandon 32-bit at the earliest opportunity.

Re:Assumption

[Solandri]

That said, 64-bit does have some quite significant advantages for iOS, so I don't imagine Apple wanting to keep the 32-bit code around in the OS for longer than they have to.

Microsoft ran the same hyped up 64-bit campaign when switching from 32-bit to 64-bit Windows.

64-bit basically gets you three things.

• A flat memory space above 4 GB of RAM. This is convenient (especially if a single program actually needs to store more than 4GB of data), but not necessary. 8-bit could only address 256 bytes of memory, 16-bit only 64kB. We got around in those days with segmented memory. Given a choice I would always pick flat memory over segmented, but it's not a show-stopper.
• double floats and long ints (long long int in the old days) can be loaded and handled in one instruction instead of two. Regular floats are 32-bit, as are regular ints (long int in the old days). Those are handled exactly the same as on a 32-bit processor. The vast majority of programs do just fine with a 4 billion int range, and single point floating point.
• Char types can be handled 8 bytes at a time instead of 4 bytes at a time. This isn't as useful as it sounds - it mostly affects data compression where you're handling a long, continuous stream of chars. Most other operations are not bottlenecked by the speed at which you can handle chars.

That's it. The vast majority of programs run exactly the same speed in 32-bit as they do in 64-bit, except they take up a bit more memory. So there's no advantage to 64-bit, and a slight disadvantage. The only programs which benefit from 64-bit are ones which need more than 4GB of RAM (no iOS device yet has more than 4GB of RAM), ones which need double floats or long ints (mostly scientific applications large accounting databases and spreadsheets - stuff you wouldn't want running on an iOS device), and ones which do a lot of data processing like compression. Most of the speed advantages of Apples 64-bit processors in iOS device benchmarks was due to new instructions and hardware functions they added, not due to it being 64-bit.

As practically no iOS program can actually use 64-bit to its advantage on their current hardware, right now it's mostly marketing hype to get people with older hardware to feel bad and upgrade (even though the upgrade provides no advantage). Long-term, Apple is being proactive about trying to avoid falling into the trap Office fell into. A lot of the extensions written for Office are 32-bit, so Microsoft still recommends installing 32-bit Office instead of 64-bit Office a decade after we transitioned to 64-bit Windows.

Re:Assumption

[Guspaz]

32-bit code runs fine on 64-bit ARM processors: Apple has been doing it for years. 64-bit ARM is not not a minor extension to 32-bit ARM as is the case on x86, though. Apple may have decided they want to slim down iOS by removing all the 32-bit binaries/libraries, or they may have decided that they want to drop the 32-bit instruction set from their processors to spend the transistors on something else. Or perhaps they've decided to do no such thing, since this is all based on assumptions from a textbox in a beta OS that says such a thing might happen in the future.

Re:Assumption

[Anonymous Coward]

64bit is clearly the way forward with the memory sizes in mobile devices.

It makes little sense to maintain the compatablity/interop part of your operating system if you're working away from 32bit. Apple has tight control of their environment and there isn't any good legacy reason to keep 32bit applications.

Apple shipped the 5s, their flagship phone, with a 64bit arm CPU when nobody was even /sampling/ 64bit arm silicon. Apple has a big jump on 64bit and they've been working towards this for years.. When the last 32bit only iOS devices fall off of extended support, so will 32bit iOS apps.

Re:Assumption

[Anonymous Coward]

Yeah, SlashDEAD is nothing but idiot millenials like BeauHD posting politicized SPAM and MORONS sitting in their mothers' basements on their iMacs posting to SlashDEAD while being distracted by the gay porn they're watching in their iFruits with popups from Grindr and Tinder. This is the type that puts diesel fuel in their vapes and kills about 30% of its [sic] brain cells and rather than think for a second that they have NO IDEA WHAT THEY ARE TALKING ABOUT would rather tell you that you're stupid for failing to realize that they are stupid and have no idea about any modern CPU architectures, ISAs, OSes, compilers, formats (oh let's see....ELF and so on), and knowledge of support for binaries compiled for different memory spaces. Because that's really all that's going on here. Some lame brain thought that it would be cute if the world could get past a 4GiB ceiling and continue on with its business. It's almost as retarded as saying that Linus Torvalds is going to discontinue support for "single core applications" because no CPU has just one core anymore.

Re:Assumption

[the_B0fh]

Seriously? How do you think 32bit and 64bit binaries exist in a package? Do you think Apple, having developed this for OS X, would then turn around and do something else on iOS, which is basically running on top of the OS X kernel?

Re:Assumption

[the_B0fh]

Apple is forcing the app developers to keep their applications updated. On the source code side, they have to do some minor work.

Apparently you think this is a bad thing. Why?

Re:Assumption

[UnknowingFool]

Way to kill ARM's usefulness, Apple. Meanwhile, on my Android phone, I can run whatever the fuck I want without issue.

Assuming what you said is true (which it isn't), I don't think Apple, even with their architectural license from ARM, can fundamentally change how ARM 32 bit APIs work. By the way, you do realize that Android suffers from the same problem because your Android OS makes the same ARM API calls.

Re:Assumption

[the_B0fh]

You are really such an expert on 64 bit arm architecture and iOS architecture aren't you? Have you even looked up any of the discussions that happened when Apple first delivered a 64bit CPU on a phone back in the iPhone 5S days, when none of the other manufacturers even had a solid roadmap? And why do you think things that are true in the wintel x86 world applies to iOS on ARM?

Re:Assumption

[Anonymous Coward]

I dare you to call the Applecare number and complain about 32-bit x86 code not running on your iPhone anymore.

I'll do the same and protest this outrageous affair. But you go first.

Snort.

Re:Assumption

[UnknowingFool]

The only programs which benefit from 64-bit are ones which need more than 4GB of RAM (no iOS device yet has more than 4GB of RAM), ones which need double floats or long ints (mostly scientific applications large accounting databases and spreadsheets - stuff you wouldn't want running on an iOS device),

That's not true. There are many advantages to using a 64 bit processor including cryptography. One of the main reasons is ARM itself will stop developing architectures for 32 bit processors. While you could buy and use 32 bit ARM legacy chips in the future, it is unlikely that ARM will continue to develop them further.

As practically no iOS program can actually use 64-bit to its advantage on their current hardware, right now it's mostly marketing hype to get people with older hardware to feel bad and upgrade (even though the upgrade provides no advantage).

How do you know this?

Long-term, Apple is being proactive about trying to avoid falling into the trap Office fell into. A lot of the extensions written for Office are 32-bit, so Microsoft still recommends installing 32-bit Office instead of 64-bit Office a decade after we transitioned to 64-bit Windows.

The problem for Office isn't just that legacy was 32 bit. The problem is that Office hasn't advanced too many features that most people feel are worth paying for a new version 32 bit or 64 bit.

Re:Assumption

[tlhIngan]

While you could buy and use 32 bit ARM legacy chips in the future, it is unlikely that ARM will continue to develop them further.

True, 32-bit ARMs have stopped at armv7.

However, ARM will still have 32-bit cores based on it for a simple reason - ARM is used in a variety of locations. In fact, ARM has 3 separate families of processors. You have the A series ("application", or what most users see) which are the powerful processor line. You also have the M series ("microcontroller") which is a 32-bit small core typically running in Thumb mode (it's quite something to program a 32 bit processor knowing you have 8/16K of flash and 1-64k of RAM).

There's also an R lineup for real-time processors, though I haven't personally dealt with them.

The only 64 bit cores belong to the A family with no roadmap to add them to the M or R families.

Re:Assumption

[Just Some Guy]

There's literally no reason for essentially basic x86 code to not fucking run.

ISA aside, there sure is: a tiny computer with limited resources is spending quite a bit of them on providing a 32bit compatibility layer of libraries, etc. Tossing that would allow those resources to more efficiently run the other applications, save battery, use less of the small and finite flash storage, and so on. In the specific case of an iPhone, it likely also means that the apps in question are probably using ancient API versions that Apple would like to deprecate, low-res graphics, have fixed-size and fixed-ratio display canvases, and aren't taking advantage of any modern features.

None of those matter so much on a PC with (comparatively) enormous storage, huge amounts of RAM, and unlimited power drawn from a wall outlet. They're a pretty big deal on a phone, though.

Re: Assumption

[WarJolt]

Android binaries are not native apps(with a few exceptions like ndk). 32 vs 64 bit argument is not really relevant for Android.

Re:Assumption

[Anonymous Coward]

True. Also one can't drop 32 bit support because there are many older devices and peeps still spend money on them.

Re:Assumption

[Applehu Akbar]

"Well, did you see the ComputerWorld artilce copied in TFS? Because it says Apple did say that."

The warning is in an iOS beta, not the current release version.

Re:Assumption

[Khyber]

If it isn't broken (example, a guitar tuning program) why the fuck fix it?

You fail at living up to your name, give it up.

Re: Assumption

[UnknowingFool]

It is relevant because a 32 bit ARM processor simply won't run 64 bit applications whether it runs on Android or iOS. The OS itself makes the calls not the Apps in Android, but the Apps cannot suddenly do 64 bit operations without some major tweaking.

Re:Assumption

[UnknowingFool]

Again while 32-bit ARM will still be used for all sorts of applications in the future, I don't see them being used for smart phones any longer. Dumb phones maybe. Thus app developers will need to move to 64 bit now.

Re:Assumption

[Anonymous Coward]

Because 32 bit is broken you fucking dumbass.

Re:Assumption

[Half-pint HAL]

You are completely ignorant.

Yes, I am.. or rather I was. Ignorance is cured by informing, so thank you for correcting me.

Re:Assumption

[Waccoon]

Tossing that would allow those resources to more efficiently run the other applications, save battery, use less of the small and finite flash storage, and so on

Not to mention other revolutionary modernizations, such as 6GB of new graphics, cutting-edge UX nonsense, and a thinner case with a smaller battery.

I'd rather have the compatibility, thank you. I'm sick of living in a world where things more than a few years are forced to die because reasons.

Re:Assumption

[TheRaven64]

That's it. The vast majority of programs run exactly the same speed in 32-bit as they do in 64-bit, except they take up a bit more memory

That's not it at all. First, on a 64-bit system ASLR has a lot more bits to play with. In a 32-bit system, you're lucky to get 12 bits of entropy (Android gets 8 bits on 32-bit systems, which is one of the reasons StageFright was so bad: 256 probes took well under a second from JavaScript and pretty much guaranteed breaking ASLR). On a 64-bit system you can easily make the search space large enough to be infeasible to probe without the OS noticing something odd is going on.

When running Objective-C code, you can store small objects inside pointers. On 32-bit systems this basically lets you store small ints, which isn't that useful (I don't think Apple even bothers). With 64-bit systems, you can store 7-character ASCII strings, which is enough for a lot of dictionary keys. This makes comparisons cheaper, reduces memory consumption, and improves cache usage (when I added this optimisation to the GNUstep Objective-C implementations, I found that 5-20% of total object allocations were stored inside the pointers instead of on the heap for typical desktop workloads). Apple also stores the refcount embedded in the class pointer for objects on 64-bit systems which, again, improves performance and cache usage.

Supporting both AArch32 and AArch64 comes with several costs. ARMv8 makes both AArch32 and AArch64 optional (though they've now fixed the spec so you must implement at least one - until then I had the world's simplest ARMv8 compliant core...). Removing the AArch32 parts simplifies the silicon and improves power consumption. Not having to have 32-bit versions of all of the shared libraries installed means that you can dramatically reduce memory usage.

Re:Assumption

[TheRaven64]

True, 32-bit ARMs have stopped at armv7.

Not true. ARMv8 contains both AArch32 and AArch64. AArch32 ARMv8 is not the same as ARMv7, it adds several new instructions. M and R profile ARMv8 chips are all AArch32.

Re: Assumption

[Anonymous Coward]

That was very different, 16-bit had almost no rules to play by and were not multitasking.

Re: Assumption

[jeremyp]

Aren't most Android apps essentially some form of Java byte code which is agnostic in terms of the word width of the virtual machine in which it is running?

32 bit emulator App

[Anonymous Coward]

Someone needs to write a 32 bit ioS emulator App and they'll get rich.

Re:32 bit emulator App

[Anonymous Coward]

And promptly lose all that money when apple sues them.

Re:32 bit emulator App

[UnknowingFool]

And how will they get rich? They'll have to run it somewhere. It's unlikely Apple will allow it to run in iOS. While it might run on other devices, the apps will not as they are locked to iOS.

Re:32 bit emulator App

[Anonymous Coward]

Good luck with that. Apple would never allow one to get into iStore, as it would contradict with their planned obsolescence strategy.

Re: 32 bit emulator App

[Anonymous Coward]

It's against Apple's rules to have code which runs other code. No Flash, no JavaScript, no VMs of any kind (e.g. JVM). It's why there aren't any real attempt to challenge Safari on iOS: you have to use Apple's js engine no matter what.

So the idea of a 32-bit code emulator is laughable.

you can still use your old apps

[known_coward_69]

your old phone will still work and even if you reset it you can download old versions of apps from the app store

you can stop hysterically crying now

Re:you can still use your old apps

[Anonymous Coward]

Not necessarily.

Apple could be dropping 32 bit support altogether in the next major iOS version, so an updated iDevice wouldn't work with 32 bit apps anymore.

Re: you can still use your old apps

[HTH NE1]

But if your apps are revealed to have a security flaw, those flaws will not get fixed for you. If the backend server supporting your app requires an upgrade that makes the old version incompatible, you lose access to that app's functionality. Unless you migrate to new hardware, your software will be forced into early obsolescence.

Re: you can still use your old apps

[Anonymous Coward]

But if your apps are revealed to have a security flaw, those flaws will not get fixed for you.

If the app is revealed to have a security flaw, Apple will pull it from the App Store, thus invalidating that part of his argument from the beginning.

Re:you can still use your old apps

[The-Ixian]

Alternative facts!

I prefer to be outraged!

Re:you can still use your old apps

[known_coward_69]

then your device won't get the latest IOS and you will continue to use what you have

i still have an ipad 2 that's on some old IOS and if i ever download an app on there it just downloads the latest version that works on that hardware and IOS level

Re: you can still use your old apps

[known_coward_69]

so? same with everything

nice thing about IOS is that apps run in their sandbox so that security issues most likely won't affect the whole system

Re:you can still use your old apps

[Khyber]

Wrong. I've already checked and 32-bit versions of Camfrog no longer exist for my fiance's old iPhone. So once that phone gets wiped, that's fucking it.

Re: you can still use your old apps

[Karlt1]

But if your apps are revealed to have a security flaw, those flaws will not get fixed for you. If the backend server supporting your app requires an upgrade that makes the old version incompatible, you lose access to that app's functionality. Unless you migrate to new hardware, your software will be forced into early obsolescence.

In the real (not hypothetical) world, when I unpacked late last year, I found my old 1st generation iPad that stopped being officially supported with OS updates in 2012. I reset it because I forgot the password and started downloading apps, I got prompts that I can download an older version. I tried Facebook, Hulu, Plex, Netflix, Google Drive (for my technical PDFs), Crackle, and I believe the CW app. They all worked..

Re:you can still use your old apps

[Karlt1]

And I just redownloaded DeadSpace that I bought years ago and was pulled from the app store over a year ago for new purchases.....

Re:you can still use your old apps

[MachineShedFred]

If you have a 32-bit processor, why would you be able to update to a 64-bit only OS? Why would Apple release an OS for a 32-bit device that can't run 32-bit apps?

This is such a non-issue it's not even funny.

Re: you can still use your old apps

[MachineShedFred]

How is that any different from any other software publisher on any other platform, ever?

Example: Microsoft releases a new version of Windows, which cuts off minimum support for otherwise perfectly working hardware. App developer X targets new version of Windows because it has a new spiffy API that allows them to cut out huge chunks of ass-pain code, causing their minimum OS requirement to be the new version of windows. Customer Y who has a PC that won't run the new version of Windows is stuck with old version of app X, which couldhave any of the issues above.

The world moves on, and backwards compatibility must be cut off at some point in order to do it.

Re:you can still use your old apps

[Guspaz]

And the iPad 2 will never have this problem, both because it has a 32-bit processor, and because it doesn't run anything newer than iOS 9.3.5.

Re:you can still use your old apps

[UnknowingFool]

Presumably you won't be able to run 10.3 and newer.

Re: you can still use your old apps

[Just Some Guy]

AFAIK, all Apple devices introduced in 2013 and later have been 64-bit. I don't think you can reasonably call mobile devices older than that "early obsoleted".

In before "I still use my Amiga and a Palm IIIxe, and these modern kids with their wasteful ways, upgrading every decade argh warble". That's nice, Grandpa. But in the real world, people upgrade their mobile devices at least every 4 years. That might not be as true now as we're approaching "good enough" in a lot of ways, but I sure as hell wouldn't want to be saddled with an iPhone 5 (the last 32-bit model) today.

Re:you can still use your old apps

[unixisc]

That's not how it works. I had the first or second generation of iPod touch and had some neat apps on it. Unfortunately, that thing could only upgrade upto iOS 4.3, so after a while, there were no apps in the app store that would work w/ that version. Best one can do is back it up on iTunes, which I did.

Re: you can still use your old apps

[Blaskowicz]

saddled with an iphone 5?, lol a couple years ago iphone 4S still was popular.

It's all just Game Boys with a touch screen and a modem anyway. What are people doing with them, running Crysis?

Re:you can still use your old apps

[Schnapple]

Presumably you won't be able to run 10.3 and newer.

Looks like 10.3 will still be usable, the "future version" of iOS is likely iOS 11.

Dang it!

[Anonymous Coward]

What about my original iPad? Will I be able to run the newest apps and IOS?

Good choice

[Anonymous Coward]

64 bit ought to be enough for anybody.

Re:Good choice

[unixisc]

By now, it's time to go all 64-bit. 32-bit should be just for embedded - maybe the Raspberry Pi's, Beaglebones, Arduinos, et al

Catchup

[Anonymous Coward]

Something Microsoft should've done a long time ago

Good.jpg

[bigdady92]

Even more reason to toss your Iphone 5 in the trash and get an Iphone X.

Not true!

[edxwelch]

It doesn't matter if that you can download old apps from the App store. The restriction is being enforced by the operating system. If you have iOS 10.3 installed on your device it will not run 32-bit apps, as the article states.
Also not many people realise that this has happened before. iOS 9 broke old versions of apps by inforcing requirement of root viewcontroller, which hadn't been inforced before.

Re:Not true!

[RandyHill]

Uh, 10.3 already runs 32 bit apps. I am running them now on it.

Re:Not true!

[edxwelch]

it gives you a warning though. In 10.4 it'll be disabled.

Only affects old payware garbage

[Lumpy]

This just means your old garbage closed source app from way back will die.
All the open source stuff can easily be fixed if it's still only 32 bit.

Aren't 32-bit devices off support anyway...?

[Half-pint HAL]

I'm a bit confused about this "stopping" support for 32-bit devices, because as of iOS 10, all non-retina devices are already unsupported, and I didn't think there was a single 32-bit retina iOS device anyway.

What we're looking at here is Apple slowly phasing out the last remnants of sales to old devices. It has been impossible for over a year to release new software targeted at people with old devices through the App Store, and it is about to become impossible to sell them new copies of software that was previously released.

This is what gets me about the Apple model (I'm an iPad Mini user -- non-retina) -- the walled garden does an awful lot to preserve the security of the device, but they then brick us old users up in a tiny corner when us and the devices we bought are of no interest to them. If they want to rent us iPads, rent us them. Don't sell them to us then make them useless when the hardware is still working perfectly well.

Re:Aren't 32-bit devices off support anyway...?

[angryargus]

I didn't think there was a single 32-bit retina iOS device anyway.

The iPhone 5 is a 32-bit retina device.

Re:Aren't 32-bit devices off support anyway...?

[edxwelch]

No. They're stopping support of running 32-bit apps on 64-bit devices.

Re:Aren't 32-bit devices off support anyway...?

[Guspaz]

It's more about users with modern devices that are still using 32-bit apps that haven't been updated in ages. Those apps may not even support retina displays.

In terms of 32-bit retina devices, the iPhone 4 was the first retina iPhone, while the iPhone 5S was the first 64-bit iPhone. Ditto for the iPad, there were a bunch of retina 32-bit devices.

Apple has tended to offer software support for their older devices for years longer than Google/Microsoft/RIM/etc have. While you could definitely argue that they're still not doing enough in that regard, they're already doing far more than any of the other smartphone manufacturers are.

Re:Aren't 32-bit devices off support anyway...?

[RailRide]

What we're looking at here is Apple slowly phasing out the last remnants of sales to old devices. It has been impossible for over a year to release new software targeted at people with old devices through the App Store, and it is about to become impossible to sell them new copies of software that was previously released.

This is what gets me about the Apple model (I'm an iPad Mini user -- non-retina) -- the walled garden does an awful lot to preserve the security of the device, but they then brick us old users up in a tiny corner when us and the devices we bought are of no interest to them. If they want to rent us iPads, rent us them. Don't sell them to us then make them useless when the hardware is still working perfectly well.

Obligatory Transformers clip

---PCJ

Re:Aren't 32-bit devices off support anyway...?

[Half-pint HAL]

It's more about users with modern devices that are still using 32-bit apps that haven't been updated in ages.

Yes, I'm thinking the summary writer may have misunderstood.

Apple has tended to offer software support for their older devices for years longer than Google/Microsoft/RIM/etc have. While you could definitely argue that they're still not doing enough in that regard, they're already doing far more than any of the other smartphone manufacturers are.

Accepted. However, the difference is that when Google walks away from support, you can still produce and procure new software for the device, if there's demand. When Apple walks away, you're left locked in an empty garden.

Apple's attitudes

[Anonymous Coward]

so I don't imagine Apple wanting to keep the 32-bit code around in the OS for longer than they have to.

Yes, Apple is always perfectly happy to break your working stuff. Because they are presumptuous assholes. They leave a consistent trail of broken OS's, non-working Apple apps, and non-working 3rd party apps behind them as they couragously blunder and stumble into the future.

I'm sick of them.

Who cares?

[Anonymous Coward]

What useful apps can't be instantly recompiled with a new modern tool chain creating a 64bit binary.

Only apps I'd imagine could suffer are ones created by things like Cordova that have never been updated or maintained. That's a very small minority.

Low end hardware

[Anonymous Coward]

All because apple ran out and bought the cheapest hardware they could find to make their ipads and iphones at one point. It's possible they would still be doing it now if it weren't for the limitations being something they couldn't work around. They of course passed the savings on to you by charging you outrageous amounts. Apple has always been a shitty company more concerned with its own greed than anything.

Arch Linux Did It First

[Grady Martin]

One week ago: https://www.archlinux.org/news/phasing-out-i686-support/

Re:Arch Linux Did It First

[Anonymous Coward]

DragonFly BSD was first.

Classic games and apps have been killed

[edxwelch]

What's really happened here is that Apple has killed all old classic games and apps.
A similiar thing happened when Microsoft released Windows 7. A lot of old games (like the origonal Xcom) didn't work on the new OS. However, because Windows is more or less open system, the comunity was able to get them working using DosBox.
But iOS unfortunately is a closed system. All those classic games are dead forever.

Re:Classic games and apps have been killed

[RandyHill]

Nope, you will still be able to download them and play them on iOS 10 and previous. Apple has not said they'd be removed from the store.

And developers have this thing called Xcode, if they click the "compile" button it spits out a 64 bit version of their classic games they can put on the store.

And windows isn't an open system. it's bloatware because it supports terribly dated old apps that require hacks to run. IT's so bloated the first Surface couldn't offer 16 gigs as entry level system because the OS required all of it.

Re:Classic games and apps have been killed

[edxwelch]

> play them on iOS 10 and previous
You're being a bit disengenuous. If you buy a new device it comes with the latest iOS with no option to downgrade. Also iOS warns you every day that you have to upgrade. Plus the fact that other apps only support the latest version. Not upgrading is not really an option.

Re:Classic games and apps have been killed

[Anonymous Coward]

HAHA A simple apple worshippers view of tech. Click the compile button, its just that easy. No wonder apple keeps selling you guys crappy tech.

Abandoned Apps

[Sherman Peabody]

One of my main apps has been abandoned by the developer, mostly because they now sell it as a yearly subscription. They will never update my pre-subscription full functionality app. Am I supposed to delete that? Why should I when I purchased a fully functional app in good faith?

Re:Abandoned Apps

[Neuroelectronic]

Apple has always and relentlessly enforced their right to not only remove your access to "Apps" but to delete them from your phone remotely.

64 bit for mobile apps?

[Neuroelectronic]

What is the conceivable benefit to having apps that can address 2TB of ram? Do any apps use more then a gigabyte that aren't leaking XML all over the place?

Thought of doing same & I already knew

[Anonymous Coward]

See subject: To my APK Hosts File Engine 9.0++ SR-5 32/64-bit https://www.google.com/search?... [google.com] - most users use 64-bit model (I ask them & it's to find out what they use more (32 vs. 64 bit)).

* @ 1st in 2012 (when I released to 'everyone' as I kept it to myself late 2002-2011 until the 'malware explosion' went crazy)?

It was about a 50/50 split, so I kept developing BOTH models... lately?

Almost ALL 64-bit users the past 1-2 yrs. now.

APK

P.S.=> I already knew this was coming as I brought it up per the above to family of mine that CONTROLS iOS builds over @ Apple. He "hinted" @ it being this way possibly there too - makes sense (didn't tell me direct but I got the picture)... apk

Loses good old apps on new devices

[FlaSheridn]

The real tragedy in TFA for owners of current devices ("Your ability to run that 32-bit app is coming to an end.") would be that you could no longer run the last good version (if it's 32-bit) of apps that have gotten worse, e.g., AppBox Pro 1.8.4, Facebook 6.9.1, Foursquare 7.0.7, GoodReader 3.21.7, iStanford 5.9.1, Pulse News 2.9.4.