Slashdot Mirror
Apple To Phase Out 32-Bit Mac Apps Starting In January 2018 (macrumors.com)
Apple will be phasing out 32-bit apps with iOS 11, and soon the company will make the same changes on its macOS operating system. During its Platform State of the Union keynote at the Worldwide Developers Conference, Apple told developers that macOS High Sierra will be the "last macOS release to support 32-bit apps without compromises." MacRumors reports: Starting in January of 2018, all new apps submitted to the Mac App Store must be 64-bit, and all apps and app updates submitted must be 64-bit by June 2018. With the next version of macOS after High Sierra, Apple will begin "aggressively" warning users about 32-bit apps before eventually phasing them out all together. In iOS 11, 32-bit apps cannot be installed or launched. Attempting to open a non-supported 32-bit app gives a message notifying users that the app needs to be updated before it can run on iOS 11. Prior to phasing out 32-bit apps on iOS 11, Apple gave both end users and developers several warnings, and the company says it will follow the same path for the macOS operating system.
and write some code
Evil Apple making me type
Die in a Fire
They went from carbon based apps to OS X native and from ppc to intel, this should be far less painful than those two transitions.
It is nice that they can do it. It does mean though that they don't have a huge legacy base in business. Try this on Windows and what you would end up with is that businesses would just not upgrade to the new version of Windows that blocked 32 bit apps. Hell, we even have a handful of 16 bit apps circa 1992 and have to keep around some Windows 7 x86 version for these craptastic things. Almost everything we run in enterprise is 32 bit and the majority of it is several years old. Upgrade? No, it works - and the upgrades are $. A good chunk of the business treats software like physical plant. They build a refinery and expect it to run for at least 50 years. They buy software and it should run for that long too. Crazy, but nearly true.
Good. It's been 14 years since the first x86-64 processor went on the market, and as far as I know, there's been no x86 processor without 64bit support sold from retailers in the past 10 years. There's no reason to keep shipping new software in a 32bit format.
- 100% increase in bit count. Thats innovative!!!!
Also it means I have to throw away my Core Duo based macs. This is a bit why, after using macs and OSX for 15 years that I have walked away from them. I can't keep up with the pace that Apple has set for consumers.
“Common sense is not so common.” — Voltaire
Apple bashing, as good and easy as it is, gets tiresome at this rate.
Anyway. That will only push people to virtualization. No big deal.
Mac Mini released in August 2007 and sold until it was replaced in March 2009.
“Common sense is not so common.” — Voltaire
You can keep asking that question forever. The only answer is hubris. They can, therefore they are.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
How does one virtualise on an i device?
You could always ... you know ... not read them.
Oh well, I was thinking Macs only.
On IOS11 I guess people will really have to stop playing Angry Birds or something drastic like that.
So what happens to people with Macs more than a few years old? Are they SOL for new software?
I don't respond to AC's.
steam windows is only 32 bit and there are lot's of apps that don't need 64 bit.
Also office 32 bit is still big due to add-ins / plug-ins.
The iPhone 5c is 32-bit and was only discontinued in September of 2015. iOS 11 will not work on it, and presumably there will be no security updates for the 5c as of the iOS 11 release date.
https://www.theguardian.com/te...
https://en.wikipedia.org/wiki/...
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
WWDC was earlier in the week, so plenty of Apple related news still coming out
This is Slashdot, the bashing happen with any company from any (in)action.
- Don Mattrick, Microsoft, 2013.
They're removing support - phasing would require them to gradually remove it in steps.
Also office 32 bit is still big due to add-ins / plug-ins.
Which is exactly the kind of problem Apple is trying to avoid by pushing hard for 64-bit.
A 64-bit operating system, an archetype that is known widely by developers and IT to support both 32 and 64-bit, is now going to purposely block 32-bit when we all know it will work? You know what this really is right? I have tried to tell both Linux and Window$ communities either here or on Reddit a while back about how 64-bit was nothing more than a tactic to get people to buy new hardware. The dropping of 32-bit for Linux is what actually made me angry. Now that everyone has an iPhone, maybe people will start to see when they have to buy iPhone 7's or later because their iPhone 5's no longer get updates and services block them from their network. You could get a 6, but very few would. It's a sales tactic. On top of which, if you pay attention to this kind of thing, most security vulnerabilities certain agencies have developed software for or even Dirty Cow for that matter, are primarily 64-bit. I think Apple security is going to get much worse over the next year. With 64-bit you've got way too much going on to be able to monitor like you can a simple 32-bit because things like GPU, which hackers love because of it enables faster brute force attacks.
The ideal is an operating system that runs every app ever created for any notable platform. For security reasons, the opposite should be default, with only the most recent runtime installed and running. But convenient one step process should be provided to install other runtimes. There is a galore of open source emulation/virtualization solutions and sandboxing to mitigate security risks, so maintenance overhead is insignificant for the likes of Apple and Microsoft. Why would anyone not want an option to run apps they paid for?
Backwards compatibility is doing twice the same job. I know developers trend to be a bit lazy but I think this is reasonable.
It's fun, though. Reading articles about Apple is like sniffing your armpit or smelling your own farts.
Apple already phased out 32-bit by making the programming tools 64-bit only on the developer side in 2014. When developers stopped supporting 32-bit apps with updates, I was forced to abandon my legendary black MacBook with a 32-bit processor. Linux Mint went on the MacBook and I switched to an inexpensive Dell laptop. The only 32-bit apps in the Mac store are by developers who are going the extra mile to support the older versions of Mac OS X.
no apple software or hardware is mission critical anyways.
Which is exactly the kind of problem Apple is trying to avoid by pushing hard for 64-bit.
The last 32 bit plugin will cease to have relevance approximately on the day when the 128 bit architectures start rolling out. This is not a problem you can avoid by pushing hard for 64 bit now. This has happened before, and it will all happen again.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Just wait until next year, when Apple rolls out their new 65-bit OS and accompanying product line...
iBook G3 [1999] - in orange
Power Mac G3 Blue & White [1999]
iBook SE (FireWire) [2000]
12 iBook G3 (Mid 2002)
12" iBook G4 (Late 2004)
Mac mini G4 (Early 2005)
13" MacBook Core Duo (May 2006) 1.83 Ghz - yes 32-bit only x86, my first x86 laptop mac
Mac mini (Mid 2007) - my first x86 desktop Mac
MacBook White (Late 2008) - earlier MacBook died, was expensive enough to repair that I bought a new(refurb) one instead
Mac Pro "Quad Core" 2.8 [2008] - this venerable MacPro3,1 is still alive as a Win7 gaming machine. (another refurb)
13 MacBook Pro (Mid 2009) - current laptop, dual-boot OSX and Win7
Present - (hopped off the carousel)
I think that's all my Macs, not counting the Xserve G5's in colocation (running Debian now, PowerPC OSX is kind of a dead end now). I took a best guess at the chronological order because some of the Macs on the list above I bought used. I usually would buy used around the time their replacements were announced. So if x86-64 Core 2 Duo MacBooks came out in 2007 (I think?), I didn't buy one until around 2009-ish.
“Common sense is not so common.” — Voltaire
What apple should do is automatically cross recompile the old apps to work on the new hardware. There are a lot of old apps that are excellent but will never get updated, a great many for small business, games and a huge inventory of educational applications. Nobody else will bother to write a replacement but cause the original creator was inspired and it is a small market in many cases. Yet, they are still great apps. Apple is doing this again on both iOS and MacOS. This same problem has happened before when Apple abandoned earlier MacOS versions. They are nearly a trillion dollar company. They could easily put forth the effort to bring the old apps, all the way back to the Lisa, onto the modern operating systems with recompiling. Shame on Apple for creating deadwood.
For those who think it's too hard a problem, you're wrong. I'm a programmer and have written both compilers and cross compilers. You don't need the source code. If you have the final program you can run it through a cross compiler, a just-in-time compiler or just emulate to run it on different hardware. That list is in order of efficiency and preference. This is not a hard task. Apple has done it before.
Apple should be interested in doing this is it adds value for their customers because the software you use today will run tomorrow and because it maximizes the Apple application ecosystem which Apple likes to crow about in their marketing materials, ads, etc.
With the extraordinary computing power of todays devices this is all very easy and even emulated software can run faster than it did on the original hardware.
Imagine a world where all your old books, music, photos and other documents are no longer accessible because Apple and other companies drop support.
It is time for two pieces of legislation:
1) If a company or an individual wants to release a program they must also accept that their copyright and patents end within two years of their stopping supporting the software. Same thing for hardware. In other words, shorten the protection time dramatically. This will make it so other people can pickup the product and support it if they want to as fans or as another vendor.
2) If a company is above a certain threshold, which should be very low, then they must also release the supporting documentations for source code, maintenance, etc so that other people can pick it up.
3) If a company is at the high level of Google, Microsoft, Sun, Apple and the like then they must continue to offer legacy support for a minimum of 50 years in addition to #1 and #2 above.
How many dunderheads have been stuffing pointers into ints?
And yes, if you think it's OK to put a pointer value into an int with something like "int x = &myObject;", you're a dunderhead.
Well, your code will now break.
32-bit ios actually stands to be the first "lost platform" in computing history. EVER!
Hyperbole? Hear me out:
Unlike almost every other platform, there's no reliable and good way to run ios software (or ios itself) outside of the hardware. The only things that look like emulators are open source, and you can't even choose to install older versions of the OS on hardware past a cut-off date. Apple has fully DRMed their platform, fully closed it off. But up until now, if you have played by their rules, there's always been a way to run any given application: the expectation that your app can't be emulated well on Linux or whatever isn't something universal, so the computing consumer world has been pretty accepting of this.
This fully closed and cryptographically sealed system is something reasonably new in computing, and Apple's smashing success with it has encouraged others to duplicate it to some lesser degree- Windows 10S tries to take their model and offer a greater degree of freedom with an opt-out for cash (instead of no opt-out), Android has taken parts of their system, etc. But so far, everything has eventually (once it is no longer a primary economic driver) been emulated, been archived, been available for the future. Perhaps the loss of 32-bit ARM code compiled for ios is no great eternal loss to the world, but the precedent is now set for the expiry of code in a way that has never been done before.
Wrong. I do. I build my SDR app - which is a very complex thing - for 10.6.8 and up, and XP and up, is tested on all subsequent releases of both OSX and Windows, and (among other CPUs) on core 2 duo machines prior to release level issuance. It takes awhile, but mostly its rote testing using only slightly updated test suites, since I am long past requiring new OS calls.
Unless you actually need something from a later OS or CPU, there's no particular reason to target said CPU specifically, or to artificially inconvenience or lock out users of earlier hardware/OS (as Apple has done... the "Sierra won't run on these machines" business has been shown to be an artificial limit by software patches around the "oh no you don't" code that enables it to run just fine.)
In my case, a C2D provides (just barely) enough horsepower to run my app. Since it can, I see to it that it will. Further, since I have a 17" C2D macbook pro that still works fine (albeit running 10.6.8), it is always possible that some of my users do, or a C2D mini, as well. Many are still running 10.6.8 for certain, as I get a lot of mail / forum posts thanking me for keeping them covered. My app doesn't have a huge number of users - a few tens of thousands - but there are more than enough that my dev process has to cover a lot of OS levels and CPU types to be sure I'm not kicking someone downhill without any good reason. And yeah, I still carry that laptop around, and frankly, it pleases me that my app runs adequately on it.
Apple's move to 64-bit code is interesting. But unless the CPUs involved can't run 32-bit code, I rate choosing to obsolete applications people have bought or otherwise obtained legitimately to run on previous versions of the OS as pretty high on the scale of "Hey! Let's be fuckheads!" It's not like Apple is short of resources. If they want to support those apps, again barring impossible to address CPU-specific issues, they can. Which boils down to "Apple didn't have to screw you; Apple chose to screw you."
I've fallen off your lawn, and I can't get up.
This is an interesting one - their Pro base has a lot of music writers in it, and a lot of virtual instrements including major ones like Sylenth etc. are still 32bit only. Now previously there was a wrapper available that added a 64->32bit compatibility layer, but if I can't launch my 32 bit plugin at in the first place then such a wrapper is kind of pointless.
Could lose a lot of music production-related stuff this way.
MacRumors, it's "altogether", not "all together"....
... by which you mean, the only Office that existed until August of last year. Lots of people have Office 2008 or whatever for a variety of reasons - they don't use it much, they hate the Ribbon, etc. It is crazy to make someone pay $150 for a worse piece of software just so it will run on MacOS with security patches.
you can build a parallel-port based 8-bit logic analyzer capable of sampling at around 100,000 samples/second, using only a db25 connector and wires. Doing it with USB requires moving all the sampling logic to the other end of the USB cable, and usually storing the data in a large SRAM buffer for subsequent "chunky" transfer to the host PC.
It's no harder than, say, building a sound card. In fact, a 16 bit 48 kHz stereo audio input device has to buffer and push 48,000 32-bit frames of data per second, which is twice the data rate of the 8 channel 96 kHz logic analyzer you describe. There are USB sound cards on Walmart.com for $6.
Does "the whole ecosystem" make up for the increased data cache misses and OOM kills that an existing device with 2 GB of RAM running software with 64-bit pointers would suffer compared to the same device running software with 32-bit pointers?
The dropping of 32-bit for Linux is what actually made me angry.
What? When do you imagine that happened?
A year ago, Canonical announced plans to drop 32-bit Ubuntu. 18.04 will ship no 32-bit kernel, and 18.10 will ship no 32-bit system libraries.
I can still run 32 bit binaries on my 64 bit Ubuntu system.
This is true in 18.04 and earlier, but in 18.10 and later, you will have to run 32-bit Linux in a virtual machine on 64-bit Linux. Running two kernels and a VMM requires more RAM than multiarch, which means more thrashing swap on machines with swap or more OOM kills on machines without swap. And many devices running 64-bit GNU/Linux still max out at 2 GB, unable to recognize larger SODIMMs plugged into a machine's sole RAM slot. Or would you recommend putting swap on an external RAM drive?
Then purchase the 64-bit version of Sylenth 18 months from now once Lennar Digital finishes it. I thought Mac users were used to re-buying software periodically after architecture transitions, that is, those from 68K-24 to 68K-32 to PowerPC to PowerPC (OS X) to x86 to x86-64.
Plenty of quite expensive 32 bit iOS games such as Sega's Miku Flick 1 and 2, Wii port of Zombie Panic in Wonderland or Cave's Deathsmiles will be lost as many of these are no longer being supported by the developer and can only be downloaded by those who previously purchased them. I probably have $200 worth of such software which I occasionally fire up but which still works perfectly with iOS 10. Apple are douchebags.
Each doubling of bits is an exponential increase in memory, not just a doubling, of course. I'm thinking you aren't really cognizant of just how large an address space 64-bit allows you. It's a big difficult to imagine any consumer-facing applications such that 16 million terabytes of RAM isn't enough. Even the current CPUs on the market that "only" support 48-bit addressing can theoretically access 256 terabytes of RAM, which is still a staggering amount.
It's not me just being unimaginative, I think (i.e. like a certain famous-if-not-quite-true predictions about how much RAM anyone should ever need). There's a practical limit to the size of our data. A video file, for instance, only needs to get as big as necessary to approach the limit of human visual and audio resolution, and after that, it's just wasting space.
So, no, 64-bit is reasonably future-proof. I think its going to be a while before we start bumping up into those limits - maybe not even in our lifetimes. If we do move to 128-bit, it will probably be for reasons other than practical limitations.
Irony: Agile development has too much intertia to be abandoned now.
If we do move to 128-bit, it will probably be for reasons other than practical limitations.
Yep. And I think it will happen, just to be stupid. We can already handle 128 bit data types on some processors.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
If there's a perfectly usable piece of equipment, they'll arbitrarily can its support.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
Unlike almost every other platform, there's no reliable and good way to run ios software (or ios itself) outside of the hardware.
After some thought, I do not agree - because you can always buy newer devices to run the same software, all app data is migrated. It's not outside the platform but it's not like you cannot move forward.
you can't even choose to install older versions of the OS on hardware past a cut-off date.
You can if you jailbreak it which you absolutely can for any 32-bit IOS device.
But why does that even matter? That seems irrelevant from a standpoint of being able to continue to use the device with the software that you have, which you can. You'll just stop getting updates after a while.
You give this grad sweeping statement of this being the only time specific binaries have been left to age. But there are very probably other niche platforms for which no simulators exist. Even for iOS some simulators do exist... so I'm not even sure that is correct.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
"Can you prove that it would produce a greater return on investment for Apple Inc. shareholders than not doing so?"
That isn't necessary. Apple does a lot of things that aren't proven to produce a return for shareholders. That is part of what makes Apple great. Basic research.
But you're missing the point. Jobs promised users they would continue to have access to their digital lives into the future. To do that requires legacy support.
It is entirely possible you're to young to remember.
"Even car companies aren't held to that standard."
Time to start.
Actually I wonder if we do not go for 96 bits, or 100 bits tagged memory, to support higher level languages.
128 bit address space pretty unlikely that mankind will ever have a use for that. On the other hand it probably costs nothing to jump from 64 to 128 and marketing guys might demand it.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
windows 10 64 bit can work on 64 bit cpu macs that can't run 64 mac os as they have an older 32-bit efi. And with the mac pro 4.1 it needs an firmware from 4,1 to 5,1 (base system platform hardware is just about the same and the 4.1 needs it run newer cpu's) hack to run newer mac os to get around the soft blocks.
Personally, I have been working on getting apps running on 64-bit OS's since 1992 (DEC Alpha, OSF/1 == Digital UNIX).
So some whiney bee-atch-ess are complaining 25 years later?
Candidly, my response is "Go Screw Yourself"
It appears it may mean that some or all 32-bit APIs may be going away. So that's somewhat of a serious concern for me as it would break Qt's OS interface. Of course, there's always the VM route, which I expect to keep working until/unless VMWARE goes away. Oh, and Parallels, too. And the others.
I don't sell it, I give it away, and I have (and plan to have) no dealings whatsoever with Apple's app store. So no, not really a realization for me. :)
ARC: I manage my own memory. I have no need of ARC. I'm glad it's there for others in some versions of the OS, though. The problem I can't get around is that the OS itself leaks like a sieve. Still true as of 10.12. I always hope it'll be better with each new release, but not so far. If you want to unmask the worst cases of it, just turn off VM for a week and watch your memory consumption. Pretty sad.
My kernal_task is currently consuming 2.87 GB. By far the biggest wastrel. 14.52 GB of memory in use; except, no, it isn't. Also 9.25 GB cached, which, meh, I'm not too worried about performance boost caching, but some of that stuff hasn't been used in weeks. I'll have to reboot to clean it up, or fling purge at the system, which cleans up waaaay too much.
ABI: The problem here is that it means abandoning support for earlier OS's, and there's no actual reason to do that at this time. Particularly in that there is operating hardware in the field that Apple won't let run the new OS levels. Quite arbitrarily, too.
I will confess though... if Apple and the Qt people actually made a serious effort to clean up all the reported bugs instead of only the ones that have X>N reporters, they might be able to tempt me into a new build using the latest and greatest.
Unfortunately, both of them are a lot more interested in "shiny" than they are in "works like we claimed it works." They both habitually leave broken software systems unrepaired, while leaping into the future with the New Shiny. And besides... if they did fix all those bugs, I expect I'd get the benefit without building anew. The reason I say that is that builds that are 100% under Windows are less so under OS X. It seems very likely indeed that the problem is specific to OS X, especially considering how badly the OS leaks for pretty much everything app it runs. Including itself.
I've fallen off your lawn, and I can't get up.
So they went 64 bit only, so they could use less memory? Thats a funny one.
Any saving would be out bloated by orders of magnitude trying to add everything and the kitchen sink, Apple standard since forever.
There are potential uses for more than 64-bit address spaces. I don't know that that will ever become an issue with RAM, but memory-mapping SSD storage could be useful. Given enough connectivity, it might become desirable to have an address space that includes IP addresses separately, so maybe 256 bits. My limited imagination is not coming up with any reason to go to 512 bits, though.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
"I'm just going to change this one little thing! Just one, and it's so little. Everything else will stay the same, so I can be sure that the system will continue working fine."
Then you discover that others have been making "minor substitutions and upgrades" just as you want to do. Eventually there is a breaking change. Often you won't know about it until it is too late.
I long ago came to the conclusion, that if you want to run ancient software, buy duplicate hardware. And don't wait, buy it now! Put it on the shelf so that when the day comes, you swap out the old dead hardware for the old working hardware. That is the best way to ensure you can run ancient software for many, many years.
And the day will come when you need to perform that swap.