Live data from Hacker News

Electron apps cannot be submitted to the Apple store

david.dev

211–220 of 441 posts

Re: Electron apps cannot be submitted to the Apple store

#211

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…

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

Re: Electron apps cannot be submitted to the Apple store

#212

Earlier quoted context omitted.

In the article, Apple support explained how he might check whether the private APIs are still being called. "It's not like this app developer is intentionally using private APIs" No, he is just incompetent.

Please don't attack people like this. I'm fairly sure they're here reading the comments, and even if they weren't, you don't need to call them things.

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?

Re: Electron apps cannot be submitted to the Apple store

#213

Earlier quoted context omitted.

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.

The developer chose to use Electron, hence the entire endeavor is in their control.

Re: Electron apps cannot be submitted to the Apple store

#216
post #187

Earlier quoted context omitted.

You can, and the rejection email even provides instructions for how to do so.

And where will you get the current list of all forbidden functions/APIs, not just those for this specific case with Electron?

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.

Re: Electron apps cannot be submitted to the Apple store

#217
post #178

Earlier quoted context omitted.

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

So never run Linux?

Re: Electron apps cannot be submitted to the Apple store

#218

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

It would be a PR disaster for Apple and the MAS to block Slack from updating its Electron app.

Re: Electron apps cannot be submitted to the Apple store

#219

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…

> why, as a user, should I pick an Electron app over native alternatives?

I'd pick the native version every time, but there is no native VSCode, Atom, Slack, or Whatsapp.

I use Sublime because it's native and I don't use too many plugins but a lot of people prefer VSCode.

Re: Electron apps cannot be submitted to the Apple store

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

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.

Post reply on HN