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

141–150 of 441 posts

Re: Electron apps cannot be submitted to the Apple store

#141

Post by bdcravens »

fortran77 wrote: post #135
bdcravens wrote: post #134

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

Why does Electron need to use non-public APIs?

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

Re: Electron apps cannot be submitted to the Apple store

#143

Post by scarface74 »

vunie wrote: post #138

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

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.

Re: Electron apps cannot be submitted to the Apple store

#144

Post by Fr0styMatt88 »

saagarjha wrote: post #112
creatornator wrote: post #110

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.

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.

Re: Electron apps cannot be submitted to the Apple store

#145

Post by scarface74 »

kd3 wrote: post #142

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

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?

Re: Electron apps cannot be submitted to the Apple store

#146

Post by krainboltgreene »

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…

I uh...Sorry are you mad that an electron application is using ~80mb more than other native applications?

I cannot fathom the indignity required to care about that difference.

Re: Electron apps cannot be submitted to the Apple store

#147

Post by scarface74 »

burfog wrote: post #100

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.

Re: Electron apps cannot be submitted to the Apple store

#148

Post by saagarjha »

Fr0styMatt88 wrote: post #144
saagarjha wrote: post #112

Earlier quoted context omitted.

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, with…

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

Re: Electron apps cannot be submitted to the Apple store

#149

Post by abjKT26nO8 »

creatornator wrote: post #110
saagarjha wrote: post #74

Earlier quoted context omitted.

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

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.

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

Re: Electron apps cannot be submitted to the Apple store

#150

Post by saagarjha »

DarkmSparks wrote: post #136
BillinghamJ wrote: post #85

Earlier quoted context omitted.

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

Is this why so many of the apps on my ipad "need to be updated to work with this version of ios"? and there is no update.

No, that's because they're 32-bit apps, which iOS no longer supports.
Post reply on HN