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…
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…
Electron apps cannot be submitted to the Apple store
281–290 of 441 posts
Re: Electron apps cannot be submitted to the Apple store
#282The lesson here is write native apps using the preferred native tools of the platform, and avoid shortcut solutions.
Yeah, when you're coding for a cpu, write in assembly only. Write a separate copy of your app for iphone and macOS because one of those is arm and one isn't. Don't use anything that provides portability like C or Objective-C, that's not really "native" to the CPU architecture. .. I know that sounds silly, but you're advocating for that one layer up. It's a very good analogy I think. People use electron in order to "c…
Re: Electron apps cannot be submitted to the Apple store
#283Earlier 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.
Case in point, if I run Slack in Safari, it runs better than the electron version. Functionally, it’s identical, except the scrolling is now native and feels a bit better integrated in macOS. So what’s the point?
Re: Electron apps cannot be submitted to the Apple store
#284Earlier 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.
> 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?
* you can't be sure code in package is same you see on github as npm doesn't do signatures
* code already in node_modules is usually minified and obfuscated
So only real way to be sure is to make own repository, copy every dependency, check code, build own packages and only use packages from your repo. Repeat process when versions are updated.
So to answer your question, yes, 99% of apps, they don't know.
Re: Electron apps cannot be submitted to the Apple store
#285Earlier quoted context omitted.
It's funny how the general consensus on here is against Microsoft's abuse of private APIs in Windows to help Word and DOS against WordPerfect and DrDOS, 20+ years ago. But Apple doing it right now in a much worse way is considered acceptable and defendable.
I don't think anyone here considers Apple's abuse of private APIs vs developers an ok thing. I will never subject myself to their app store if I can help it.
Re: Electron apps cannot be submitted to the Apple store
#286Earlier 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?
I think that ship sailed a long time ago. Right now I'm building an app with Google's mobile toolkit, Flutter. Flutter itself is a few hundred kloc. And on top of that, I'm using a bunch of libraries; I wouldn't be shocked if it were the same amount of code again. Assuming I can properly code review a few hundred lines per hour, reviewing all that will take me a year or so. Which is maybe 5x what it will take me to s…
Unless you are willing to freeze whole tree until review is done but then you don't get bug fixes and security updates for period of initial review + review of updated packages.
Re: Electron apps cannot be submitted to the Apple store
#287Earlier quoted context omitted.
As opposed to "here are some APIs that you can't use but we can, neener neener"?
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…
>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.
Re: Electron apps cannot be submitted to the Apple store
#288Here on HN we hear constantly of developers dropping out of the Mac app store. If we cobsider the premium (justified or not) of apple laptops, and thus the relatively limited audience they target, we can easily predict a steeper decline in interest to develop for the Mac platform.
Having said that, we should also consider that Electron is indirectly owned by Microsoft, and is based on tech by Google. So I don't see much incentive on their part to fix this quickly, and one could even argue that they have some interest in not fixing at all this.
Re: Electron apps cannot be submitted to the Apple store
#289I'm curious as to how Slack was/is still able to get updates out despite clearly relying on electron. Setting aside whether one agrees with Apple on this move or not, I would be outraged if they are playing favorites with a select few high-impact electron apps that they don't want off their store due to the associated bad press it would garner them.
well I guess that when you have the #1 application in the App store (under business) and an 11bn $ market cap you are probably not treated the same way as an unknown developer with a pretty insignificant app ;) OR simply you do have engineers that can patch pretty much anything so run their own version of Electron/Chromium duly compliant with the App Store requirements.
Re: Electron apps cannot be submitted to the Apple store
#290Earlier quoted context omitted.
I would assume that a quick grep through your project for the symbols mentioned would tell you where the issue is.
what if the function calls are generated with macros or something?