Hacker News new | past | comments | ask | show | jobs | submit login
The future of iOS is 64-bit only: Apple to stop support of 32-bit apps (macworld.com)
282 points by intuzhq on Feb 1, 2017 | hide | past | favorite | 294 comments

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.

So do like Microsoft does for 16bit/DOS support in the most recent 32bit windows, and let NTVDM be an optional download that is triggered on first use. Do the same for armv6/armv7 dyld files. Maybe they could even just freeze the armv6/armv7 libs on the iOS10 API level, since old apps won't be requiring new APIs. There are important apps out there that people paid for (for both the app or the hardware), and I think those users are more interested in having a working app that uses some memory, than a blocked app but lots of free memory.

The reason that Windows sucks are often linked to it's long backwards compatibility. Remember when the first Surface came out and they couldn't sell an entry level version with 16 gigs storage because the OS took 13 gigs?

At the same time this reliable backwards compatibility is what keeps Windows in the market position it has, in particular in the corporate world.

Something a number of FOSS projects should take to heart when they fret about "year of the desktop".

Even if the compatibility layer is optional, Apple still has to maintain it and port it to new OS versions.

> Apple still has to maintain it and port it to new OS versions.

Apple decided that they don't want to open-source it. That is the reason why Apple would have to maintain it.

Ok, I love open source but let's not pretend it's that easy... "Just open source it" is something I hear from people that have never open sourced a large code base developed internally only. Look at RethinkDB, I never used it but I had wanted to on multiple occasions and it looks really awesome. They were open source from the start and yet the future of it now that the company is gone is uncertain at this time. All of this ignores the fact that the compatibility layer is much more than just 1 application and an integral part of the OS. I seriously doubt Apple plans to release tools to make development of said layer easy for for whoever can clone the project off github.

With something like RethinkDB though, you're relying on it in production.

With a compatibility layer or a game, you're just toying around, trying to make it run something. If it works - awesome, if it doesn't, you're not losing money over it.

I think there's a substantial difference here.

Apple shouldn't have to open-source anything they don't see fit to open-source for their own benefit.

With the resources that Apple has, it would be silly to throw out so much backwards compatibility just because "uh, effort".

I don't think size and resources can effectively combat this sort of accrued technical debt. Once you have to maintain so much cruft it becomes emotionally difficult to write good software (at least, I experience this).

I have a few personal projects that I have maintained for years, but the motivation required to refactor, clean and maintain the code gets bigger every year.

You have to be passionate about the software you write. And unless you can find a team that is passionate about maintaining a 32 bit compatibility layer for old App Store apps, I think it would be a permanent burden on Apple.

This is the reasoning that made Windows so crappy for so many years.

It's also the reasoning that has left Windows so dominant for so many years. There are businesses that would go bankrupt overnight if Windows broke compatibility with 32-bit VB6 applications built at least a decade and a half ago.

That only matters if you are using 32-bit software. Deleting the 32-bit software is not somehow a benefit with relation to that goal. You are saying that it is better to run all 64-bit software. I am arguing that there is essentially no benefit to a device that is incapable of running 32-bit software when it clearly still has the hardware.

I'm saying that supporting multiple ABIs has a nonnegligible cost, regardless of whether the hardware supports it or not. On my MacBook (I haven't touched an iOS device in the last 5 years), the 32-bit dyld_shared_cache is 300 MB, and the 64-bit one is over 600. There might be baked in assets that are larger on the laptop form factor, and libraries that don't exist on the phone, and demand paging might buy you some of that back, but it's still going to be an absolutely massive chunk of code.

