Live data from Hacker News

Electron apps cannot be submitted to the Apple store

david.dev

341–350 of 441 posts

Re: Electron apps cannot be submitted to the Apple store

#342
post #321

Earlier quoted context omitted.

Just like `sun.misc.Unsafe` was around for ages until it wasn't. [0] [0] https://blog.dripstat.com/removal-of-sun-misc-unsafe-a-disas...

I fail to see how this is anything but the perfect case for allowing internal API usage. There was no other way to do what Unsafe did, so people used it for years . A lot of people used it to do useful things in Java. So much stuff that this article is saying it literally became indispensable for much of what Java is used for. The ecosystem was better for it. Sun says we want to remove it. So Sun can provide alternat…

The usage of Unsafe was never encouraged, it is a problem that Sun never provided a public API with similar features but relying on a private API is what caused the issue of breaking changes in the future, something that every Java developer was well aware that could happen.

Yes, I agree that the problem was that Sun didn't provide a public API for it, at the same time developers breaking the contract (instead of pushing for it to be moved to a `java.` namespace) shouldn't be excused and embraced, it causes bigger issues to the overall design of the platform when then you have to be maintaining an API for the sake of usage, the same cruft that Win32 suffers for its whole existence, and which made developing on Win32 a pain in the ass for a lot of people, for the sake of not breaking some twisted way that a major application used it.

Re: Electron apps cannot be submitted to the Apple store

#344
post #337

Earlier quoted context omitted.

as CTO I know all the dependencies in the application stack of our company and I require developers to have sufficient understanding of their purpose, licensing model etc. There are tools to simplify this task. It’s much harder to do for TypeScript than for Java, mostly because NPM ecosystem is a huge pile of junk, but it’s still important part of developer's job.

as CTO I know all the dependencies in the application stack of our company I'm a few years out of the Java world these days, but you've vetted every line in every one of those Apache commons projects that gets pulled in? Because that's a lot of reading... Over 10 years ago I went through every single Java RSS parsing library and all their forks (I think there were 5) to fix Xml eXternal Entity (XXE) attacks (eg[1]) a…

We barely have any of the Apache commons dependencies - in most cases use of them is not justified in modern Java. If there’s anything like that we are ready to support such dependency on source code level, patching and setting up own build pipeline if necessary. Free software cannot be trusted if you are not ready to own it. Commercial software cannot be trusted either, but there are other ways to manage the risks there.

Re: Electron apps cannot be submitted to the Apple store

#345

Earlier quoted context omitted.

as CTO I know all the dependencies in the application stack of our company and I require developers to have sufficient understanding of their purpose, licensing model etc. There are tools to simplify this task. It’s much harder to do for TypeScript than for Java, mostly because NPM ecosystem is a huge pile of junk, but it’s still important part of developer's job.

> as CTO I know all the dependencies in the application stack of our company You know all of the transitive dependencies in the application stack of your company? Out of curiosity, what is the ballpark figure on the total number of transitive dependencies in your application?

Hundreds, mostly because of the JS nonsense. Our Java microservices are lean and strictly controlled.

Re: Electron apps cannot be submitted to the Apple store

#346

Earlier quoted context omitted.

What are you talking about? They literally do it regularly, public APIs get deprecated then removed and consumers have to rewrite their code. This article is literally about Apple making 3rd parties rewrite their code just to access the app store. And before you or someone else points out "Firefox is directly distributed", I say: Exactly. So they can use the internal APIs as they please, then Apple can remove then as…

Apple rarely removes public APIs without any deprecation warning that appears when you compile your app at least one version ahead of time.

Apple often straight up breaks the implementations of public APIs leaving developers scrambling to fix them. See modals in iOS 13, or title bar styling.

I work at a development agency and on both macOS and iOS every release is a race to figure out which breaking changes have been sprung by Apple (including crashes caused by silent changes in behavior of existing APIs, people have had apps rejected for breaking on pre-general release OS versions when we didn't even have the tools to test them yet)

Re: Electron apps cannot be submitted to the Apple store

#347
post #21

Putting it together: This is about submitting an app to the Mac App Store. Apple has had a requirement that apps not use private APIs for a while. It sounds like Chromium, and hence Electron have had references to some private APIs for a while, but Apple has only recently started enforcing their requirement. (Or perhaps only recently started scanning for these particular APIs.) It’s a little painful for the developer…

You are missing that Chromium uses these APIs in the first place because they offer better performance or necessary flexibility. Since Google doesn't distribute Chrome on the Mac App store, chances are they don't care about "fixing" Chromium to not use them.

So, feel free to use Electron, just understand that your so easy to develop desktop app now hinges on the ability of a few unpaid developers (that's probably not you, or the "full-stack" people at Slack) to continuously keep track with the Chromium source and maintain their no doubt massive patches to its code to remove use of these private APIs.

Re: Electron apps cannot be submitted to the Apple store

#348
post #30

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…

While working on a project that uses a service built in Typescript I've been using vscode. I was wondering what was wrong with my laptop's battery, it had gone from lasting around 2-3 hours unplugged doing reasonably intensive to lasting around 40 minutes. As soon as I stopped using vscode the battery life went back to what I'd normally expect. It's honestly outrageous that applications built on Electron strangle you…

I have been very happy developing a typescript project for work in nvim and coc.nvim.

Re: Electron apps cannot be submitted to the Apple store

#349

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…

Getting out of iOS development and back into web dev was the best career decision I ever made. I feel like I escaped an abusive relationship. So much of what's wrong with computing and tech right now stems directly or indirectly from the culture at Apple.

Grass is always greener :). After years of webdev and js madness I've found a recent iOS development project to be a welcome break.

Re: Electron apps cannot be submitted to the Apple store

#350
post #94

On one hand I am not fond of Apple in general at all. On the other hand when I see developers using Electron as a GUI layer I think it is pure insanity. It is an absolute resource and performance hog that in my opinion has no place outside of browsers context.

I'm an old dinosaur who used to do GUI development way back, and while I completely agree that Electron is a beast, I also haven't seen almost reasonably cross platform app toolkit that isn't either ugly, or worse than Electron. So what are the options I am missing?

I think that’s the sad truth. There are currently no good cross-platform UI Toolkits.
Post reply on HN