Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Operating Systems OS X Software Apple Technology

Apple Prepares MacOS Users For Discontinuation of 32-Bit App Support (arstechnica.com) 180

Posted by BeauHD from the no-compromises dept.
Last year, Apple announced that macOS High Sierra "will be the last macOS release to support 32-bit apps without compromise." Now, in the macOS High Sierra 10.13.4 beta, Apple is notifying users of the impending change, too. "To prepare for a future release of macOS in which 32-bit software will no longer run without compromise, starting in macOS High Sierra 10.13.4, a user is notified on the launch of an app that depends on 32-bit software. The alert appears only once per app," Apple says in the beta release notes. Ars Technica reports: When users attempt to launch a 32-bit app in 10.13.4, it will still launch, but it will do so with a warning message notifying the user that the app will eventually not be compatible with the operating system unless it is updated. This follows the same approach that Apple took with iOS, which completed its sunset of 32-bit app support with iOS 11 last fall. Developers and users curious about how this will play out will be able to look at the similar process in iOS for context. On January 1 of this year, Apple stopped accepting 32-bit app submissions in the Mac App Store. This June, the company will also stop accepting updates for existing 32-bit applications. iOS followed a similar progression, with 32-bit app submissions ending in February of 2015 and acceptance of app updates for 32-bit apps ending in June of 2015.
This discussion has been archived. No new comments can be posted.

Apple Prepares MacOS Users For Discontinuation of 32-Bit App Support More

Apple Prepares MacOS Users For Discontinuation of 32-Bit App Support

