5 ms·

> When they did the hardware transitions, they had a compatibility layer (Rosetta) that was supported for 5 years after the transition. But with the 32 bit chan

by lanna 6y ago

> When they did the hardware transitions, they had a compatibility layer (Rosetta) that was supported for 5 years after the transition. But with the 32 bit change, the announced that it would no longer be supported in 2017, and dropped support in 2019, just 2 years later. You are comparing the time a technology was supported with the time it was announced a technology would no longer be supported. 32-bit apps were supported in 64-bit Mac OS systems for at least 7 years.

jedberg 6y ago
From what I could find, the first announcement of dropping support for 32 bit apps was in 2017, and the support dropped in 2019. Why would an app maker update their old apps before an announcement was made that they would be deprecated?
- comex 6y ago
  > Why would an app maker update their old apps before an announcement was made that they would be deprecated? Almost immediately after 64-bit support was added in 2005, it was the recommended path, not only for new apps but for existing ones to migrate to. For example, an document called "64-bit Transition Guide for Cocoa" [1] was first published in 2007. A few years later, another document [2] was more explicit: > Should You Recompile Your Software as a 64-Bit Executable? > As a general rule, in OS X v10.7 and later, the answer is probably yes. OS X 10.7 was released in 2011. Certainly, many – most – app makers did update their old apps. For example, Apple's refusal to support Carbon on 64-bit famously forced Adobe to scramble to update their apps to run on Cocoa, because they considered 64-bit support to be essential. Admittedly, one of the chief benefits of 64-bit was the ability to address more than 4GB of memory, and pro apps needed that more than your average app. But your average app was also easier to recompile, so in practice, pro apps were if anything the slowest to migrate. Even then, most of them did, long before the official deprecation. By the time the deprecation was announced, let alone by the time Catalina was released, most apps that were still 32-bit were the ones that had ceased to receive updates altogether. From that perspective, the exact timing of the deprecation doesn't matter that much: most unmaintained apps aren't going to become maintained again because of an announcement by Apple. It was going to hurt no matter what. [1] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Cocoa64BitGuide/RevisionHistory.html#//apple_ref/doc/uid/TP40004247-CH2-SW1 https://developer.apple.com/library/archive/documentation/Co... [2] https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/64bitPorting/indications/indications.html#//apple_ref/doc/uid/TP40001064-CH206-TPXREF101 https://developer.apple.com/library/archive/documentation/Da...
  - Wowfunhappy 6y ago
    So then why were there so many 32 bit apps? 2005 is, what, a year after the Intel transition? Surely not all of those apps were written during that one year. Not to mention, for better or worse, games in particular were 32bit through 2018 at least. I imagine this must have had something to do with cross platform compatibility, although I can't imagine what.
    - comex 6y ago
      > Not to mention, for better or worse, games in particular were 32bit through 2018 at least. I imagine this must have had something to do with cross platform compatibility, although I can't imagine what. Well, here are the Steam Hardware Survey results from some random date in 2014: http://web.archive.org/web/20140318083854/https://store.steampowered.com/hwsurvey/?platform=pc http://web.archive.org/web/20140318083854/https://store.stea... If you click on "Windows Version", you can see that a substantial percentage (~20%) were running 32-bit versions of Windows, which can't run 64-bit applications. Most of those were likely on 64-bit processors, but had 32-bit Windows installed anyway for whatever reason; IIRC that might include driver support and not needing as much RAM. So game developers were forced to ship 32-bit binaries if they wanted to target those users. (They could ship both 32-bit and 64-bit versions, but that's relatively difficult on Windows; there's no equivalent of Mac "fat binaries". And there wasn't much point.) That's Windows, not macOS. But then as now, game developers targeting PC primarily cared about Windows, with macOS as an afterthought at best. If the Windows version was built as 32-bit, the macOS version likely would be too for simplicity's sake. There's also game consoles to consider. PlayStation and Xbox both switched to 64-bit in 2013, so most games released from then on would have to at least have 64-bit-clean codebases (even if they weren't tested specifically on 64-bit PCs). But earlier games might well not be 64-bit clean; the kind of low-level hacks that make porting to 64-bit difficult are probably more common in game codebases than your average app.
      - marcosdumay 6y ago
        While you are talking about games, it's relevant to remember that Unity had different licenses for their 32 and 64 bits engines just up to a few years ago. I think the free license was 32 bits only, what locked a lot of people in it.
scarface74 6y ago
32 bit Carbon was deprecated in 2012. Did it really take a rocket scientist to know that you shouldn’t be writing 32 bit software in 2017? 10 years after the last 32 bit Mac shipped?
- arvinsim 6y ago
  You keep on repeating that devs are stupid because they only coded their apps in 32-bit. Perhaps you need to be more charitable and try to find the reasons why devs and businesses chose to only support 32-bit.
  - scarface74 6y ago
    Well. Business that don’t keep up with technology get left behind. I have no sympathy for developers who sat on their hands for a decade.
  - tinus_hn 6y ago
    So enlighten us with those reasons why these devs and businesses chose to only support 32-bit. Other than they would find it cheaper to do nothing while Apple and the users pick up the tab, of course.

by lanna 6y ago

jedberg 6y ago

From what I could find, the first announcement of dropping support for 32 bit apps was in 2017, and the support dropped in 2019. Why would an app maker update their old apps before an announcement was made that they would be deprecated?

comex 6y ago
> Why would an app maker update their old apps before an announcement was made that they would be deprecated? Almost immediately after 64-bit support was added in 2005, it was the recommended path, not only for new apps but for existing ones to migrate to. For example, an document called "64-bit Transition Guide for Cocoa" [1] was first published in 2007. A few years later, another document [2] was more explicit: > Should You Recompile Your Software as a 64-Bit Executable? > As a general rule, in OS X v10.7 and later, the answer is probably yes. OS X 10.7 was released in 2011. Certainly, many – most – app makers did update their old apps. For example, Apple's refusal to support Carbon on 64-bit famously forced Adobe to scramble to update their apps to run on Cocoa, because they considered 64-bit support to be essential. Admittedly, one of the chief benefits of 64-bit was the ability to address more than 4GB of memory, and pro apps needed that more than your average app. But your average app was also easier to recompile, so in practice, pro apps were if anything the slowest to migrate. Even then, most of them did, long before the official deprecation. By the time the deprecation was announced, let alone by the time Catalina was released, most apps that were still 32-bit were the ones that had ceased to receive updates altogether. From that perspective, the exact timing of the deprecation doesn't matter that much: most unmaintained apps aren't going to become maintained again because of an announcement by Apple. It was going to hurt no matter what. [1] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Cocoa64BitGuide/RevisionHistory.html#//apple_ref/doc/uid/TP40004247-CH2-SW1 https://developer.apple.com/library/archive/documentation/Co... [2] https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/64bitPorting/indications/indications.html#//apple_ref/doc/uid/TP40001064-CH206-TPXREF101 https://developer.apple.com/library/archive/documentation/Da...
- Wowfunhappy 6y ago
  So then why were there so many 32 bit apps? 2005 is, what, a year after the Intel transition? Surely not all of those apps were written during that one year. Not to mention, for better or worse, games in particular were 32bit through 2018 at least. I imagine this must have had something to do with cross platform compatibility, although I can't imagine what.
  - comex 6y ago
    > Not to mention, for better or worse, games in particular were 32bit through 2018 at least. I imagine this must have had something to do with cross platform compatibility, although I can't imagine what. Well, here are the Steam Hardware Survey results from some random date in 2014: http://web.archive.org/web/20140318083854/https://store.steampowered.com/hwsurvey/?platform=pc http://web.archive.org/web/20140318083854/https://store.stea... If you click on "Windows Version", you can see that a substantial percentage (~20%) were running 32-bit versions of Windows, which can't run 64-bit applications. Most of those were likely on 64-bit processors, but had 32-bit Windows installed anyway for whatever reason; IIRC that might include driver support and not needing as much RAM. So game developers were forced to ship 32-bit binaries if they wanted to target those users. (They could ship both 32-bit and 64-bit versions, but that's relatively difficult on Windows; there's no equivalent of Mac "fat binaries". And there wasn't much point.) That's Windows, not macOS. But then as now, game developers targeting PC primarily cared about Windows, with macOS as an afterthought at best. If the Windows version was built as 32-bit, the macOS version likely would be too for simplicity's sake. There's also game consoles to consider. PlayStation and Xbox both switched to 64-bit in 2013, so most games released from then on would have to at least have 64-bit-clean codebases (even if they weren't tested specifically on 64-bit PCs). But earlier games might well not be 64-bit clean; the kind of low-level hacks that make porting to 64-bit difficult are probably more common in game codebases than your average app.
    - marcosdumay 6y ago
      While you are talking about games, it's relevant to remember that Unity had different licenses for their 32 and 64 bits engines just up to a few years ago. I think the free license was 32 bits only, what locked a lot of people in it.

scarface74 6y ago

32 bit Carbon was deprecated in 2012. Did it really take a rocket scientist to know that you shouldn’t be writing 32 bit software in 2017? 10 years after the last 32 bit Mac shipped?

arvinsim 6y ago
You keep on repeating that devs are stupid because they only coded their apps in 32-bit. Perhaps you need to be more charitable and try to find the reasons why devs and businesses chose to only support 32-bit.
- scarface74 6y ago
  Well. Business that don’t keep up with technology get left behind. I have no sympathy for developers who sat on their hands for a decade.
- tinus_hn 6y ago
  So enlighten us with those reasons why these devs and businesses chose to only support 32-bit. Other than they would find it cheaper to do nothing while Apple and the users pick up the tab, of course.