Item — HN Reader

Apple wants to own the user's machine. They want to make it so their computers run only the software they approve. This is already true for iOS and it's only a matter of time before it also becomes true for macOS. It's the opposite of a free system.

Giving up software freedom for "ease of use" seemed like a fine deal at first but then Apple started making decisions that don't quite align with what neither users not developers want. Apple has already started taking advantage of their position as the gatekeeper of the platform.

3 comments

As a user of macOS, I want developers who makes apps to use public APIs that will be supported so I don't get breakages on system upgrades or migrations.

It doesn't really matter if it's public or not. The fact is people are using those APIs and there's nothing that can be done about that. Nonchalantly breaking stuff and rejecting applications actively subtracts from the value of their platforms and could alienate developers.

Microsoft had private APIs and data structures too and it didn't stop developers from using them. However, their approach to that was different: they maintained bug compatibility with old software in order to keep stuff working. This is one of the main reasons why Windows remained relevant for so long.

The fact is Apple simply doesn't care about backwards compatibility. It's not just private APIs, public ones are also at risk:

https://lists.apple.com/archives/cocoa-dev/2019/Oct/msg00004...

It's not a new attitude either. Apple has always been like this:

https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

> A lot of developers and engineers don’t agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded.

> The developers of the Macintosh OS at Apple have always been in this camp. It’s why so few applications from the early days of the Macintosh still work.

> For example, a lot of developers used to try to make their Macintosh applications run faster by copying pointers out of the jump table and calling them directly instead of using the interrupt feature of the processor like they were supposed to.

> Even though somewhere in Inside Macintosh, Apple’s official Bible of Macintosh programming, there was a tech note saying “you can’t do this,” they did it, and it worked, and their programs ran faster... until the next version of the OS came out and they didn’t run at all.

> The fact is people are using those APIs and there's nothing that can be done about that.

Apple is proving you wrong.

As a user of macOS, why don't you put the onus on Apple to not artificially limit what developers can offer you without it breaking on upgrades and migrations?

Some of the private APIs being used have been stable for generations and are clear improvements in one way or another over the publicly available APIs (like CAContext stuff). I mean a modern OS is not like a library you stick up on NPM and hope no one tries to use internal methods that you'll end up having to support. There are so many desperate teams working on OSX and the applications from Apple that use these APIs, it's not like backwards compatibility, documentation, and most of the issues public APIs face aren't already an issue that has to be tackled.

Apple uses these APIs to make features no one can fairly compete with, which is detrimental to you, as a user, and to external developers. Imagine if any app could use APIs like the ones that Apple Music uses to have tight integration with Siri, or that Apple Maps uses to show on your lockscreen.

> There are so many desperate teams working on OSX and the applications from Apple that use these APIs, it's not like backwards compatibility, documentation, and most of the issues public APIs face aren't already an issue that has to be tackled.

When push comes to shove, Apple can tell those teams to rewrite their code. It can't do that to the authors of, say, Firefox.

What are you talking about?

They literally do it regularly, public APIs get deprecated then removed and consumers have to rewrite their code.

This article is literally about Apple making 3rd parties rewrite their code just to access the app store.

And before you or someone else points out "Firefox is directly distributed", I say: Exactly. So they can use the internal APIs as they please, then Apple can remove then as they please and break Firrfox and... make Firefox rewrite their code.

Apple is not Microsoft. Apple does not work towards not breaking existing software, they actively break it with each macOS and iOS release, sometimes not even releasing the tools needed to fix them before general releases

Making an internal API people are already using public literally does nothing but optionally allow Apple to give a heads up about deprecation. Apple could literally slap "public" on every internal API, break them every release, and the result would be no different than the current status quo because of the overarching rule of App Store admissions... your app has to work, regardless of if an "internal" or "public" API is changed.

Honestly for most developers that wouldn't seem to different from the current situation: see iOS 13 where basic UILabel stuff was breaking.

And again, apps that don't use the App Store already use internal APIs and can already break all the time.

Apple rarely removes public APIs without any deprecation warning that appears when you compile your app at least one version ahead of time.

Apple often straight up breaks the implementations of public APIs leaving developers scrambling to fix them. See modals in iOS 13, or title bar styling.

I work at a development agency and on both macOS and iOS every release is a race to figure out which breaking changes have been sprung by Apple (including crashes caused by silent changes in behavior of existing APIs, people have had apps rejected for breaking on pre-general release OS versions when we didn't even have the tools to test them yet)

There is a difference between breaking a public API which is a defect and that’s done unintentionally - that happens with every operating system and framework - and depending on private methods to behave appropriately.

Decades ago, when Apple introduced 68040 Macs, a lot of programs broke because they were writing self modifying code and that didn’t work with the 68040 cache. Whose fault was that Apple’s or the developers?

Just like `sun.misc.Unsafe` was around for ages until it wasn't. [0]

[0] https://blog.dripstat.com/removal-of-sun-misc-unsafe-a-disas...

I fail to see how this is anything but the perfect case for allowing internal API usage.

There was no other way to do what Unsafe did, so people used it for years.

A lot of people used it to do useful things in Java. So much stuff that this article is saying it literally became indispensable for much of what Java is used for. The ecosystem was better for it.

Sun says we want to remove it.

So Sun can provide alternatives that do the same job, or find that it generates so much value that it shouldn't be removed, or remove it and leave people literally exactly where they'd be if it never existed if there's no other way to do what it does. People would gnash their teeth, but the message sent is "Java was never the right tool for the job so we don't want you as a user."

And the article rightly points out, Sun was removing it for the sake of removing it. Having a bad engineering structure where that handwavy rant about Unsafe can justify removing a useful feature has nothing to do with internal vs public APIs.

The usage of Unsafe was never encouraged, it is a problem that Sun never provided a public API with similar features but relying on a private API is what caused the issue of breaking changes in the future, something that every Java developer was well aware that could happen.

Yes, I agree that the problem was that Sun didn't provide a public API for it, at the same time developers breaking the contract (instead of pushing for it to be moved to a `java.` namespace) shouldn't be excused and embraced, it causes bigger issues to the overall design of the platform when then you have to be maintaining an API for the sake of usage, the same cruft that Win32 suffers for its whole existence, and which made developing on Win32 a pain in the ass for a lot of people, for the sake of not breaking some twisted way that a major application used it.

> so I don't get breakages on system upgrades or migrations

This is hilarious, Apple breaks apps that only use public APIs on virtually every release they do, minor releases, security patches, you name it. Apple CONSTANTLY BREAKS THINGS.

There's no need to shout; breakage in public APIs is nothing compared to private API churn. Plus you can file bugs about the former.

It's very weird for me to see people acting like Apple is "becoming" anything. They've been pretty consistent about their spot on the user freedom/paternalism spectrum, for at least a decade. This is in line with the choices they've been making since at least the launch of the iPod. Ease of use has never been exclusive of user freedom, and Apple's desire to control users has never been about the user: any half-decent interface is capable of hiding power behind an easy to use facade.

Two stereotypes, each about a decade old. The rumors about the impending doom of freedom on MacOS is as old as Mac OS X. At this point, it's the slowest conspiracy in history.

People don't prefer MacOS because they are idiots who need "ease of use". There just is no other system developed with something approaching taste. Windows is for those people that put plastic covers over their furniture, ruining in the process of trying to protect it. Linux is for servers.

Apple is the company that already has a completely locked down mobile OS and is actively nurturing an app store for the macOS. I wouldn't bet on it running unsigned code forever.

Apple has explicitly stated in WWDC sessions that there will always be a way to run unsigned code if you want.