The basic concept isn't too disturbing; Apple packages private APIs that have no guaranteed behavior or expectation of support. If you depend on those APIs, it's very possible that your app will break in a future OS update.
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.
Getting out of iOS development and back into web dev was the best career decision I ever made. I feel like I escaped an abusive relationship. So much of what's wrong with computing and tech right now stems directly or indirectly from the culture at Apple.
It's funny how the general consensus on here is against Microsoft's abuse of private APIs in Windows to help Word and DOS against WordPerfect and DrDOS, 20+ years ago. But Apple doing it right now in a much worse way is considered acceptable and defendable.
I don't think anyone here considers Apple's abuse of private APIs vs developers an ok thing. I will never subject myself to their app store if I can help it.
I think it's more a case of people just being unaware. They might have an idea that this is going on, but because they've never run into it it's not something that's a priority. I'd even wager that the vast majority of non-Americans here don't use Apple hardware.
This is a straw man argument. Who is making that point?
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 got the first warning sign that I was entering into an abusive relationship early on in 2007 when I tried to sign up for the Apple Developer Program from Europe, and Apple INSISTED that I FAX my developer program application in to them.
I work in public digitisation and while we don’t build the apps, we’re now required to publish them if we want our name as the publisher. So I’ve had the pleasure of setting up our development account and it’s easily the works service I’ve ever had to go through, and we operate 300 different IT systems, some are old terminal systems that run on mainframe.
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.
Sure, but that’s not actually what happened. I didn’t go into detail with that part, because it’s fine. We’re fine with someone else being the publisher and listed as such though, but you’re not allowed to do that on behalf of others anymore.
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.
Forgive me if I'm not understanding correctly, but in your description here it sounds like the problem is in how your organization functions around this, not in Apple's policies.
It's not really fair to expect Apple to resolve or work around your own organizational problems.
Why not? Microsoft does it all the time. So does Google, to an extend.
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.
I wouldn’t mind I had options, but I don’t. Instead we’re the ones to bend over backwards, as you put it, because Apple has a monopoly that we’re required to use.
What's bullshit about banning someone who has been notified that they are in violation of the rules and then tries to hide their use of private APIs rather than stop using them? That's exactly what I would do in Apple's position. Resubmitting the same thing and hoping that it doesn't get caught the next time isn't an honest mistake.
> then tries to hide their use of private APIs rather than stop using them [...] Resubmitting the same thing and hoping that it doesn't get caught the next time isn't an honest mistake.
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.
They do not ban you for removing some uses of private APIs, but missing others and resubmitting. In the last decade of this being the policy on the iOS app store they've been quite consistent about only banning people who very clearly are deliberately trying to sneak things in.
> maybe you know something about how Apple operates
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.
Because in the past, developers have obfuscated their use of private APIs rather than removing them. They are threatening to ban people who abuse the platform. They aren't going to ban anyone making an honest effort to eliminate their use of private APIs.
Yep - instead, Windows is dragged down by 20-40 years of bug-for-bug API compatibility, even in the things that were never documented as public API and pretty clearly look like internal solutions that the author at Microsoft never designed for public use.
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.
Dependencies of your dependencies! Imagine installing a library that depends on a couple dozen libraries in its own right. You may not have time to inspect every single node in the dependency graph.
As an end user, can I just say how uncomfortable I am at the idea that some app on the App Store includes some node.js dependency where the app developer has no idea what's in it? What if it's event-stream?
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.
I'm a developer, and knowing how this is the default is not something I particularly like, but it's really only in the most security/mission critical code that dependencies get thoroughly wetted.
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.
I get Linux from people I trust to verify source code and the source code of dependencies and to push back against dependency sprawl (Debian, in my case, and I'm on debian-devel and I happen to see every email sent for every new package; there's an overhead there). Others get Linux from a vendor they have a commercial relationship with (Red Hat, Canonical, even Oracle, etc.)
So, can you expand on why you think one should never run Linux?
GP says not to run anything you haven't looked at yourself for the most part, paraphrasing. I doubt anyone has self audited all the software and drivers going into a desktop Linux distro.
> GP says not to run anything you haven't looked at yourself for the most part, paraphrasing.
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.
> Dependencies of your dependencies! Imagine installing a library that depends on a couple dozen libraries in its own right. You may not have time to inspect every single node in the dependency graph.
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?
Hi my name is node_modules have you met me? If you invite me to a party I bring my 500 closest friends as my plus one!
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.
There are reasons forums known for being less diplomatic than HN often take delight in heaping scorn and ridicule on js devs. This is one of those reasons.
That is every javascript package ever incidentally. Do you have an alternative suggestion as far as connecting to an imap server and responding to events? Not a library to write such a thing but an actual implementation.
No, I don't, but even if there are no such alternate packages, that doesn't mean it's OK to use one that you can't sufficiently understand.
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.
You misunderstand what I'm saying. This isn't about disagreeing with how anything is written, this is about the responsibility of developers to know what they're shipping.
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.
With NPM as an example to fully know every dependency is a highly time-intensive and complicated task due to following:
* 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.
I think that ship sailed a long time ago. Right now I'm building an app with Google's mobile toolkit, Flutter. Flutter itself is a few hundred kloc. And on top of that, I'm using a bunch of libraries; I wouldn't be shocked if it were the same amount of code again. Assuming I can properly code review a few hundred lines per hour, reviewing all that will take me a year or so. Which is maybe 5x what it will take me to ship an MVP.
You are missing the fact that dependency tree is constantly changing as dependencies get bug fixes and security patches, so in the middle of your review you will be forced to re-check.
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.
Is that a joke? Surely you aren't suggesting that developers should have full knowledge of all transitive dependencies that compose their application stack.
> Is that a joke? Surely you aren't suggesting that developers should have full knowledge of all transitive dependencies that compose their application stack.
This will be borderline impossible for a nodejs developer, but a perfectly realistic expectation for e.g. a Django project.
Honestly, it boggles the mind to think that a responsible developer would just pull in some 3rd party dependency without auditing what it does/calls and what other sub-dependencies it has, and then ship it as their product that their business relies on.
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?
Can you even know every transitive dependency in an average Node.js project? I just looked at a simple web service we have, which doesn't use any framework or such, and it's 5 dependencies pull in 75 dependencies altogether.
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.
For licensing reasons alone, almost got hit by one dependency switching from LGPL 2 to GPL 3 and one project we bought dropped dead once someone went over its dependency tree and noticed the mess of highly incompatible licenses, it would have taken years to get to a point where we could legally publish anything. Not knowing about all of your dependencies is a liability.
Not full knowledge. But you should know about every single dependency, know what they do and if they're from a trustworthy source. Being able to say with confidence that you aren't installing malware on your customers machines is the least you can do.
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.
Knowing every transitive dependency in your application stack is totally unrealistic and is pretty much impossible for any modern commercial software outside of specialized/embedded systems.
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.
I never brought up operating systems in the context of this discussion on dependencies. Electron is not an operating system, so I am not sure what your point is.
Chromium and also Electron are trustable sources. Besides that any Mac OS X App from 10.15.1 (Catalina) has to be notarized. I got the dmg notarized so I know that the malware is not the issue. Now asking every ElectronJS developer to know every single part of Chromium or even electron itself is a bit unreasonable.
as CTO I know all the dependencies in the application stack of our company and I require developers to have sufficient understanding of their purpose, licensing model etc.
There are tools to simplify this task. It’s much harder to do for TypeScript than for Java, mostly because NPM ecosystem is a huge pile of junk, but it’s still important part of developer's job.
> as CTO I know all the dependencies in the application stack of our company
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?
as CTO I know all the dependencies in the application stack of our company
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[1]) 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?
We barely have any of the Apache commons dependencies - in most cases use of them is not justified in modern Java. If there’s anything like that we are ready to support such dependency on source code level, patching and setting up own build pipeline if necessary. Free software cannot be trusted if you are not ready to own it. Commercial software cannot be trusted either, but there are other ways to manage the risks there.
I can't believe you check all the source code, dependencies source code and the rest of the shit show that npm brings to the party, that's very cool, all CTOs should be like you. As a CTO should you have to do this though? I'm not sure.
We are growing startup and it’s important to have this culture of understanding what and how you build from the very beginning. This responsibility is now transferred to technical leads, but I’m still aware of what’s going on and spend some time on the code reviews.
Usually you don't write a project and then sit down to read through all dependencies, but it's a process that happens when you do add a dependency.
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.
I think that's not an unreasonable thing to expect at all. If the libraries you're using make that impossible, then you shouldn't use those libraries. You should know what you're shipping.
As a developer, I'm honestly and utterly stunned to see other developers arguing otherwise.
It's going to sound uncharitable, but if you're clearly being rejected for something that your dependencies is doing wrong you should make time to figure out which one it is.
Is it really difficult to find private API usage? Can they be searched for through static or dynamic analysis?
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.
> 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?
No.
> 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.
Your dependencies (including the transitive ones) are your responsibility. If you can't keep track of them, perhaps you fucked up. https://queue.acm.org/detail.cfm?id=3344149
> You may not have time to inspect every single node in the dependency graph.
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.
Have you never run maven, sbt, gradle on a Java project, or PHP compose or .. anything in node? There are so. Many. Dependencies in some of the frameworks people commonly use. It can get pretty insane. We all remember left-pad, right?
Lack of knowledge of your dependency tree isn't really an excuse here. If you're submitting your application to an App Store -- where one of the express purposes is that customers know the application is safe -- then having an unknown dependency is not really a good argument.
How are you sure that your code gets compiled properly? Do you read the assembly generated for the processor and the source code for your compiler?
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.
Yeah... Everytime I try to use something like that and it wants to pull in 10 or 50 dependencies, it's a hard no. I would rather write something from scratch than use something and potentially debug through all those layers.
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.
Because Electron developers might say "we fixed it" and the app developer might resubmit based on that and now they're banned due to a mistake made by an upstream dependency.
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.
That resubmit approach ways used by at least one camera app years ago who masked their private API usage to secretly include a volume button “take photo” feature. They were told to knock it off (and Apple also added that option to the API at a later date).
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.
Camera+ didn't use a hidden API - they just used a standard system volume control but placed it offscreen and monitored if the volume changed (and then lower it imperceptibly if you hit 100%). And Apple has still not added an API to do this officially, last I checked all third party camera apps use a similar hack.
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.
it would but it wouldn't solve the problem. This would require the developer to modify electron and basically run his own branch. It would then make your package possibly acceptable (but attention here: as Apple clearly stated keeping too use private APIs can get you banned so if you miss something you can lose your access to the apple store) leaving however everyone else using electron with the same problem. So the solution has to come from Electron.
Who do you imagine is responsible for making sure your app doesn’t contain malware?
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.
you simply notarized the app and you know that there is no malware. Also we are talking about ElectronJS and Chromium -- not exactly untreatable sources. Note that apple does check for malware and quality on the upload stage itself (now done via transporter) so it wouldn't even make it to then review state if something is dodgy.
Apple can’t magically tell that there’s no malware in an app you upload. There is no automated scan which can detect all security vulnerabilities or back doors in code. And we’re talking about electron plus hundreds to thousands of npm modules - which contain who knows what.
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.
I've done that over my entire career. It's always been a requirement. To say you can't find time for it is the same as saying that you can't find time to complete development.
Sometimes saying the truth is unpleasant. But the fact is, these developers have no idea what they are using, or what runs on the users' machines. They bring a ton of dependencies and have no idea what those involve. If that is not incompetency, what is?
This policy has been there since the beginning of the App Store.
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.
The "first class" experience for developing on a Mac would be to develop only for the Mac. If you're not doing that, your job is going to be a bit more difficult.
Yes, I'm aware. But it's a bit weird to say the developer experience on Linux is first-class. For things that don't have a GUI, sure. But that's not what the discussion was about.
As far as my experience goes, it looks pretty native on Windows. Looking at the documentation [0] it also seems to strive for mac-OS native look and feel.
This is just a phrasing of a sentence in a mail. It does not define either what reasons they are allowed to ban you for, nor does it define what reasons they will use to ban you.
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.
You assume it isn't an honest mistake. Most people submitting electron apps won't have knowledge of the browser engine layer and its calls to Apple APIs and probably will have some difficulty assessing whether or not they have resolved the issue. That doesn't make them bad people. They are not malicious or trying to hide things. Apple's scripts should give them more chances until they get it right.
Whatever symbols are found in the public header files in the /System/Library/Frameworks. Iirc, there are tools which look at a binary's used symbols and compare them to those headers.
In practice it is pretty easy to slip things past the automated checks if you try to, which is one of the reasons they threaten you with a permaban for doing so.
Huh? The problem isn't that the developer itself is trying to cover his misbehavior, but the fact that the developer can get banned for something out of his control.
The developer is the one who takes responsibility for the submission. Enforcement is meaningless if you can just say "oh I asked you to publish dangerous code, but it's not my fault."
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.
> "Keep trying to submit, and we might just ban you forever" is insane.
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.
I think that's being too charitable to Apple. Their review process is automated, and nobody really knows what will trigger the Ban Bot into deleting your account.
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.
> Their review process is automated, and nobody really knows what will trigger the Ban Bot into deleting your account.
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.
> While review is automated, I would like to believe that account deletion isn't.
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.
> Apple has no love nor concern for their developers anymore
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.
> 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.
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.
Ideally anything that is theoretically callable by an application should not pose a security hole. The only issue with private API is that it breaks from release to release.
> I did write back to Apple trying to explain that I am using Electron and I can't really change any of these public-framework usage
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.
From what I recall, this practice goes back to the original 68k Apple Mac.
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.
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.
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.
Undocumented APIs get broken. That's a big problem for user experience, particularly if it happens to be being done by a framework relied upon by a very high percentage of app use. Seems pretty fair imo
It isn't? There's a difference between dropping 32bit libraries from your OS (after a lot of time in which Apple clearly said "we will drop support!") and banning for using unauthorized APIs inside the MAS.
Microsoft was vilified for many anticompetitive practices.
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.
You are assuming that these Apple APIs are used to give Apple a competitive advantage somehow. From what I can tell, these specific APIs don't. What they do give Apple an advantage in ironically is in forcing more developers to develop using (Apple) native APIs.
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.
>None of these are giving Apple a direct advantage.
>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.
There is a very valid reason for an API to be kept private, if it's based on internals that are too hardware-specific and you don't want to break compatibility when/if you update the hardware (so a higher-level abstraction is needed and that is in the public API) is a very fair one. Core Animation might fall into that or it might not but it doesn't necessarily is a conspiracy to keep 3rd party apps in the mud.
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[0] 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.
Public core animation APIs on Apple hardware are plenty fast. I suspect the issue here is that web browsers are acting as yet another abstraction layer and thus are introducing more performance overhead. Electron is probably trying to squeeze as much performance as it can get or electron has a rendering cycle that makes it hard to have it not skip frames due to overhead. Best thing to do is to ask Electron devs.
I was wrong about some of them being drawing frame related. See https://www.cocoawithlove.com/2008/12/drawing-custom-window-.... Apparently customizing the window frame. The CA prefixed ones are correct. Apparently, at least on a Mac, it was more about battery than performance (at least for what Mozilla did) but it was still about the amount of work they were doing per frame (for Mozilla).
Code signing does not do what you apparently think it does. They can’t block it unless it’s a windows store app/universal app, which is sandboxed. And that’s exactly what they do for those apps. Tim Sweeney ranted about this quite vocally!
I never said code signing DID do that. Of course it didn't, there were no secret high performance Microsoft only APIs in the first place. I said it COULD have easily been used to do that. E.g. make special API/syscall to unlock restricted APIs, Windows checks the signing status of the executable making the call and only grants permissions if it is signed by MS.
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).
> E.g. make special API/syscall to unlock restricted APIs, Windows checks the signing status of the executable making the call and only grants permissions if it is signed by MS.
I think perhaps your memory is short if you think that this is worse than anything Microsoft ever did. Did we forget them funding, to the tune of millions of dollars, a felonious pump and dump scheme designed to defraud investors and destroy competitors with fraudulent lawsuits.
In a completely fair world a substantial number of executives would probably be in jail.
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.
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:
> 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.
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.
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 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?
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
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.
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.
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...
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.
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.
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.
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.
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:
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.
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.
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.
There are no such things as “secret APIs”. By definition an Application Programmers Interface is the vendors promise to other developers that when you call it, it will have well defined results no matter if the implementation changes. Every modern programming environment has the concept of public and private methods either enforced by the language (with hacks to get around it) or by convention (prepending a function with an underscore)
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.
That’s true. Apple doesn’t say “secret APIs” that’s a conspiratorial phrase made up by third party developers.
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.
So you expect the EU to not allow Apple to ban the use of private methods? Are they going to also ban Apple from not changing them?
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?
Exactly. An application developer chooses his dependencies and has to take responsibility for them. Even if the app store is going to let you pass the buck, it's going to make your customers unhappy.
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.
It’s more of a general point that if your application is buggy, the customer isn’t going to give a damn whether the bug is in your code or in somebody else’s code.
this is exactly what they told me in the follow up message. I am somehow surprised how the bug in electron repository is not given much importance at all.
after this post apparently the issue has been upgraded to a bug and someone is working on it. I hope they will find a solution OR at least let everyone know that they shouldn't bother creating MAS packages and upload the apple store. I think it is dangerous as it can get you banned.
This summarizes Apple's attitude to developers. Eventually, you'll run foul of some obscure nonsensical Apple policy, and Apple will not hesitate to show you the finger. And Shame you for your dev choices.
The post shot to #1 because there are a lot of Javascript developers that see Electron as a gateway into apps they would otherwise be unable to develop. There's a lot of interest in whether or not that door closes.
Apple's policy towards private APIs has been known for years.
Apple is roadblocking the use of private APIs, not languages. Or interpreted another way, they're roadblocking frameworks, not languages. This is true whether you're using Javascript, Swift, or C. This rule has been in place for years.
You must be chugging the koolaid to believe developers LOVE Apple's policies, or enjoy getting their hard-work rejected by a bot, or getting shamed by an overzealous Apple employee on HN. Developers are homogeneously unappreciative of Apple's treatment of them. They just don't have any leverage, or opportunity to negotiate
Who are you going to blame when applications start breaking because Apple removes or changes the functionality of a private function? [1] without warning?
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.
[1] 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.
Blame the developer? Which is why, when an app breaks on the Mac store or app store, users pound the app with 1-star reviews. Even if the breakage happened from a platform (iOS or MacOs or Android) bug.
This is not Apple "watching out" for the developers, no matter how much you spin it
What about on iOS? And what about the fact that on MacOs notarization is more expensive than publishing to the store? I don't believe that to be a coincidence
Now you've thrown me a curveball. I will have to test. I think last time I looked, Developer ID is considered a distribution certificate and requires payment.
Apple doesn't rebuild apps that require massive features, but they do often build things into the OS or as base apps that negates the need for apps, some of them wildly popular.
Wouldn't a more reasonable path be for Apple to talk directly to Electron and Chromium about the issue and work out a path forward before rattling a banhammer at app developers, though?
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...
Chrome and Firefox are using a critical feature that has no equivalent public API. If they didn't then they would end up using 3x as much energy which is important for the battery life of laptops and phones.
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.
Judging by the history of a related issue on the Electron Github project [1], I suspect that Apple might have given the framework a two-month grace period starting in early September, and that just expired. Or the exception was supposed to be permanent, but something made it stop working.
Apple's WebKit is safe to compile for their stores. The scripts and macros WebKit has disables use of private API unless you are compiling against Apple's internal SDKs.
Edit: Sorry, no. Only JavaScriptCore is safe for stores, not the entire WebKit project.
You are missing that Chromium uses these APIs in the first place because they offer better performance or necessary flexibility. Since Google doesn't distribute Chrome on the Mac App store, chances are they don't care about "fixing" Chromium to not use them.
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.
As a user I am glad. As is custom for all Electron discussions, someone must point out its flaws. Why the dislike, you ask? A picture is worth a thousand 64-bit words:
And mind you, GitHub Desktop is taking that much just for showing a mostly empty window! while Fork and Tower are displaying a lot more UI, more controls, trees, custom drawing, more text, and have overall more features (best of all: spell checking for commit messages because all native text fields get it for free.) You can try it on your own machine and compare them.
Now yes Electron has made life very easy for some developers and some apps wouldn't even exist if not for Electron, but why, as a user, should I pick an Electron app over native alternatives?
While working on a project that uses a service built in Typescript I've been using vscode. I was wondering what was wrong with my laptop's battery, it had gone from lasting around 2-3 hours unplugged doing reasonably intensive to lasting around 40 minutes. As soon as I stopped using vscode the battery life went back to what I'd normally expect. It's honestly outrageous that applications built on Electron strangle your CPU to this extent. I'm not sure if vscode is particularly resource expensive compared to other Electron apps, but compared to other editors it's just ridiculous.
This is the bigger thing for me. The CPU usage of many electron apps is through the roof. It's so convenient to use that I'll probably still make electron apps, but I'd love to see Apple and Microsoft partner with each to make both more performant.
These numbers are too low. I assume that this task manager might show only private pages and not account shared pages with code (and the code size in Chrome is close to 100 Mb). Anyway, the number looks a bit unrealistic. Or maybe it doesn't count swap.
I used Electron apps on Linux and typically memory usage doesn't get below 250-500 Mb.
Here is an example for Skype: 220 Mb of swap + 388 Mb of PSS (Proportional set size).
I would rather use smem, that calculates PSS (Potential Set Size) that properly accounts for pages shared between processes and shows swap usage per process. 1 Gb seems realistic though.
The memory usage issue is insane. My work laptop is regularly at 20GB memory usage partly because all of these electron apps take up 300mb to sit in the background and show me a notification every now and then. Its hugely refreshing to see my notes app (Zim Wiki) using 19mb of ram while being super fast and providing a huge amount of utility.
As a user I think Electron is great. It means many more apps have a Mac version. Compare to games, where Electron typically isn’t feasible, and observe how many games don’t have a Mac version. A little extra memory usage is fine by me. I can understand how people disagree, and that’s fine, just don’t use Electron apps. No need to ban them from the platform.
Often, nothing is better than the Electron equivalent.
Case in point, if I run Slack in Safari, it runs better than the electron version. Functionally, it’s identical, except the scrolling is now native and feels a bit better integrated in macOS. So what’s the point?
I work on AVs, so we have incredibly beefy workstations: I've never managed to make my workstation seize up, even when building and running the full AV stack. Somehow, all of my coworkers who use native Slack have developed the reflex of killing and restarting the application whenever their workstation hangs. It's beyond me why they continue to use it.
(That isn't to say that the web version of Slack isn't horribly engineered too, but it poses far less of a problem)
There is literally no reason to distribute an electron app when you could simply run
it as a web server using `npm start` and navigate to
`http://localhost:[port number]`. Electron is born out of a misplaced notion that
some apps are "special" and deserve a certain extra percentage of the users' CPU
cycles and battery life for a spot in a user's system tray. 10% of a user's battery
life multiplied by all their electron apps is not worth it when alternatives (like
starting a web server and launching the users' preferred browser) exist.
I once used this pattern and implemented the webserver using C++. It was quite interesting that I could read gigabytes worth of files and run a sqlite database in the same process and still not exceed 3MB of RAM. Of course the tab in the browser used a lot more RAM (maybe 25MB) but browsers can suspend or simply close tabs. With regular applications the GUI would always be loaded in memory.
The reason why this pattern isn't used more commonly is the fact that right now web browsers simply aren't designed to be used this way unless you start a new instance for just a single app. The second reason is that electron developers are lazy. They only want to test a single browser (or browser version) and are perfectly happy that this means Google can get away with shady things.
I once used this pattern and implemented the webserver using C++. It was quite interesting that I could read gigabytes worth of files and run a sqlite database in the same process and still not exceed 3MB of RAM. Of course the tab in the browser used a lot more RAM (maybe 25MB) but browsers can suspend or simply close tabs. With regular applications the GUI would always be loaded in memory.
The option is native vs. electron vs. a regular web app. There's rarely any reason you need your web app to live in a dedicated Chrome instance without a URL bar.
Nobody is asking that, there's a crowd in here that restates the same three points about memory, performance and native UI about once a week.
I dislike waste, I have written assembly code for tiny processors. And yet, I run several Electron apps on my 8gb 2013 Macbook Air and it runs fine, especially VSCode. I am picking that over my previous choice which was native (vim), because I think it's better.
Not every developer runs a Macbook. Like many others for my laptop I use Linux running on a cheap ThinkPad with a quarter of the specs of the one you mentioned. ( I could afford to buy an overpriced Macbook, but I like my rugged $100 ThinkPad. )
As I stated elsewhere in this thread, vscode absolutely chews up my battery power. That's a practical concern. If I run several Electron apps on my laptop I'd be lucky to get an entire commute's worth of battery life out of it.
As someone who spent years complaining about the lack of cross-platform apps that I could run on Linux, I'm grateful everyday for Electron and for MS for using it for VS.Code.
The fact that it works the same on OSX and Linux is even better.
You are right and I am sorry, that was unnecessary.
For the record, I do think there are problems with Electron, just not the ones usually mentioned. A big (huge!) problem in my opinion is that two windows can't share JS context. It's the reason why VSCode is way behind in multi-monitor support for instance.
Not everyone is in your boat. As developers, we build things for others to use;
empathy is a cornerstone of the job description. Hopefully this will help illustrate
why Electron isn't a good choice:
Say a somewhat below-average user has 6GB of memory (I'm being generous here; plenty
don't have more than 4GB). Today is a worse-than-usual day, and 4GB are taken by
everything that isn't Electron because 40 tabs are open for a research paper due
tomorrow. That leaves three gigs to spare. Now the user starts up some Electron
apps.
- Music player? +400mb
- Note-taking? +300mb
- Messaging? +500mb (thanks, Slack!)
- News? +300mb
- Editor/IDE? +500mb
That's it. No more space. And that's before we even begin talking about what we're
putting that dual-core CPU through. Battery life is a joke at this point.
A comparison: My OS, window manager, mail client, password manager, taskbar, music
player (mpd+ncmpp+clerk.pl), file manager, system monitor, RSS reader, podcast
player, IRC client, and editor/IDE (neovim+language servers with diagnostics, gotos,
floating documentation, and refactoring all running) barely use over 1GB of memory,
combined. Let that sink in. Essentially, a single electron app using 500mb of
memory would increase my memory usage by 40%.
People shouldn't have to throw away/upgrade their computers every four years. I'm
still rocking a 2013 HP Elitebook G1 with a Haswell i5 as my secondary machine. It
runs just as well as my desktop for anything except heavy websites with JS enabled,
compiling, and graphics-intensive work. I plan to either continue using it for
another few years or donate it and switch to a more lightweight \$199 Pinebook Pro.
Using less powerful hardware forces me to empathize with users who are using tech
from the past rather than the future, because that's my job. I build tools for
people besides myself to use.
If you must use the web, consider making your "app" start a local web server and
launching the users' preferred browser for a more lightweight solution.
Not owning an iPhone, I don't have a horse in the race, but if company X is going to make a client for their service, and for whatever reason you need to use their client, if they are not allowed to use Electron, then they will use a different toolkit. If you don't like Electron apps, then this is a win for you personally. Too many services can only be accessed with the official app, which means it's not like you can just download the "not made with electron" version.
> "I cannot fathom the indignity required to care about that difference."
Your failure to empathize seems like an odd thing to brag about. Even if you have plenty of memory available, you should be capable of empathizing with people who are short on it.
lol. The communities were a bit more close knit with editors back then, so you couldn't avoid hearing such things. Nowadays there are so many choices that I hadn't heard the joke in a long time.
Good. It’s time app developers began to treat Electron like the Goliath of a dependency that it is rather than a cost-free shortcut to launching a cross-platform GUI product.
It’s no different than any other library or toolkit you would link against normally. You wouldn’t be hearing these complaints from a “native” app developer that intentionally picked any other library or runtime that (ab)used private frameworks.
Technical details aside, it describes two methods of performing delegated rendering on Mac. One uses public APIs and causes a "reduction in performance and increase in GPU power consumption." The other uses the reverse-engineered CAContext API.
Its looks as if the Electron team had the assumption that developers would be unlikely to distribute their Electron Mac apps via the App Store, but instead as a DMG or zip which doesn't require Apple reviewing private APIs.
Mozilla recently published a good write up on why they started using these undocumented CALayer API's in Firefox 69. The TLDR is that that these private API's allowed them to get up to 3x better battery usage in Firefox. The article also mentions that Chrome uses these same Core Animation API's.
I just wonder they bump major releases very quickly --now is 7.0.1 and basically a lot of stuff you find, including courses are obsolete and a lot of deprecation -- and yet they didn't take this seriously enough.
This is not an Electron issue as Apple has deprecated these APIs and the issues go back for the past few years worth of Electron releases. We just bumped our Electron version from 4.0.5 to 6.0.12 and we just needed to add a single line of code.
I think half the drama is that there are Electron apps in Apple's app stores already, e.g., a quick grep of Slack.app shows it contains all of these symbols in "Electron Framework.framework", yet it was apparently approved.
Is this another case where you can break the rules but only if you're rich enough?
According to a previous poster, the public API cause excessive power drain and is a fair bit slower. Since Apple usually use the argument of how the OS and API's are built to draw less power, it's quite peculiar that they can't find a more constructive solution than threatening to ban people and companies from the app store.
On one hand I am not fond of Apple in general at all. On the other hand when I see developers using Electron as a GUI layer I think it is pure insanity. It is an absolute resource and performance hog that in my opinion has no place outside of browsers context.
I'm an old dinosaur who used to do GUI development way back, and while I completely agree that Electron is a beast, I also haven't seen almost reasonably cross platform app toolkit that isn't either ugly, or worse than Electron. So what are the options I am missing?
Ones that come to mind right away and support most popular OSs:
1) wxWidgets
2) QT
3) Delphi with Firemonkey
4) Lazarus
Whole bunch of other which you are welcome to Google and explore
Also it depends on your type of application but I am seriously considering using 3D rendering library as a basis for multiplatform GUI. This one does not look too native but it looks like it may be the leanest, fastest option. This would require some groundwork first.
Their own apps certainly isn't following the same rules, newer have, and probably never will unless forced by law. There probably are, and have been quite a feq things on any iPhone/Pad that only Apple apps can do. Although I don't have my ear that close to the ground, they seem to get more and more aggressive about protecting their turf in any way they can.
Apple's apps have never claimed to follow the App Store Guidelines. The issue at hand here is when third-party developers are selectively granted exceptions.
I'm curious as to how Slack was/is still able to get updates out despite clearly relying on electron. Setting aside whether one agrees with Apple on this move or not, I would be outraged if they are playing favorites with a select few high-impact electron apps that they don't want off their store due to the associated bad press it would garner them.
well I guess that when you have the #1 application in the App store (under business) and an 11bn $ market cap you are probably not treated the same way as an unknown developer with a pretty insignificant app ;) OR simply you do have engineers that can patch pretty much anything so run their own version of Electron/Chromium duly compliant with the App Store requirements.
At least Apple in this case actually provided a reason and list of APIs it is unhappy with. Armed with this you could either in theory or actuality chase through the maze of your app's dependencies. If this happened to me I'd then have a fighting chance of moving forward.
On the other hand, plenty of rejections I've anecdotally encountered are far less obvious and boil down to "we say so". Then you get banned while you still wonder. Google have done this a few times to others I know.
Off topic: this is the first time I see Latin Modern Roman used on a web page. Doesn't look that great on low-DPI screens (13" at 2560x1440) but looks good on high-DPI (530 DPI Pixel 4 XL).
This is not new. There have been checks for private API usage for as long as I can remember – at least on iOS. It could be the case that there was less enforcement on OSX.
However, this is not really about unsigned binaries. These APIs are from OSX itself. This is about access to private APIs. These have no contract and can be changed at any time, as they were not intended for public consumption.
No. The symbols mentioned in the rejection are all in signed Apple libraries; the problem is that those symbols aren't part of the public/documented/stable API.
I feel Apple is moving into somewhat dangerous territory. If the intent, as documented by internal messages and emails, is purely to protect the consumer by forcing people to use only public APIs, that's one thing.
But, if Apple is trying to apply anticompetitive behavior against certain technologies, if this rule is selectively enforced, if there is any bad smell or anything dirty about this process, then Apple is inviting antitrust scrutiny or new laws.
Apple had better make sure it is squeaky clean on this.
This is nothing new, developing iOS and MacOS apps you use public APIs and never use private ones. I have never had any desire or need to use something not documented/public in anything I have built. You'd have to be pretty dumb to depend on something that Apple can and will change whenever they want. When I worked at Apple 25 years ago I remember the source code to the old MacOS was riddled with "if Word version 4.05 do this, if 4.15 do that" to try and avoid breaking Microsoft's apps". It was a nightmarish attempt to ensure buggy software didn't suddenly stop working. I don't blame Apple for wanting to avoid this kind of pain today.
Valid points. My worry is if this is being exercised inconsistently. Is the same rule applied in the same way to everyone? Even Apple granting itself exceptions isn't great -- and I know it does grant this exception to itself -- but if it grants exceptions to some third parties but not others, or does not faithfully and consistently enforce the rule for everyone, that would be extremely troubling.
I think the intent of these rules is (and generally has been) to allow Apple to classify APIs into "public" and "private" categories, where the public APIs are documented, and will not change or be removed without plenty of notice, and the private APIs aren't any of those things.
In some cases, private APIs are used as implementation details of public APIs. For example, the symbol "NSNextStepFrame" sounds like it might be part of the implementation of NSWindow. In some other cases, Apple has made early versions of some APIs private before later releasing them publicly -- for example, the Catalyst APIs (UIKit on macOS) was a private API for a while before being publicly released, allowing Apple to test the APIs (and potentially make backwards-incompatible changes) before external developers started using it.
They have selectively applied them to themselves for ages as far as I know. Which must be regarded as anti competitive to some extent.
It's also pretty much a straw man kind of argument around the public/private API distinction as important to prevent applications from breaking, as it seems to be the rule rather than the exception that lots of apps break on iOS updates anyway.
They don't seem to care that much, but it could be a good way to make sure it's harder for eg Chrome to compete with Safari. Simply make the API they have to use a bit slow and inefficient.
> They have selectively applied them to themselves for ages as far as I know. Which must be regarded as anti competitive to some extent.
This only affects the App Store, which Chrome quite purposely is not part of and which the vast majority of Apple apps aren't distributed through.
> They don't seem to care that much, but it could be a good way to make sure it's harder for eg Chrome to compete with Safari. Simply make the API they have to use a bit slow and inefficient.
My understanding is that the inefficiencies in question come from a need to bridge from cross-platform code into the public APIs.
For example, one of the private functions mentioned was needed to treat mach ports as file descriptors - not needed if you are using the proper API to deal with ports.
My understanding is the CoreAnimation private calls are because the layers are rendered and composited externally and CA is only being used for display. Because the rest of CA is skipped, it can't determine a list of partial changes and thus performs a lot more work than necessary. The Private calls are being used to force CA to skip rendering parts of parts of the display. Safari doesn't need to do this because they are using the proper API for the entire pipeline.
While this decision looks rational and technically solid on the surface, it makes the Mac platform, and in particular the Mac app store, even less appealing to developers.
Here on HN we hear constantly of developers dropping out of the Mac app store. If we cobsider the premium (justified or not) of apple laptops, and thus the relatively limited audience they target, we can easily predict a steeper decline in interest to develop for the Mac platform.
Having said that, we should also consider that Electron is indirectly owned by Microsoft, and is based on tech by Google. So I don't see much incentive on their part to fix this quickly, and one could even argue that they have some interest in not fixing at all this.
Electron apps can be submitted to the Apple store...
Slack has recently been updated for example.
This seems to only affect some developers, especially electron <= 5
5 doesn't work either (others having the same issue in GitHub even got rejected with electron 3). Slack was updated a few days ago (I also had no such an error then). Also let's not forget that Slack is #1 in the App Store for the category business so is certainly not treated like a small app from an unknown developer ;)
Because of how Obj-C works, it’s not really possible to have completely hidden classes or methods. You can instantiate classes by name at runtime, and can similarly create a message (aka call a method) at runtime. This is basically the “concealed” option mentioned elsewhere. Because of this dynamism, it’s possible to recreate a header file from the compiled frameworks, and then just compile like normal.
Well to be honest and at the risk of getting down voted I think a fair amount of readers will agree that you shouldn't submit Electron apps not only on the Apple store but also elsewhere, it may be a good way to get a prototype out of the office but that's about it
Because they need to link against these symbols themselves. They have used TAPI in the past to keep these symbols out of the public SDK, but it's quite easy to make your own TBD that lets you link against them anyways. (By the way, you posted your comment twice.)
Even if its just 10% of your users that installed your app from MAS, that’s still a huge problem. 10% of your users you can’t ship an update to and have no easy way of moving to your self-hosted updater, that’s a major problem.
I personally prefer using MAS for such apps, since that means updates are installed automatically overnight without having to deal with other people’s annoying auto-updating software. Wish Chrome itself was in the MAS, so I didn’t have to deal with Google Autoupdater.
right but I think the Apple store is still a big market. Let's not forget that even a notarized DMG (required in the Catalina update) still shows a warning "this app was downloaded from the internet" which obviously doesn't trigger in thee apple store.
And similarly, web tech wrapper apps for macOS that use WebKit instead of Chromium are not facing private API usage rejections.
WebKit on macOS doesn’t have the limitations that its iOS cousin does… cutting edge API support is a bit spotty but if one looks at how old the versions of Electron being shipped are, that clearly isn’t a problem. More web wrappers should opt for the locally available engine instead of bringing their own.
Apple does not like platforms that make it easy to publish lowest common denominator apps for iOS. It makes for garbage apps that look the same on iOS and Android and presents a false equivalency. They know most companies care about iOS customers than Android so this forces companies to spend more making the iOS app better than the Android app.
It’s dumb too depend on private APIs and shows a complete lack of understanding how development works. Have you read Raymond Chen’s blog about all of the obscure one off hacks Microsoft has had to add to keep misbehaving apps from breaking?
And where has that gotten them? Slow release cycles, unable to compete in mobile and now Apple alone sells more iOS devices than all Windows manufacturers combined. You create a compelling platform for users and developers will come along.
That’s what happens when you focus on developers instead of users. How much smaller would Windows be if they didn’t have all of these backwards compstible hacks? Hell, they had a half dozen different ways to define a string that you actively had to convert back and forth between just to call various APIs and that was back in the early 2000s. I’m sure it’s gotten worse since then.
You don’t have to make developers happy. Developers will go to where the users are. Where is all of the development energy these days? It’s definitely not on Windows. What makes developers “happy” are paying customers.
Microsoft has been trying and failing for years to produce a viable ARM laptops. Partially because of an insistence on backwards compatibility and all of the code bloat that entails. Apple transitioned the Mac platform four times since 1984 and created four successful ARM based platforms in the last decade.
Microsoft’s hardware was often the same hardware that ran Android especially from HTC.
But as far as the Surface. MS only made $1.329 billion on Surface devices. That’s less than a third of what Apple makes on Macs. Heck that’s less than Apple makes on Watches and AirPods.
Yes. That way I can install apps on five computers, I do not have to keep a list and go lookin for them, because they are in one place, and I get regular updates.
I think this is a really elitist and unsympathetic statement. It completely ignores the fact that there are people out there whose only realistic option if they want to release on multiple platforms is to use something like electron. You can preach native all day long but the reality is that some people simply do not have the time (i.e. money) to learn, build and maintain three completely different systems and architectures and at the same time and also build a product. Are you saying that these people should simply give up because you consider it a "shortcut solution"?
Yes electron comes with some overhead. But what you get from paying that price are products that otherwise likely wouldn't exist. Some of these are bad indeed, but some of them are also really good and provide real value.
Thanks for sharing this perspective. Some of us have a core competency in a domain outside of CS and want to build niche tools to serve our industry. Electron helps us reach our userbase without excluding one or more platforms. Bloat is secondary compared to the other heavyweight software I have to use.
perhaps, but you can still build a "native" iOS app using flutter without any issue. I think given that even Skype and Visual Studio are build on electron II don't think is all about shortcuts. Having more options is always healthy for developing apps and for the apple store. Of course if you build with pure native code (swift) you won't have the same issues :)
The lesson here is apple will screw up their ecosystem enough that developers will start to leave. Was looking at building pretty involved app and evaluated SwiftUI vs Electron with React. The effort on SwiftUI side about 10x vs Electron/React Apple needs to invest in their tools.
Regardless of what Apple calls them, they don't behave like a native Mac app, and I (and many other Mac users) will refuse to call them as such until they do better.
Pretty much. Back when apps were native to the platform they would be windows only. It is insane to require every app developer to have to put in 3x the work to rebuild the app for every single platform using its native tools. I would rather have one app that is 3x better and works everywhere. We just need to solve the massive memory issues with electron.
Yeah, when you're coding for a cpu, write in assembly only. Write a separate copy of your app for iphone and macOS because one of those is arm and one isn't.
Don't use anything that provides portability like C or Objective-C, that's not really "native" to the CPU architecture.
.. I know that sounds silly, but you're advocating for that one layer up. It's a very good analogy I think.
People use electron in order to "compile to" native apps for linux and windows and mac without having to write the app 3 times.
Apple could just not have private APIs. At the very least, they could be impossible to access. If they have to exist at all, they could be in a separate library with permissions that prevent it from being read or mapped into memory.
If the APIs didn't exist, then there would be no need for Apple to check and there would be no developers tempted to use anything private.
Again this shows a complete lack of understanding how software development works.
If you have a public function “A” that is implement using private methods B,C,D. The implementor is free to change B, C, D or completely get rid of them to implement A. This is software engineering 101. Apple was able to make multiple cpu transitions doing this. Back in the PPC days, non native apps could run at near native speeds calling public APIs that were implemented by changing the private interface.
Put B,C,D on the other side of a privilege boundary.
Most obviously, they can go in the kernel. They can go in a separate process, using the Mach messaging that Apple so loves. There are other designs, as seen in Multics and VMS, with semi-privileged libraries. One could implement semi-privileged libraries on ARM by switching to a different page table when an attempt is made to run the library code.
For secured forms of code like WebAssembly and the JVM, simply validate at load time that there will not be calls to non-whitelisted library functions.
There is always a performance penalty when switching between “rings”. Private methods are an “implementation detail” that shouldn’t be depended on.
Would you write a C++ program that called private functions using pointers? Would you write a C# program that called a private method using reflection? Should the dependency maintainer have the expectation of people calling private methods and not break your code?
Every suggestion you have leads to performance issues.
Firefox is often criticized for it's power consumption on the mac because it is not on par with safari. Chrome/electron uses private APIs to reduce power consumption to be more competitive with Apples browser. Apple bans the use of private APIs.
Banning private APIs is absurd. Permanently banning developers for using private APIs is shear lunacy
An API by definition is the public interface that a platform promises developers will not change without notice. The vendor has every right to change a private API. Once you start letting third party developers use private APIs either you are stuck with them forever or when you change it, users will blame you not the developer when applications break.
What a moronic comment. No ware in my comment have I argued that apple should not change their private APIs. What I'm arguing against is preventing third party developers from accessing them the same way apple does. We all understand that private APIs are subject to change without notice and accept the inherent risks involved.
It’s moronic to use a private method that may change in a minor update. If anyone is using private APIs - they should work on their development skills.
Of course Apple is going to use private methods to implement public APIs. Would it be more sound architecturally if they made all of their public APIs thousands of lines of code and copy and paste duplicated functionality so they wouldn’t use private functions?
The risk isn’t just to you. Apple has been able to get customers to upgrade their operating system at a cadence that no other platform vendor has. What happens if every time they release an operating system apps break because they use private APIs? Either they will have to take the Windows strategy of putting individual hacks to keep apps from breaking or they will just have to let them break? Microsoft has historically not been able to ship OS upgrades on time partially because of the backwards compatible bloat of Windows.
Apple has successfully done multiple platform transitions by completely changing the underlying code for public interfaces. They wouldn’t have been able to do that if developers were using private methods.
In the grand scheme of things, you as a developer aren’t and shouldn’t be Apple’s focus. The customer is. If Apple is able to keep the customer happy developers will come along.
> users will blame you not the developer when applications break
Apple breaks apps CONSTANTLY that use only public APIs, and the users DO NOT BLAME APPLE.
Do you even work in the iOS ecosystem? Because everyone who does knows this. Users don't blame Apple when things break, they blame 3rd party developers.
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.