[BoorishBears]

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.

[scarface74]

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

[BoorishBears]

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)

[scarface74]

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?

[BoorishBears]

It is not a defect. It is literally intentionally broken! Do you actually know this space?

The modal example, it's to support new design language Apple is pushing, straight up breaks modals designed a certain (valid) way.

Catalina removed XML exports used by music apps. There was no deprecation warning.

Apple's recommended fix? Don't update if you need one of those apps.

These are not defects, they are literally breaking changes intentionally made with no warning.

I don't understand why all of you seem to be operating underthe assumption apps using "public APIs" just work with each OS update. It just doesn't work like that. They break and crash not due to defects but due to intentional changes

[scarface74]

It was part of the first beta release that the new iTunes wouldn't support XML exports. So there was warning that it wouldn't work. Public API's doesn't mean "something will never change". It should mean that API's won't change between minor version numbers. The entire purpose of semantic versioning is that there might be major breaking changing when there is a major release.

Apple did in fact provide a method to share music between apps and some apps do take advantage of it. Do you really think that Apple didn't need to do a major overhaul of iTunes?

Of course it's Apple's advice and common sense not to upgrade your OS until the apps you use are updated to support it.

This is all modern software engineering 101.

As a developer there are a few expectations.

- depending on private method may break your code with any point release. The vendor has no obligation not to break code if you depended on a private API.

- If your code breaks calling a public method during a point release, it is a bug and the vendor has an obligation not to break public API's when releasing a point release.

- If the vendor makes a breaking change during a major release (x.0.0). It's the vendor's responsible to communicate the breaking change and give enough notice to developers/users about breaking changes so that either the developer can fix their code, the user can find a replacement app, and/or the user not upgrade.

[BoorishBears]

You spent so many words to latch onto a single part of my entire comment, construct a strawman around it, and burn it down.

But lo and behold something useful did come of it, I finally found the fundamental misunderstanding keeping you from understanding what the crux of the issue is.

> If your code breaks calling a public method during a point release, it is a bug and the vendor has an obligation not to break public API's when releasing a point release.

Not when the vendor is Apple.

This whole time you've been operating on the set of rules that apply when your vendor considers you a partner of sorts, maybe in the vaguest sense of the word, but a partner nonetheless.

iOS point releases break things literally all the time. Iirc we actually saw more fires on 13.1 than 13.0

This literally has nothing to do with semantic versioning or whatever else you want to confuse it with. It's a blatant disregard for developers that Apple has carried throughout it's operations, from APIs to app store rejections. If anything the only reason they get the slightest pass is they're not Google, who manages to make talking to a human, no matter how hard they stonewall you, a selling point in mobile developer relations now.