I'm not actually arguing that this is a net win for the consumer of the device. If your choice is between a device that supports 32-bit and a device that doesn't, with literally zero difference in performance, I would totally agree with you (modulo engineering effort it takes to maintain them all, but that probably isn't too high). I'm just saying that there are real quantifiable benefits to what they're doing.

edit: and that's not considering the actual advantages of forcing 64-bit like improved security via better ASLR

What you say is true, but can you imagine trying to explain to the average user that the reason their phone is running slower than necessary is because they are using applications which necessitate multiple libraries be loaded simultaneously?

From Apples perspective, the App market is so saturated that any missing functionality will be quickly replaced. This way, everyone gets a performant system without needing to know what the difference between a 32bit app and 64bit app is.

They already show a "this app may slow down your device" alert occasionally when you open a 32-bit app. This was added with iOS 10.

Oh, is that why you get that message? Uhm, I have a few of those apps then :(

I think you're assuming the upcoming A11 chip will also be capable of running 32-bit software. The hardware may be changed, for the sake of simplicity.

As far as anyone is reporting, Apple is intending to remove support for existing devices that get updated to new versions of the firmware, not just for new hardware.

Lack of fragmentation is a good thing.

As others have said important software will be made available. Apple has the luxury of a dedicated userbase and can afford to make these calls.

I imagine they are dropping the support in new hardware too.

If I may, if all your pointers are now 64bit, the memory used by your program will typically grow significantly. Not sure that all in, reducing memory consumption is a benefit of switching to 64bit.

64-bit allows Objective-C programs to use things like tagged pointers (allowing boxed numbers, dates, small strings etc. to be stored inline in the pointer) and non-pointer isa (storing things like an object's refcount in the same word as the pointer to the object's class) which can reduce memory usage significantly.

The larger pointers will certainly cause some programs to increase their memory usage, but these changes will cause others to shrink, and the net effect seems to be more or less a wash.

iOS apps have been 64-bit for several years. Apple's tools build dual 32/64-bit binaries, and the App Store will not accept uploads where the 64-bit part is missing.

So, any modern iOS device has been running pretty much only 64-bit code for a long while.

The only thing affected by this is the ability to run really old binaries that have not been updated in years. But those will often be suffering from other compatibility issues anyway, such as display sizes and not meeting modern security standards like Apple's TLS mandate.

Among these 32bit applications there is my beloved Tetris app. Which doesn't need modern security standards or use the half of an inch more screen real estate available. If I have to chose between yet another iOS update (with the usual harassment to use apple pay, apple music, icloud and all that shit every time I upgrade) and Tetris, I chose Tetris.

I agree, so let's yell at EA and get them to update the app. I suppose they have no interest because they now have a "free" version in the App Store...

> I suppose they have no interest because they now have a "free" version in the App Store

Not "free" as in "freedom". :-(

If you think you're being "harassed" by the device offering to use essential features of the platform then perhaps it's not the device for you? I've used iOS for years and have never found any prompts that are remotely harassing about anything iirc. It's been nearly two years since they started requiring all apps and updates to be 64 bit, it's not a huge surprise this is coming.

> the device offering to use essential features of the platform

If you think "apple pay, apple music, icloud" are essential features of the platform, you are misinformed. They are attempts to lock you into a platform by providing an (inferior but embedded) alternative to products in the respective market.

> I've used iOS for years and have never found any prompts that are remotely harassing about anything

Then you have never tried avoiding to upload all your personal information into the Apple icloud. Harassment at every minor dot-dot update.

I think cm2187's use of the word "harassed" is grossly overstated. Only one of the three things he mentions even has a prompt at initial setup, but even then, skipping iCloud setup leads to absolutely zero prompts from then on.

No Apple Pay, Apple Wallet and iCloud get prompted with a confirmation prompt (so you have to decline twice each) on pretty much every iOS upgrade.

I do think that "harassed" is the appropriate term for this repetitive nagging.

You mean the upgrade, that involved the wizard setup that shows users new features?

I am not sure if it is the wizard setup, but when it has updated iOS, it reboots, and on first boot I am greated with multiple prompts to start using each of these services, in a similar way than if it was a new iphone. But this is not for new features. The same prompts come back at every update, even if I opted out many times before.

I would not call a update and setup screen "harassed." Pop-up ads are being harassed, iClouds prompts without updates is harassed.

> The only thing affected by this is the ability to run really old binaries that have not been updated in years. But those will often be suffering from other compatibility issues anyway

There are numerous applications — mostly games — which haven't been updated in years (and show the 32 bit warning thing) yet work just fine. Trainyard, Auditorium, Drop7, Eliss, Tilt to Live, geoDefense, Walking Mars, Canabalt, …

Just a side note, the rollout of ATS requirements on iOS/AppStore has been delayed until further notice.


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.

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

Everybody should be able to decide for themself what they consider as important and what should be preserved. So I strongly oppose when the benevolent/malevolent dictator decides that you have to leave this piece behind.

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

But others perhaps care. So I strongly encourage you to open-source it if you don't care about it anymore.

> So I strongly oppose when the benevolent/malevolent dictator decides that you have to leave this piece behind.

There is no one dictating that. The source code is still in the hands of developers, and your advice to me was to "open source it." All developers of 32 bit apps have that option, and they also have the option to maintain their source going forward.

Apple's decision to shed technical debt shouldn't be seen as them eschewing some moral responsibility to support old software.

> But others perhaps care. So I strongly encourage you to open-source it if you don't care about it anymore.

I would consider it if I still had the source. But you should realise that saying "open source it" trivialises the amount of effort and emotion required to do so. Sharing your work with the world (especially if you are embarrassed by old code you have written) is not something that everyone finds easy to do. I would feel obligated to update the code, write build instructions and a readme file at the very least.

That would take a good few days of my time to make the code "presentable" before I would be willing to share it. I don't have the mental or emotional energy to devote to that task.

> > So I strongly oppose when the benevolent/malevolent dictator decides that you have to leave this piece behind.

> There is no one dictating that.

Apple is.

> dictator decides that you have to leave this piece behind

They aren't dictating that you have to leave this piece behind.

They are dictating that you have 9 months to either port your code to 64 bit, leave it behind, open source it. Or whatever else you want to do.

They are dictating that the end user leave this piece behind. The developer could be dead or out of business.

Granted, they have been doing this for a long time -- you can't easily install older versions of software, for example.

You can very easily install older versions of software. If you make a local iTunes backup, you can keep the apps and reinstall them locally. If you have an older device that doesn't support the newest version of the app, you will be prompted that there is an older version available that us compatible and be allowed to download it.

The former option works on all iOS devices ever made, the latter works at least as far back as iOS 5 devices.

The former stopped working in iOS 9.

You can't restore local copies of apps that you backed up using iTunes in iOS 9? But you can download older copies of apps on a first gen iPad? That's weird if that's what you are saying. I was able to download older apps on my 1st gen iPad about a month ago.


Are you sure it stopped working? You can't download an older version of an app on a non supported OS unless you either previously downloaded a version before on a compatible device or used iTunes and bought the app on a computer.

Edit 2:

Apparently you still can download the app to your computer directly using iTunes but you can't back it up to your device.


No they shouldn't. Those people should either update their software or force their users to stay on legacy devices. It should not be Apple's responsibility to not move forward and continue to complicate their environment for the benefit of the few.

> So I strongly oppose when the benevolent/malevolent dictator decides that you have to leave this piece behind.

You don't have to leave it, you just cannot sell it on the App Store or run it in modern devices. By all means, open source the code, publish it, archive it... do whatever you want with it.its not the end of the world and its a sensible decision.

> But others perhaps care. So I strongly encourage you to open-source it if you don't care about it anymore.

This is false thinking in my mind. Others may care, but that does not mean they have the right to guilt someone into releasing the source for _their creation_.

On a grander scale - nothing lasts forever. Not even stars. So, we don't need to preserve everything - this is very egoic mind to me. It is ok to let things die and be forgotten. Software, art, ideas, songs, poems included.

If the creator of these things decides to not release it to the world, that is _their_ prerogative.

The same reason you treat cinema and games the same way. It's not worth destroying all access to The Godfather just because "there's so many other films coming out nowadays"

He isn't saying that. He is saying we shouldn't continue to support tape cassettes because the creator of the Godfather didn't want to update it to DVD.

I think the difference is that film has archival formats to keep them around. If you have a film reel you can rescan it for a new format, whether it be VHS, Betamax, DVD, Bluray, HD-DVD or whatever is next. For software we have the source code, but given Apple's iOS ecosystem you are likely tied into that platform (Especially for early software when there was little cross platform tooling.)

The problem with the App Store is that neither users nor developers have a good method for keeping their apps around (other than releasing a binary for jailbroken devices.) You can't just create a DMG and host it on S3 to allow any old iOS device to install because the platform is locked down. The issue is that a lot of the history of mobile gaming is going to be lost (And some already has been with the purging of non-updated apps already happening) because the App Store is the arbiter for users obtaining software.

The "simple" solution is for apple to allow users to install IPA files outside of the App Store, like Android can install APK files. Developers can build their app in an old version of Xcode and put it up for install on their own terms.

Apple does allow developer users to install IPA files outside of the App Store. I can easily take an app off Github, build it with Xcode, and install it on my iPhone, for example. There are even scripts to do this similar to a "configure; make; make install", eg: https://github.com/phonegap/ios-deploy

This doesn't require the $99 it used to either, anyone can do it, though it does require you to get a free signed developer certificate from Apple which signs the app (you'll also need to tell your device to trust your cert).

You can even distribute an IPA file and install it via iTunes and not the App Store, but it needs to be signed by a trusted authority (your company; your dev cert; or most likely Apple, as long as it is a non-revoked cert).

> This doesn't require the $99 it used to either, anyone can do it, though it does require you to get a free signed developer certificate from Apple which signs the app (you'll also need to tell your device to trust your cert).

There's a limit of 3 installs per device, though. And you'll have to re-sign the app every 7 days if you choose to go down this path.

> You can even distribute an IPA file and install it via iTunes and not the App Store, but it needs to be signed by a trusted authority (your company; your dev cert; or most likely Apple, as long as it is a non-revoked cert).

Doesn't this specifically require an Enterprise Developer account?

Seriously? That's awesome, I'm really glad Apple's taken that step in the right direction.

Question though, has it had a large impact on popularity of pirated apps if you no longer have to jailbreak to use them?

It should be noted that it's quite limited. You can only install a few of these apps on a given device, and they expire quickly. It's not really practical for sideloading in the general case.

In practice, what people do is they pay something like $5 a year to get added to a shared pool of developer accounts. In China they also had a really slick scam going for a long time involving pools of otherwise-unused enterprise certificates (though I haven't tracked this one recently, and so maybe they got hit even harder than the resigning services have been).

I will also point out that for many of the use cases of piracy, which involves games and other content where the user rapidly get "bored" and moves on to other content, a limit of three at a time for only seven days doesn't matter: people can pirate a few games and play them for a weekend, and then move on to pirate other games.

(If you are curious, I'm of course excited by these things and like explaining them as it further weakens the argument some people try to make that jailbreaking leads to mass piracy, something even the US Copyright Office doesn't believe; but this line of analysis makes the whole situation more obvious ;P;)

Stretching the metaphor a bit; but what if the creator is dead? Or can't afford to update it? Does it make the Godfather worthless because of its medium?

The Mona Lisa is deteriorating. Should we also stop efforts to preserve it, because there's so many other paintings out there?

As long as there are people willing to preserve it, then we will preserve it. Few people would ever "stop" efforts to preserve something, it's just going to stop being preserved when there is no one around who cares about it anymore.

There are many millions of paintings that have been lost to time, and there will be many more.

Just because something isn't preserved doesn't mean it is worthless. The transience of human creativity is part of what makes it so beautiful.

If the Godfather was to be removed from existence this instant it would still have value because it has already made a mark on the world and the memories of the people in the world. And will indirectly influence generations to come. Value accrues in the humans who experience the work, not in the work itself.

> As long as there are people willing to preserve it, then we will preserve it.

As long as there are people willing to preserve it, there are still laws (e.g. DCMA) that prohibit people from doing it.

Those laws exist to protect the rights of the creator for a period of time; if they want a thing to pass into history, without openly publishing the source, that's their prerogative.

Even before copyright expiration, anyone can clean-room reimplement a thing in open source if they wanted to, and not be violating copyright. This has been common in OSS. (Samba for example)

The period is effectively infinite now, since congress keeps retroactively extending it.

Also, the SMB protocol does not contain any copyrightable material, like music, sprites, icons, game assets, etc. Copyright law prevents you from faithfully cloning (pixel for pixel) most GUIs and games (so most phone apps)

The Sonny Bono act was passed 19 years ago. 100 years of protection isn't infinite. It also requires an entity to WANT to enforce that copyright. if they exist, then you really don't have a right to pixel clone something - they can keep it buried.

There are plenty of game variants created that capture the feel of prior games without being IP violations

This is a poor analogy because the customer can turn a Godfather tape into a DVD at home. Or a DVD into a mp4. Or a mp4 into whatever the future holds and be able to watch it on newer equipment. If there's DRM its typically trivially broken or worked around via hdmi converters or even a basic analog output.

As a customer of a 32-bit app, I have no such power. I can't convert it to 64-bit. That's the problem.

If you have a 32-bit app that you are not willing to strap into 64-bit, then the medium in which it can be used on with stay in the past. So if I don't update my iPhone, I can continue to use your app and will have to begin finding ways to preserve your app for myself and people like me who enjoy it.

I don't believe that you can be said to cherish something if you don't care if it goes and you don't feel the need to preserve it.

cherish (verb):

​ 1. to love, protect, and care for someone or something that is important to you:

Although I cherish my children, I do allow them their independence.

Her most cherished possession is a 1926 letter from F. Scott Fitzgerald.

Freedom of speech is a cherished (= carefully protected) right in this country.

2. to keep hopes, memories, or ideas in your mind because they are important to you and bring you pleasure:

I cherish the memories of the time we spent together.

Why not? I have fond memories of it. I have the memories of sleeping in my car for weeks on end when I was building the software. I have memories of the two friends I built it with. I have fond memories of the bucket-based OpenGL render engine I wrote for it, the dynamic water system, the physically-driven character rig, the 3D models I made, memories of the art I painted.

I also remember the blog posts I wrote about some of the complexities and fun problems we solved. I remember the reviews written about the product.

I cherish it. I just don't care if I have the source code or a working binary (though I still have the latter until this 32 bit support is dropped!). I have the memories and experience and the desire to create more.

Your quote says it all:

> I cherish the memories of the time we spent together.

I cherish the time I spent creating my software and putting it out into the world. Now I'm creating something else, and I'm happy with the memories.

So you cherish the memories, not the thing

I don't know if there is really a difference there.

It is absolutely possible to care, and love, and cherish something -- while also be willing to let it go, so you can move on to something else. And it's software, not a human child or something. These are absolutely not in conflict, at all. Why does this even need to be said? Are half the people here robots? Apparently they are, because the moment someone talks about throwing away some software, people begin making allusions to child rearing.

Bringing out dictionaries is just a way of being an annoying pendant; nitpicking phrasing like "... and care for" in a Merriam Webster definition does not make you sound like someone enlightened "loving" or in tune. It makes you sound like that insufferable jackass, that guy everyone avoids, because they have to remind everyone "but what about the pedantry" anytime any complaint exists in the public sphere.

I'm not trying to sound anything at all. I'm trying to understand his point of view. I broke out the dictionary to help establish whether he was using the word as I understood it, not as an attempt at irritating pedantry.

The discussion is about whether it matters that these 32-bit apps (and more generally, all software eventually) will be lost to us. In that context, whether you cherish the thing or the memory of the thing is a crucial distinction.

As for being loving or "in tune", jumping on strangers who are trying to understand somebody's point of view is neither. It is precisely the behaviour of a jackass.

Some people are genuinely upset when they lose the use of cherished thing, be it a pen, a car, or the iOS games or other apps which they enjoyed using, and ignoring that or dismissing that out of hand betrays a lack of empathy.

>Does it really matter if we leave some behind?

Who decides? Popularity and economic benefit? So we get to keep Call of Duty video games, but apps that benefit a niche industry or are simply not very popular but considered important should be left behind? In other words, my Mona Lisa isn't your Mona Lisa.

Not too long ago, maybe the mid/late 1990's, we had this battle with deteriorating celluloid from the earlier stages of Hollywood. The studios were happy to let many old movies that were never transferred to VHS or DVD just wither away because the cost of transfer would never be recouped. I remember a lot of petitions and outrage and the studios reversed their policy (perhaps with grants or other funding, I don't recall). It was a small controversy and most of those movies weren't critically acclaimed, but some were and they were all part of history.

Not sure how well this analogy transfers to software but it always makes sense from a practical and moral perspective to save everything than to curate a few, especially in the age of automation and cheap computing.

We're not just talking about art here, and we're not talking about geological timescales either. I think it's perfectly reasonable to think that if I compile a program for an operating system, it will still run okay in twenty years on the latest version of that operating system. The Linux ecosystem (and Microsoft in a lot of ways is the best at this) manages this pretty well, and I think they're getting better at it. That's why people can safely build things like nuclear control systems on Linux or Windows, and not have to worry about recompiling every single binary every 3 years.

(Now mind you, they should be recompiling every binary monthly, but OS vendors shouldn't be breaking everyone's builds unless security demands it.)

It's a capricious decision that eliminates a bunch of actual useful applications with no consideration.

Meanwhile, there are 10,000 fart apps.

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.


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.

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.

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

This sort of regulation is terrible, and in my opinion should be resisted. It institutionalizes the worst tendencies of open source - free riding and slowing progress due to community restrictions.

At best, a community will be a thriving organic set of users and contributors. At worst, they are abusive parasites to the core maintainers.

The former has its own future guaranteed - customers care about a thing and are investing in it. The latter however is far more common - everyone wants something for nothing.

The world is built on organizations that need revenue to continue their mission and fulfill customer needs. Forcing companies to allocate resources to the past, the obsolete, that which customers do not want to pay for, hurts society far more than letting products die of obsolescence.

A compromise might exist where a portion of copyright law and/or taxes are allocated to preserve certain works, which would capture a balance between the economic need to create the future and the social need to preserve tradition and past practices, but that's tricky a level of nuance for policy.


I also see this somewhat as a 'own your st' 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.

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.

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.

And among the hundreds of thousands of older apps are apps built by smaller teams to supplement other things i.e. web services that struggle to keep everything maintained.

It's far more important that the apps remain usable to their end users than it is that they adapt perfectly to a slightly larger screen size :s

Apple's development platform moves too quickly for many developers to keep pace with. It's not that all these apps are not valuable or misleading to customers.

> My claim: we need regulation

We already have this. Copyright gives Apple a legal monopoly on iOS. It isn't supposed to give Apple a monopoly on the distribution of third party iOS apps. That's just the sort of monopoly leveraging the antitrust laws are intended to deal with.

They built it, it's their property. If you don't like it don't buy an iDevice. For those who do buy iDevices, they can rely on Apple to ensure the quality of the apps and platform. Look at Android, it's the wild wild west, insecure and full of scammers.

They built it, it's their property. If you don't like it don't buy service from AT&T in 1981. For those who do buy AT&T service, they can rely on AT&T to ensure the quality of the phones and platform. Look at The Internet, it's the wild wild west, insecure and full of scammers.

And if you don't like AT&T, all you have to do is sell your house and move out of their service area. Unless you make phones or modems or are an ISP; then even moving doesn't help you because you can't move your customers.

Don't forget Google, gcc has been shown the door on the Android's NDK.

Regulations like the DMCA are what got us into this situation, by creating an environment where companies can declare that it's illegal to use "your" hardware in ways they don't approve of. We could start by getting rid of those restrictions, rather than creating even more surface area for regulatory capture.

Regulations cut both ways: regulations like "people can enforce contracts" are required to make things sane. Without regulation, DRM happens and wins. As one of the people extremely affected by the DMCA and often involved in official complaining about it (look me up), the DMCA is actually a red herring: whether it is legal or not is irrelevant if it isn't possible, and we are rapidly running into a world where the biggest issue isn't whether it is legal (I mean, even when we have exemptions, we still don't have exploits). Moving to a world without laws doesn't make things safer or happier.

Pollution is a "tragedy of the commons", the atmosphere and ground water are shared resources that if degraded affects all of us. But you don't have to regulate how I clean my house, if I don't want to live in filth I'll do it.

If you don't like Apple's house, you don't have to live there. There are many free software projects that you can use for your phone, pc, etc.

There are many arguments for libretto software, but the support argument is the weakest. I'm much more confident of getting support from someone I've paid than someone I haven't. At least any support I'm entiriedcyo will. Even a contract.

The reality of most liner software is that scads if it go out of support all the time and only users that are members of the developer elite (and happen to be skilled in the relevant platform, libraries and dev tools) have even a chance of doing anything about it.

> The reality of most liner software is that scads if it go out of support all the time and only users that are members of the developer elite (and happen to be skilled in the relevant platform, libraries and dev tools) have even a chance of doing anything about it.

That's only true for things for which there isn't even one user who is a developer, who fixes your problem because it was also their problem.

You have the same problem with free software, only that you can step in and maintain it yourself (which costs a lot of time/money).

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

Is this though? How much of the impacted software would exist as free software?

Again. And again. And again. But we'll keep saying it.

I wonder how long it will take for people like you to realize what users want. Hint: they don't want to control, there are already to many things to control. They want to use.

Control and use go hand in hand. If you don't control your stuff, then it's just about inevitable that whoever does will eventually block your ability to use it.

> I wonder how long it will take for people like you to realize what users want. Hint: they don't want to control, there are already to many things to control. They want to use.

I wonder how long it will take for people to realize that "using" means "controling" (i.e. "using" without ability to "control" will sooner or later lead to a loss of ability to "use").

Your comment doesn't make any sense, in this context or otherwise.

I thought it made sense.

I know lots of non technically inclined people who use software every day. Most of them have no idea what free software is. If you asked them, they say it's software they don't have to pay for.

If you explained it to them, they wouldn't care. They neither care about not want the control and freedom granted by free software, nor are they going to start wanting it even if we spell out for them why it would benefit them. They'll take it if it means no effort or sacrifice on their part, but they're not going to ask for it or advocate for it or fight for it in any way.

What the grandparent was saying is that the vast majority of people neither care about nor want the additional control they'd have in a free software ecosystem. And I think he or she is correct.

It's not just free software, but the ability to control which set of binaries you use. The final straw that pushed me away from iOS devices was when the ability to pack and backup apps from devices was removed in iOS 8 (IIRC). Case in point, I had been holding out on a particular build of official twitter app for iPad (ver4.3.2) for some time as I detest the subsequent major updates for being ugly and hard to use. From that point onwards if I lose that signed copy stored on my computer it is goodbye forever since I won't be able to pull it from my tablet if I wanted to.

Maybe I overreacted since there is a good chance that I was in voilation of whatever EULA I have agreed to, or the app might be broken by another random update but enough was enough.

I interpret "that users want" to be a typo of "what users want".

Correct. Fixed, thank you.

While i agree on the value of libre software, i think we should not exaggerate what's happening here.

1. Most people are not aware there is such a thing as libre software, let alone why it would benefit them. Most people therefore will not channel their frustration at this move into a demand for libre. In fact, most people won't even realize apple did anything. They'll blame the original developer.

2. In apple's view, if there is 32-bit software people need or want, some developer will fill that gap. Apps to them are easily replaced and ephemeral. That is not necessarily wrong or in conflict with the view that all software should be Free.

So I don't think this decision matters much or will have much consequence. But it still is regrettable.

You don't really need copyleft protected software. The BSD community is very much alive.

The important point is actually use the type of software you care about. If you care about copyleft, use as much copyleft software as you can, if you care about BSD, use BSD systems.

In particular, if an open source version is available but you take the closed source version because it is somehow nicer, you are sending a message that you don't actually care.

And the only way we can keep open source alive is if we care. Just using it helps. Reporting bugs helps.

Apple is focused on offering a secure, fast, modern platform, and they keep moving it forward. These dusty apps aren't being banned, the authors just need to recompile them and re-release them. Blame the authors for never maintaining, not Apple.

Android lets you and virus makers and scammers do whatever you want. Why not focus on that if freedom is a bigger end goal that quality.

For most users this is an annoyance, but not enough of an annoyance to turn them on to free software ideology. It's hard for me to imagine what sort of closed-source irritation could outweigh the horrendous irritation of prioritizing using (and, in fact, just using) most free software.

The only user facing freedom in free software is the ability to get and redistribute the software for free. But that's not what free software is about. For all the other freedoms you need to be able to program, which makes you a developer.

Imagine your business depends on it. You can hire someone who works on it. Try that with proprietary software.

Then, as a business you: A) Buy a newer app that does what you need it to do. B) Pay for software support or C) Develop your own version

