Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Electron apps cannot be submitted to the Apple store

david.dev

Post reply on HN
Print view View original

31–40 of 441 posts

Re: Electron apps cannot be submitted to the Apple store

#31

Post by skymt »

roblabla wrote: post #3

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

I started searching for the private identifiers listed in the blog post and ran across this document describing Chromium's Mac compositor:

https://www.chromium.org/developers/design-documents/chromiu...

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.

Re: Electron apps cannot be submitted to the Apple store

#32

Post by plorkyeran »

thomascgalvin wrote: post #22

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…

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.

Re: Electron apps cannot be submitted to the Apple store

#33

Post by thothamon »

mensetmanusman wrote: post #2

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

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.

Re: Electron apps cannot be submitted to the Apple store

#35

Post by duskwuff »

jmull wrote: post #21

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 developer…

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.

[1]: https://github.com/electron/electron/issues/20027

Re: Electron apps cannot be submitted to the Apple store

#36

Post by partiallypro »

throwGuardian wrote: post #24
outworlder wrote: post #11

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

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.

Apple just rebuilds any popular app and makes it first party anyhow. At some point most developers will stop bothering just for that.

Re: Electron apps cannot be submitted to the Apple store

#38

Post by ajxs »

codedokode wrote: post #29
Razengan wrote: post #18

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 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 (bes…

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…

Even that's low. Here's my result of running pmap on an open vscode process. "total 1046516K"

Yikes.

Re: Electron apps cannot be submitted to the Apple store

#39

Post by dragonwriter »

jmull wrote: post #21

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 developer…

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

Re: Electron apps cannot be submitted to the Apple store

#40

Post by albru123 »

plorkyeran wrote: post #32
thomascgalvin wrote: post #22

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…

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.

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.
Post reply on HN