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

331–340 of 441 posts

Re: Electron apps cannot be submitted to the Apple store

#331

Post by simonh »

throwGuardian wrote: post #197
scarface74 wrote: post #168

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

It's Apple watching out for users.

Re: Electron apps cannot be submitted to the Apple store

#332

Post by simonh »

arvinsim wrote: post #153
throwGuardian wrote: post #120

Earlier quoted context omitted.

You must be chugging the koolaid to believe developers LOVE Apple's policies, or enjoy getting their hard-work rejected by a bot, or getting shamed by an overzealous Apple employee on HN. Developers are homogeneously unappreciative of Apple's treatment of them. They just don't have any leverage, or opportunity to negotiate

Doesn't help that developers still buy their machines. Apple will only listen if it hits their bottom line.

The problem is that flakey software on their platform, that breaks on OS updates and bug fixes annoys users, and thus also hits Apple's bottom line.

Re: Electron apps cannot be submitted to the Apple store

#333

Post by vkoskiv »

matheusmoreira wrote: post #281
matt4077 wrote: post #263

Earlier quoted context omitted.

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.

Apple has explicitly stated in WWDC sessions that there will always be a way to run unsigned code if you want.

Re: Electron apps cannot be submitted to the Apple store

#334

Post by scarface74 »

analog31 wrote: post #210
kjksf wrote: post #61

Earlier quoted context omitted.

How short are memories. I remember how Microsoft was vilified for supposedly having secret Windows APIs that allowed Microsoft apps to get better performance. That was mostly made up and even if such APIs existed, any program could have used it. Even at the height of corporate arrogance Microsoft didn't dream of banning developers for using undocumented APIs. Apple seems intent on becoming more evil than Microsoft ev…

From what I recall, this practice goes back to the original 68k Apple Mac. The prehistory is that developers for the Apple ][ had access to third party documentation, and made extensive use of unofficial system variables and entry points. The result was that it became impossible for Apple to update their own system without breaking popular apps and getting blamed for doing so. It turned Apple ][ technology into a dea…

The Mac was intended to be a much more tightly controlled developer environment. And it came out at a time when there was still a lot of debate over the right way to develop a computing platform.

This is very much not true. The entire extension mechanism on Macs was about using undocumented hacks to add functionality. Apple has no control over what a third party app could do through the Classic MacOS era from 1984-1999.

In fact, it wasn’t until around 2011-2012 when Apple started having sandboxing and that was only for Mac App Store apps. It was even later that they had system integrity protection. Even today, you can basically do what you want to on the Mac except for having unsigned kernel extensions.

Re: Electron apps cannot be submitted to the Apple store

#335

Post by scarface74 »

BoorishBears wrote: post #326
saagarjha wrote: post #275

Earlier quoted context omitted.

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

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

Re: Electron apps cannot be submitted to the Apple store

#336

Post by scarface74 »

shafiqissani wrote: post #313
kjksf wrote: post #61

Earlier quoted context omitted.

How short are memories. I remember how Microsoft was vilified for supposedly having secret Windows APIs that allowed Microsoft apps to get better performance. That was mostly made up and even if such APIs existed, any program could have used it. Even at the height of corporate arrogance Microsoft didn't dream of banning developers for using undocumented APIs. Apple seems intent on becoming more evil than Microsoft ev…

I trust the EU with these matters, more so than any other government.

So you expect the EU to not allow Apple to ban the use of private methods? Are they going to also ban Apple from not changing them?

What happens when Apple updates the operating system and starts throwing up a big dialog box every time an app accessed a private API that says “the publisher of this app needs to update their poorly written app.”?

What next? Is the EU going to also ban language makers from having public and private functions?

Re: Electron apps cannot be submitted to the Apple store

#337

Post by nl »

ivan_gammel wrote: post #244
root_axis wrote: post #224

Earlier quoted context omitted.

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

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]) and submitted fixes for them all.

That was a huge amount of work, because they all used random version of different XML parsers, all of which required external entity processing to be turned off in different ways.

None of the authors of the packages were aware of the issue, and as far I could determine at the time I was the only person in the entire Java ecosystem who knew all the different parsers arguments.

This was a critical, remotely exploitable vulnerability. I'd never claim to know about it now, and it was only for a few weeks back in 2006 that I really knew it then.

So when you say you "know" all the dependencies in your stack, what do you mean exactly?

[1] https://rometools.jira.com/browse/ROME-46

Re: Electron apps cannot be submitted to the Apple store

#338

Post by nl »

ajxs wrote: post #241
kristiandupont wrote: post #184

Earlier quoted context omitted.

>Why the dislike, you ask? Nobody is asking that, there's a crowd in here that restates the same three points about memory, performance and native UI about once a week. I dislike waste, I have written assembly code for tiny processors. And yet, I run several Electron apps on my 8gb 2013 Macbook Air and it runs fine, especially VSCode. I am picking that over my previous choice which was native (vim), because I think i…

Not every developer runs a Macbook. Like many others for my laptop I use Linux running on a cheap ThinkPad with a quarter of the specs of the one you mentioned. ( I could afford to buy an overpriced Macbook, but I like my rugged $100 ThinkPad. ) As I stated elsewhere in this thread, vscode absolutely chews up my battery power. That's a practical concern. If I run several Electron apps on my laptop I'd be lucky to get…

As someone who spent years complaining about the lack of cross-platform apps that I could run on Linux, I'm grateful everyday for Electron and for MS for using it for VS.Code.

The fact that it works the same on OSX and Linux is even better.

Re: Electron apps cannot be submitted to the Apple store

#339

Post by josefx »

root_axis wrote: post #224
Scapeghost wrote: post #193

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.

For licensing reasons alone, almost got hit by one dependency switching from LGPL 2 to GPL 3 and one project we bought dropped dead once someone went over its dependency tree and noticed the mess of highly incompatible licenses, it would have taken years to get to a point where we could legally publish anything. Not knowing about all of your dependencies is a liability.

Re: Electron apps cannot be submitted to the Apple store

#340

Post by kalleboo »

floatingatoll wrote: post #79
freehunter wrote: post #45

Earlier quoted context omitted.

Because Electron developers might say "we fixed it" and the app developer might resubmit based on that and now they're banned due to a mistake made by an upstream dependency. It's not like this app developer is intentionally using private APIs. "Resubmitting the same thing and hoping that it doesn't get caught" seems to be a strawman.

That resubmit approach ways used by at least one camera app years ago who masked their private API usage to secretly include a volume button “take photo” feature. They were told to knock it off (and Apple also added that option to the API at a later date). Between that and the folks who hid MAME in an app or whatever, I think Apple is not simply constructing straw men when they warn that attempts to circumvent the sp…

Camera+ didn't use a hidden API - they just used a standard system volume control but placed it offscreen and monitored if the volume changed (and then lower it imperceptibly if you hit 100%). And Apple has still not added an API to do this officially, last I checked all third party camera apps use a similar hack.

What changed was just the interpretation of the app store rules - the rules said something like "you're not allowed to use hardware buttons in a non-standard way". Once they added the volume shutter feature to the system camera, now it's not a non-standard way and it's not against the rules.

Post reply on HN