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).
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.
Something a number of FOSS projects should take to heart when they fret about "year of the desktop".
Apple decided that they don't want to open-source it. That is the reason why Apple would have to maintain it.
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.
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.
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
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.
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.
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.
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.
Not "free" as in "freedom". :-(
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 do think that "harassed" is the appropriate term for this repetitive nagging.
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, …
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.
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.
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.
> There is no one dictating that.
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.
Granted, they have been doing this for a long time -- you can't easily install older versions of software, for example.
The former option works on all iOS devices ever made, the latter works at least as far back as iOS 5 devices.
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.
Apparently you still can download the app to your computer directly using iTunes but you can't back it up to your device.
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.
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 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.
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).
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?
Question though, has it had a large impact on popularity of pirated apps if you no longer have to jailbreak to use them?
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;)
The Mona Lisa is deteriorating. Should we also stop efforts to preserve it, because there's so many other paintings out there?
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, there are still laws (e.g. DCMA) that prohibit people from doing it.
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)
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)
There are plenty of game variants created that capture the feel of prior games without being IP violations
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.
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.
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.
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.
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.
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.
(Now mind you, they should be recompiling every binary monthly, but OS vendors shouldn't be breaking everyone's builds unless security demands it.)
Meanwhile, there are 10,000 fart apps.
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.
This is an "I told you so" moment for a lot of Free software advocates.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Is this though? How much of the impacted software would exist as free software?
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").
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.
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.
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.
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.
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.
Hinging one's business on software who's future isn't so certain is a potentially stupid risk.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Cooking Mama iOS
Those were just a few I tried.
If those apps are so seminal, let's hope they are open source and available for study, porting, and upgrading.
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.
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.
Also known as the death of the general purpose computer. Free software advocates have been warning about this slow-rolling catastrophe for ages.
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.
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.
Say product didn't work as advertised.
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:
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.
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.
I would be very hesitant to legislate Apple supporting 32bit apps. That sounds absurd on its face.
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.
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!
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.
In any case, these (32-bit only) binaries predate bitcode by several years, so it's not relevant.
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...
> 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
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.
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.
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.
Hopefully next year this time there will be only one.
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.
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?
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).
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.
* 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.
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.
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.
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.
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.
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?
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
For example, the iPad 2 can't upgrade to iOS 10, but plenty of apps still support iOS 9.
I might have to get an Android device just for classic games, like his.
Is this true? If I recall correctly, 32-bit to 64-bit doesn't always necessarily mean "end-user performance improvements."
(That said, the "x32" ABI is not widely used)
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.
It's not just extra registers and address space. ARM64 is a large-scale restructuring to better enable modern processor design, including things like removing barrel shifting on every instruction (expensive and not very useful) and removing predication on every instruction (expensive and makes OoO machinery slower). http://stackoverflow.com/a/26841196
Of course, this may be an idiosyncrasy of that processor implementation, or it may not generalize well to real applications which tend to stress the instruction cache more...
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).
You can compile C/C++ programs using this ABI, and get all 64-bit benefits without 64-bit pointers.
Can you explain how these are related? What do you mean by "larger code"? I'm assuming you're talking about the binaries, rather than actual code.
I'd agree with you on the large data size but I really don't think 32->64 bit increase will make much difference overall unless someone is using a lot of existing numerical data. Most of the data is taken up by multimedia resources and this won't really be affected by the architecture.
More registers are always good, unless you have a terrible compiler. And since Apple uses LLVM a lot, and actually takes care of the compiler backend. I don't really see caching problems. AFAIK there will be more registers to store data in so caches will actually be used less than usual.
Normal way of negating this increase is to use uint32_t offset items into a master array of the items the pointers represent, which reduces the size again and has a side benefit of possibly making the items more coherent (localised) in memory.
> In practice only two architectures matter: x86 and ARM.
So I replied about x86, because that is the architecture I know best.
This is technically true, but it's a very bland statement vs "64-bit yields end-user performance improvements" or even "64-bit is a net positive".
Generally, other things equal, going from 32 to 64 bit word size makes things slower because pointers suddenly double in size, and you can fit fewer program objects in your caches.
In practice there are a slew of miscellaneous improvements in the new 64-bit revision of an instruction set that makes up for some of the slowdown. This is less pronounced on ARM, but was big on x86 because a big flaw, the register count, was fixed.
A 32-bit application is going to be older too and won't be using non-64-bit-specific enhancements present in the processor families that may help it more than being able to deal with bigger integers. More registers being available for instance, additional SIMD instructions (for doing more with collections of smaller values) or wider versions of existing SIMD instructions.
There may be other architecture dependant factors to consider too.
Other considerations come from running 32-bit apps on systems that support both 64 and 32: you end up with two versions of some libraries in RAM which could give a one-off hit upon loading an app but also means more memory pressure so other stuff could be being pushed out and will need to be reloaded later from slower storage later when next called. That won't matter for libraries that one one app is using anyway, but for shared system libraries it could be significant. Also if the 32-bit libraries are really just a translation layer calling the 64-bit ones, then there is extra work per call that isn't related to how many bits you can process in one instruction. The extra memory pressure may slow down other apps when you switch back to them (via user action or due to them having a background service portion that needs to respond to an event) as more pages need to be reloaded from slower storage instead of already being in RAM, meaning the slow down the warning is talking about may not be immediate or affect the current app at all.
"64-bit gets faster performance because you can do twice as much in one step" is a useful explanation for the general public, one that is true (or at least not completely false), easy to understand, and much simpler than the larger collection of real details. A bit like in GCSE physics when you are told "yeah, what we said in science lessons before is a simplification and on some levels actually wrong, this is what really happens" and in A-Level physics you are told "yeah, what we said at GCSE level is a simplification and on some levels actually wrong, this is what really happens" and so on up your education as far as you take it. The simplification is needed to get the message across to those who don't need or care to know more, but doesn't hold as much water upon more detailed inspection.
I think talking about the performance hit is a mistaken way of talking to the users about the matter though because for a great many cases on an iPhone that is unlikely to be significant as the reporter here notes. And even if there is an effect overall the common user will not notice an immediate effect and assume going forward that there is no effect at all and that the warning was being over sensitive. A better way to get the message over on an iDevice is to point out that more battery power will be consumed. This is equally true (if not more so) and people are likely to care more IME.
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.
— 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.
An iPhone is more complex than the desktop computer you wrote this comment on and you know it.
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.
Not that I am defending not updating the OS, but its not nearly as bad as removing the support completely.
I still have a HTC Desire HD (bought in 2011) that gets updates in this way. I still keep it around to see how long it will live (that's one solid phone), but my main phone is a nexus
If I read this correctly, Apple will stop letting people upload and distribute apps for iPhone 5C, which is significantly newer, right?
Apple keeps old copies of apps for old versions of the OS almost for ever. My youngest was using my old iPhone 3GS until last September. I was still able to download an app from the App Store I bought for it long ago, but which hasn't been available to buy in the store for years and only supported ancient versions of the OS.
Edit: Well now you edited your response and mine doesn't make sense :/
It feels surreal to read this line of complaints about this when Apple is in such a high regard when it comes to precisely smartphone support.
And Windows compatibility with so much old software is a big reason why it sucks. There are too many apis that should have been deprecated and hacks to support specific apps that bloat it up.
There is a definite opportunity for app developers here.
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.
Which means that even if I've paid for the content, now I'll have to purchase it again from another developer only because some random limitation is introduced, and even that purchases can soon disappear again.
Does 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?
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.
I believe there is a mechanism in place now that serves the last working version to older devices.
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.
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.
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.
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.
Also new ones still listed for sale direct from Walmart it appears:
If you purchased a new device and in less than a year support is dropped, yeah you might be livid.
Yes, such a bad purchase, a far faster phone with a better camera, better wifi and cellular connectivity, a better camera, and perhaps most importantly, far, far better security.
If all this does is help encourage people to get onto Secure Enclave-equipped iOS devices, it's a winner.