5 ms·

This article seems to laying a lot of blame/duty on Apple for reasons I don't think are very valid. The author even recognizes the fact in the piece. If there

This article seems to laying a lot of blame/duty on Apple for reasons I don't think are very valid. The author even recognizes the fact in the piece. If there is anyone to lay a duty toward, I would argue it's the developers (Big developers, like Adobe) who could contribute directly in providing code/documentation for their legacy formats.

Wowfunhappy 6y ago
I think that Apple: • Never should have removed Rosetta 1. • Should not have dropped support for Carbon and 32bit apps. • Should not remove Rosetta 2 in a few years, as many believe they will. I acknowledge that it's easy for me to sit here in my chair and say that someone else should be doing extra work—but we're talking about one of the most profitable companies in the world! Apple could hire engineers to maintain this stuff, if they wanted to spend the money. It would not somehow make the rest of macOS worse—no one is required to use old APIs. If you compared the amount of effort it would take Apple to maintain these systems, with the combined effort of every single developer migrating their software, I'm pretty confident the former route would be a lot less work. The alternative is that developers migrate to systems like Electron instead of trying to keep up with macOS's changing base, and that's not good for users.
- alwillis 6y ago
  I acknowledge that it's easy for me to sit here in my chair and say that someone else should be doing extra work—but we're talking about one of the most profitable companies in the world! Apple could hire engineers to maintain this stuff, if they wanted to spend the money. It would not somehow make the rest of macOS worse—no one is required to use old APIs. It's not about not forcing developers to use old APIs; there are lots of developers who wouldn't upgrade their existing apps because they still ran. It's just human nature to not want to update your apps if they're working fine under Rosetta or using Carbon and 32-bit APIs. Among the many other issues this would cause, people would expect 32-bit Carbon apps to run on an M1 Mac; trying to do so would make Rosetta much more complicated. The other thing is by pushing the leading edge, it gives upstarts a way to enter the market against incumbents. It's doubtful Affinity, which makes fabulous design apps [1] would been able to gain a foothold at all if old versions of Photoshop, Illustrator and PageMaker/InDesign just ran forever because Apple kept backwards compatibility with old APIs and frameworks. And unlike Adobe, Affinity takes full advantage of Apple's latest APIs and frameworks in a way Adobe never has, to make them competitive. It also discourages developers from using newer, better APIs to move things forward. Apple developed some amazing technologies in the 80's/90's they discontinued when MacOS X became a thing, like QuickDraw GX, HyperCard, OpenDoc, OpenTransport, etc. I've experienced every Mac transition starting from the classic Mac days (16-bit 68000) to today, with 64-bit Intel and ARM processors. There's not anything off the top of my head I'd want to use today from back then. I also started the first Newton users group in the world at least a year before the Newton MessagePad shipped in 1993. I know people who are still pissed that Steve Jobs canceled the Newton when he became iCEO in 1997. There does come a time when you have to move on. [1]: https://affinity.serif.com/en-us/ https://affinity.serif.com/en-us/
  - Wowfunhappy 6y ago
    > It's not about not forcing developers to use old APIs; there are lots of developers who wouldn't upgrade their existing apps because they still ran. It's just human nature to not want to update your apps if they're working fine under Rosetta or using Carbon and 32-bit APIs. And for every developer who took the time to update their apps to modern libraries (and would not have done if not forced), how many just moved to a non-native framework like Electron instead? I don't think this work the way Apple thinks it does.
    - chipotle_coyote 6y ago
      > And for every developer who took the time to update their apps to modern libraries (and would not have done if not forced), how many just moved to a non-native framework like Electron instead? Like the poster you're replying to, I've been through all of Apple's transitions from the 68K days to now. And in this context? I can't honestly think of any apps like that. The Electron-based apps I know of started as Electron-based apps. Adobe and Microsoft have their own proprietary cross-platform toolkits, but they're still ultimately building actual Windows or macOS apps; the Affinity apps are likewise native to their operating systems; many of the productivity programs I'm often in (Ulysses, Acorn, Drafts, Scrivener, BBEdit, Nova, MindNode, Safari) are actual genuine Mac apps. I think the things here are that (a) it may be easier to port an "old" native Mac app to "new" native Mac frameworks than to completely rewrite the app; (b) Electron is relatively new compared even to the "new" Mac frameworks (Cocoa is nearly two decades old, older if you count NextStep!); (c) while Electron might be high-performance enough now to write a full-blown desktop publishing program in like the one the article poster (who is my former college roommate, it turns out, hi Franklin), it definitely didn't start out that way; (d) a lot of folks are still not super thrilled with most Electron apps compared to native ones anyway. Yes, Visual Studio Code rocks, but it's kind of the exception to the rule. Personally, I also think Apple being more ruthless than Microsoft in deprecating old APIs is probably a good thing for the Mac platform in the long run. one of the programs I used to use more often, Dramatica Story Expert, has been tenaciously clinging to the trailing edge of technology for years: like me, it started on the Mac in the 68K days, and it has stubbornly missed every single transition, its developers doing the absolute bare minimum after the fact to get it quasi-working. This is an app which, in 2020, is not only still 32-bit, but does not run at retina resolution because they have been hacking their old codebase rather than moving to "new" -- i.e., from this century -- APIs for shit as basic as text rendering. Its text boxes don't respond to OS X key shortcuts, it doesn't support services, its fuzzy UI is in Lucida Grande. I look at its sorry ass and shudder to think what the state of Mac software would be like if Apple had gone out of their way to make it easy for developers to behave that way.
