It is a tremendous amount of work, far more than most people would imagine, just to keep up (i.e. zero features, just keeping the code base in sync with the platform). I ported the entire code base from System-6-style to Mac OS 8, complete with fancy Appearance support and a lot of different callback mechanisms and other OS features of the day. I ported networking code away from deprecated layers. I ported from 68K to PowerPC, to Intel 32-bit, and now 64-bit is required. I ported file management code multiple times to entirely different APIs. I added tons of Objective-C. I migrated compilers from MPW, to CodeWarrior, to GCC, to LLVM. I replaced, painstakingly, thousands of lines of Carbon-style code with entirely different Cocoa idioms. I redesigned interfaces that were once described by Rez input files, to use Interface Builder (multiple times, as IB kept changing). I added code-signing. I split a single-application architecture into sub-processes with OS services. And these are just things I can pick off the top of my head; I am sure there are many more. Again, this is just to keep the damn code working as a nice modern app, before you even add work to make it do whatever it’s supposed to do.
Also, in every single case, it is noteworthy that the OS features I worked so hard to adopt were eventually thrown out by Apple anyway. This means I fully expect 10 years from now that even today’s code isn’t going to “last”. Some of the changes were particularly insulting, I would add, since Apple at the time made bold statements about those APIs being “the future”, and such; for instance, after completely redesigning an application to use the Mac HIToolbox “properly” in every possible way, it really hurt when Apple just decided they didn’t give a damn about Carbon to the point where it wouldn’t even compile anymore a few releases back.
I am fine with this because this is the kind of thing I like to work on. I do wish though that more people would realize how much effort software maintenance really is. Unfortunately, a heck of a lot is hidden behind simple-looking UIs and most programs will be a lot more effort to build than they appear to be.
Apple is the world's most valuable company, and an independent Mac division would still likely rank in the fortune 500. They are much too eager to effectively offload maintenance burdens to much smaller, individual developers.
I'm not even an app developer—just a power user who wants his wonderful mac apps to keep working! Apple seems to think they're protecting users by forcing developers to update their apps, but they're also pushing developers to non-native technologies like Electron, and I'm quite worried about what their iOS portability initiative is going to do to the landscape.
(I will note that legacy compatibility with precompiled binaries seems to be significantly better than with code; I use some apps that haven't been updated in more than a decade.)
When I was deep into Windows development, I remember how crazy it was that MS refused to deprecate APIs.
Just the concept of a “string” when programming on Windows could be different depending on the API Microsoft had:
- standard C strings: a null terminated character array
- the standard 16 bit wide character string that was null terminated.
- a BSTR - a double byte character array where the first byte is the length.
- the C++ STL string class.
- a CString - not to be confused with the C style string. This was part of the Active Template Library
- CStringT - it’s been awhile. I have forgotten what this is.
Keeping APIs forever leads to bloat, is a maintenance nightmare, and increases the surface area for security vulnerabilities.
One of the earliest security vulnerabilities that I remember was that it was easy to run shell commands on a remote computer just by escaping the command in IE if the site was running IIS because MS overlooked a type of string encoding.
My personal favorite is the PCZZWSTR type, which I've only ever seen used by SHFILEOPSTRUCT. Basically it's a null-terminated collection of null-terminated strings. And of course, there's a corresponding PCZZSTR for narrow-char paths.
VC++ is... interesting.
This would basically be a modification of the "least permissions" principle—only expose old APIs to programs old enough to need them.
iOS on the other hand is ubiquitous enough and there is no one killer app that people can’t live without, Apple can deprecate and then abandon APIs and pull developers forward.
Even if the old APIs requires the user to manually right click the executable, go into properties, and enable compatibility mode? It's not hard for the user to do, but I wouldn't want it to be my users's first experience with something I made.
Just a nit; Microsoft is currently $30 billion over Apple in market cap.
It goes back and forth here of course.
On one hand, I understand the commenters frustration over constantly changing API's. I understand that it is difficult and not fun and a lot of work.
On the other hand, as a user, I appreciate the fact that Apple forces people to update their code. I don't know how true it is, but there are roomers that Microsoft didn't release Windows 9 in fear of code that checked to see if the Windows version started with "9". Look at Windows first party apps, you have things like control panel and settings, two apps that have no excuse for being duplicates besides the fact that Microsoft refuses to stop supporting legacy code.
In my opinion, software is something to be maintained. Maintenance is ugly and isn't glamorous (won't see BBEdit on product hunt anytime soon), but is necessary. I think the user and developer experience would be worth is software written 25 years ago ran perfectly on my computer, I don't want that.
When developers update their apps, that's great! But for every developer Apple "forces" to make updates, there's a developer who decides to just target Electron instead, or an old app that simply breaks.
Also, re Adobe: idiots at the genius bar basically said it's fine and good that using Photoshop cores a brand new mbp on the latest os, and that's not apple's problem because Adobe hasn't certified the new os. We're getting close to buying this employee a windos laptop that is both cheaper and actually runs Photoshop
It is built on Qt, of course.
I wouldn't use a native macOS/OSX/nextStep api for anything more than the tiniest bit of integration; using Apple's native API's is crazy, for an application developer. Because of the crazy churn, because of the infinitesimal market share, because of the generally awful documention.
Most of the changes were bug fixes because we didn't read the C standard when we started.
The largest addition was code that serialize all the data structures so that the flat files could be moved between little endian and big endian machines.
It's still in production.
The truth is probably somewhere in the middle, supporting things longer than Apple, and shorter than Microsoft.
“This is a field where one does not write a principia, which holds up for two hundred years. This is not a field where one paints a painting that will be looked at for centuries, or builds a church that will be admired and looked at in astonishment for centuries. No. This is a field where one does one’s work and in ten years it’s obsolete, and really will not be usable within ten or twenty years.”
When it comes to hardware (which is probably what Steve was most concerned about), there's still plenty of electronics that can stand the test of time. I'd say the IBM Model M will be admired and looked at in astonishment for centuries - no modern keyboard has managed to make it obsolete it in the last 35 years.
If there's Amigas running infrastructure and DOS boxes still working in the wild, I'd wager there's still some shop somewhere using an Apple II as part of its inventory system.
But you can’t run 68K Mac software or PPC software on a modern Mac. Should Apple still include 68K and PPC emulators in MacOS.
The curve has flattened out, and the number of architectures has shrunk. I'm typing this on a 10-year-old computer, and it's running modern software just fine.
We're not building systems like we used to. We're taking maintainability into account. Performance is good enough that applications rarely publish hardware requirements. Continuing to assume that everyone is going to throw out their computer (and its entire architecture) in 5 years, so we might as well make developers rewrite everything, is just going to lead to a lot of frustrated developers. A little more care inside Apple could save a ton of time outside of it.
Apple is great at long-term thinking in some respects, and terrible in others.
I occasionally see comments here complaining about the ephemerality of the work we do... but I see no other alternative outside of a few domains. I fully accept that the code I will write next week when I get back from vacation won't exist in less than five years.
I just realized that the text editor I wrote together with friends in University (still usable and open source) Tincta turns 10 this year. Maybe it's time for some serious update with support for the new programming languages that came out, as well as some UI overhaul. With Tincta we also went through some porting pain, like changes to NSTextStorage, which broke with 10.6 for us and the bug report was answered with "wait for 10.7..." and before that the swift introduction and deprecation of GC.
While I still enjoy writing software for macOS, actually more than for iOS, it's hard for Indie developers. I also wish that people would realize how much work it is to create and maintain software over years and why $1.99 is not enough for every app.
If anyone thinks this is just me being facetious, they need to read Raymond Chen’s blog with entries about all of the hacks they had to do to keep badly written programs from breaking.
Let Microsoft worry about how to keep Windows running and I'll worry about keeping my own applications running.
There is a reason that all of the energy and money when it comes to applications has moved to mobile and the web.
Any platform creator has three priorities.
1. The company
2. The Users
Developers will go where ever the users are. You don’t have to make life comfortable for developers. Windows Mobile was a joy to develop for compared to any other platform, but it didn’t matter.