
Electron apps cannot be submitted to the Apple store - rdevnull
https://david.dev/you-cannot-submit-an-electron-6-or-7-app-to-the-apple-store
======
thomascgalvin
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.

~~~
plorkyeran
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.

~~~
MauranKilom
> 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.

~~~
saagarjha
How exactly do you miss a dependency?! If it's not your code, then it's a
dependency that you need to look at.

~~~
creatornator
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.

~~~
Scapeghost
> 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?

~~~
root_axis
Is that a joke? Surely you aren't suggesting that developers should have full
knowledge of all transitive dependencies that compose their application stack.

~~~
ivan_gammel
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.

~~~
root_axis
> _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?

~~~
ivan_gammel
Hundreds, mostly because of the JS nonsense. Our Java microservices are lean
and strictly controlled.

------
outworlder
> 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.

~~~
kjksf
How short are memories.

I remember how Microsoft was vilified for supposedly having secret Windows
APIs that allowed Microsoft apps to get better performance.

That was mostly made up and even if such APIs existed, any program could have
used it.

Even at the height of corporate arrogance Microsoft didn't dream of banning
developers for using undocumented APIs.

Apple seems intent on becoming more evil than Microsoft ever was.

At some point the goodwill they built as underdog making great products will
run out and some government somewhere will take an anti-trust action.

I'm just hoping it'll happen sooner rather than later.

~~~
matheusmoreira
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.

~~~
ptlu
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.

~~~
BoorishBears
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.

~~~
saagarjha
> 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.

~~~
BoorishBears
What are you talking about?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This is all modern software engineering 101.

As a developer there are a few expectations.

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

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

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

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

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

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

Not when the vendor is Apple.

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

iOS point releases break things _literally all the time_. Iirc we actually saw
_more_ fires on 13.1 than 13.0

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

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

But your argument has nothing to do with this submission - using _private
APIs_.

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

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

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

[https://djtechtools.com/2019/10/10/update-to-catalina-
heres-...](https://djtechtools.com/2019/10/10/update-to-catalina-heres-how-to-
manually-export-your-music-app-as-xml/)

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

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

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

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

Maybe spend more time reading and less time replying.

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

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

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

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

    
    
      int b= a++ + ++a;
    

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

~~~
BoorishBears
Again you spend more time replying than reading.

I said this internal API rejection situation of _Apple not treating developers
like partners_

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

I'm done replying to this.

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

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

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

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

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

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

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

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

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

