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

[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

[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

[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

[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

[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

[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

[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

[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

[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.

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: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.

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.