- kevindong 6y ago
  > but we're talking about one of the most profitable companies in the world! Apple could hire engineers to maintain this stuff, if they wanted to spend the money. It would not somehow make the rest of macOS worse—no one is required to use old APIs. I think it's a mistake to assert that a company should always indefinitely support their software. There's certainly an upside in maintaining backwards compatibility, but there's also certainly a distinct other upside in breaking it (e.g. authentication services dropping support for HTTP and requiring HTTPS). To restate that in a more generic way: given multiple existing constraints and you want to add on even more constraints, there's no guarantee that you can always satisfy all constraints under all circumstances (e.g. if you have to support multiple API versions, you can't necessarily always support every single one since sometimes the changes are fundamentally backwards incompatible).
- abecedarius 6y ago
  I realize this ship has long since sailed, but when OS X dropped Classic, it weirded me out that they could keep the name "Mac" for this completely incompatible computer, and that seemingly nobody blinked.

Wowfunhappy 6y ago

I think that Apple: • Never should have removed Rosetta 1. • Should not have dropped support for Carbon and 32bit apps. • Should not remove Rosetta 2 in a few years, as many believe they will. I acknowledge that it's easy for me to sit here in my chair and say that someone else should be doing extra work—but we're talking about one of the most profitable companies in the world! Apple could hire engineers to maintain this stuff, if they wanted to spend the money. It would not somehow make the rest of macOS worse—no one is required to use old APIs. If you compared the amount of effort it would take Apple to maintain these systems, with the combined effort of every single developer migrating their software, I'm pretty confident the former route would be a lot less work. The alternative is that developers migrate to systems like Electron instead of trying to keep up with macOS's changing base, and that's not good for users.