Hinging one's business on software who's future isn't so certain is a potentially stupid risk.

there's also option D: pay the developer to continue support.

Sadly there are ways for monied interests to hijack the direction of even that kind of software for their own goals.

One play we are seeing right now is code churn. Get developers you payroll to churn to many changes in central parts of the stack that people either have to accept your goals or fork the whole stack.

It will take at least very long, and probably will never happen, unless we change our own nature as species. This obvious fact alone is a hint that FS is invalid as ideology-for-everything. Why advocating at large scale then?

unless we change our own nature as species

says who? libre software is only uncommon for consumers. Google, Facebook, Amazon, Red Hat, Oracle, et al, all depend on and contribute to libre software. a lot of other companies develop libre software and manage to turn a profit. personally, i have used libre software to build production systems at every step of my career.

That was in the context of "to enable users to control their technology" and "software people want/need, that they are no longer permitted to use because Apple said so". It is about consumers.

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.

Anyone have any examples of a "seminal" iOS app which is still 32 bit?

You won't hear any good answer because there isn't one.

Who are you or anyone else to tell me that the app that I paid for is not "seminal" and therefore Apple gets to remove my ability to use it?

You might suggest that I don't have to upgrade iOS. But I have two responses to that. First, is that Apple has begun popping up frequent nag dialogs on the devices telling you to upgrade. Second, upgrades to iOS are the only way to get security fixes. It's one thing to give people a choice to opt out of the newest UI style vs. running older apps. It's something entirely different to require them to forego security fixes. Security issues that by rights should be considered defects in the products with Apple being given a choice of repairing the defects on every platform the defect exists on or buying back the old devices and paying the costs of switching for the people who bought the products in good faith.

