OS Compatibility and the Web

OK, not EOL yet, but soon. Long before any rational person would switch to an untested, incompatible new OS version. Among other things, anyone using Adobe software can't go to Catalina.

The policy I like is to support the last two or three major OS releases. There are good techniques in Objective-C to support testing for new features and falling back if you don't have them; I don't think most of those work in Swift, because Swift's an amateur hour language.

Happily, I use Feedbin to sync my RSS feeds rather than keep them all local, so when NNW stops updating I can just go back to a working web interface. Sad that Brent keeps resurrecting and killing his app, but that's what he gets for chasing Apple's tail.

This is why the web beats native applications. You can indeed make a better interface in native code; you can't maintain it, and you can't port it. The native dev is constantly chasing a new API that breaks everything past, and fighting with garbage tools like Xcode. The web dev just needs ed or another text editor, and only has to target the browser, which is a moving target but has backfills and a compatibility policy, and native browsers generally work on the last two major OS releases. Firefox is a UI shitshow, but still supports OS X 10.9 Mavericks (2013); Safari obviously is part of the OS, and the last few changes are making me strongly consider moving off it, but this Mojave version will keep browsing the web just fine long after Catalina is released.

The ideal of cross-platform languages ever since UCSD Pascal is to get the best of both worlds, write code once and have it compile and run everywhere, and ignore underlying OS changes.

%d bloggers like this: