Electron apps cannot be submitted to the Apple store • Hacker News Board

Re: Electron apps cannot be submitted to the Apple store

#171

Post by scarface74 » Mon, Nov 04, 2019, 2:02 AM UTC

duskwuff wrote: post #70

thothamon wrote: post #33

Earlier quoted context omitted.

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

I think the intent of these rules is (and generally has been) to allow Apple to classify APIs into "public" and "private" categories, where the public APIs are documented, and will not change or be removed without plenty of notice, and the private APIs aren't any of those things. In some cases, private APIs are used as implementation details of public APIs. For example, the symbol "NSNextStepFrame" sounds like it mig…

Having public and private methods has been an industry standard forever. As has the understanding that you don’t depend on private methods.

Re: Electron apps cannot be submitted to the Apple store

#172

Post by rdevnull » Mon, Nov 04, 2019, 2:04 AM UTC

The_rationalist wrote: post #163

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

5 doesn't work either (others having the same issue in GitHub even got rejected with electron 3). Slack was updated a few days ago (I also had no such an error then). Also let's not forget that Slack is #1 in the App Store for the category business so is certainly not treated like a small app from an unknown developer ;)

Re: Electron apps cannot be submitted to the Apple store

#173

Post by babesh » Mon, Nov 04, 2019, 2:05 AM UTC

kjksf wrote: post #61

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.

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…

Microsoft was vilified for many anticompetitive practices.

I worked on an app that competed with a Microsoft app. Our app was actually winning in the marketplace. One year they release a new version of their app with some really cool features at the same time as the latest Windows release. Those features were based on some new APIs released with that version of Windows. Just gave their app a year leap.

Another evil practice was forcing PC makers to pay for a Windows license for each computer sold irrespective of whether the computer shipped with Windows.

Microsoft was pretty evil.

Re: Electron apps cannot be submitted to the Apple store

#174

Post by aaronbrager » Mon, Nov 04, 2019, 2:05 AM UTC

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…

Yes, as indicated in the OP you can use otool to see which private APIs are being called.

Re: Electron apps cannot be submitted to the Apple store

#175

Post by orf » Mon, Nov 04, 2019, 2:08 AM UTC

saagarjha wrote: post #166

orf wrote: post #165

Earlier quoted context omitted.

Then why suggest that the reason Chrome is approved is because they sneak in private API usage?

Popular applications often get passes for private API usage.

Private APIs they don’t need to use because it’s just a wrapper for Safari, as you’re aware?

Re: Electron apps cannot be submitted to the Apple store

#176

Post by rdevnull » Mon, Nov 04, 2019, 2:08 AM UTC

_coveredInBees wrote: post #161

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.

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.

Re: Electron apps cannot be submitted to the Apple store

#177

Post by bdcravens » Mon, Nov 04, 2019, 2:11 AM UTC

saagarjha wrote: post #166

orf wrote: post #165

Earlier quoted context omitted.

Then why suggest that the reason Chrome is approved is because they sneak in private API usage?

Popular applications often get passes for private API usage.

Has nothing to do with the article, which is about Electron (and by extension, Chromium)

Re: Electron apps cannot be submitted to the Apple store

#178

Post by geofft » Mon, Nov 04, 2019, 2:12 AM UTC

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.

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 business relationship with, it's a major library from a known author that other apps on the store are also using, etc.). Otherwise you're being irresponsible. If you don't have the time to look at the library, don't use it.

Re: Electron apps cannot be submitted to the Apple store

#179

Post by burfog » Mon, Nov 04, 2019, 2:12 AM UTC

scarface74 wrote: post #147

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

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.

Re: Electron apps cannot be submitted to the Apple store

#180

Post by babesh » Mon, Nov 04, 2019, 2:12 AM UTC

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…

Also letting an app use those private APIs can be a security hole.