It's bullshit that fully functional hardware is completely unsafe to use because Apple chooses not to fixes security bugs in the iOS versions that run on those devices. E.g. first generation iPad is not safe to use online because Apple has abandoned support.

Why do you care about security fixes when updating the OS but you don't care about security fixes of apps? If an app is 2 years old it is probably using libraries with security issues. I would blame the developer for not updating the app, not apple. (I am saying this as an app developer).

Not all apps involve connecting to an arbitrary set of network services or provide a listening port as an attack vector.

Regardless, these are not exclusive values. We don't have to have one or the other. If Apple ships a device that is defective, it's bullshit for them to say "that piece of hardware is two years old, it's not going to get fixed."

Ask yourself how many if the goods you have are less than two years old? I'm not saying they should bring every feature from all later releases to the older devices, but actual bugs should be fixed for longer than two years.

I don't understand your comment. I am saying you should have updated SO and updated apps. Apple is in charge to update the SO and the app developers to update their apps.

I'm saying that I should have a choice not to upgrade to the latest features -- including the dropping of support for 32-bit apps -- without having to give up security fixes, which are fundamentally defects in the product.

Imagine if you bought an mp3 & aac player, amassed a collection of mp3 formatted audio, and then the vendor said "oh, we have to do an update because if we don't the player will explode. and we're removing the ability to play mp3 formatted music, but that's ok, you can play aacs." No one wants their audio player to explode, but by the same token it was sold as a device that plays mp3 and aac.

