
The future of iOS is 64-bit only: Apple to stop support of 32-bit apps - intuzhq
http://www.macworld.com/article/3163248/ios/the-future-of-ios-is-64-bit-only-apple-to-stop-support-of-32-bit-apps.html
======
saurik
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).

[https://arstechnica.com/apple/2017/01/future-ios-release-
wil...](https://arstechnica.com/apple/2017/01/future-ios-release-will-soon-
end-support-for-unmaintained-32-bit-apps/)

~~~
xj9
i'd just like to interject for a moment..

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/](https://www.fsf.org/)

~~~
jl6
Quite. When you accept a dependency on proprietary software, you open yourself
to the risk of the vendor withdrawing support. Looks like that risk
materialized for some users today.

This is an "I told you so" moment for a lot of Free software advocates.

~~~
saurik
FWIW, as a serious advocate of Free Software (someone who constantly travels
around to developer conferences, college hackathons, and even sci-fi
conventions giving talks that stress the benefits of the GPL3), this doesn't
help and almost becomes a non-sequitor, as it makes it sound like a business
decision related to productivity applications. I doubt anyone would say they
"rely" on Trainyard, and the Trainyard developer did "rely" on iOS, but they
probably liked that and for all I know they are dead now (I realize they
almost certainly aren't, but like: this is the extent to which they aren't
relevant).

As a free software advocate, there isn't a group of "some users" whom I get to
point at and say "I told you so": in fact, most of the people who played
Trainyard and enjoyed it probably don't even care that it is going to be
inaccessible. And while I sort of care myself about some specific
applications, it isn't about people like me either. The devastating reality is
that this purge of 32-bit software combined with the centralized control on
the computers that are capable of running it is a devastating blow to society
as a whole, and the people who are causing it are the people who either don't
directly feel the downsides (as historical preservation is an externality,
like pollution) or are actually in the minority of people who experience an
_upside_.

Advocating for free software is good as it can be a weapon in this fight, but
in practice Apple just isn't feeling the burn: when they wanted a new
compiler, they hired a ton of engineers and wrote one so they didn't have to
rely on gcc anymore. There is only so much power in the lever of free software
to force societal change in a way that doesn't continually lead to a handful
of resistance fighters looking at the carnage of the land and thinking "I know
what will make me feel better: I'll point at the majority of people who don't
even understand this enough to notice and the handful of people who are happy
this happened and yell 'I told you so'", particularly when developers like
Linus Torvalds, who have critically important positions, aren't fighting for
the same battle.

My claim: _we need regulation_. In the same sense that we have regulation
about pollution--to keep a handful of people who benefit from pollution enough
to not care about its downsides to society (and them) from doing horrible
things--we need to regulate companies like Apple to force them to provide open
platforms and to have some reasonable set of responsibilities when it comes to
sunsetting older hardware. The issue of closed vs. open ecosystems is
_related_ to free software, but _isn 't the same_, and we need to be paying a
lot more attention to the former and avoid a lot of knee jerk to the latter if
we want to prevent some of the worst case scenarios.

~~~
spronkey
Amen.

I also see this somewhat as a 'own your s __t ' scenario. Apple makes all of
these systems and platforms, and then proceeds to abandon them, producing
waste (in both materials and developer time for the apps that get updated for
nothing but compatibility reasons).

They update their APIs, deprecate the old stuff, at a breakneck pace, and they
leave a great mess behind. They should be forced to think more about the mess
they are making, and be unable to leave it without penalties. One way for them
to not leave it would be to open it up. Another way would be to support older
versions for a longer timeframe, and allow users to continue to download and
use them.

Either way, it's not in Apple's interests to do this - they're much more
content to force this crap down our throats, and rely on us just dealing with
it because there really isn't any choice.

~~~
valuearb
The mess they are leaving behind are outdated, crappy apps. They don't adapt
to modern screen sizes, use memory efficiently, download efficiently
(bitcode), etc.

Apple is continuously improving and modernizing it's platform. They should be
banning hundreds of thousands of zombie apps that haven't been touched in many
years because they are not valuable and misleading to customers. But they
don't, they allow you to keep your apps available on the store no matter how
old or how poorly written. Finally they have their first platform change
that's going to break them, and they can automatically boot them. That's a
very good thing.

~~~
spronkey
For another example, a thread today brought up Winamp. Winamp's last major
updates happened, quite literally, a _decade_ ago.

This is a player that works just fine on Windows 10, and there's definitely a
case to be made that it's better [overall] than any more modern alternative.

This type of software can never happen on iOS, and is quickly becoming a relic
on Mac OS.

The core principles of good software haven't changed much over the years. UI
(in HCI terms) has in many ways not moved forward much at all. Apple are
changing their platform it seems, more for the sake of change, than for the
sake of real progress. And they're forcing some really good software out
because of it.

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

~~~
exDM69
Yes, it would be a smart move if they can actually drop the 32 bit mode from
the CPU/SoC but I wouldn't be so sure about that. Having the 32 bit mode may
still be required for the firmware/bootloader/OS early boot environment.

The 32 bit mode may be partially or fully implemented using microcode and the
actual silicon area that could be saved by this might not be that big.

What comes to OS and firmware, yes it could be simpler but most of the code is
probably there already. Getting rid of it would mean more engineering work,
not less (in the short term). On the other hand, removing the parts would
reduce maintenance burden in the long run. And Apple doesn't care about
supporting old hardware anyway so they might as well drop it.

I work with ARM SoC's but the above is no more than an educated guess as I
don't know details about their CPU architecture or firmware/bootloader/OS
software, take it with a grain of salt.

~~~
nicky0
Presumably they can write their firmware using 64-bit code too? is there a
reason it would still be 32-bit?

~~~
exDM69
If it's all their code, yes they can do it (it might be a lot of engineering,
though). But it might contain 3rd party code or dependencies to something
that's non trivial to port to 64 bits.