alwillis 6y ago
I acknowledge that it's easy for me to sit here in my chair and say that someone else should be doing extra work—but we're talking about one of the most profitable companies in the world! Apple could hire engineers to maintain this stuff, if they wanted to spend the money. It would not somehow make the rest of macOS worse—no one is required to use old APIs. It's not about not forcing developers to use old APIs; there are lots of developers who wouldn't upgrade their existing apps because they still ran. It's just human nature to not want to update your apps if they're working fine under Rosetta or using Carbon and 32-bit APIs. Among the many other issues this would cause, people would expect 32-bit Carbon apps to run on an M1 Mac; trying to do so would make Rosetta much more complicated. The other thing is by pushing the leading edge, it gives upstarts a way to enter the market against incumbents. It's doubtful Affinity, which makes fabulous design apps [1] would been able to gain a foothold at all if old versions of Photoshop, Illustrator and PageMaker/InDesign just ran forever because Apple kept backwards compatibility with old APIs and frameworks. And unlike Adobe, Affinity takes full advantage of Apple's latest APIs and frameworks in a way Adobe never has, to make them competitive. It also discourages developers from using newer, better APIs to move things forward. Apple developed some amazing technologies in the 80's/90's they discontinued when MacOS X became a thing, like QuickDraw GX, HyperCard, OpenDoc, OpenTransport, etc. I've experienced every Mac transition starting from the classic Mac days (16-bit 68000) to today, with 64-bit Intel and ARM processors. There's not anything off the top of my head I'd want to use today from back then. I also started the first Newton users group in the world at least a year before the Newton MessagePad shipped in 1993. I know people who are still pissed that Steve Jobs canceled the Newton when he became iCEO in 1997. There does come a time when you have to move on. [1]: https://affinity.serif.com/en-us/ https://affinity.serif.com/en-us/
- Wowfunhappy 6y ago
  > It's not about not forcing developers to use old APIs; there are lots of developers who wouldn't upgrade their existing apps because they still ran. It's just human nature to not want to update your apps if they're working fine under Rosetta or using Carbon and 32-bit APIs. And for every developer who took the time to update their apps to modern libraries (and would not have done if not forced), how many just moved to a non-native framework like Electron instead? I don't think this work the way Apple thinks it does.
  - chipotle_coyote 6y ago
    > And for every developer who took the time to update their apps to modern libraries (and would not have done if not forced), how many just moved to a non-native framework like Electron instead? Like the poster you're replying to, I've been through all of Apple's transitions from the 68K days to now. And in this context? I can't honestly think of any apps like that. The Electron-based apps I know of started as Electron-based apps. Adobe and Microsoft have their own proprietary cross-platform toolkits, but they're still ultimately building actual Windows or macOS apps; the Affinity apps are likewise native to their operating systems; many of the productivity programs I'm often in (Ulysses, Acorn, Drafts, Scrivener, BBEdit, Nova, MindNode, Safari) are actual genuine Mac apps. I think the things here are that (a) it may be easier to port an "old" native Mac app to "new" native Mac frameworks than to completely rewrite the app; (b) Electron is relatively new compared even to the "new" Mac frameworks (Cocoa is nearly two decades old, older if you count NextStep!); (c) while Electron might be high-performance enough now to write a full-blown desktop publishing program in like the one the article poster (who is my former college roommate, it turns out, hi Franklin), it definitely didn't start out that way; (d) a lot of folks are still not super thrilled with most Electron apps compared to native ones anyway. Yes, Visual Studio Code rocks, but it's kind of the exception to the rule. Personally, I also think Apple being more ruthless than Microsoft in deprecating old APIs is probably a good thing for the Mac platform in the long run. one of the programs I used to use more often, Dramatica Story Expert, has been tenaciously clinging to the trailing edge of technology for years: like me, it started on the Mac in the 68K days, and it has stubbornly missed every single transition, its developers doing the absolute bare minimum after the fact to get it quasi-working. This is an app which, in 2020, is not only still 32-bit, but does not run at retina resolution because they have been hacking their old codebase rather than moving to "new" -- i.e., from this century -- APIs for shit as basic as text rendering. Its text boxes don't respond to OS X key shortcuts, it doesn't support services, its fuzzy UI is in Lucida Grande. I look at its sorry ass and shudder to think what the state of Mac software would be like if Apple had gone out of their way to make it easy for developers to behave that way.
kevindong 6y ago
> but we're talking about one of the most profitable companies in the world! Apple could hire engineers to maintain this stuff, if they wanted to spend the money. It would not somehow make the rest of macOS worse—no one is required to use old APIs. I think it's a mistake to assert that a company should always indefinitely support their software. There's certainly an upside in maintaining backwards compatibility, but there's also certainly a distinct other upside in breaking it (e.g. authentication services dropping support for HTTP and requiring HTTPS). To restate that in a more generic way: given multiple existing constraints and you want to add on even more constraints, there's no guarantee that you can always satisfy all constraints under all circumstances (e.g. if you have to support multiple API versions, you can't necessarily always support every single one since sometimes the changes are fundamentally backwards incompatible).
abecedarius 6y ago
I realize this ship has long since sailed, but when OS X dropped Classic, it weirded me out that they could keep the name "Mac" for this completely incompatible computer, and that seemingly nobody blinked.