You can not upgrade, but you will have security issues.

It is very hard to offer support for legacy systems. You should expect more than 2 year support. Software evolves really fast, companies cannot sit and wait. They will lose their hype and money.

You are giving the developer a free ride for never maintaining that app you paid them for, and blaming Apple for greatly improving the operating system?

No. Your sentence presents a false dichotomy. There is nothing inherent in software design that binds security fixes and new features. I get it, no amount of software updates will put a camera in a first generation ipad, but there is absolutely nothing about the hardware that prevents the correcting of buffer and stack overflows.

No, no they don't. Any app that's still 32 but hasn't been updated in almost two years. How crucial could it be?

How about an App that controls stuff where the iPad (or iPod) is just used as a "cheap" HMI. For example iPads are used in stage control with dedicated Apps.

The hardware, which the App controls, does not change. But the iPad itself has to be replaced with a newer one, or even you can't buy old ones. Think about, building control which is build for 20+ years.

If you're using it in that situation and you're blindly updating the OS, you're doing it wrong. You have a very explicit dependency, the application. The OS shouldn't get touched unless you know the application is supported by it.

We have, similar, setups at work for our test stations, though with Windows holding the interface application. Essentially replacing walls of control panels with one application and computer. We do not push OS or major library updates to those computers until we have verified that the application will either be unaffected or has been updated to correct whatever issues the new OS or library introduce.

