This is conceptually no different than calling something in the sun.* packages in Java. For years it was ok, and then ... it wasn't.
This, however, is draconian:
> Continuing to use or conceal non-public APIs in future submissions of this app may result in the termination of your Apple Developer account, as well as removal of all associated apps from the App Store.
"Keep trying to submit, and we might just ban you forever" is insane. Every program of any complexity depends on third party libraries, and many people wouldn't be able to tell what arcane APIs their dependencies (or their dependencies' dependencies) call. "If you continue to have an upstream dependency that violates our terms, we might permaban you" is bullshit.
It's also completely unsurprising. Apple has no love nor concern for their developers anymore. It used to be the premier development platform in the world. Now it's ... I don't even know anymore.
It's shameful but eh, it's a living.
In general, I find the opinions on these things to be pretty consistent: the “free market” types tend to support Apple/MS - usually with some form of “its their platform” as an argument - and the FOSS types holding the opposite position.
I’m not sure why the process was so complicated either. A couple of steps involved Apple calling me, and my superior, to verify that we were real. Except they didn’t actually verify that, because it was a simple conversation and I could have just lied with a buddy of mine... Even adding developers from our suppliers was a tedious process, and of course Apple has no way of integrating with our IDM or local security setups.
They sure are lucky to have a monopoly on iOS devices.
That seems reasonable to me -- they're just saying that if you want to be listed as the publisher, you need to be the publisher...
The result is 98 muniplacities having to pay Apple developer fees, but it gets better because the app can’t be called the same thing anymore. So now there are 98 apps instead of one. :p
I mean, I guess our central digitisation agency should really just pick it up, but the bureaucracy doesn’t work like that.
It's not really fair to expect Apple to resolve or work around your own organizational problems.
Apples inability to work with us is the primary reason we replaced thousands of iPads for school children with Chrome books. Eventually Apple caved to our needs, but it was way too late. Google were “what can we do to make this deal work for both of us?” from day one.
What I'm saying is that it's unfair to expect it. As in, if a company is not willing to bend over backwards for you, it's not fair to condemn them for that. It's totally fair to praise their competitors who will, though.
This is missing the point of the post you are replying to. Say you identify five closed API dependencies and remove them. Do you resubmit? If you missed any others, you and all your apps might be banned.
Maybe not -- maybe you know something about how Apple operates. But clearly they ARE sending responses threatening to do exactly that.
Anecdotally, I have never heard of this happening in non-malicious cases, ever. And I know a couple hundred Mac and iOS developers who would raise a lot of noise if this did happen, so I'm inclined to believe that it doesn't.
There is a good reason for how Apple approaches use of their private APIs, and for how Microsoft approaches use of their private APIs. Not saying either one is correct, there really is no answer, but consider that for any public API that exists, there may be undocumented details that some software somewhere relies upon whether they realise it or not. Apple is just taking a more aggressive approach than Microsoft here by detecting and disallowing private API use in their store so as to avoid issues down the line.
They don't, though. And we trust them not to, because it is not reasonable behaviour and it would absolutely not make sense for them to do this.
This is the same.
If you're sending me code to run on my computer—especially if I'm paying for it—you either need to have glanced at the code yourself or have some reason to trust what's in there (it's from a company you have a business relationship with, it's a major library from a known author that other apps on the store are also using, etc.). Otherwise you're being irresponsible. If you don't have the time to look at the library, don't use it.
You can fully expect that less then 1% of the apps in any app store has a transitive dependency chain that is fully known and understood by the author to any meaningful extent.
Most of that code is however understood by someone, although not necessarily the app developer. The sandboxing and app permission dialogue boxes are unfortunately a critical part of the defense against malicious code, although not a perfect one by any stretch of the imagination.
So, can you expand on why you think one should never run Linux?
* (any source available OS)
The point is, at some point you stop digging
That is a highly inaccurate paraphrase of what I said. You can tell it's inaccurate because I'm specifically suggesting that end users should be able to trust apps on the App Store without auditing the apps ourselves, as long as we trust the app authors, and that app authors should bear responsibility for what they redistribute.
Excuse me, are you, the developer, telling me, a user, that you don't know what you're giving me to run on my computer?
I just looked at the node_modules folder for a project that runs user configured code when your imap server gets a new mail via imap idle. It's called imapnotify and inside its node_modules dir I see it pulls in 549 js files.
The majority are under 100 lines per file dozens are between 1 and 30.
Cutting just the last segment so that /foo/bar/baz.js and /bam/baz.js both appear as baz.js and removing dupes reduced the number of unique filenames to 383.
Basically every js dev is either telling you or not telling you that they don't know what they are giving you to run on your computer.
That sort of thing is a big red flag that perhaps you should reconsider using that package.
But even if you do use it, that in no way reduces the fact that it's your responsibility to know what you're shipping.
If you can't find an acceptable package, then I'd absolutely recommend writing that functionality yourself. connecting to an IMAP server and responding to events aren't complicated tasks, after all.
If devs can't do things like be able to tell what dependencies a module/library has, then they shouldn't use that module/library.
* you can't be sure code in package is same you see on github as npm doesn't do signatures
* code already in node_modules is usually minified and obfuscated
So only real way to be sure is to make own repository, copy every dependency, check code, build own packages and only use packages from your repo. Repeat process when versions are updated.
So to answer your question, yes, 99% of apps, they don't know.
Unless you are willing to freeze whole tree until review is done but then you don't get bug fixes and security updates for period of initial review + review of updated packages.
This will be borderline impossible for a nodejs developer, but a perfectly realistic expectation for e.g. a Django project.
On the developer side there's more though, you should know what their release cycles are like, how they manage compatibility, how long they support older releases etc. You don't what your app stuck in a 3 month upgrade cycle just because a transitive dependency needed an update.
There's a reason dependencies are there own form of technical debt and need to be minimized.
Having knowledge of every dependency explicitly linked into your application is a basic tenet of software development that literally every software professional would endorse as a necessary best practice, but it's not what we're talking about here. I am 100% certain that every developer with a commercial Electron app is aware that they are relying on Electron as a dependency and Github as a trustworthy software vendor.
I think you're conflating platforms and dependencies. The OS it runs on is a platform that the the user already trusts, left-pad is a dependency the developers are responsible for. There's some grey area like electron or the JVM but even there electron sticks out as a huge binary blob the user isn't explicitly asked to install.
You know all of the transitive dependencies in the application stack of your company? Out of curiosity, what is the ballpark figure on the total number of transitive dependencies in your application?
I'm a few years out of the Java world these days, but you've vetted every line in every one of those Apache commons projects that gets pulled in? Because that's a lot of reading...
Over 10 years ago I went through every single Java RSS parsing library and all their forks (I think there were 5) to fix Xml eXternal Entity (XXE) attacks (eg) and submitted fixes for them all.
That was a huge amount of work, because they all used random version of different XML parsers, all of which required external entity processing to be turned off in different ways.
None of the authors of the packages were aware of the issue, and as far I could determine at the time I was the only person in the entire Java ecosystem who knew all the different parsers arguments.
This was a critical, remotely exploitable vulnerability. I'd never claim to know about it now, and it was only for a few weeks back in 2006 that I really knew it then.
So when you say you "know" all the dependencies in your stack, what do you mean exactly?
So, the process would be something like: have a problem that a library might solve, find a library that could solve the problem, verify it can solve the problem, look through the implementation, look through it's dependencies, then actually include it in the build. If anything doesn't look nice at each step, rollback and find something else or start writing your own implementation.
Do this from beginning of the project and you'll always have a full understanding of the system.
Everywhere I’ve ever worked, adopting a dependent library was a HUGE DEAL. You don’t do it lightly. You have to know what’s in it, know what it calls, know what the license is, understand the increased security attack surface, measure how much bigger it makes your binary, measure any performance deltas, and so on. In bigger companies, you need to get all sorts of approvals... Who the heck are these companies where you just hook up the git submodule and wing it?
Since most applications nowadays are server side, you would usually already pull 1 GB+ of Docker layers, before you even add application + libraries.
Facebook on iOS seems to be around 400 MB of size (first result from quick googling, might be wrong), and average Electron app is 120 MB+, so I don't think the size is a huge concern.
I will never in a million year ship anything on, for instance, node.js, for exactly this reason.
As a developer, I'm honestly and utterly stunned to see other developers arguing otherwise.
I don’t develop for iOS so I’m genuinely curious. Do they provide automated tools for developers to use? Or a flag that fails your build if you’re trying to call private APIs: For that matter, how are the reviewers catching these API usages?
I find it strange that a private API can be used accidentally, without something notifying the developer before they’ve gotten to the stage of submitting their app.
It's difficult to use private API accidentally. However, it is possible to use a dependency that purposefully uses private API, which is what happened here.
> Do they provide automated tools for developers to use?
> Or a flag that fails your build if you’re trying to call private APIs
Kinda, but that doesn't help you if your dependency is trying really hard to use that API and has been precompiled.
> For that matter, how are the reviewers catching these API usages?
They're running somewhat stupid static analysis and possibly some dynamic analysis? They don't tell you what they do but they're not very good at it and don't generally catch even basic obfuscation. However, if a human finds your private API usage and you look like you're trying to obfuscate it, they won't be nearly as lenient.
You may not have time to do your job properly?
If you're using libraries in your project, it's normal and expected that you know what those libraries are doing and what those libraries depend on. You should know this stuff regardless of what Apple (or anyone else) may require.
Are you sure that your machine code gets run properly? Do you test the CPU hardware and all the logical gates and whatnot so that they respond to the schemes and it passes the electric current properly?
Like xkcd 378, we could follow this logic quite deep. At some point you just have to trust, or at least assume that something is going to work, without properly verifying it yourself.
Smarter people than me have essentially dedicated their life to some extremely specific area of computing. It's not reasonable to assume that I could and should deep-dive into every possible nook and cranny just in order to build an application. I already have to do a whole lot of assumptions because of my hardware used for development, my OS and software tools like my IDE, task runners and yes, external libraries.
I don't think anyone is suggesting that you should.
If it's in my product, I'm responsible for it, so it needs to be possible for me to audit it, even if I may not be looking too closely.
It's not like this app developer is intentionally using private APIs. "Resubmitting the same thing and hoping that it doesn't get caught" seems to be a strawman.
Between that and the folks who hid MAME in an app or whatever, I think Apple is not simply constructing straw men when they warn that attempts to circumvent the spirit of their request - and the letter of it - will result in a lifetime ban.
What changed was just the interpretation of the app store rules - the rules said something like "you're not allowed to use hardware buttons in a non-standard way". Once they added the volume shutter feature to the system camera, now it's not a non-standard way and it's not against the rules.
And until it does, developers should not use Electron.
There's a number of reasons why I refuse to use Electon-based apps, and this is one of them.
The only answer is that as a developer, you are responsible. Yes, we have to make calculated risks. But the buck stops at you. There is nobody else who can take responsibility for the contents of your app.
If you pull in some bad modules, directly or transitively, and as a result your app steals my data or worse, that’s on you for shipping malicious code to my computer. There is no one else who can be responsible for that. Not Apple. Not the user. You.
If this was "don't conceal or we'll ban you for life", it would be somewhat understandable.
But it's "use or we'll ban you for life" which is just insane. Apple is at the height of their arrogance towards developers.
If you use a private API they will reject the app. If you try and hide the fact you are using private APIs after has told you to stop then they will ban you.
It's all very common sense and not arrogant at all.
Yep. I've migrated away from macOS after using it for a decade over to Linux, and the developer experience is first class.
They are allowed to ban you for literally any reason. What matters is what they do, not the exact phrasing in a random email.
And in practice, they will ban you if you actively try to skirt their rules after they tell you to cut it out.
It's the same reason people hold companies like Apple and Nike accountable for working conditions in their factories even if they hired a third party to run them. Third parties are not the ones putting their brand on the product.
I was under the impression that if you're being annoying and keep trying to submit a build with private API, making App Store Review's life hard, they're going to ban you. In general, you should be reviewing your dependencies yourself to make sure it's doing things that you approve of; if you can't do that after Apple has warned you that it's doing something that's not allowed I don't really have much sympathy for you.
There is also no apparent way to scan your own app to make sure that you are not in violation of this issue. So you're in a position where the only way to see if you are in compliance is to submit to Apple, but that may result in your account being banned.
While review is automated, I would like to believe that account deletion isn't.
> There is also no apparent way to scan your own app to make sure that you are not in violation of this issue. So you're in a position where the only way to see if you are in compliance is to submit to Apple, but that may result in your account being banned.
They literally tell you the symbols that you're not supposed to use: it's easy to check if your dependencies are using them.
I would like to believe that, too, but I don't.
> They literally tell you the symbols that you're not supposed to use: it's easy to check if your dependencies are using them.
Sure, if you have a better-than-average understanding of C (or Objective C), and know how to use the command line to grep strings out of a binary, and know all of the binaries you need to be searching.
This is a rejection for an Electron app, and I'm going to go out on a limb and say that the majority of Electron developers do not have the requisite skills. Hell, I've been programming for a couple of decades now, and I couldn't 100% guarantee that an app I wrote didn't call one of the forbidden APIs, even indirectly.
The rejection email doesn't bother to say where in the code the problem is, so it's apparently not so easy as to be part of an automated process. "Learn what these esoteric commands do, use them correctly on every upstream dependency your app has, make sure you don't call any of these symbols, and if you fuck up you're banned for life" is utter dogshit customer service.
I'll believe it up until the point that "Apple automatically deleted my account because of repeated app submissions" makes the front page of Hacker News. Until then, I have no reason to doubt it as I have never heard of this happening except in clearly malicious cases.
> The rejection email doesn't bother to say where in the code the problem is
I'd argue that any answer to this question would require the skills that you say Electron developers lack. I don't know what your solution to this is, because getting your app past review by claiming ignorance into what your dependencies is doing ("oh no, I totally didn't know this framework was literally malware, can you please let me be on the App Store anyways?") isn't going to work either.
Because Apple knows it doesn't need to attract developers to iOS. They will come no matter what because that's where the mobile market is.
On macOS it's different. There are very few macOS exclusive developers so most of the popular apps are either cross platform (Office, Photoshop, Sublime Text, Chrome, Firefox, Maya, Cubase, Cinema4D, Resolve, etc) or are from Apple. In both cases the Apple dev experience is irrelevant. There are plenty of boutique devs making small products exclusively for macOS (eg: Panic, Bjango, Bohemian) but these are a drop in the ocean. Apple knows this which is why it's making Catalyst to attract iOS devs to macOS. AFAIK the only big developer making macOS exclusive products is Apple itself.
Wait a second. When was this exactly? Are you talking about the Apple II era?
When has Apple ever been developer friendly?
Their ecosystem always had more money for app developers, but I can't think of any point in time when developers weren't shouting to anyone who will listen about Apple's rules.
Yeah. So? By linking a framework that's using private APIs, this becomes your problem now. And Electron's problem, by extension. Go bug them, not Apple.
I remember how Microsoft was vilified for supposedly having secret Windows APIs that allowed Microsoft apps to get better performance.
That was mostly made up and even if such APIs existed, any program could have used it.
Even at the height of corporate arrogance Microsoft didn't dream of banning developers for using undocumented APIs.
Apple seems intent on becoming more evil than Microsoft ever was.
At some point the goodwill they built as underdog making great products will run out and some government somewhere will take an anti-trust action.
I'm just hoping it'll happen sooner rather than later.
The prehistory is that developers for the Apple ][ had access to third party documentation, and made extensive use of unofficial system variables and entry points. The result was that it became impossible for Apple to update their own system without breaking popular apps and getting blamed for doing so. It turned Apple ][ technology into a dead end.
The Mac was intended to be a much more tightly controlled developer environment. And it came out at a time when there was still a lot of debate over the right way to develop a computing platform.
IBM had a different approach, which was to make things more open like the Apple ][, and they paid the price for it. For instance, a lot of the weird limitations of the IBM PC were caused by developers bit-banging hardware registers and video memory rather than going through "official" BIOS calls that were less efficient.
I don't personally know the right answer, but this is just the history as I recall it. At the time I preferred the IBM approach, because I could do some friendly bit banging and get stuff done, but my programs were mostly for a severely limited audience and lifespan. Today I try to do things in a way that insulates me from knowing anything about the platform that I'm using.
This is very much not true. The entire extension mechanism on Macs was about using undocumented hacks to add functionality. Apple has no control over what a third party app could do through the Classic MacOS era from 1984-1999.
In fact, it wasn’t until around 2011-2012 when Apple started having sandboxing and that was only for Mac App Store apps. It was even later that they had system integrity protection. Even today, you can basically do what you want to on the Mac except for having unsigned kernel extensions.
"C is just PEEK and POKE with syntactic sugar." -- Bill Joy
and there is no update.
I worked on an app that competed with a Microsoft app. Our app was actually winning in the marketplace. One year they release a new version of their app with some really cool features at the same time as the latest Windows release. Those features were based on some new APIs released with that version of Windows. Just gave their app a year leap.
Another evil practice was forcing PC makers to pay for a Windows license for each computer sold irrespective of whether the computer shipped with Windows.
Microsoft was pretty evil.
The CA prefixed ones are core animation related. Some of the others appear to be drawing frame related. I am not sure what the remote one does. None of these are giving Apple a direct advantage. I bet Electron tried to access to them to draw web pages smoothly.
The Windows API availability window gave Windows apps market advantages.
There are other private Apple APIs that do give Apple an advantage against app developers. Those advantages are in accessing physical hardware and possibly associated software, background processing, and integration (iCloud, etc...) But these aren't the bone of contention.
>I bet Electron tried to access to them to draw web pages smoothly.
How is this not a direct advantage? If these uncommented API calls provide a better performing solution than anything a third party can make then that is a direct advantage. Apps with that call could have a longer battery life or just run smoother.
When you consider that Windows has to keep backwards compatibility with applications from decades ago using whatever calls to Win32, to the point of keeping comments in the source code about why some call is done that way and shouldn't be changed then it's pretty fair that a company providing a platform wants to keep a tidy, secure (or at least following their guidelines for security/privacy concerns) public API.
The Java community had a huge debacle about `sun.misc.Unsafe`, it was a private API being abused by numerous libraries and when its removal was announced there was a quite big backlash about its repercussions.
I don't think that Apple is evil because of its enforcement on private APIs, there might be other issues with this enforcement but there are very valid reasons to do it.
Apple, or Microsoft for that matter, would do the same thing here, because the locked down platform is more valuable/profitable then an open platform.
Developed for Android - at least you can have your app sideloaded if the platform owner decided to remote you.
Or better, make your app a progressive web app. Don't use hardware api not available to the browser and you cannot be removed!
Sure they could have, they had a code signing platform since the mid 90s and could have locked API access only to apps signed by them.
They didn't because it would have been pointless not because they couldn't figure out how.
It's actually also not true that Microsoft only ever blocked things based on signing cert from the Windows Store/UWP platform. Windows Defender Smart Screen blocked/blocks apps from running without user intervention unless it was either extremely well known or was signed (and even then if it was new you might still get caught by it).
This is how iOS works, FYI.
In a completely fair world a substantial number of executives would probably be in jail.
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.
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:
It's not a new attitude either. Apple has always been like this:
> 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.
Apple is proving you wrong.
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.
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.
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.
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)
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?
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
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.
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.
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...
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.
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;
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.
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.
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:
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.
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.
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.
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.
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.
The fact is that all of MS’s Office competitors early on wrote horrible GUI apps whether it be fir Windows or the Mac.
I don't know what Apple means by "secret APIs", but I'm assuming they mean "undocumented APIs". Those are certainly real things that commonly exist.
> By definition an Application Programmers Interface is the vendors promise to other developers that when you call it
Yes, but those "other developers" may be other engineers in the same company. The APIs they use are still APIs, but are not intended for use by anyone outside the company.
Say Team A within Apple creates a module that is only to be used by Team B and C. Then Teams D creates a module that depends on Team A and B and they release a public API.
Team A should publish an internal documentation and Teams B and C should also not use methods that were not documented by Team A and Team A shouldn’t follow standard semantic versioning. If Teams B and C need some functionality they should inform Team A.
The same goes for Teams B and C. Also, Apple controls the release schedule for any internal teams. If they want to move to ARM tomorrow they can coordinate it within Apple without breaking any third party apps. The only team that has any responsibility to not break external developers is Team D.
If Apple starts allowing external developers to use private functions now their release schedule is tied to when enough major third party developers update their documentation.
Amazon is even a better example. They have a policy that everything should be a service internally and no team should reach “inside” of the implementation of another team.
What happens when Apple updates the operating system and starts throwing up a big dialog box every time an app accessed a private API that says “the publisher of this app needs to update their poorly written app.”?
What next? Is the EU going to also ban language makers from having public and private functions?
Apple is within their rights here, but please, let's not pretend this is about user experience.
It's about the Apple machine doing what it wants, and rolling over who it wants, because it can.
That would explain why Apple developer relations (read: humans) had previously backpedalled after the same rejection in the past:
Most likely these rejections were not intentionally resumed, but because the machine that is app stores these days is completely non-deterministic, this could still be a big problem.
This time the wrong developer could reach out to the wrong channel and trip some sort of trap that turns this into a "known issue: won't fix + always send automated reply", instead of someone with the right connections getting to the right person and having them go and flip a switch that fixes everything with their pinky finger.
The problem isn't the usage of an internal API, the problem is the breaking of an internal API.
Which is already covered by App Store testing and guidelines which already require your app isn't a broken mess.
By Apple, or the Electron developers?
Apple's policy towards private APIs has been known for years.
Which is not a homogenous group, both in ideals and for why they'd upvote a submission like this.
> this rejection, and it's backing policy to be nonsensical
They're different things. I personally think the rejection is perfectly sensical in the context of the backing policy, with which I don't fully agree.
When you are writing any software that has a public API you should feel no obligation to change the functionality or completely remove a private method without warning.
 I refuse to call it a private API. An API is public documentation of the inputs and expected behavior of a dependency. It should be a completely black box how that functionality is implemented.