If you go look at the boot procedure of a modern ARM SoC, it's pretty complex
(also it's different for every SoC, there's no governing standard like the "PC
is for x86"). The CPU may go through several operating modes and the procedure
of booting up the cores is non-trivial.

I do not think it's impossible, but the benefits for all that engineering work
may not be as great as GP suggests.

They are in a pretty unique position as they control all the hardware and the
software, though.

~~~
my123
There is UEFI+ACPI on ARM also, that's how Windows on ARM works. Windows on
ARM devices use a far more desktop-like bootchain than anything else

~~~
exDM69
Yes, but that's in addition to the dozens of proprietary boot procedures
commonly used by Android tablets and smartphones and other ARM devices.

~~~
bostand
Actually there are more or less only two big ones used in 2017: the well
engineered open source boot solution that ARM started and is now backed by
Linux and that piece of garbage that Qualcomm uses.

Hopefully next year this time there will be only one.

~~~
my123
UEFI with ACPI on ARM was started by Microsoft first, but is now the ARM
standard :)

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

~~~
FollowSteph3
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.

~~~
valuearb
It had 256 megs of ram. I'm running the latest OS on an iPhone 5c that is 4
and a half years old.

The pace of change in phones/tablets has been tremendous since the iPhone and
iPad were released. Current versions are more than 10x faster and ship with
much more ram. There aren't infinite resources at any company (unless you want
the army of programmers failed model from IBM of yore), focusing limited
engineering resources on most important issues is crucial to making progress.

You got an iPad that worked well. They stopped enhancing it after 2 years.
When did your car maker stopped enhancing your car?

~~~
mikeash
The trouble with the car analogy is that internet-connected devices need
constant security updates, whereas cars don't. A car built ten years ago is as
safe as it ever was, minus whatever problems arise from wear and tear. A
device running iPhone OS 1.0 will probably not survive long on the internet of
2017.

------
djrogers
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).

~~~
masklinn
> This doesn't sound as devastating as some of the tweets and headlines would
> imply (that seems to be common these days).