What if the hardware fails and you have to buy new hardware? Not a problem with Windows, but you can't downgrade iOS.

That should be a major consideration before purchasing it, then. We have dependencies on VAX systems, so I'm fairly well aware of this risk. We work deliberately, now, to future-proof our systems. Depending on a very closed platform like iOS and a specific iPad version is the antithesis of future-proofing and any risk analysis should reveal the pitfalls. If someone still chose to use it, they have little ground to complain about being unable to replace that hardware/software easily in 3-5 years, let alone 20.

Field Runners

Cooking Mama iOS

Wolfenstein RPG

Those were just a few I tried.

Think of all the web sites optimized for IE6.

If those apps are so seminal, let's hope they are open source and available for study, porting, and upgrading.

Those websites should still work perfectly well on modern browsers (unless they use ActiveX components of course).

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.

I happen to know someone who had managed to build an emulator for iOS, but it could only emulate one particular old device (the key thing to understand is that we had a bootrom exploit that let us dump a lot of the code and encryption keys from these older devices). The issue with Apple goes well beyond distribution of apps: they also control the hardware, and they use that control to shroud the software; and unlike with a typical game console, there is a ton of software running on the device as part of a network of dependencies.

But like, we can go further: as it stands, without exploits for security vulnerabilities for these devices, it isn't even possible to get a copy of the apps to run in an emulator, due to the as-yet uncracked DRM used by Apple (which may or may not use hardware AES keys; I still haven't figured this out). So even if you had an iPhone emulator (and you don't, and might not for a very long time, if ever), you also need to obtain an unencrypted copy of Trainyard (the app in the banner image of this article) to run on it, as if they really are using hardware AES keys for that, your emulator is going to be missing those.

Essentially, I would argue that we are moving into a post-emulator reality. It was really easy to write a Nintendo emulator, and it was sort of OK to write a Nintendo 64 emulator. The existence of Wii and PS3 emulators is only due to bugs in security of systems, often the kind that are caused by people too often using unsafe languages like C. Imagine a world where people with intent to lock things down and the experience to know how to do it well are also coding in secure-by-default languages: you get to a point where even a scanning tunneling microscope isn't enough to get you access to the code either from the console or from the game.

Imagine a world where people with intent to lock things down and the experience to know how to do it well are also coding in secure-by-default languages: you get to a point where even a scanning tunneling microscope isn't enough to get you access to the code either from the console or from the game.

This is why I've always found these "safe" languages and the general security trend rather worrisome: they can effectively secure our devices against attackers, but also against their owners. Personally I think these issues need to be solved before advocating for these more secure systems, as otherwise we'll just be locking ourselves out.

I've been looking at the FairPlay DRM this week. I followed the path from the memory pager, through IOTextCrypter et al, through to fairplayd via com.apple.unfreed IPC. Static analysis of that binary looks impracticable (a lot of effort appears to have been made to ensure this), but have you considered dynamic analysis using Unicorn?

> moving into a post-emulator reality

Also known as the death of the general purpose computer. Free software advocates have been warning about this slow-rolling catastrophe for ages.


So... we have to wait for quantum computers to break the AES keys? :)

