Live data from Hacker News

Electron apps cannot be submitted to the Apple store

david.dev

271–280 of 441 posts

Re: Electron apps cannot be submitted to the Apple store

#271

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?

Is that a joke? Surely you aren't suggesting that developers should have full knowledge of all transitive dependencies that compose their application stack.

Not full knowledge. But you should know about every single dependency, know what they do and if they're from a trustworthy source. Being able to say with confidence that you aren't installing malware on your customers machines is the least you can do.

On the developer side there's more though, you should know what their release cycles are like, how they manage compatibility, how long they support older releases etc. You don't what your app stuck in a 3 month upgrade cycle just because a transitive dependency needed an update.

There's a reason dependencies are there own form of technical debt and need to be minimized.

Re: Electron apps cannot be submitted to the Apple store

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

It doesn't really matter if it's public or not. The fact is people are using those APIs and there's nothing that can be done about that. Nonchalantly breaking stuff and rejecting applications actively subtracts from the value of their platforms and could alienate developers.

Microsoft had private APIs and data structures too and it didn't stop developers from using them. However, their approach to that was different: they maintained bug compatibility with old software in order to keep stuff working. This is one of the main reasons why Windows remained relevant for so long.

The fact is Apple simply doesn't care about backwards compatibility. It's not just private APIs, public ones are also at risk:

https://lists.apple.com/archives/cocoa-dev/2019/Oct/msg00004...

It's not a new attitude either. Apple has always been like this:

https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

> A lot of developers and engineers don’t agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded.

> The developers of the Macintosh OS at Apple have always been in this camp. It’s why so few applications from the early days of the Macintosh still work.

> For example, a lot of developers used to try to make their Macintosh applications run faster by copying pointers out of the jump table and calling them directly instead of using the interrupt feature of the processor like they were supposed to.

> Even though somewhere in Inside Macintosh, Apple’s official Bible of Macintosh programming, there was a tech note saying “you can’t do this,” they did it, and it worked, and their programs ran faster... until the next version of the OS came out and they didn’t run at all.

Re: Electron apps cannot be submitted to the Apple store

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

> so I don't get breakages on system upgrades or migrations This is hilarious, Apple breaks apps that only use public APIs on virtually every release they do, minor releases, security patches, you name it. Apple CONSTANTLY BREAKS THINGS.

There's no need to shout; breakage in public APIs is nothing compared to private API churn. Plus you can file bugs about the former.

Re: Electron apps cannot be submitted to the Apple store

#274

Earlier quoted context omitted.

So never run Linux?

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

Re: Electron apps cannot be submitted to the Apple store

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

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

Re: Electron apps cannot be submitted to the Apple store

#276

Earlier quoted context omitted.

Who are you going to blame when applications start breaking because Apple removes or changes the functionality of a private function? [1] without warning? When you are writing any software that has a public API you should feel no obligation to change the functionality or completely remove a private method without warning. [1] I refuse to call it a private API. An API is public documentation of the inputs and expected…

Blame the developer? Which is why, when an app breaks on the Mac store or app store, users pound the app with 1-star reviews. Even if the breakage happened from a platform (iOS or MacOs or Android) bug. This is not Apple "watching out" for the developers, no matter how much you spin it

If enough applications break, users are more than likely to blame the "stupid Apple update" rather than their apps.

Re: Electron apps cannot be submitted to the Apple store

#277
post #175

Earlier quoted context omitted.

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?

Sure. Not all private API needs to go into the web renderer.

Re: Electron apps cannot be submitted to the Apple store

#278

Earlier quoted context omitted.

Popular applications often get passes for private API usage.

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

Right, we veered off of that the moment Chrome on iOS was brought up.

Re: Electron apps cannot be submitted to the Apple store

#279

It seems mostly reasonable to me for Apple to reject apps that use those features assuming their own apps have to obey the same rules. Unfortunately if you're popular they seem to let you bend the rules. AFAICT Slack has not been rejected and I believe Slack is electron based. The issue is in Chromium. I have no idea if removing the API usage will be easy or hard but it's been https://github.com/electron/electron/iss…

Their own apps certainly isn't following the same rules, newer have, and probably never will unless forced by law. There probably are, and have been quite a feq things on any iPhone/Pad that only Apple apps can do. Although I don't have my ear that close to the ground, they seem to get more and more aggressive about protecting their turf in any way they can.

Apple's apps have never claimed to follow the App Store Guidelines. The issue at hand here is when third-party developers are selectively granted exceptions.
Post reply on HN