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

351–360 of 441 posts

Re: Electron apps cannot be submitted to the Apple store

#351

Post by zozbot234 »

ch_sm wrote: post #350
lostmyoldone wrote: post #251

Earlier quoted context omitted.

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.

wxWidgets. The original toolkit is C++ and rather MFC-like, but there are bindings to other languages that are quite a bit easier to use.

Re: Electron apps cannot be submitted to the Apple store

#352

Post by vunie »

scarface74 wrote: post #143
vunie wrote: post #138

Banning private APIs is absurd. Permanently banning developers for using private APIs is shear lunacy. As someone else pointed out, not using private APIs would put some applications at a disadvantage against first party software: https://news.ycombinator.com/item?id=21437673 Firefox is often criticized for it's power consumption on the mac because it is not on par with safari. Chrome/electron uses private APIs to re…

Banning private APIs is absurd. Permanently banning developers for using private APIs is shear lunacy An API by definition is the public interface that a platform promises developers will not change without notice. The vendor has every right to change a private API. Once you start letting third party developers use private APIs either you are stuck with them forever or when you change it, users will blame you not the…

What a moronic comment. No ware in my comment have I argued that apple should not change their private APIs. What I'm arguing against is preventing third party developers from accessing them the same way apple does. We all understand that private APIs are subject to change without notice and accept the inherent risks involved.

I suggest working on your comprehension skills.

Re: Electron apps cannot be submitted to the Apple store

#353

Post by LeoNatan25 »

saagarjha wrote: post #246
throwGuardian wrote: post #201

Earlier quoted context omitted.

What about on iOS? And what about the fact that on MacOs notarization is more expensive than publishing to the store? I don't believe that to be a coincidence

Notarization is free.

Creating a Developer ID certificate requires a paid Apple account. Hardly free.

Re: Electron apps cannot be submitted to the Apple store

#354

Post by scarface74 »

BoorishBears wrote: post #346
scarface74 wrote: post #335

Earlier quoted context omitted.

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…

There is a difference between breaking a public API which is a defect and that’s done unintentionally - that happens with every operating system and framework - and depending on private methods to behave appropriately.

Decades ago, when Apple introduced 68040 Macs, a lot of programs broke because they were writing self modifying code and that didn’t work with the 68040 cache. Whose fault was that Apple’s or the developers?

Re: Electron apps cannot be submitted to the Apple store

#355

Post by ldh »

fooey wrote: post #268
lacker wrote: post #203

Earlier quoted context omitted.

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.

Yes, this is the thing. The option isn't electron vs native, it's electron vs nothing.

The option is native vs. electron vs. a regular web app. There's rarely any reason you need your web app to live in a dedicated Chrome instance without a URL bar.

Re: Electron apps cannot be submitted to the Apple store

#356

Post by starbugs »

ajxs wrote: post #38
codedokode wrote: post #29

Earlier quoted context omitted.

These numbers are too low. I assume that this task manager might show only private pages and not account shared pages with code (and the code size in Chrome is close to 100 Mb). Anyway, the number looks a bit unrealistic. Or maybe it doesn't count swap. I used Electron apps on Linux and typically memory usage doesn't get below 250-500 Mb. Here is an example for Skype: 220 Mb of swap + 388 Mb of PSS (Proportional set…

Even that's low. Here's my result of running pmap on an open vscode process. "total 1046516K" Yikes.

I manage to get these numbers with Sublime Text on a big project. Sublime Text is native.

Re: Electron apps cannot be submitted to the Apple store

#357

Post by babesh »

Mirioron wrote: post #287
babesh wrote: post #185

Earlier quoted context omitted.

You are assuming that these Apple APIs are used to give Apple a competitive advantage somehow. From what I can tell, these specific APIs don't. What they do give Apple an advantage in ironically is in forcing more developers to develop using (Apple) native APIs. The CA prefixed ones are core animation related. Some of the others appear to be drawing frame related. I am not sure what the remote one does. None of these…

> None of these are giving Apple a direct advantage. > I bet Electron tried to access to them to draw web pages smoothly. How is this not a direct advantage? If these uncommented API calls provide a better performing solution than anything a third party can make then that is a direct advantage. Apps with that call could have a longer battery life or just run smoother.

Public core animation APIs on Apple hardware are plenty fast. I suspect the issue here is that web browsers are acting as yet another abstraction layer and thus are introducing more performance overhead. Electron is probably trying to squeeze as much performance as it can get or electron has a rendering cycle that makes it hard to have it not skip frames due to overhead. Best thing to do is to ask Electron devs.

Re: Electron apps cannot be submitted to the Apple store

#358

Post by scarface74 »

vunie wrote: post #352
scarface74 wrote: post #143

Earlier quoted context omitted.

Banning private APIs is absurd. Permanently banning developers for using private APIs is shear lunacy An API by definition is the public interface that a platform promises developers will not change without notice. The vendor has every right to change a private API. Once you start letting third party developers use private APIs either you are stuck with them forever or when you change it, users will blame you not the…

What a moronic comment. No ware in my comment have I argued that apple should not change their private APIs. What I'm arguing against is preventing third party developers from accessing them the same way apple does. We all understand that private APIs are subject to change without notice and accept the inherent risks involved. I suggest working on your comprehension skills.

It’s moronic to use a private method that may change in a minor update. If anyone is using private APIs - they should work on their development skills.

Of course Apple is going to use private methods to implement public APIs. Would it be more sound architecturally if they made all of their public APIs thousands of lines of code and copy and paste duplicated functionality so they wouldn’t use private functions?

The risk isn’t just to you. Apple has been able to get customers to upgrade their operating system at a cadence that no other platform vendor has. What happens if every time they release an operating system apps break because they use private APIs? Either they will have to take the Windows strategy of putting individual hacks to keep apps from breaking or they will just have to let them break? Microsoft has historically not been able to ship OS upgrades on time partially because of the backwards compatible bloat of Windows.

Apple has successfully done multiple platform transitions by completely changing the underlying code for public interfaces. They wouldn’t have been able to do that if developers were using private methods.

In the grand scheme of things, you as a developer aren’t and shouldn’t be Apple’s focus. The customer is. If Apple is able to keep the customer happy developers will come along.

Re: Electron apps cannot be submitted to the Apple store

#359

Post by codedokode »

ajxs wrote: post #38
codedokode wrote: post #29

Earlier quoted context omitted.

These numbers are too low. I assume that this task manager might show only private pages and not account shared pages with code (and the code size in Chrome is close to 100 Mb). Anyway, the number looks a bit unrealistic. Or maybe it doesn't count swap. I used Electron apps on Linux and typically memory usage doesn't get below 250-500 Mb. Here is an example for Skype: 220 Mb of swap + 388 Mb of PSS (Proportional set…

Even that's low. Here's my result of running pmap on an open vscode process. "total 1046516K" Yikes.

I would rather use smem, that calculates PSS (Potential Set Size) that properly accounts for pages shared between processes and shows swap usage per process. 1 Gb seems realistic though.

Re: Electron apps cannot be submitted to the Apple store

#360

Post by codedokode »

starbugs wrote: post #356
ajxs wrote: post #38

Earlier quoted context omitted.

Even that's low. Here's my result of running pmap on an open vscode process. "total 1046516K" Yikes.

I manage to get these numbers with Sublime Text on a big project. Sublime Text is native.

It is partly written in Python, as well as plugins.
Post reply on HN