12 ms·

Apple will phase out Rosetta 2 in macOS 28

• gumboshoes 1y ago
  Seems premature. My scanner software, SnapScan, still regularly updated, requires Rosetta. Abbyy FineReaser, the best Mac OCR, requires Rosetta. Although they may be related, as the SnaScan software does OCR with the FineReader engine.
  • morshu9001 1y ago
    Owning a Mac has always meant not relying on 3P software. Forget printer/scanner drivers. Even if they target macOS perfectly, there will come a day when you need to borrow a Windows PC or old Mac to print. It happens to be ok for me as a SWE with basic home uses, so their exact target user. Given how many other people need their OS to do its primary job of running software, idk how they expect to gain customers this way. It's good that they don't junk up the OS with absolute legacy support, but at least provide some kind of emulation even if it's slow.
  • caseyohara 1y ago
    The M1 chip and Rosetta 2 were introduced in 2020. macOS 28 will be released in 2027. 7 years seems like plenty of time for software vendors to make the necessary updates. If Apple never discontinues Rosetta support, vendors will never update their software to run natively on Apple chips.
    • spacechild1 1y ago
      There is lots of existing software (audio plugins, games, etc.) that will never see an update. All of that software will be lost. Most new software has ARM or universal binaries. If some vendors refuse to update their software, it's their problem. Windows still supports 32-bit applications, yet almost all new software is 64-bit.
    • out_of_protocol 1y ago
      Windows 95 was released... well, in 1995. In 2025 you can run apps targeting W95 just fine (and many 16-bit apps with some effort)
      • stalfosknight 1y ago
        That's not necessarily a good thing.
      • K7PJP 1y ago
        This isn't a new or unique move; Apple has never prioritized backwards compatibility. If you're a Mac user, you expect this sort of thing. If running neglected software is critical to you, you run Windows or you keep your old Macs around.
        • timw4mail 1y ago
          I seem to remember 68k software working (on PowerPC Macs) until Classic was killed off in Leopard? I'm likely misremembering the length of time, but it seems like that was the longest backwards-compatibility streak Apple had.
        • torstenvl 1y ago
          It's a bizarre assumption that this is about "neglected software." A lot of software is for x64 only. If Rosetta2 goes away, Parallels support for x64 binaries in VMs likely goes away too. Parallels is not neglected software. The x64 software you'd want to run on Parallels are not neglected software. This is a short-sighted move. It's also completely unprecedented; Apple has dropped support for previous architectures and runtimes before, but never when the architecture or runtime was the de facto standard. https://docs.parallels.com/parallels-desktop-developers-guide/software-development-specific-functions-of-parallels-desktop/using-rosetta-to-run-x86-64-linux-software-on-apple-silicon-macs https://docs.parallels.com/parallels-desktop-developers-guid...
          • galad87 1y ago
            Paralles x86_64 emulation doesn't depend on Rosetta.
    • linguae 1y ago
      This is also consistent with Apple’s previous behavior with backwards compatibility, where Apple would provide a few years of support for the previous platform but will strongly nudge developers and users to move on. The Classic environment in Mac OS X that enabled classic Mac OS apps to run didn’t survive the Intel switch and was unavailable in Leopard even for PowerPC Macs, and the original Rosetta for PowerPC Mac OS X applications was not included starting with Lion, the release after Snow Leopard.
      • delusional 1y ago
        Honestly, for apple this is above and beyond. They've killed support with less fanfare and compatibility support than what we see here.
        • bigyabai 1y ago
          Bully on me for owning hardware and expecting it to behave consistently across OTA updates.
          • renewiltord 1y ago
            I think you probably should not buy Apple hardware. It is not a guarantee they have ever offered that their software would behave consistently across updates. If this mattered to me, I would have done some research and rapidly found out that Apple has done this every few years for the last 30 years.
            • subarctic 1y ago
              But their new hardware is so good though, it's kind of hard to pass up
          • searls 1y ago
            At what point in history have you owned a particular piece of hardware for use with a particular piece of never-to-be-updated software and installed a major OEM operating system release a full 7 years after release without issue? I doubt such a thing has ever happened in the history of consumer-facing computing.
    • watermelon0 1y ago
      The main problem is not native software, but virtualization, since ARM64 hardware is still quite uncommon for Windows/Linux, and we need Rosetta for decent performance when running AMD64 in virtual machines.
  • sixothree 1y ago
    I spent what I would consider to be a lot of money for a unitasker Fujitsu scanner device and am just astounded by how unmaintained and primitive the software is. I only use it on a Windows machine though, so I'm not in the same boat.
  • bitwize 1y ago
    This is Apple's "get your shit together and port to ARM64, you have 2 years" warning. If you're not willing to commit to supporting the latest and greatest, you shouldn't be developing for Apple.
  • eisa01 1y ago
    You can most likely use Vuescan, I use that with an old ScanSnap i500 (or something) [1] https://www.hamrick.com https://www.hamrick.com
    • ZeWaka 1y ago
      Love VueScan for my film scanner!
    • e40 11mo ago
      I have Vuescan and it’s not even close.
  • joshuat 1y ago
    I think this is exactly what they're issuing this notice to address. Rosetta performs so well that vendors are pretty okay just using it as long as possible, but a two year warning gives a clear signal that it's time to migrate.
    • jayd16 1y ago
      If it's ok now then what's even the problem with letting it be?
      • coder543 1y ago
        One problem from Apple’s perspective is that it continues to cost them money to maintain both the translation layer and the x86_64 frameworks on an ongoing basis.
        • jayd16 1y ago
          I mean, is it really an excessive burden to keep a "too popular" feature alive for users? Features users pay for cost money to build and maintain. These aren't unique situations. It would be different if the feature wasn't popular at all but that doesn't seem to be the case.
          • coder543 1y ago
            It doesn't seem especially popular to me, so... citation needed? It's not being discontinued for being too popular, that's for sure. Apple doesn't want to maintain it forever, and a handful of legacy apps will never be bothered to update to native Apple Silicon support unless it means losing access to their user base. Apple has given them plenty of time to do it naturally, and now Apple is giving them a stronger reason and a couple more years to get it done. Apple is not randomly discontinuing it with no notice; two years is plenty of time for maintained software to get over the finish line. At the end of the day, Apple doesn't want to pay to maintain this compatibility layer for forever, and Apple's customers will have a better experience in the long run if the software they are using is not running through an extra translation layer. There will always be some niche users who want this feature to remain forever, but it's clearly not a significant enough percentage of users for Apple to be worried about that, or else Apple would maintain it forever.
  • al_borland 1y ago
    They were pretty quick to sunset the PPC version of Rosetta as well. It forces developers to prioritize making the change, or making it clear that their software isn’t supported. It The one I have my eye on is Minecraft. While not mission critical in anyway, they were fairly quick to update the game itself, but failed to update the launcher. Last time I looked at the bug report, it was close and someone had to re-open it. It’s almost like the devs installed Rosetta2 and don’t realize their launcher is using it.
    • mrpippy 1y ago
      Rosetta for PPC apps was supported from the first Intel Macs released in January 2006 until 10.7 Lion was released in July 2011.
      • JimDabell 1y ago
        So just over five years? If Apple phase out Rosetta 2 in macOS 28, then it will have been supported for seven years.
  • poemxo 1y ago
    I usually agree with Apple but I don't agree with this. Rosetta 28 is basically magic, why would they take away one of their own strongest features? If they want big name apps to compile to Apple Silicon, why can't they exert pressure through their codesigning process instead?
    • drob518 1y ago
      The “big name apps” have already moved to Apple Silicon. Rosetta helped them with that process a few years ago. We’re down to the long tail apps now. At some point, Rosetta is only helping a couple people and it won’t make sense to support it. I just looked, and right now on my M1 Air, I have exactly one x86 app running, and I was honestly surprised to find that one (Safari plug-in). Everything else is running ARM. My workload is office, general productivity, and Java software development. I’m sure that if you allow your Mac to report back app usage to Apple, they know if you’re using Rosetta or not, and if so, which apps require it. I suspect that’s why they’re telegraphing that they are about ready to pull the plug.
      • prewett 1y ago
        How do you check if you're running any x86 apps?
        • thijsvandien 1y ago
          There's this Silicon app that scans your disk for them: https://github.com/DigiDNA/Silicon https://github.com/DigiDNA/Silicon.
        • timsneath 1y ago
          In macOS 26, you can see every Rosetta app that has recently run on your machine by going to System Information and then Software / Rosetta Software. It includes the "Fallback Reason" (e.g. if you manually forced the app under Rosetta or if it was an Intel-only binary).
          • alwillis 1y ago
  • e40 11mo ago
    Me, too. Would be horrible to lose access to my scanner. I have no faith in Fujitsu tgat they would support my iX500.
  • jajuuka 11mo ago
    QEMU will still be an option. Albeit not the fastest or easiest option compared to Rosetta 2.
• PeaceTed 1y ago
  By the time this happens, it will have been a 7 year transition. That isn't too bad considering the original Rosetta only got 5. I do have sympathy for those that still use this in their daily work flow, but also... this is Apple. This is how they have always rolled.
  • sedatk 1y ago
    Meanwhile, I can still run my apps from the 90’s on my ARM laptop on Windows. That’s two architectures back to be clear: ARM64 -> x86-64 -> x86
• kstenerud 1y ago
  Would be nice if they open sourced Rosetta, so that the community could continue support.
• keyle 1y ago
  That means the end of the Hackintosh era if the OS won't run x86, I imagine it won't install on x86 either.
  • cmckn 1y ago
    Aw that bums me out, brings back a lot of memories. Though I assume it’s been effectively dead for a while. I haven’t dabbled with hackintoshes in nearly a decade, I stepped away around the time iMessage started needing those extensive hacks to work. Things seemed to shift away from driver/bootloader gaps to faking Apple hardware. Years earlier, I had an Asus Eee PC (remember “netbooks”?) that ran macOS without any major issues. I even built a machine that I believed I could hackintosh easily, though it never quite worked as well as I hoped. The era of random companies selling pre-built Hackintoshes was so cool. Kids these days probably wouldn’t even believe it if you told them, like how Netflix used to actually send you a DVD in the mail. :)
  • pjmlp 1y ago
    Tahoe is officially the last version to support x86. I never liked the idea, either get Apple, or get one of the other OSes. It was like getting a Fiat Coupe with a Ferrari logo.
• deleted 1y ago
  [deleted]
• 0x0 1y ago
  I'm guessing they don't want to maintain and build and test x86_64 versions of all the macos libraries like Appkit and UIKit (including large changes like liquid glass) when they are no longer shipping x86_64 macOS versions. Which is not entirely unreasonable as I'm sure it takes a lot of effort to keep the whole ui library stack working properly on multiple archs. Perhaps that's what they're hinting about with the note about a "subset of Rosetta". So maybe there is hope that the core x86_64 binary translator will stick around for things like VM and emulation of generic (linux? wine?) binaries, but they don't want to maintain a whole x86_64 macOS userspace going forward. Space savings from not shipping fat binaries for everything will probably also be not insignificant. Or make room for a new fat binary for a future "arm64v2" :)
  • saagarjha 1y ago
    It’s basically just a recompile though.
    • WanderPanda 1y ago
      Until it isn't
    • RossBencina 1y ago
      Can you enable TSO for ARM executables?
      • saagarjha 1y ago
        Yes but I don't see how that is relevant
    • 0x0 1y ago
      I'm sure there's lots of x86_64 specific code in the macOS userland that is much more than just a recompile - things like safari/javascriptcore JIT, various quartz composer core animation graphics stack and video encoder decoder stack libraries, as well as various objective-c low level pointer tagging and message passing ABI shenanigans and so on. This is probably why 32bit intel mac app support was dropped pretty hard pretty fast, as the entire runtime and userland probably required a lot of upkeep. As just one example, 32bit intel objective-c had "fragile instance variables" which was a can of worms.
• ngcazz 1y ago
  Tangentially, this was surprising The system prevents you from mixing arm64 code and x86_64 code in the same process. Rosetta translation applies to an entire process, including all code modules that the process loads dynamically. I've been using this VST from Arturia (Minimoog V) since they distributed it for free back in like 2011 or 2012, and it runs as well on my M1 Mac as it did on my previous Intel Macs. I mean, it's literally the same DMG from way back when and there's no chance it doesn't run under Rosetta, but I run Ableton natively!
  • spacechild1 1y ago
    Seems like you're trying to load an Intel-only plugin binary in a native ARM application. This doesn't work. DAW and plugins must use the same archicture. You would either have to run Ableton in Rosetta or use a plugin bridge. (This is similar to Windows if you want to run 32-bit plugins in a 64-bit DAW.)
    • lukeh 1y ago
      AU plugins work, the AU framework itself spins up a separate process to host the translated Intel plugin.
      • spacechild1 1y ago
        Yes, that's how you do it. I have written a VST plugin host for Pure Data and SuperCollider and it supports sandboxing/bridging. It's not rocket science. I'm not sure why Ableton never bothered to implement this.
      • ngcazz 1y ago
        That's actually what's going on, it turned out -- I'm using the AU version of the plugin, Activity Monitor lists an Intel process when I add it to a track. Not sure this will be of any help to my projects once Rosetta 2 gets sunsetted...
• darkamaul 1y ago
  I’ve always been amazed by Rosetta, such an incredible piece of engineering. But I wonder if we’ll ever see its source code opened up. It feels like keeping it alive could really help long-term x64 support on Apple Silicon, even if Apple decides to move on.
  • smat 1y ago
    Check out Asahi Linux, they run on Apple Silicon and have translation for 32 and 64 bit x86, so they even go further than what Rosetta achieved. Open Source as well.
  • ferguess_k 1y ago
    I'd also love to see the source code of the embedded M68K emulator for PPC Macs. I believe there are two versions -- one interpreter style and one dynarec style.
• stuaxo 1y ago
  Bring back Rosetta 1. User mode emulation for PPC and Intel Mac apps.
  • dangus 11mo ago
    https://sheepshaver.cebix.net/ https://sheepshaver.cebix.net/
• aranw 1y ago
  For a few years now it's been feeling like Apple are pushing devs away and are more interested in catering for general consumers. Just look at what DHH has written and said about it, and his move to Omarchy
• tonyedgecombe 1y ago
  Hopefully this will finally push Sonos to produce an Apple Silicon binary.
• matjazk 1y ago
  Running Windows in Parallels. Even when running Windows ARM version, you still need Rosetta to run Windows x86 binaries.
• Rochus 1y ago
  This is very frustrating. As if they couldn't afford to continue it. And at the same time they keep making the system more and more closed, so that you can't even run applications without Apple's permission. I don't understand why people still buy such products.
  • matthewmacleod 1y ago
    And at the same time they keep making the system more and more closed, so that you can't even run applications without Apple's permission. This is simply not true.
    • Rochus 1y ago
      > This is simply not true. Ok, then try to run a pre-compiled macOS M1 compatible application on your new Sequoia system, such as https://github.com/rochus-keller/oberonsystem3/ https://github.com/rochus-keller/oberonsystem3/ or https://github.com/rochus-keller/leancreator/ https://github.com/rochus-keller/leancreator/. Requires quite some tricks so that at least some applications run without Apple's benedictions, but the tricks don't work for all such applications; and as it looks, they will also remove the last remaining work-arounds in future.
      • Klonoar 1y ago
        Uhhh, “don’t work for all applications” needs more context here. What the hell are you talking about?
        • Rochus 1y ago
          Very simple. Some of the applications work with the "console/allow all" trick (which is a tedious procedure, but hey, I'm just a dumb customer), others still don't work but crash and give strange errors that some stuff could not be accessed. But none works immediately. On systems older than Sequoia, everything works as expected (I just have to start them via the context Open menu, which is ok).
• rowanG077 1y ago
  It will be interesting to see whether they keep optional TSO in their SoCs after Rosetta 2 is no longer working.
• kburman 1y ago
  Phasing out Rosetta 2 seems like a reasonable move. Maintaining backward compatibility indefinitely adds complexity and technical debt. Apple has supported Intel-based systems for a long time, and this step aligns with their goal of keeping macOS streamlined for Apple Silicon.
  • AshamedCaptain 1y ago
    Backwards compatibility may be many things, but it is never technical debt.
  • jajuuka 11mo ago
    I wouldn't call 6 years a long time for support. Imagine if Microsoft announced that any software older than 2020 will not longer work. Not be out of support or not get any more updates, just become not runnable. The problem I have with it is Apple unilaterally deciding that support ends. I don't see the harm in no longer supporting it but leaving it as an option for legacy support. No garentee that anything will work with it and no support for it. They've done this with their hardware before but here it's just a cudgel to force devs to update their apps.
• wosined 1y ago
  Just use linux. You learn it once and it works forever.
  • BirAdam 1y ago
    If only this were true. Stuff in Linux changes. Not quite as frequently, but it does change and in major ways that require significant amounts of relearning. Example 1: audio OSS -> Alsa -> Random Layers on top of Alsa -> Pulse -> Pipewire Example 2: init SysV -> OpenRC || runit || s6 || upstart -> systemd Examples 3: desktops KDE 1/2/3 -> KDE 4/Plasma GNOME 1 -> GNOME 2 -> GNOME3+ Example 4: networking ifconfig -> ip Example 5: Xfree86 -> Xorg -> Wayland Now, it's important to note that people were attempting to resolve issues. The transitions weren't always clean, but the results are usually great. For example, moving to pipewire is possible the greatest advancement of audio ever. Linux audio finally doesn't suck. Xfree86 to Xorg was likewise great. For the last few years of X11, I usually didn't have to modify the config. I kind of don't care about init systems most of the time. The only major complaint for systemd is that disk I/O on embedded systems is kind of an issue, but things like Alpine are better there and Alpine doesn't use systemd. With that said, I think the real issue is that people dislike advancements that break things. Early in Pulse's life, people absolutely hated it. Early in Wayland's life, people absolutely hated it, but it wasn't default so no one complained. With Windows and macOS, stuff changes seemingly constantly and randomly and breaks things, so people hate it. Saying, however, that Linux doesn't change seems a little daft to me. It changes faster than anything else on small levels, and different distributions have breaking changes at different rates.
    • wosined 1y ago
      You don't have to install gnome, kde, wayland or systemd. You are just talking about your preferences masked as something that “had to be done”. I only had to fiddle with audio on the raspberry pi when connecting bluetooth. Everything works out of the box nowadays. If wayland was a good protocol, the user would not have to know about it.
      • BirAdam 1y ago
• ioma8 1y ago
  Does this mean end to macOS wine gaming? From what I know you need to be using x86_64 build of wine on macos to run the x86 built windows games.
  • BirAdam 1y ago
    No, follow the link. The article states that a subset of Rosetta 2 will remain for things like games.
• nottorp 1y ago
  Ok, application developers will maybe update by then. But this is another way for Apple to say "do not trust us for your gaming needs no matter what PR says".
  • latexr 1y ago
    From the page, inside an large block marked “Important”: > Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.
    • nottorp 1y ago
      Shocking. Good idea but shocking coming from Apple.
• vbezhenar 1y ago
  May be M7 CPU will run qemu emulation of x86 fast enough for Rosetta to not be required.
• ksec 1y ago
  I guess this is another way of Apple saying x86 is dead. Would have loved if Intel and AMD joined force to open up x86. Instead they are following the same path as POWER, likely doing it when it is too little too late.
• pohl 1y ago
  That means Steam will release a native Apple Silicon client circa 2028. Exciting!
  • Sekhmet 1y ago
    Steam already has Apple Silicon build in Steam Beta channel.
    • davidkwast 1y ago
      So it was not released yet. What is keeping Valve from release it? Apple is "giving a hand" now.
• geoffpado 1y ago
  For those unfamiliar with Apple’s new version-numbering system, this is the version that will be released in 2027, presumably around September or October of that year.
• crims0n 1y ago
  As is tradition.
• t_sawyer 1y ago
  Well this kinda screws me over running docker on macos. Not all images I use have an arm version.
  • tobyjsullivan 1y ago
    How does this work currently? I was under the impression that Docker for Mac already ran containers in an x86 VM. Probably outdated info, but I’m curious when that changed.
    • cpuguy83 1y ago
      Docker on Mac runs containers in a VM, but the VM is native the cpu architecture and takes advantage of hardware virtualization. You can of course always use qemu inside that vm to run non-native code (eg x86 on Apple Silicon), however this is perceived as much slower than using Rosetta (instead of qemu).
  • hakube 1y ago
    Doesn't Orbstack or Colima solve this?
    • p0w3n3d 1y ago
      if you run x86 code without rosetta (probably using the qemu) it will work painfully slow
  • saagarjha 1y ago
    That won’t be going away, none of that requires any support from the host OS.
  • swiftcoder 1y ago
    This isn't about the virtualisation support - it's about all the Mac system frameworks being available in the rosetta environment
    • nicce 1y ago
• markus_zhang 1y ago
  Ah, I guess it was wise for the original developer of Rosetta 2 to quit earlier this year. One of the people that I look up to. https://news.ycombinator.com/item?id=42483895 https://news.ycombinator.com/item?id=42483895
  • cwzwarich 1y ago
    My reasons for leaving Apple had nothing to do with this decision. I was already no longer working on Rosetta 2 in a day-to-day capacity, although I would still frequently chat with the team and give input on future directions.
    • ta9000 1y ago
      Thank you for your work!
    • casualscience 1y ago
      Just went through that thread, I can't believe this wasn't a team of like 20 people. It's crazy to me that apple would put one guy on a project this important. At my company (another faang), I would have the ceo asking me for updates and roadmaps and everything. I know that stuff slows me down, but even without that, I don't think I could ever do something like this... I feel like I do when I watch guitar youtubers, just terrible I hope you were at least compensated like a team of 20 engineers :P
      • nxobject 1y ago
        History doesn't repeat, but it does rhyme: the initial (re)bootstrapping of OS X for Intel was done by one person, too. https://www.quora.com/Apple-company/How-does-Apple-keep-secrets-so-well/answer/Kim-Scheinberg?srid=i1 https://www.quora.com/Apple-company/How-does-Apple-keep-secr...
        • markus_zhang 1y ago
          This is amazing. I wonder what it took to port MacOS from PowerPC to Intel. Every assembly language part must be rewritten, that’s for sure. Anything else?
• deleted 1y ago
  [deleted]
• nasretdinov 1y ago
  This seems to basically only apply to full-fledged GUI apps and excludes e.g. games, so potentially stuff like Rosetta for CLI isn't going anywhere either
  • TheTon 1y ago
    But games are full fledged GUI apps. At a minimum they have a window. It’s really unclear what it means to support old games but not old apps in general. I would think the set of APIs used by the set of all existing Intel Mac games probably comes close to everything. Certainly nearly all of AppKit, OpenGL, and Metal 1 and 2, but also media stuff (audio, video), networking stuff, input stuff (IOHID etc). So then why say only games when the minimum to support the games probably covers a lot of non games too? I wonder if their plan is to artificially limit who can use the Intel slices of the system frameworks? Like hardcode a list of blessed and tested games? Or (horror) maybe their plan is to only support Rosetta for games that use Win32 — so they’re actually going to be closing the door on old native Mac games and only supporting Wine / Game Porting Toolkit?
    • dagmx 1y ago
      Games use a very small portion of the native frameworks. Most would be covered by Foundation, which they have to keep working for Swift anyway (Foundation is being rewritten in Swift) and just enough to present a window + handle inputs. D3DMetal and the other translation layers remove the need to keep Metal around. That’s a much smaller target of things to keep running on Intel than the whole shebang that they need to right now to support Rosetta.
      • TheTon 1y ago
        I don’t agree. My point is their collective footprint in terms of the macOS API surface (at least as of 2019 or so) is pretty big. I’m not just speculating here, I work in this area so I have a pretty good idea of what is used.
        • dagmx 1y ago
• deleted 1y ago
  [deleted]
• anthonyskipper 1y ago
  This is awful. I love playing games on my MBP and the latest crossover releases have been amazing in the ability to play almost all windows PC games at full speed. Losing rosetta means crossover is dead. You would hope that apple would open source it, but they are one of the worst companies in the world for open sourcing things. Shame on all their engineers.
  • mxey 1y ago
    Isn’t that part of Rosetta also used in their own Game Porting Toolkit?
  • Cloudef 1y ago
    mac for gaming is just not a good idea
    • fragmede 1y ago
      What are you talking about? There's Do I have enough RAM to run Slack, all my Chrome tabs, and a terminal program; there's what terminal program shall I run today: Ghost edition; there's Can I get Colima to run, now with docker DLC. There's Kubernetes on Mac: Kind edition; there's Let's with Tart!; Nix is for Ops: New and more obtuse config edition. With so many fun games to play, who's got time for anything else?
  • snvzz 1y ago
    Fortunately, whoever has money for a Mac can also afford hardware that will actually run games.
    • wooger 1y ago
      A Macbook (air) is no longer a crazy expensive unobtainable thing, just a perfectly reasonable mid-price choice for most people. Whereas a good graphics card alone is still insane money.
      • gbear605 1y ago
• shrinks99 1y ago
  RIP a ton of older audio plugins.
  • p0w3n3d 1y ago
    I've already lost my "studio" (a few appliances in the corner of my room) due to upgrade from windows 7 to 10. Now it will happen again after I migrated to mac. I guess the "studio" should be left alone when it comes to upgrades. I'm starting to believe, that a "studio" is a set of software AND hardware, so I guess I won't sell my mac to buy new, but rather maintain it with given software and hardware on it, just maybe unplug it from the internet. -- EDIT -- or just move back to windows, but I can't imagine it with the current state of AI bloat
    • wooger 1y ago
      It's just a choice between competent AI bloat (Microsoft) vs. laughable non-functional AI bloat (Apple).
  • braebo 1y ago
    I lost access to decades of my albums which can no longer open on my MacBooks. Some open partially running Ableton Live with Rosetta. My record label recently reached out asking for stems for an old song for a sync deal with Rocket League — after spending a week trying to revive the old sessions I concluded that it was impossible and they were forever lost thanks to apples complete abandonment of backwards compatibility. It’s heart breaking really.
    • Mashimo 1y ago
      Could you not open the project on a windows computer or older mac? I also think current Native Instruments luncher "Native Access" still requires rosetta for the installation :)))
      • braebo 1y ago
        I was foolish enough to use Audio Units instead of VSTs back then… and even my oldest mac isn’t old enough. I managed to make a portable installer with the right Mac version and tried containerizing it but gave up after a couple days.
• al_borland 1y ago
  Hopefully this means macOS 27 will be a Snow Leopard type release to focus on bug fixes, performance, and the overall experience, rather than focusing on new features.
  • egorfine 1y ago
    No. Only Steve Jobs could have pulled this. Modern day Apple cannot. A bugfix-only release is not going to sell anything.
  • lapcat 1y ago
    Why would it mean that? It's a myth that Snow Leopard was a bug fix release. Mac OS X 10.6.0 was much buggier than 10.5.8, indeed brought several new severe bugs. However, Mac OS X 10.6 received two years of minor bug fix updates afterward, which eventually made it the OS that people reminiscence about now. Apple's strict yearly schedule makes "another Snow Leopard" impossible. At this point, Apple has accumulated so much technical debt that they'd need much more than 2 years of minor bug fix updates. https://lapcatsoftware.com/articles/2023/11/5.html https://lapcatsoftware.com/articles/2023/11/5.html
    • dagmx 1y ago
      Not sure why you’re downvoted because you’re right. Snow leopard brought a huge amount of under the covers features. It was a massive release. The only reason it had that marketing was because they didn’t have a ton of user facing stuff to show
      • wtallis 1y ago
        That is more or less what users asking for another Snow Leopard want: a release that doesn't have gratuitous UI churn and superficial changes, doesn't break the end user's muscle memory, but instead focuses on deep-seated and long-standing issues under the hood. If the right thing for the OS in the long term is to replace an entire subsystem instead of applying more band-aid fixes, then take the time to do a proper job of it. lapcat loves his straw man about OS X 10.6.0 having plenty of bugs, but that misses the point of Snow Leopard. Of course a release that makes changes as fundamental as re-writing the Finder and QuickTime to use the NeXT-derived frameworks rather than the classic Mac OS APIs, and moving most of the built-in apps to 64-bit, is going to introduce or uncover plenty of new bugs. But it fixed a bunch of stubborn bugs and architectural limitations, and the new bugs mostly got ironed out in a reasonable time frame. (Snow Leopard was probably one of the better examples of Apple practicing what they preach: cleaning out legacy code and modernizing the OS and bundled apps the way they usually want third-party developers to do to their own apps.) Fixing architectural bugs is still fixing bugs—just at a deeper level than a rapid release schedule driven by marketable end-user features easily allows for.
• luizfelberti 1y ago
  They barely just released Containerization Framework[0] and the new container[1] tool, and they are already scheduling a kneecapping of this two years down the line. Realistically, people are still going to be deploying on x64 platforms for a long time, and given that Apple's whole shtick was to serve "professionals", it's really a shame that they're dropping the ball on developers like this. Their new containerization stuff was the best workflow improvement for me in quite a while. [0] https://github.com/apple/containerization https://github.com/apple/containerization [1] https://github.com/apple/container https://github.com/apple/container
  • pjmlp 1y ago
    Apple has always been like this, there are other options when backwards compatibility is relevant feature.
    • jack_tripper 1y ago
      That's why like 80%+(?) of corporate world runs Windows client side for their laptops/workstations. They don't want to have to rewrite their shit whenever the OS vendor pushes an update. Granted, that's less of an issue now with most new SW being written in JS to run in any browser but old institutions like banks, insurances, industrial, automation, retail chains, etc still run some ancient Java/C#/C++ programs they don't want to, or can't update for reasons but it keeps the lights on. Which is why I find it adorable when people in this bubble think all those industries will suddenly switch to Macs.
      • AdamN 1y ago
        they use Windows because it's ostensibly cheap and there's momentum. I don't think any modern tech company is majority Windows.
        • pjmlp 1y ago
          It surely is outside US, and countries with similar income level. https://www.accio.com/business/operating-system-market-share-trend https://www.accio.com/business/operating-system-market-share...
• deleted 1y ago
  [deleted]