Hacker News new | past | comments | ask | show | jobs | submit login

I’ve maintained my Mac project for 20 years for free (despite paying $99/year these days) and I can say quite a bit about the experience.

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 really needs to stop removing documented APIs. If they want to announce that some APIs have been moved to "maintenance mode", that's fine—just make some effort to ensure said APIs keep working.

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.)

Apple really needs to stop removing documented APIs. If they want to announce that some APIs have been moved to "maintenance mode", that's fine—just make some effort to ensure said APIs keep working.

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.


As a user, however, I think MS has it right.

The worst is COM's apartment threading model, which is still in your face to this day despite being pretty much nothing more than an extremely elaborate workaround for the fact that Visual Basic 6 didn't support threads. (VB6 was released in 1998; it became old enough to drink this year.)

I doubt that VB6 is actually the only justification for COM's apartment threading model. If that were the case, then I don't think WinRT would still have ASTA (application single-threaded apartments). I think the real rationale is that making sure certain code runs on the UI thread is something that applications have to do all the time, even today, even on non-Windows platforms.

If I'm not mistaken, CStringT is just the template class for CString, CStringW, and CStringA. Makes perfect sense :)

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.

Random thought, could the attack surface be reduced by limiting old APIs to programs running in compatibility mode?

This would basically be a modification of the "least permissions" principle—only expose old APIs to programs old enough to need them.

It’s almost impossible to get developers to move to newer APIs as long as you allow them to use old APIs. Fortunately (?) only two third party developers really matter on Macs - Adobe and Microsoft. The rest either have to come along for the ride or get left behind.

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.

> It’s almost impossible to get developers to move to newer APIs as long as you allow them to use old APIs.

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.

When the super-geniuses of Redmond devised WinRT which was supposed to be the savior of it all, they tried to fix this problem with a new string type, HSTRING. It had some additional quirks around NULL that the other types didn't have.

I'd like to think that there's a balance between Apple and Microsoft in this area.

> Apple is the world's most valuable company,

Just a nit; Microsoft is currently $30 billion over Apple in market cap.

It goes back and forth here of course.

I think this is a delicate balance as a user.

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.

Again, I'm actually a user, not a developer.

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.

Makechecks comment reads like an psa for just use electron. Which sucks cause electron is a pig but damn. Code shouldn't bitrot this fast.

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

I am the maintainer of an application that will be 20 years old this year. It has never been completely rewritten. There have been two involved ports to a newer version of the framework it uses. It is cross-platform, and runs on Linux, Windows and macOS.

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.

This is why I like about X11/Motif and mwm. We wrote an application in 1992 for HP/UX. Since then we ported to Red Hat Linux, GCC and 64 bit.

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.

Wow, that's impressive. I've always had a soft spot for X11. I still have fond memories for setting up a FluxBox ubuntu partition on an old socket 478 Celeron. With a now ancient 5900SE, that thing would really fly, and I bet it still would today despite being ancient. Compare that to the sad state of the comparatively bloated OSX/Windows/web with new frameworks every two years that are incompatible with each one just before it and it all makes you quite sad.

This is why I love being a Windows programmer. Microsoft really does take backward compatibility seriously, and the last breakage worth mentioning happened when Vista started to enforce roles and permissions.

This is why I personally don't love using Windows. The user is left with duplicate, inconsistent experiences like Control Panel and Settings, Edge and Internet Explorer, all because Microsoft is too afraid to cut off old APIs.

The truth is probably somewhere in the middle, supporting things longer than Apple, and shorter than Microsoft.

For contrast, this is why I still use Windows primarily at home.

I agree with you although at this point I wish MS would start over from zero with an entirely new OS and then just run all old stuff in some VM. There's too much cruft and they really need a reboot like Apple did with OS9 to OSX

I feel this would be the case having done a bit of MS work my self over the years. But at the same time, I'd say it's also the reason MS don't innovate as much as Apple do. Just a personal opinion.

Visual Studio for example has gotten so many neat debugging tools in the past few years, while xcode has gotten...dark mode.

MS doesn't build sexy products as Apple, but I don't think they're lagging behind in innovation.

As an iOS developer, I feel the same. To quote Steve Jobs:

“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.”

That seems by design more than anything. Outside of iOS, plenty of software doesn't become obsolete in ten or twenty years. Even on the Mac itself, you still have all the classic Unix utilities. Will grep ever become obsolete? People are still using vi/m after 42 years despite all manners of new text editors and IDEs popping up.

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.

Even on the Mac itself, you still have all the classic Unix utilities. Will grep ever become obsolete?

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.

From what I can tell (the video, ironically, was taken down) he said this in 1994, which was right at an inflection point. 10 years from there in either direction was a huge change. He'd just shipped the fastest 68k NeXT workstation they'd ever build. 10 years earlier was the original Macintosh, and 10 years later was the PowerMac G5. Obviously there's not going to be much compatibility across those systems.

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.

While grandparent's comment shows an extreme situation, I agree with the quote.

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.

Poor Steve, secretly wishes he could have had the constructive legacy of Stallman instead of his destructive consumerism.

Just wait until they deprecate Objective-C :(

I have the same experience, to keep up with OS updates alone is a ton of work.

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.

Can you share which app that is?

I wondered the same thing myself; looks like it's MacTerm:



Having worked on a product for Windows for 26 years. Fortunately Windows hasn't changed as much in that time frame as Mac.

Kinda makes me appreciate the lengths that Microsoft will go to to ensure existing applications work on new platforms :-)

And that’s not really a good thing. Windows is so full of hacks that it is bloated and impossible to maintain. Apple has been able to port the base of MacOS to phones, tablets, watches, tv devices, etc. MS can barely make Windows run well in a Docker container.


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.

The difference is: that's not my problem, and it shouldn't be!

Let Microsoft worry about how to keep Windows running and I'll worry about keeping my own applications running.

It is your problem - the inconsistent APIs, the slow as molasses updates for Windows, security vulnerabilities etc.

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





3. Developers.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact