[scarface74]

No one is going to argue that this entire release cycle hasn’t been a clusterfuck and the rapid release cycle of iOS/MacOS/watchOS this year is evidence of that.

But your argument has nothing to do with this submission - using private APIs.

At least one of your two examples - getting rid of XML exports - wasn’t about Apple breaking a public API during a point release. How is it a straw man refuting one of your major points? It was about Apple changing an API during a major release and letting developers know. This is how a vendor should behave.

Now whether they gave developers enough of a warning is a completely separate argument.

BTW: While it is a major change and no longer automatic. There is a manual workaround...

https://djtechtools.com/2019/10/10/update-to-catalina-heres-...

[BoorishBears]

My point with that example was about how Apple doesn't treat developers as partners, something I said multiple times in my other comments is the crux of the issue, which this whole internal API in Electron rejection issue is simply a symptom of.

You ignored my perfectly good example of Apple breaking an API because you have nothing to say about it.

You ignored my comment you just replied to pointing out how irrelevant sem-ver is when your "vendor" doesn't care about you.

You are fixated on trying to nitpick the one tiny foothold you've found for your screed, one which only exists because you're ignoring the initial point I, not the article brought up, that this is an issue with Apple not caring about developers literally in the first comment you replied to.

Maybe spend more time reading and less time replying.

[scarface74]

You gave two examples - the one I know about “broke” with a major version release, was known during the beta period and is exactly how a platform vendor should behave. The only thing in question was the beta period long enough. The other you didn’t say whether it was a point release or an iOS 13 change.

The electron rejection is not a symptom of Apple breaking a public API. It’s just the opposite. An API change didn’t break Electron apps - it was rejected for using a private API.

It’s not “nitpicking” to point out that your examples are completely irrelevant to the submitted article - Apple rejected an app that used private APIs. None of your examples have anything to do with the submitted post.

Would you also complain if you wrote a C program that depended on documented “undefined behavior”...

  int b= a++ + ++a;

and it broke with the next version of the compiler or broke based on which optimizations were turned on? Yes I am sticking with examples of how irresponsible it is to depend on private APIs and undocumented behavior - something you advocated in other comments because that’s the entire point of the submitted article.

[BoorishBears]

Again you spend more time replying than reading.

I said this internal API rejection situation of Apple not treating developers like partners

Like it's literally right there in the comment you replied to clear as day and yet you manage to muck it up then spend several more paragraphs on a new screed nitpicking your wrongly quoted text.

I'm done replying to this.

[scarface74]

The internal API rejection is about not treating developers like “partners”. You aren’t their partner. Internal APIs are just that - for internal employees.

It’s dumb to use “internal”, private APIs. It always has been. It hurts your products stability, it hurts your customers, and it keeps the platform vendor from making rapid changes.

Microsoft never cared about you as a developer - they would just as easily run over you if it met their business objectives.

[BoorishBears]

Ugh, I promised myself I'd stop replying, but I'll ignore most of this comment and correct some obvious misinformation for the benefit of other people who actually read comments.

Microsoft has a history from the earliest days of existence of bending over for developers.

Going as far as to literally to add a special case to their memory allocator to support explicit undefined behavior (reading memory after free) for when a specific game, Sim City.

They avoided writing more than 80 characters on any given line in system.ini, because one specific program would fail to read those lines correctly, then delete the system.ini when attempting to write it back

Microsoft is literally still packaging 16-bit subsystems with Windows 10

Anyone actually interested in learning more about it should read Raymond Chen's blog and learn about the truly insane lengths Microsoft goes to make sure they don't break what developers have done, no matter how wrong it is:

https://devblogs.microsoft.com/oldnewthing/author/oldnewthin...

Honestly anyone who doesn't know the lengths Microsoft goes to treat developers as partners doesn't have the base knowledge for the conversation this thread has been about, but I digress.