Live data from Hacker News

Electron apps cannot be submitted to the Apple store

david.dev

281–290 of 441 posts

Re: Electron apps cannot be submitted to the Apple store

#281

Earlier quoted context omitted.

Apple wants to own the user's machine. They want to make it so their computers run only the software they approve. This is already true for iOS and it's only a matter of time before it also becomes true for macOS. It's the opposite of a free system. Giving up software freedom for "ease of use" seemed like a fine deal at first but then Apple started making decisions that don't quite align with what neither users not d…

Two stereotypes, each about a decade old. The rumors about the impending doom of freedom on MacOS is as old as Mac OS X. At this point, it's the slowest conspiracy in history. People don't prefer MacOS because they are idiots who need "ease of use". There just is no other system developed with something approaching taste. Windows is for those people that put plastic covers over their furniture, ruining in the process…

Apple is the company that already has a completely locked down mobile OS and is actively nurturing an app store for the macOS. I wouldn't bet on it running unsigned code forever.

Re: Electron apps cannot be submitted to the Apple store

#282
post #20
post #8

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

Yeah, when you're coding for a cpu, write in assembly only. Write a separate copy of your app for iphone and macOS because one of those is arm and one isn't. Don't use anything that provides portability like C or Objective-C, that's not really "native" to the CPU architecture. .. I know that sounds silly, but you're advocating for that one layer up. It's a very good analogy I think. People use electron in order to "c…

Compilers can often outperform handwritten assembly.

Re: Electron apps cannot be submitted to the Apple store

#283
post #268
post #203

Earlier quoted context omitted.

As a user I think Electron is great. It means many more apps have a Mac version. Compare to games, where Electron typically isn’t feasible, and observe how many games don’t have a Mac version. A little extra memory usage is fine by me. I can understand how people disagree, and that’s fine, just don’t use Electron apps. No need to ban them from the platform.

Yes, this is the thing. The option isn't electron vs native, it's electron vs nothing.

Often, nothing is better than the Electron equivalent.

Case in point, if I run Slack in Safari, it runs better than the electron version. Functionally, it’s identical, except the scrolling is now native and feels a bit better integrated in macOS. So what’s the point?

Re: Electron apps cannot be submitted to the Apple store

#284

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.

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

With NPM as an example to fully know every dependency is a highly time-intensive and complicated task due to following:

* you can't be sure code in package is same you see on github as npm doesn't do signatures

* code already in node_modules is usually minified and obfuscated

So only real way to be sure is to make own repository, copy every dependency, check code, build own packages and only use packages from your repo. Repeat process when versions are updated.

So to answer your question, yes, 99% of apps, they don't know.

Re: Electron apps cannot be submitted to the Apple store

#285

Earlier quoted context omitted.

It's funny how the general consensus on here is against Microsoft's abuse of private APIs in Windows to help Word and DOS against WordPerfect and DrDOS, 20+ years ago. But Apple doing it right now in a much worse way is considered acceptable and defendable.

I don't think anyone here considers Apple's abuse of private APIs vs developers an ok thing. I will never subject myself to their app store if I can help it.

I think it's more a case of people just being unaware. They might have an idea that this is going on, but because they've never run into it it's not something that's a priority. I'd even wager that the vast majority of non-Americans here don't use Apple hardware.

Re: Electron apps cannot be submitted to the Apple store

#286

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?

I think that ship sailed a long time ago. Right now I'm building an app with Google's mobile toolkit, Flutter. Flutter itself is a few hundred kloc. And on top of that, I'm using a bunch of libraries; I wouldn't be shocked if it were the same amount of code again. Assuming I can properly code review a few hundred lines per hour, reviewing all that will take me a year or so. Which is maybe 5x what it will take me to s…

You are missing the fact that dependency tree is constantly changing as dependencies get bug fixes and security patches, so in the middle of your review you will be forced to re-check.

Unless you are willing to freeze whole tree until review is done but then you don't get bug fixes and security updates for period of initial review + review of updated packages.

Re: Electron apps cannot be submitted to the Apple store

#287
post #185

Earlier quoted context omitted.

As opposed to "here are some APIs that you can't use but we can, neener neener"?

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.

Re: Electron apps cannot be submitted to the Apple store

#288
While this decision looks rational and technically solid on the surface, it makes the Mac platform, and in particular the Mac app store, even less appealing to developers.

Here on HN we hear constantly of developers dropping out of the Mac app store. If we cobsider the premium (justified or not) of apple laptops, and thus the relatively limited audience they target, we can easily predict a steeper decline in interest to develop for the Mac platform.

Having said that, we should also consider that Electron is indirectly owned by Microsoft, and is based on tech by Google. So I don't see much incentive on their part to fix this quickly, and one could even argue that they have some interest in not fixing at all this.

Re: Electron apps cannot be submitted to the Apple store

#289

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.

This is a problem with licensees like MIT. The essential features will be proprietary.

Re: Electron apps cannot be submitted to the Apple store

#290

Earlier quoted context omitted.

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

what if the function calls are generated with macros or something?

Isn't it literally the responsibility of the developer to figure it out, instead of just ignoring it because it's potentially hard?
Post reply on HN