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

321–330 of 441 posts

Re: Electron apps cannot be submitted to the Apple store

#321

Post by piva00 »

BoorishBears wrote: post #233
ptlu wrote: post #226

Earlier quoted context omitted.

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…

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

Re: Electron apps cannot be submitted to the Apple store

#322

Post by geofft »

tracker1 wrote: post #217
geofft wrote: post #178

Earlier quoted context omitted.

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…

So never run Linux?

I get Linux from people I trust to verify source code and the source code of dependencies and to push back against dependency sprawl (Debian, in my case, and I'm on debian-devel and I happen to see every email sent for every new package; there's an overhead there). Others get Linux from a vendor they have a commercial relationship with (Red Hat, Canonical, even Oracle, etc.)

So, can you expand on why you think one should never run Linux?

Re: Electron apps cannot be submitted to the Apple store

#323

Post by geofft »

tracker1 wrote: post #274
rmgraham wrote: post #255

Earlier quoted context omitted.

Or only run Linux? * * (any source available OS)

GP says not to run anything you haven't looked at yourself for the most part, paraphrasing. I doubt anyone has self audited all the software and drivers going into a desktop Linux distro. The point is, at some point you stop digging

> GP says not to run anything you haven't looked at yourself for the most part, paraphrasing.

That is a highly inaccurate paraphrase of what I said. You can tell it's inaccurate because I'm specifically suggesting that end users should be able to trust apps on the App Store without auditing the apps ourselves, as long as we trust the app authors, and that app authors should bear responsibility for what they redistribute.

Re: Electron apps cannot be submitted to the Apple store

#324

Post by ichicoro »

dingo_bat wrote: post #206
saagarjha wrote: post #150

Earlier quoted context omitted.

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

Which is the same thing.

It isn't? There's a difference between dropping 32bit libraries from your OS (after a lot of time in which Apple clearly said "we will drop support!") and banning for using unauthorized APIs inside the MAS.

Re: Electron apps cannot be submitted to the Apple store

#325

Post by vbezhenar »

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.

Apparently Apple silently whitelisted Electron for some time.

Re: Electron apps cannot be submitted to the Apple store

#326

Post by BoorishBears »

saagarjha wrote: post #275
BoorishBears wrote: post #233

Earlier quoted context omitted.

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…

> 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. When push comes to shove, Apple can tell those teams to rewrite their code. It can't do that to the authors of, say, Firefox.

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 they please and break Firrfox and... make Firefox rewrite their code.

Apple is not Microsoft. Apple does not work towards not breaking existing software, they actively break it with each macOS and iOS release, sometimes not even releasing the tools needed to fix them before general releases

Making an internal API people are already using public literally does nothing but optionally allow Apple to give a heads up about deprecation. Apple could literally slap "public" on every internal API, break them every release, and the result would be no different than the current status quo because of the overarching rule of App Store admissions... your app has to work, regardless of if an "internal" or "public" API is changed.

Honestly for most developers that wouldn't seem to different from the current situation: see iOS 13 where basic UILabel stuff was breaking.

And again, apps that don't use the App Store already use internal APIs and can already break all the time.

Re: Electron apps cannot be submitted to the Apple store

#327

Post by BoorishBears »

piva00 wrote: post #321
BoorishBears wrote: post #233

Earlier quoted context omitted.

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…

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 alternatives that do the same job, or find that it generates so much value that it shouldn't be removed, or remove it and leave people literally exactly where they'd be if it never existed if there's no other way to do what it does. People would gnash their teeth, but the message sent is "Java was never the right tool for the job so we don't want you as a user."

And the article rightly points out, Sun was removing it for the sake of removing it. Having a bad engineering structure where that handwavy rant about Unsafe can justify removing a useful feature has nothing to do with internal vs public APIs.

Re: Electron apps cannot be submitted to the Apple store

#328

Post by moksly »

cageface wrote: post #209
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…

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.

I work in public digitisation and while we don’t build the apps, we’re now required to publish them if we want our name as the publisher. So I’ve had the pleasure of setting up our development account and it’s easily the works service I’ve ever had to go through, and we operate 300 different IT systems, some are old terminal systems that run on mainframe.

I’m not sure why the process was so complicated either. A couple of steps involved Apple calling me, and my superior, to verify that we were real. Except they didn’t actually verify that, because it was a simple conversation and I could have just lied with a buddy of mine... Even adding developers from our suppliers was a tedious process, and of course Apple has no way of integrating with our IDM or local security setups.

They sure are lucky to have a monopoly on iOS devices.

Re: Electron apps cannot be submitted to the Apple store

#329

Post by BoorishBears »

philwelch wrote: post #257
BoorishBears wrote: post #47

Earlier quoted context omitted.

How is it going to make customers unhappy if your app isn't using the features? Apple is within their rights here, but please, let's not pretend this is about user experience. It's about the Apple machine doing what it wants, and rolling over who it wants, because it can. That would explain why Apple developer relations (read: humans) had previously backpedalled after the same rejection in the past: https://github.co…

It’s more of a general point that if your application is buggy, the customer isn’t going to give a damn whether the bug is in your code or in somebody else’s code.

And? That's exactly why internal APIs should be allowed.

The problem isn't the usage of an internal API, the problem is the breaking of an internal API.

Which is already covered by App Store testing and guidelines which already require your app isn't a broken mess.

Re: Electron apps cannot be submitted to the Apple store

#330

Post by swiley »

lacker wrote: post #203
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…

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.

Most decent apps build fine on BSD, electron is for closed crap with bad GUIs.
Post reply on HN