Quantum computers are only marginally faster against symmetric key encryption - AES128 requires 2^64 quantum operations.

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.

How can a user tell whether an iOS app is 64-bit? I use some old apps that are no longer maintained and worry that they will just stop working.

If you are on iOS 10.1 or later, you should get a dialog box that clail the application "may slow down your phone" (this dialog'a appearance is remembered and only shows up occasionally per app, I believe).


Is there any way to tell before you buy an app? I just bought one yesterday, actually paid money for it, and it gave me that warning. While six months is a long time, if I buy it the day before the cutoff, I'd be pretty disappointed when I lose access 24 hours later.

I also wish there was a way to see which apps support retina displays before you buy them, I've been tricked a few times.

Ask the developer if they ware going to fix them. If not, get a refund. You can do it through your iTunes account or directly with


Say product didn't work as advertised.

> Is there any way to tell before you buy an app?

I believe that most apps built to support "iOS 8 or later" (this is shown in the app's Information section) are 64-bit.

> While six months is a long time, if I buy it the day before the cutoff, I'd be pretty disappointed when I lose access 24 hours later.

I just looked it up, and Apple has been asking developers to build against the iOS 8 SDK for 2 years now:


Ah so that's what that warning is about.

There is a warning, when you first open the app. The warning is that the app developer should update their app. It started appearing either in 10.1 or in 10.2

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


This is the price of using Apple and Google gardens. Would you like reasonable freedom? Build a web app.

I would be very hesitant to legislate Apple supporting 32bit apps. That sounds absurd on its face.

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

It is ... the kind of thing we probably need to solve using regulation

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.

No. It is not that abstract or general. It enables tuning, but several aspects of the target architecture are assumed in the bitcode. It allows for CPU-aware optimization passes, such as - for example - reconfiguring math to use faster instructions when possible, but it is specifically not an abstract machine-independent bytecode.

True, bitcode is not completely abstract, and things like calling conventions are baked into the bitcode.

But it is abstract enough that Apple could use it to recompile binaries for, say, a new 64-bit CPU architecture.

Yes, they might have to jump through a few hoops to make it work, but given the control that Apple have over their platforms (they can define things like calling conventions) it shouldn't be too difficult.

Apple did JIT compilation of binaries during the PowerPC -> Intel transition years ago. Recompiling bitcode on the App Store would be easy by comparison!

Apple's PPC emulation was carried out at the process level. That means that not only the program was PPC, but also all libraries it used. And that means that Apple had to keep shipping PPC versions of all their system frameworks.

When it comes to 32-bit ARM, that's basically the situation Apple is already in. It's just that instead of emulation, the 32-bit code is run natively by the CPU.

They could replace that with an actual emulator, but it would gain you almost nothing. 32-bit support in the CPU doesn't cost much. The real reason Apple wants to dump 32-bit support is so they can stop shipping 32-bit versions of all their system libraries. Doing that will save disk space, memory, and development effort.

It's really, really hard to create an emulator which will run a 32-bit program that talks to 64-bit libraries, and bitcode doesn't help.

I was not suggesting that bitcode could be used for 32-bit -> 64-bit translation, but rather that bitcode means that Apple may be able to avoid similar situations in the future.

In any case, these (32-bit only) binaries predate bitcode by several years, so it's not relevant.

Lattner refuted the ability of Apple to recompile bitcode into alternate architectures in his recent ATP interview

Lattner said that bitcode is "not a panacea that makes everything magically portable"[1], which of course is true.

But that doesn't mean it couldn't be recompiled for different architectures, given reasonable bounds like both 64-bit, same endian, similar calling conventions, etc.

I'm not suggesting Apple is considering that, just that it would be technically possible if there were ever a compelling reason.

It's unlikely they would ever move away from ARM on iOS, but on something like the Apple Watch with it's highly custom SIP, and ultra-low-power requirements, you never know...

[1] http://atp.fm/205-chris-lattner-interview-transcript/#bitcod...

He actually references that pretty specifically saying that indeed it can't be used to move 32bit -> 64bit [0]

> Bitcode is not [12:30] a magic solution, though. You can't take a 32-bit app, for example, and run it on a 64-bit device. That kind of portability isn’t something that Bitcode can give you, notably because that is something that's visible in C. As you're writing C code, you can write #ifdef pointer size equals 32, and that’s something that Bitcode can't abstract over. It's useful for very specific, low-level kinds of enhancements, but it isn't a panacea that makes everything [13:00] magically portable

[0]: http://atp.fm/205-chris-lattner-interview-transcript/#portab...

I suppose I also don't comprehend the moral weight of the responsibility for running 32-bit code. What sort of problems do you foresee happening?

Did we read the same article? I am looking a whole lot of Cunningham worlds for how this move by Apple is a good thing...

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.

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.

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

Yes, iOS 64-bit devices use a full 64-bit bootchain

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.

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

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

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.

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

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.

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?

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.

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

If only the authors of abandonware would open source their projects.

Complaining about one closed source company that is actively growing and managing the platform we rely on for increasing performance and security because other closed source companies abandoned their software seems rather confusing to me.

Consider the following situation:

* an application was an early 32-bit iOS port; the codebase was not 64-bit clean at the time of the port

* elsewhere, the world moves forward: new DirectX APIs for the desktop, new graphics and asset pipeline techniques, etc. Development, accordingly, moves on; the application ships on other platforms, and large reusable sections of the code - the engine - have been updated, rewritten, made 64-bit clean, used in other applications etc; however none of this work was migrated to the branch for the original iOS port: at the time, that had shipped and was stable, large sweeping changes are expensive and risky, with (at the time) little visible benefit for an existing working stable iOS application to justify that.

* 2015: Apple pulls the rug out from under updates by mandating 64-bit support. The developer is faced with a stark choice: pay the porting cost to iOS again for the new codebase, or redo the 64-bit cleanup work from current trunk on the ancient branch (a cost comparable to porting again, at this point), or suck it up and say there won't be any more updates. Since the app is several years old and sales are down to a negligible trickle, the third option is picked - the other two are not affordable.

* 2017: Apple pulls the rug out from 32-bit-only apps by releasing an OS update that no longer runs them. Users that bought the application can no longer use it. The developer can't afford to update it or port it, but is (a) still selling it on other platforms and (b) is still using the engine in other applications that are selling, so would be crippled by making it open source.

Each individual decision is sensible at the time, but it all adds up to checkmate.

I'm personally aware of at least three developers that are in this trap right now.

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

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.

Oh dear, note that while your interpretation makes perfect sense upon re-reading my comment I really meant "developer" as the developing company rather than the actual person, and "dead" as in folded/gone, rather than the actual physical death of a living human being.

Not really, the iPhone 5C was sold worldwide up until September 2015 and was sold in India until February 2016 so anyone still using it will be stuck.

The article makes a claim that Apple will drop 32 bit in the OS that Apple has never said. I'm fairly certain that is wrong.

All Apple has said is that it will remove apps from the App store that don't support 64-bit.

Journalists shouldn't make stuff like that up.

Yeah, that changes everything. I’m all for Apple forcing developers to include 64bit support in their builds.

I agree totally, the point is cleaning up app store. Most of those legacy apps are already buggy or consuming too much power

Update the apps or they won't run on anything BUT 5 year old hardware.

> 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

Older apps that users have paid money for a while back, that work and are in use right now, but that developers haven't received much income for in years since everyone that wanted them has already bought them, will stop working for users that upgrade their device.

Cue user complaints, but no extra money coming to deal with them.

Apple have unilaterally decided it's time to burn something; developers have roughly 9 months to choose whether it is their time and money or their users' possessions that get burned.

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.

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.

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.

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

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.

That is only true if Apple doesn't change behavior or deprecate APIs. They don't do that often but they do do that. (Yes, I said doodoo).

This is not a counterargument; it is, in fact, the definition of the problem.

Removing them from store doesn't mean you can't still download them. Apple has always been good about making sure you can still download stuff you've bought.

If it's a fear, don't upgrade beyond iOS 10. But Apple HAS to start removing all those crappy old apps that developers aren't maintaining, zombie apps are near useless and are misleading to customers.

What apps would that be? Also, it will have zero effect on iOS upgrades, unless the number of "users with expensive external hardware items that require ancient apps" is in double percentage digits. In reality I guess they don't even reach thousdanth of the percent.

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

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

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

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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact