3 ms·

For carbonlib? No idea, now seems fine. For 32-bit cocoa apps? I see no obvious technical reason to drop support, unless I'm missing something.

• ratww 7y ago
  I think their rationale is that they don't want to maintain 32-bit and 64-bit code forever. But IMO, Apple should have removed Carbon last year (six years after deprecation). That would have made the removal of 32-bit Cocoa a bit less traumatic.
  • snuxoll 7y ago
    Even though Linux distributions have been slowly dropping support for running on 32-bit systems nobody is talking about dropping 32-bit multilib support. The cost is primarily disk space, and Apple could just make 32-bit libraries an optional download.
  • Aloha 7y ago
    Making CarbonLib an optional component several years ago would have made it clearer to users that "this is going away"
    • scarface74 7y ago
      “Users” don’t know what CarbonLib is. When Apple announced that they weren’t porting CarbonLib, developers knew.
      • Aloha 7y ago
        Users would have noticed when Application X stopped working unless they downloaded this thing that the download page for makes very clear will be unsupported in 2 years.
        • scarface74 7y ago
          Do you really think any app developer would ask the users to download a dll from the web to make their app work? They would jusr bundle it like installers bundle the Java runtime or Windows apps bundle the compatible version of msvcrt32.dll