Live data from Hacker News

Electron apps cannot be submitted to the Apple store

david.dev

231–240 of 441 posts

Re: Electron apps cannot be submitted to the Apple store

#231

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?

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 ship an MVP.

Re: Electron apps cannot be submitted to the Apple store

#233
post #226

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…

As a user of macOS, I want developers who makes apps to use public APIs that will be supported so I don't get breakages on system upgrades or migrations.

As a user of macOS, why don't you put the onus on Apple to not artificially limit what developers can offer you without it breaking on upgrades and migrations?

Some of the private APIs being used have been stable for generations and are clear improvements in one way or another over the publicly available APIs (like CAContext stuff). I mean a modern OS is not like a library you stick up on NPM and hope no one tries to use internal methods that you'll end up having to support. There are so many desperate teams working on OSX and the applications from Apple that use these APIs, it's not like backwards compatibility, documentation, and most of the issues public APIs face aren't already an issue that has to be tackled.

Apple uses these APIs to make features no one can fairly compete with, which is detrimental to you, as a user, and to external developers. Imagine if any app could use APIs like the ones that Apple Music uses to have tight integration with Siri, or that Apple Maps uses to show on your lockscreen.

Re: Electron apps cannot be submitted to the Apple store

#234

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…

What a ridiculous question... why would you not want the option to download Electron apps through the app store?

Not owning an iPhone, I don't have a horse in the race, but if company X is going to make a client for their service, and for whatever reason you need to use their client, if they are not allowed to use Electron, then they will use a different toolkit. If you don't like Electron apps, then this is a win for you personally. Too many services can only be accessed with the official app, which means it's not like you can just download the "not made with electron" version.

Re: Electron apps cannot be submitted to the Apple store

#235

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…

57 MB. The horror. How will you survive. Is there a software engineering equivalent to "ok boomer"? Seems appropriate here. I can't wait until people who think MBs of memory usage matter to retire/stop hanging out on the Internet...

We used to joke about EMACS being Eight Megs And Constantly Swapping

Re: Electron apps cannot be submitted to the Apple store

#236

Earlier quoted context omitted.

> and avoid shortcut solutions and then the app is never written

Pretty much. Back when apps were native to the platform they would be windows only. It is insane to require every app developer to have to put in 3x the work to rebuild the app for every single platform using its native tools. I would rather have one app that is 3x better and works everywhere. We just need to solve the massive memory issues with electron.

The memory issues isn’t Electron’s fault; It’s Chromium’s

Re: Electron apps cannot be submitted to the Apple store

#237
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…

I'm a developer, and knowing how this is the default is not something I particularly like, but it's really only in the most security/mission critical code that dependencies get thoroughly wetted.

You can fully expect that less then 1% of the apps in any app store has a transitive dependency chain that is fully known and understood by the author to any meaningful extent.

Most of that code is however understood by someone, although not necessarily the app developer. The sandboxing and app permission dialogue boxes are unfortunately a critical part of the defense against malicious code, although not a perfect one by any stretch of the imagination.

Re: Electron apps cannot be submitted to the Apple store

#239

Earlier quoted context omitted.

Have you never run maven, sbt, gradle on a Java project, or PHP compose or .. anything in node? There are so. Many. Dependencies in some of the frameworks people commonly use. It can get pretty insane. We all remember left-pad, right?

Lack of knowledge of your dependency tree isn't really an excuse here. If you're submitting your application to an App Store -- where one of the express purposes is that customers know the application is safe -- then having an unknown dependency is not really a good argument.

How are you sure that your code gets compiled properly? Do you read the assembly generated for the processor and the source code for your compiler?

Are you sure that your machine code gets run properly? Do you test the CPU hardware and all the logical gates and whatnot so that they respond to the schemes and it passes the electric current properly?

Like xkcd 378, we could follow this logic quite deep. At some point you just have to trust, or at least assume that something is going to work, without properly verifying it yourself.

Smarter people than me have essentially dedicated their life to some extremely specific area of computing. It's not reasonable to assume that I could and should deep-dive into every possible nook and cranny just in order to build an application. I already have to do a whole lot of assumptions because of my hardware used for development, my OS and software tools like my IDE, task runners and yes, external libraries.

Re: Electron apps cannot be submitted to the Apple store

#240

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…

> It's also completely unsurprising. Apple has no love nor concern for their developers anymore. It used to be the premier development platform in the world. Now it's ... I don't even know anymore.

When has Apple ever been developer friendly?

Their ecosystem always had more money for app developers, but I can't think of any point in time when developers weren't shouting to anyone who will listen about Apple's rules.

Post reply on HN