Most of these applications are games, the developer may not even be alive
anymore at this point and there's no ROI in updating working complete games
just because they are old.

Your basic actual game (not the F2P/IAP garbage) just creates an opengl
context and handles touch input, that stuff only breaks when the OS itself
breaks core API, I've got many games from my early 3G/iPhoneOS2 days which
still run fine on a 7 running iOS10 (though not all of them).

~~~
valuearb
If the developer is dead, what man alive now could ever figure out how to open
it in Xcode 8 and click "compile"?

~~~
jeff_tyrrill
Many other requirements have been instituted from iOS version to iOS version
that require substantial work to bring old code up to current App Store
standards. Among them are things like screen size support and retina-
resolution assets. Meanwhile, many of these apps still work perfectly fine on
iOS 10, even if Apple won't accept those submissions today.

------
0x0
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.

~~~
danudey
The fact that those apps are still 32-bit means they're unmaintained. The fact
that they're unmaintained means that they're likely to break at some arbitrary
OS update anyway. Even common apps like Tweetbot, by reputable developers,
will break on a new major version, so your app that hasn't been updated in
years is probably going to die off soon anyway.

The only way to make sure to keep those apps open is to keep from updating
iOS, and if you do that this doesn't affect you anyway.

~~~
0x0
There's no reason apps should break on arbitrary OS updates as long as they
are well-behaved and stick to documented UIKit APIs and so on. I have apps
from 2009 that work perfectly well for the task they need to do. The companies
have long since folded and closed down their app store account. Others have
similar apps, perhaps controlling $1000+ worth of DVR equipment. I think (and
hope) Apple may be underestimating the effect of a vocal minority still
requiring these apps, and the chilling effect this may have on paid apps or
even free apps for the made-for-iphone hardware program in the app store in
general.

~~~
saurik
And a lot of games hardly even use UIKit, relying only on OpenGL ES and some
input handling logic: these are the kinds of apps I would expect to
essentially never break (and would usually assume a platform bug if they did
break).

~~~
giovannibajo1
I run iOS public betas and many games break during the beta period of new iOS
versions. Even highly-rated apps like Rayman Run has been completely broken
for weeks for me; like the audio breaks out, the touch input is not accepted
in some menus, etc. At some point I couldn't event start the game. Then, an
update arrives and everything is fine.

------
johndoe4589
> 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?

Sigh.