[https://devblogs.microsoft.com/oldnewthing/author/oldnewthin...](https://devblogs.microsoft.com/oldnewthing/author/oldnewthing)

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.

------
jmull
Putting it together:

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.

~~~
dragonwriter
> It sounds like Chromium, and hence Electron have had references to some
> private APIs for a while

I wonder if it has been that way in Chromium since Blink was WebKit and
maintained largely by Apple with priority on performance on Apple platforms.

~~~
LeoNatan25
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.

------
Razengan
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:

[https://imgur.com/a/XnCOHUD](https://imgur.com/a/XnCOHUD)

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?

~~~
kristiandupont
>Why the dislike, you ask?

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.

~~~
ajxs
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.

~~~
nl
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.

~~~
ptx
Linux wasn't exactly lacking in text editors, though.

------
fintler
Tracked over at:

[https://github.com/electron/electron/issues/20027](https://github.com/electron/electron/issues/20027)

------
ComputerGuru
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.

------
roblabla
Well, why the hell is electron/chromium using private APIs? That seems like
the real problem here...

~~~
jrochkind1
Another interesting question is how Chrome itself gets approved for the Apple
web store then, right?

[https://apps.apple.com/us/app/google-
chrome/id535886823](https://apps.apple.com/us/app/google-chrome/id535886823)

~~~
AndroidKitKat
That's the mobile version of chrome, which as required of all browsers on iOS,
is using the Safari web renderer under the hood.

~~~
jrochkind1
Aha, you're right!

Is the desktop version of chrome not in the app store? Maybe not.

------
bdcravens
There's no drama here.

The oldest copy of the current app store guidelines I could find goes back to
2014:

[http://web.archive.org/web/20140903022336/https://developer....](http://web.archive.org/web/20140903022336/https://developer.apple.com/app-
store/review/guidelines/)

"2.5 Apps that use non-public APIs will be rejected"

However this has been known dating back to 2010, so I'm sure someone can dig
up an older version of the agreement that says as much.

The fact that Electron is a much easier way to build apps than Swift, Obj-C,
etc has nothing to do with the enforcement of these long-standing rules.

~~~
fortran77
Why does Electron need to use non-public APIs?

~~~
bdcravens
My understanding is that it's Chromium that uses these (ostensibly for
performance), not Electron, but Chromium is a dependency of Electron.

------
FpUser
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.

~~~
lostmyoldone
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?

~~~
ch_sm
I think that’s the sad truth. There are currently no good cross-platform UI
Toolkits.

~~~
zozbot234
wxWidgets. The original toolkit is C++ and rather MFC-like, but there are
bindings to other languages that are quite a bit easier to use.

------
greggman2
It seems mostly reasonable to me for Apple to reject apps that use those
features assuming their own apps have to obey the same rules.

Unfortunately if you're popular they seem to let you bend the rules. AFAICT
Slack has not been rejected and I believe Slack is electron based.

The issue is in Chromium. I have no idea if removing the API usage will be
easy or hard but it's been

[https://github.com/electron/electron/issues/20027](https://github.com/electron/electron/issues/20027)

~~~
lostmyoldone
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.

~~~
saagarjha
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.

------
_coveredInBees
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.

~~~
rdevnull
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.

~~~
z3t4
This is a problem with licensees like MIT. The essential features will be
proprietary.

------
rs23296008n1
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.

Strange times.

------
mrb
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).

~~~
rdevnull
wow glad you noticed :) is latex CSS and I thought it would make the text look
different (it looks like everyone is using Open Sans nowadays :)
[https://github.com/gurugeek/latexcss/blob/master/latex.css](https://github.com/gurugeek/latexcss/blob/master/latex.css)

------
mensetmanusman
Is this an attempt by Apple to increase robustness by reducing dependencies on
unsigned binaries?

~~~
thothamon
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.

~~~
coldcode
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.

~~~
thothamon
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.

------
ghego1
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.

------
therealmarv
Wait. Does this mean Slack will be banned soon? Or are they all using Electron
8?

~~~
rdevnull
I am pretty sure the problem will also be in Electron 8.

------
The_rationalist
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

~~~
ken
Does Slack use private APIs?

~~~
The_rationalist
No electron application use private APIs, it's the embedded chromium that do.

------
haecceity
Why doesn't Apple change their SDK to make their API non linkable?

~~~
paxswill
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.

------
fookitty
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

------
haecceity
Why doesn't Apple change their SDK to make the public APIs non linkable?

~~~
saagarjha
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.)

------
YoannMoinet
I was able to submit my app after an upgrade to Electron 6 with no issue
whatsoever.

Only issue was first with the signature of the app, got fixed with later
updates.

My app is up in the AppStore with latest Electron 6.

------
paulie_a
Hopefully this will happen everywhere. Electron apps are shit. If you don't
want to write a native app. Don't support that platform.

------
peruvian
Probably not a big deal for publishers - most (non-tech) people I know
download Electron apps via their own website e.g. Slack, Notion, etc.

~~~
mikl
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.

------
personjerry
Does this apply to React Native apps?

~~~
ptlu
React Native doesn't use Chromium under the hood, it renders using native
iOS/Android components not a web view like Electron.

------
groovebits
Wonder why they couldn't do the same for the iOS appstore. Like js apps based
in phonegap

~~~
saagarjha
They do, but those apps use WebKit and hence don't rely on private API.

~~~
kitsunesoba
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.

------
nickpeterson
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.

~~~
saagarjha
Apple did not ban this app for being "garbage"–it's not even an iOS/Android
app.

------
jasonmp85
So stop using Electron?

------
rado
Good.

------
flipetty
why not contact Electron for this problem? There must be thousands of people
having this at the moment

~~~
saagarjha
They did:
[https://github.com/electron/electron/issues/20027](https://github.com/electron/electron/issues/20027)

------
paggle
If Apple doesn’t want third party apps calling private APIs why don’t they
simply run third party apps in a sandbox that doesn’t have them exposed?

~~~
saagarjha
Because the private APIs are used by frameworks that are loaded into the same
process as the application.

~~~
paggle
Sorry, can you explain further? I haven't done any mobile development so if
you have some resource I can learn more from I would really appreciate it.

------
kd3
This is absolutely insane. Apple could learn a lot from Microsoft of how to
treat developers. God i miss Steve Ballmer

~~~
scarface74
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?

~~~
kd3
> 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?

That is precisely why I mentioned Microsoft. They have historically gone
through great lengths to keep devs happy.

~~~
scarface74
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.

~~~
kd3
Microsofts failure in mobile has simply been due to the fact that they weren't
able to excite users with hardware. This changed with the Surface line.

~~~
scarface74
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.

[https://sixcolors.com/post/2019/10/apple-results-64b-in-
reve...](https://sixcolors.com/post/2019/10/apple-results-64b-in-revenue-on-
record-services-income/#more)

[https://www.techradar.com/news/microsofts-surface-sales-
keep...](https://www.techradar.com/news/microsofts-surface-sales-keep-getting-
stronger-with-a-21-leap)

------
thefounder
Does anyone use the Mac appstore?

~~~
rdevnull
I think so :) there are several apps that users prefer to install on the apple
store, and even a notarized DMG shows some warnings so..

------
gsich
Good.

------
thrower123
So there goes one of the primary reasons to use Electron...

Cross-platform comparability always promises so much, and falls down in the
implementation.

------
ilaksh
That's what you get for supporting the Apple ecosystem. Its a closed system.

------
natch
The lesson here is write native apps using the preferred native tools of the
platform, and avoid shortcut solutions.

~~~
autoconfig
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.

~~~
robmiller
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.

------
burfog
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.

~~~
scarface74
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.

~~~
burfog
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.

~~~
scarface74
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.

------
vunie
Banning private APIs is absurd. Permanently banning developers for using
private APIs is shear lunacy.

As someone else pointed out, not using private APIs would put some
applications at a disadvantage against first party software:
[https://news.ycombinator.com/item?id=21437673](https://news.ycombinator.com/item?id=21437673)

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.

Monopoly laws need to be updated.

~~~
scarface74
_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.

~~~
vunie
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.

I suggest working on your comprehension skills.

~~~
scarface74
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.

