Live data from Hacker News

Electron apps cannot be submitted to the Apple store

david.dev

311–320 of 441 posts

Re: Electron apps cannot be submitted to the Apple store

#311
post #8

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

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

Sad to see how putting effort to learn is considered "elitist".

Re: Electron apps cannot be submitted to the Apple store

#312
post #3

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

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.

https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...

Re: Electron apps cannot be submitted to the Apple store

#313
post #61

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

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

I trust the EU with these matters, more so than any other government.

Re: Electron apps cannot be submitted to the Apple store

#314
post #271

Earlier quoted context omitted.

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

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…

> outside of specialized/embedded systems.

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.

Re: Electron apps cannot be submitted to the Apple store

#315

Earlier quoted context omitted.

How exactly?

I would assume that a quick grep through your project for the symbols mentioned would tell you where the issue is.

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.

Re: Electron apps cannot be submitted to the Apple store

#317
post #118

Earlier quoted context omitted.

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.

> They do not ban you for removing some uses of private APIs, but missing others and resubmitting. Maybe not -- maybe you know something about how Apple operates. But clearly they ARE sending responses threatening to do exactly that.

They can ban you for absolutely any reason whatsoever. They can ban you for using the number "4" in your code.

They don't, though. And we trust them not to, because it is not reasonable behaviour and it would absolutely not make sense for them to do this.

This is the same.

Re: Electron apps cannot be submitted to the Apple store

#318

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

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

I do know just that for apps I ship.

I will never in a million year ship anything on, for instance, node.js, for exactly this reason.

Re: Electron apps cannot be submitted to the Apple store

#319
post #185

Earlier quoted context omitted.

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…

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

[0] https://blog.dripstat.com/removal-of-sun-misc-unsafe-a-disas...

Re: Electron apps cannot be submitted to the Apple store

#320
post #42

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.

"use or conceal" "use" If this was "don't conceal or we'll ban you for life", it would be somewhat understandable. But it's "use or we'll ban you for life" which is just insane. Apple is at the height of their arrogance towards developers.

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.

Post reply on HN