Comments Filter:

  • Apple compatibility is a joke (Score:4, Interesting)

    by Anonymous Coward on Thursday January 25, 2018 @09:37PM (#56004693)

    I can still run Windows apps originally compiled in 1992 on Windows 10.

    Just sayin'.

    • Re:Apple compatibility is a joke (Score:4, Insightful)

      by Anonymous Coward on Thursday January 25, 2018 @09:44PM (#56004737)
      Microsoft needs to maintain Windows compatibility because it's used extensively in the business world for mission-critical applications, sometimes requiring that old and unsupported software still work the way it always did. Apple can get away with this more easily because most Macs are in the home, being used for... well I'm not exactly sure what people use them for, Facebook or something I guess, but they wouldn't be caught dead using old software.

      • Re: Apple compatibility is a joke (Score:2, Funny)

        by Anonymous Coward

        Once had a woman laugh at me because I used the WSDOT webpage to view Seattle traffic maps. Literally said "Your 'app' looks so old fashioned" and remarked how quaint it was, like I was using fucking Gopher or something.

        She was an Apple user.

        • Re: (Score:3)

          by colinwb ( 827584 )

          I still use Gopher, you insensitive clod!

          (Well, actually I've never used Gopher, but apparently some people still do: Gopher protocol [wikipedia.org]:
          ... Gopher has been described by some enthusiasts as "faster and more efficient and so much more organised" than today's Web services. The Gopher protocol is still in use by enthusiasts, and although it has been almost entirely supplanted by the Web, a small population of actively maintained servers remains. ...)

      • Re: (Score:3, Informative)

        by codlong ( 534744 )
        I know a lot of people use linux, but our shop uses exclusively Apple macbook pros for developers. The system admins lobbied for it because they claim they are much easier to maintain, and OS X gives us a BSD-based system to develop on. Apple is fantastic for professional developers, not just grandma using Facebook.

    • Re: (Score:2, Informative)

      by sit1963nz ( 934837 )
      Weird because we have lots of Windows XP, Win7 and Win8 Apps that fail to run under Win10. Just sayin'

      • Re: Apple compatibility is a joke (Score:5, Interesting)

        by Midnight Thunder ( 17205 ) on Friday January 26, 2018 @01:04AM (#56005467) Homepage Journal

        While I do feel Apple can be too eager in breaking backwards compatibility, I also think Microsoftâ(TM)s model is equally absurd.

        In many ways I imagine the better model would be to to break backwards compatibility and then run legacy apps in a transparent VM. Maybe something like Wine for Legacy Windows?

        • Re: Apple compatibility is a joke (Score:4, Informative)

          by Hal_Porter ( 817932 ) on Friday January 26, 2018 @03:09AM (#56005681)

          You should go to Raymond Chen's Old New Thing blog and tell him this. I'm sure he'd be eager to hear one liner technical advice from Slashdotters on how Microsoft should handle back compatibility.

          https://blogs.msdn.microsoft.c... [microsoft.com]

          • Chen wrote that back in 2005. VM technology is drastically better than it was more than 12 years ago.

            • I've got a Mac and I run Windows 10 in a Parallels VM. It's true that Parallels has a number of technical advances on the XP mode for Windows 7. However much of this paragraph would still apply

              Since the virtual machine is running its own operating system, you can't easily share information across the virtual machine boundary. For example, suppose somebody double-clicks a .XYZ file, and the program responsible for .XYZ files is set to run in a virtual machine.

              * Start the virtual machine.
              * Log an appropriate user on. Hopefully, the user has an account in the virtual machine image, too. And of course the user will have to type their password in again.
              * Once the system has logged the user on, transfer the file that the user double-clicked into the virtual machine's hard drive image somehow. It's possible that there are multiple files involved, all of which need to be transferred, and the identities of these bonus files might not be obvious. (Your word processor might need your spelling exceptions list, for example.)
              * Run the target program with the path to the copied file as its command line argument.
              * The program appears on the virtual machine operating system's taskbar, not on the main operating system's taskbar. Alt+Tab turns into a big mess.
              * When the user exits the target program, the resulting file needs to be copied back to the main operating system. Good luck dealing with conflicts if somebody changed the file in the main operating system in the meanwhile.

              The hassle with copying files around can be remedied by treating the main operating system's hard drive as a remote network drive in the virtual machine operating system. But that helps only the local hard drive scenario. If the user double-clicks a .XYZ file from a network server, you'll have to re-map that server in the virtual machine. In all cases, you'll have to worry about the case that the drive letter and path may have changed as a result of the mapping.

              And that's just the first problem. Users will expect to be able to treat that program in the virtual machine as if it were running on the main operating system. Drag-and-drop and copy/paste need to work across the virtual machine boundary. Perhaps they get information via e-mail (and their e-mail program is running in the main operating system) and they want to paste it into the program running in the virtual machine. International keyboard settings wouldn't be synchronized; changing between the English and German keyboards by tapping Ctrl+Shift in the main operating system would have no effect on the virtual machine keyboard.

              Isolating the program in a virtual machine means that it doesn't get an accurate view of the world. If the program creates a taskbar notification icon, that icon will appear in the virtual machine's taskbar, not on the main taskbar. If the program tries to use DDE to communicate with Internet Explorer, it won't succeed because Internet Explorer is running in the main virtual machine. And woe unto a program that tries to FindWindow and then SendMessage to a window running in the other operating system.

              If the program uses OLE to host an embedded Excel spreadsheet, you will have to install Excel in the virtual machine operating system, and when you activate the object, Excel will run in the virtual machine rather than running in the main operating system. Which can be quite confusing if a copy of Excel is also running in the main operating system, since Excel is a single-instance program. Yet somehow you got two instances running that can't talk to each other. And running a virus checker in a virtual machine won't help keep your main operating system safe.

              As has already been noted, the virtual machine approach also doesn't do anything to solve the plug-in problem. You can't run Internet Explorer in the main operating system and an Internet Explorer plug-in in a virtual machine. And since there are so many ways that programs on the desktop can interact with each other, you can think of each program as just another Windows plug-in.

              In a significant sense, a virtual machine is like having another computer. Imagine if the Windows compatibility story was "Buy another computer to run your old programs. Sharing information between the two computers is your own problem." I doubt people would be pleased.

              Even with a Parallels type VM where the VM windows appear on the host machine's desktop, copy paste works and drives are shared you've still got the fundamental feature that what happens in the VM stays in the VM.

              Now for me, that's actually something of a feature - I want to be able to run a separate Windows 10 machin

        • In many ways I imagine the better model would be to to break backwards compatibility and then run legacy apps in a transparent VM. Maybe something like Wine for Legacy Windows?

          You mean like Windows XP Mode for Windows 7? It was a Virtual PC environment that ran a copy of Windows XP which was viewed with Remote Desktop to appear as if the application Windows ran on the main desktop. It was a good way to run 16-bit applications on a 64-bit version of Windows.

          Of course, the way that you run 32-bit programs on 64-bit Windows is through a layer called WoW64. This quite literally stands for Windows on Windows. It is a subsystem that translates the differences between 32- and 64-bit API

          • If you read Raymond Chen's Old New Thing blog he explains how the compatibility stuff is mostly in shims that get loaded only when an application needs them. So the notion that worrying about compatibility held back Microsoft is dubious.

            Despite that Microsoft did abandon back compatibility around XP SP3 and Vista which both broke insecure code. And then they tried to convince people to stop writing Win32 code and start writing code for their newest API which changed every year. Joel ranted about this memora

      • Weird because we have lots of Windows XP, Win7 and Win8 Apps that fail to run under Win10. Just sayin'

        This! I've always wondered what world the backwards compatible people live in. Probably using XP and only think that everything they have is forwards compatible.

        It's hard to get happy about, but Windows does the same thing as Apple. It even removes apps without asking. If they pray at the altar of backwards compatibility, they should just leave the programs like WMP alone.

        This isn't to excuse Apple. The High Sierra update killed my Final Cut Studio suite's Apps.

        So I installed them on a Core2Duo 27 i

        • The High Sierra update killed my Final Cut Studio suite's Apps.

          Sierra killed Motion first. I might have to buy an ancient iMac for FCP, since I don't do enough video work to buy new software - or worse, subscribe.

          • The High Sierra update killed my Final Cut Studio suite's Apps.

            Sierra killed Motion first. I might have to buy an ancient iMac for FCP, since I don't do enough video work to buy new software - or worse, subscribe.

            Yes, that was some years ago, and I forgot. I used Motion fairly often too. My old iMac with dual core isn't a speed demon by today's standards, but fast enough.

    • Re:Apple compatibility is a joke (Score:5, Informative)

      by 0100010001010011 ( 652467 ) on Thursday January 25, 2018 @09:54PM (#56004775)

      Apple has handled 68k -> PPC -> PPC64 -> x86 -> x64 -> arm -> arm64 fairly well.

      How much 'cruft' and security holes exist in Windows because of that backwards compatibility? Let some things die. If you want to run an app on Windows 3.1, run a VM of Windows 3.1.

      • There are some games that just won't ever be ported to 64 bit. That's a crying shame those will go the way of the Dodo. For everything else you shouldn't use apps that are so old. The transition to 64-bit apps on macOS has happened long ago. It's a non issue for everything but games.

        • Which ones? No really... serious question. Can you think of any titles?

          Don't get me wrong... I have a fair assortment of classic games. But most are purchased from GoG and run in dosbox, which I have no doubt will be updated to support 64-bit Macs, assuming it hasn't already. (Sid Meier's Alpha Centauri still gets regular gameplay and is still much better than the disappointment that is Civ: Beyond Earth.) But in the last decade and a half, going from old versions of OS X that included Classic OS 9 emul

          • A lot of the games (including a lot of the ones bought from GOG) that I run are 32-bit Windows binaries running in WINE. That said, it's not clear that WINE needs to actually be a 32-bit Mach-O binary: it already includes its own PE loader and a bunch of translation layers that turn Windows structures into host system structures. It could probably be a 64-bit binary that would switch to 32-bit mode before jumping into Windows code and back to 64-bit code before switching out.

            I doubt that Apple wants to

            • Re: (Score:2)

              by Rob Y. ( 110975 )

              That was my question. I have a win32 app that runs on the Mac under WINE, and I've seen no reason to port it to be Win64 code. It still works fine on Windows and Linux/WINE, and to tell the truth, requests to run it on Macs have been pretty few and far between - though it works well there under WINE too.

              Are you saying a 64-bit version of WINE will retain the ability to run 32-bit windows apps - or will this mean WINE can only run 64-bit windows apps in the future? What about Parallels? Will it run 64-bi

            • And I'm sure the important thing is that it doesn't rely on any 32-bit macOS APIs.

          • Re: (Score:2)

            by _merlin ( 160982 )

            I still wish Bugdom and Deimos Rising didn't stop working, even before Apple switched to x86. Stuff gets broken by OS updates all the time.

      • By fairly well you fail to acknowledge the massive fuck you that was given to it's core audience (content creators) as companies like Adobe struggled to produce versions of their software thanks to the change. There were whole versions of Photoshop not available on Mac (THE platform to have if you used Photoshop professionally) because of the "fairly well" handled transition.

        Cruft? Definitely. When the Windows source code leaks happened years ago there was a lot of comments in security circles on how much c

      • Apple has handled 68k -> PPC -> PPC64 -> x86 -> x64 -> arm -> arm64 fairly well.

        IMHO, it was idiotic for Apple to go x86, because x86-64 was already available at the time. Soon after their first x86 machines, they moved on to Core 2, but the performance was crippled for a long time due to compatibility. And now they need this final transition stage to clean it all up.

    • I can still run Windows apps originally compiled in 1992 on Windows 10.

      Just sayin'.

      But you deal with the consequences in the limitations legacy support has put on windows development over the last 20 years.

    • Any OSX app going back to the start of the intel era still runs, so this is the first break in compatibility. However itâ(TM)s entirely reasonable , itâ(TM)s been a very long time since apples actually made a 32bit machine and weâ(TM)re talking about 12 year old software

  • Going to be some resistance to this one (Score:4, Informative)

    by fyngyrz ( 762201 ) on Thursday January 25, 2018 @09:38PM (#56004701) Homepage Journal

    I think it likely there's going to be a lot of resistance to this one. There are an awful lot of perfectly good apps out there where the developers have gone away - they're just not going to make the transition to 64-bit. Apple's asking a very large number of users to take a serious a hit in terms of lost investment all at once.

    There's no particularly good reason for it. The existing OS support can be frozen, and new OS stuff added; it's not like we're short on memory or storage.

    For some, the answer will be to simply not move to the new OS (notice I didn't use the term "upgrade.") For others, it may be a VM, unless the VM's can't run in 32-bit mode (don't know why that would be the case, but perhaps it is.)

    It is Apple's habit to go with "hey, I have an idea" where for some reason, no one stands up and tells them "you know, that's not a good idea..." They did it with the PPC emulation, they did it with headphone jacks, they did it with slowing down people's phones, and now... now they're going to kill a lot of people's tools.

    Interesting times for Apple.

    • Re: (Score:3)

      by msauve ( 701917 )
      Bend over and take it.

      Macs haven't run my 68K apps for years. 8088 MS-DOS 3.1 batch files still (mostly) work in Windoze, though.

      • Opensource (Score:4, Insightful)

        by DrYak ( 748999 ) on Friday January 26, 2018 @09:03AM (#56006457) Homepage

        Macs haven't run my 68K {NOTE: binary} apps for years. 8088 MS-DOS 3.1 batch {text, source} files still (mostly) work in Windoze, though.

        NOTE: {notes} are mine.

        Which makes a great argument in favor of accessible source.
        Because your batch file are human readable text-file, you can even edit what's needed to remove the "(mostly)" part of the sentence.
        Much more difficult with binary 68k machine code.

        If you had access to the original C / Pascal code that the 68k apps were compiled from, it would be much more easy for devs to adapts them to modern architectures/APIs.

        • Much more difficult with binary 68k machine code.

          OK, but you can install the 32 bit version of Windows 10, and still load the GWBASIC.EXE compiled in 1986 on a current operating system.

          Microsoft did away with 16 bit compatibility layer in the 64 bit OS, but as others have pointed out, VMs and things like DosBox make it not a big loss.

          Mac users seem more accustomed to having old software getting obsoleted into oblivion. I don't even know how I'd go about running some PPC-era app now if it wasn't open-sourced or modernized. They had Rosetta on early Inte

          • OK, but you can install the 32 bit version of Windows 10, and still load the GWBASIC.EXE compiled in 1986 on a current operating system.

            Yup. Indeed, Microsoft (and FreeDOS. And DosBox. And dosemu) do maintain the set of API needed to get it running. (Basically, IBM-PC BIOS Interrupt call APIs, and DOS int 21h API. And an extra ton of emulated audio/video hardware in the case of DosBox).
            (It helps that 3 out of the 4 mentioned software are opensource, and thus can share a bit of the workload: Indeed, dosemu uses bits from FreeDOS to provide the Int 21h MS-DOS API).

            Though note again that most of the things that you will run *inside* GWBASIC.EX

      • A MS-DOS batch file is a text file ... obviously it runs on modern windows.

        Posts like this show how less clue you have about computers ...

        • Re: (Score:2)

          by msauve ( 701917 )
          A batch file is a program. That's it's in human readable ASCII text has no bearing on that. Perhaps you're familiar with JavaScript? That's "just a text file," too.

          More specific to my OP - for a while, Apple included a PPC to x86 translator to allow applications compiled for PPC to run on x86. They dropped that too, deliberately breaking backward compatibility. Apple has a short attention span and doesn't give a shit about protecting their customer's investments. (see: recent deliberate slowing of older iP

          • A batch file is a program. That's it's in human readable ASCII text has no bearing on that.
            Comments like this show how much clue you have about the working of computers ...
            A human readable text filed does not (need to) know if the kernal is 32bit or 64bit ... go figure.

            • Re: (Score:2)

              by msauve ( 701917 )
              No, just whether it's ASCII, EBCDIC, UTF-8, UTF-16, or UTF-32 (and a whole bunch of others). Once you get through CS101, you'll understand.

              • We nave no CS 101 in my country :) And I doubt CS 101 in your ccountry covers EBCDIC etc.

                And yet again: no, the text filed does not (need to) know if it ASCII or any other format. The interpreter needs to know ...
                And now stop this farce.

      • Bend over and take it. Macs haven't run my 68K apps for years. 8088 MS-DOS 3.1 batch files still (mostly) work in Windoze, though.

        Let me tell you about my copy of Visual Studio 2005 that will not work on W10. But at let you have those mostly working files.

    • Re:Going to be some resistance to this one (Score:5, Insightful)

      by sit1963nz ( 934837 ) on Thursday January 25, 2018 @10:00PM (#56004803)
      What the hell are you talking about ????

      If you do not move to the new OS, all you existing Apps will work just fine, there is no "hit"

      You do NOT have to move, you do NOT have to upgrade, these choices are 100% the end users. Version 13.4 of OSX will simply be warning you in advance that OSX 14 will no longer support 32 bit Apps. You can then either choose to stay on 13 and get support for another couple of years or move to version 14 and upgrade your Apps.
      Apple is not going to kill anyones tools, they will continue to function tomorrow just as they did today.

      For example my old iPad still works today even though Apple no longer supplies updates for it. It is stuck at IOS 9.
      Bento on it however works fine and is still useful.

      • Re:Going to be some resistance to this one (Score:5, Interesting)

        by Immerman ( 2627577 ) on Thursday January 25, 2018 @10:42PM (#56005011)

        Having developed on both platforms (addmitedly only some on Apple), I have to say that Apple has a tendency to add a lot of little "programmer shinies" with every new update - handy new utilities, programming features, etc. that tempt developers to use them. Which then makes their software incompatible with older versions of the OS. So, if you want to keep running the latest versions of all your modern apps you pretty much need a fairly recent version of the OS.

        Contrast that with Microsoft, whose "go suck it" attitude to developers, and tendency to try to replace old, reliable components with newer, more annoying ways of doing things, combined with their commitment to maintaining backwards compatibility, means that developers tend to stick with the old tried-and-true standbys, unless there's some compelling reason to move forward (e.g. powerful new features added in DirectX 10 and 11).

        Apple's approach does a lot more to create a constantly improving programming environment (or at least the impression of one), but also keeps their users on a more vigorous upgrade treadmill.

        That said - at this point I suspect most 32 bit-only Apple software can probably run in an "emulated" compatibility layer with plenty of performance, much as older XP apps can do on modern windows. But such compatibility is always imperfect, hence "will be the last macOS release to support 32-bit apps without compromise."

        • Apple also has no qualms about promoting the crap out of something, then if it doesn't stick quickly deprecating and removing it, which can mean often times having to re-write entire apps because you bought into the Apple hype about a particular framework and it being the "future" of that kind of dev on mac. I ported a bunch of legacy stuff to Apple's "new" video editing/playback framework(whose name escapes me, this was a while back) only to have that framework totally scrapped and a completely new one pu

          • Yep, that's the impression I got - one of the reasons I didn't stay long - I'd rather spend most my time making new and useful tools than constantly learning how to use the new tools in my toolbox, even if they really are superior to the old ones.

            Still, they've obviously got enough of a developer base willing to jump through those hoops to let them get away with it, and it's probably letting them evolve much faster than they otherwise would. Almost Linux-like in a way, with new better technologies constant

      • >You do NOT have to move If this were true I would still be on 10.6, back when the OS was reliable and all this annoying crap hadn't been added yet. At some point you stop getting security updates and homebrew stops working. Staying behind more than a couple of versions is unfortunately not feasible for internet-connected devices.

        • If you don't behave loke an idiot in the internet, the OS version has not much to say.
          My 17" runs happily on 10.6.8.

      • What the hell are you talking about ???? If you do not move to the new OS, all you existing Apps will work just fine, there is no "hit" You do NOT have to move, you do NOT have to upgrade, these choices are 100% the end users.

        To be certain, I didn't see any warnings when High Sierra nuked my Final Cut Studio.

        I would have taken the day's loss effort to go back to the previous OS, but I had an older Mac that isn't supported any more, so I just installed the programs on that.

        But this is the bigger issue to me, not ancient MS-DOS batch files or 68K programs. Having been bit both on the Mac end and the Windows end, it's just screwed up that perfectly functional ad expensive software gets cast aside.

    • I think it likely there's going to be a lot of resistance to this one. There are an awful lot of perfectly good apps out there where the developers have gone away - they're just not going to make the transition to 64-bit. Apple's asking a very large number of users to take a serious a hit in terms of lost investment all at once.

      The way I see it, if it's a great app that been abandoned, this is a great time for developers to modernize them. If there are apps out there that are laden with patents/copyrights and can't be modernized... there's always virtual machines, which may be a better place for these apps to live.

    • I think it likely there's going to be a lot of resistance to this one. There are an awful lot of perfectly good apps out there where the developers have gone away - they're just not going to make the transition to 64-bit.

      Which ones are those? I'm not trying to be a smartass - I'm genuinely curious. I can't recall the last time I used a 32 bit Mac Application.

      Apple's asking a very large number of users to take a serious a hit in terms of lost investment all at once.

      True, and not true. At this time, a warning is issued that it will eventually not work. Now the true part isn't related to 32 versus 64 bit. When I upgraded to High Sierra, it killed my Final Cut Studio install. Not wanting to spend the bucks for an already functioning software that got botched, I had a Core2Duo iMac sitting around that now runs Final Cut Studio.

      The

  • How the hell am I supposed to (Score:4, Funny)

    by tgibson ( 131396 ) on Thursday January 25, 2018 @10:14PM (#56004859) Homepage

    do anything useful using only numbers larger than 2,147,483,647?

    • Hey man, the new OS is 64 bit, not 33 - you can only use numbers greater than 9,223,372,036,854,775,807.

  • So what special exception will they make to kowtow to Intuit, who has steadfastly refused to update their Quicken 2007 locally hosted app. This 11 year old app is still used by many, and made use of Rosetta so its 68K code could run on Intel iron. When Rosetta was retired by Apple, Apple made special dispensation so that lazy intuit could still run this essential financial application on modern Mac OS with little modification, up to today under High Sierra. I have no doubt most of its code is the same 68K c

  • If you plan on keeping your OS up-to-date, than I would highly recommend that you keep an eye out for -- nay, even seek out -- these warning messages. I had an experience with my iPhone, which I view as a bit of foreshadowing here:

    I was participating in the iOS beta program, and I pretty much ignored the iOS 10 obsolescence warnings, even though I knew better. That meant that I was essentially blazing the trail, so there were no user stories online to enable me to learn from the mistakes of other people...

Slashdot Top Deals

E = MC ** 2 +- 3db

Close