[https://appadvice.com/app/pdf-
highlighter/400191310](https://appadvice.com/app/pdf-highlighter/400191310)

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

~~~
valleyer
Don't forget that the newest Apple Watch is 32-bit.

~~~
richardwhiuk
Apple Watch (from a development perspective) runs bitcode, not
armv6/armv7/armv7s.

~~~
0x0
32bit bitcode. You can't go from LLVM bitcode to both 32bit and 64bit as far
as I understand. You need "bit-specific" (architecture-specific) bitcode.

------
ClassyJacket
"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

~~~
josephpmay
My dad still uses an iPhone 5. Will he be unable to download any app updates
until he gets a new phone?

~~~
X-Istence
Yep. Nor will he be able to get the latest version of iOS. So just like any
other upgrade that removed older devices from the supported list.

~~~
xenadu02
Based on what evidence? Apple still accepts 32-bit slices if you want to
submit them. 64-bit slices are required.

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

[http://minotaurproject.co.uk/blog/?p=376](http://minotaurproject.co.uk/blog/?p=376)

~~~
valuearb
I'd be mad at Jeff Minter. Not Apple.

------
markcerqueira
> Since a 64-bit processor processes more data at a time than a 32-bit
> processor, you get faster performance.

Is this true? If I recall correctly, 32-bit to 64-bit doesn't always
necessarily mean "end-user performance improvements."

~~~
xenadu02
_sigh_

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.

~~~
cameldrv
Assuming you don't need the extra address space, what are those? End-user
improvements that is... Performance wise, I doubt that the performance gains
from extra registers make up for the higher cache miss rate from the larger
code and data sizes.

~~~
johncolanduoni
Being able to rely on at least SSE2 is a big win for 64-bit on x86.

Technically you could use 32-bit addresses on a 64-bit processor and not have
your data be any bigger, but most languages don't offer a good way to do this
(IIRC the HotSpot JVM's UseCompressedOops option does something along these
lines).

~~~
andreyv
This is actually implemented on Linux/glibc:
[https://en.wikipedia.org/wiki/X32_ABI](https://en.wikipedia.org/wiki/X32_ABI)

You can compile C/C++ programs using this ABI, and get all 64-bit benefits
without 64-bit pointers.

------
anonova
Arch Linux also recently announced phasing out the 32-bit distribution (though
multilib will still be available).[1] Perhaps the start of a trend.

[1]: [https://www.archlinux.org/news/phasing-
out-i686-support/](https://www.archlinux.org/news/phasing-out-i686-support/)

~~~
kogepathic
That's a different kettle of fish.

Multilib means you can still run 32-bit binaries. Although given Linux doesn't
have a stable ABI, I haven't found that 32-bit Linux binaries age well (e.g.
if you run something from 10 years ago, it's probably using OSS, enjoy trying
to wrap that to alsa...).

Arch is deprecating the i686 only distribution. Which IMHO is a good idea.
Multilib support is generally excellent, and to my knowledge no one who is
shipping i686 systems (e.g. industrial PCs with a 10 year availability) is
using Arch Linux anyway.

~~~
andreyv
From my experience, the aoss wrapper works pretty well. I had the UT99
Loki/UTPG port running with it with no problems.

------
yoz-y
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.

~~~
makecheck
“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.

------
magoghm
It feels really weird to me that now 32 bit CPUs aren't considered good enough
even for a telephone. Maybe I'm getting old.

~~~
Sargos
Did you write this just to be snarky and call it a "telephone"?

An iPhone is more complex than the desktop computer you wrote this comment on
and you know it.

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

~~~
johncolanduoni
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?

~~~
Sargos
This is markedly different because most applications written for the first
versions of Android still work even on the newest version of the OS. Apple is
explicitly breaking 32bit applications from running on the device/OS. Remember
we are talking about application compatibility which is not much related to OS
updates.

~~~
valuearb
Unless the developer recompiles. Which is simple to do.

------
jmkni
It would be nice if they published a list of the software which will no longer
be supported.

There is a definite opportunity for app developers here.

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

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

------
mrmondo
So glad this is happening, it'll be a nice forced purge of old outdated apps,
also there is no good reason to have a 32bit app in 2017...

------
Traubenfuchs
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?

------
EugeneOZ
Online banking app of my bank is 32-bit, so for me it means "don't update
anymore".

~~~
al2o3cr
Nobody at the bank could be bothered to push the "Build" button in Xcode since
JUNE 2015? (when they stopped accepting 32-bit apps) Sounds like you need to
upgrade your bank...

~~~
ValentineC
I'm guessing it's more because they want to support customers who might still
be on iOS 6. The 64-bit compiler only came with the iOS 7 SDK.

Five years doesn't seem like a long time at banks, even though iOS 6 probably
has a whole bunch of privilege escalation exploits that wouldn't be very nice
to deal with.

~~~
massysett
Seems to be a good reason to have a mobile website as well as apps. Though
I've never bothered to see if my main bank even has a decent mobile website
because I always use the app. But another bank I use has only a mobile website
and has no app.

------
mnd999
So the Squeezebox remote app is finally going to break. How annoying.

------
cooper12
Say what you will about legacy support or planned obsolescence, but Apple has
been constantly pushing the computing envelope exactly because they don't have
to be Microsoft and get held back by older technology.

~~~
averagewall
Yes, only Apple could get away with this and it's great that they're willing
to sacrifice a few short term $ for the long term benefit. Sure, a lot of
software will become useless. Same as happened with all the Mac architecture
changes over the past couple of decades. Apple developers should should expect
to stay on the ball and users should expect not to start depending on old
unsupported software.

If you prefer longer backward compatibility, and no rush to keep updating
everything, use Windows, but pay the price in ugliness.

I'll be glad when all 32 bit platforms are out of use. There's so much
duplicated code around and time wasted debugging 32/64 bit mixups.

~~~
simonh
> Yes, only Apple could get away with this

Android phone vendors drop support for their devices and software like a stone
all the time, but it's just considered business as usual. Apple twitches in a
vaguely unexpected way and the internet burns down in paranoid outrage.
Personally, I'm going to wait until we actually find out what this means.

~~~
saurik
So, some people are talking about iOS itself possibly dropping support for
32-bit hardware, while others (including myself) are talking about issues with
existing hardware not even being able to run things that will soon no longer
be downloadable, and are taking this as an opportunity to lament over the lack
of historical preservation of software. FWIW, you might mean the former, but
I'm going to address the latter.

In one of the few really legitimately "open" things Google does with Android,
they provide emulators for their devices and downloadable historic stock
firmwares; and because they don't have control over their hardware, they don't
have the ability to implement "actually good" DRM on their application archive
files. Apple has set up an environment where when they sunset something, it
will actually fade from existence: that is not the case with Android.

------
Frogolocalypse
TIL there are still 32-bit apps for apples.

------
andrei512
this translates to: swift will be included with the next iOS

~~~
masklinn
That makes no sense. You can already develop iOS (or tvOS) applications in
Swift, the runtime bits are provided by the pre-existing Objective-C runtime.

~~~
zydeco
Every app that uses Swift embeds its own copy of the Swift runtime libraries,
since they are not part of the system (the ABI isn't stable yet).

------
general_ai
I wonder if they will at some point remove the crap that's needed for 32 bit
mode from the die. That could shrink the die size a tiny bit.

------
reilly3000
iPhone 5 users are plentiful and will be pretty livid if they are locked out
of a future major version over this issue. Apple just can't get out of their
own way these days. If I were an iPhone 5 user and was forced into a twinked
device like the iPhone SE or iPhone 7 I would probably leave the entire
ecosystem and hundreds of dollars worth of DRM purchases behind.

~~~
X-Istence
Do you have stats for how plentiful iPhone 5 users are?

The Apple iPhone 5 was released in 2012. Apple has provided those users with 5
years of updates (assuming September is when they will release the new iPhone
and also update the major iOS version number).

5 years is a long time in the mobile handset business... I doubt too many
people will be livid about anything.

~~~
bruceb
You assume everyone purchased the iphone 5 in 2012. The iphone 5c was still
selling new in India less than a year ago.

Also new ones still listed for sale direct from Walmart it appears:
[https://www.walmart.com/ip/Apple-iPhone-5C-8GB-AT-T-
Locked/4...](https://www.walmart.com/ip/Apple-iPhone-5C-8GB-AT-T-
Locked/45722852)

If you purchased a new device and in less than a year support is dropped, yeah
you might be livid.

~~~
tuxracer
Standard practice in the world of Android phones. To add even more salt to
that wound the OS was probably a couple years out of date when you bought it
as well.

------
BuckRogers
I can only presume part of a long ramp up for an iOS Macbook play.

~~~
millstone
If you have no 32 bit processes on the system, then 32-bit shared libraries
don't have to be loaded (saving RAM), can be omitted from the system entirely
(saving disk space), and don't have to enter into the test matrix (saving
engineering time). I suspect it's as simple as those optimizations.

~~~
ProAm
With hardware SO cheap, and the amount of RAM or disk space these take up it
would be self destructive for Apple to ostracize so many customers over
something that is literally dirt cheap to accommodate.

~~~
sroussey
No, the 32bit libs will cause havoc with the CPU cache. Good to drop them.

~~~
ProAm
Yeah sure burn more customer goodwill after the last batch of MacBook Pro's...
Apple is in customer maintenance mode, Tim Cook especially, technically this
might make sense ,just be prepared for customer backlash at a time when Apple
really doesnt need anymore of that.