This is not Apple "watching out" for the developers, no matter how much you spin it
Apple will only listen if it hits their bottom line.
If you can't avoid Apple's stores then make damn sure you fall in line as they effectively own you.
I mean, did Electron or Google just refuse to fix this? Are these private APIs things that actually get exercised in the apps being threatened?
It's not so much about culpability or Apple's right to control their app deployment environment, it's that the response seems really disproportionate to the offense and pretty badly misdirected.
A more conspiratorially minded poster might wonder if the real goal here was to dissuade developers from using cross-platform frameworks...
Thank you Apple for keeping things clean!!
This is about submitting an app to the Mac App Store. Apple has had a requirement that apps not use private APIs for a while.
It sounds like Chromium, and hence Electron have had references to some private APIs for a while, but Apple has only recently started enforcing their requirement. (Or perhaps only recently started scanning for these particular APIs.)
It’s a little painful for the developers for this to suddenly pop up like this, but it’s better than all Electron apps suddenly crashing one day, which would have happened sooner or later when one of these APIs changed or was dropped.
The solution is a Chromium fix to avoid using these APIs, and an associated Electron release to incorporate the new version of Chromium.
I wonder if it has been that way in Chromium since Blink was WebKit and maintained largely by Apple with priority on performance on Apple platforms.
So, feel free to use Electron, just understand that your so easy to develop desktop app now hinges on the ability of a few unpaid developers (that's probably not you, or the "full-stack" people at Slack) to continuously keep track with the Chromium source and maintain their no doubt massive patches to its code to remove use of these private APIs.
Indeed, and the article's title is confusingly wrong, as "Apple Store" refers to Apple's retail and online store that sells hardware.