3 ms·

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 profita

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.
heavyset_go 6y ago
Ideally there would be incentives to upgrade because there are benefits to doing so, and not just because upgrading is convenient for Apple's bottom line.

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.

heavyset_go 6y ago

Ideally there would be incentives to upgrade because there are benefits to doing so, and not just because upgrading is convenient for Apple's bottom line.