Electron apps cannot be submitted to the Apple store
david.dev
david.dev
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-public APIs in future submissions of this app may result in the termination of your Apple Developer account, as well as removal of all associated apps from the App Store.
"Keep trying to submit, and we might just ban you forever" is insane. Every program of any complexity depends on third party libraries, and many people wouldn't be able to tell what arcane APIs their dependencies (or their dependencies' dependencies) call. "If you continue to have an upstream dependency that violates our terms, we might permaban you" is bullshit.
It's also completely unsurprising. Apple has no love nor concern for their developers anymore. It used to be the premier development platform in the world. Now it's ... I don't even know anymore.
It's shameful but eh, it's a living.
In general, I find the opinions on these things to be pretty consistent: the “free market” types tend to support Apple/MS - usually with some form of “its their platform” as an argument - and the FOSS types holding the opposite position.
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.
That seems reasonable to me -- they're just saying that if you want to be listed as the publisher, you need to be the publisher...
The result is 98 muniplacities having to pay Apple developer fees, but it gets better because the app can’t be called the same thing anymore. So now there are 98 apps instead of one. :p
I mean, I guess our central digitisation agency should really just pick it up, but the bureaucracy doesn’t work like that.
It's not really fair to expect Apple to resolve or work around your own organizational problems.
This is missing the point of the post you are replying to. Say you identify five closed API dependencies and remove them. Do you resubmit? If you missed any others, you and all your apps might be banned.
Maybe not -- maybe you know something about how Apple operates. But clearly they ARE sending responses threatening to do exactly that.
Anecdotally, I have never heard of this happening in non-malicious cases, ever. And I know a couple hundred Mac and iOS developers who would raise a lot of noise if this did happen, so I'm inclined to believe that it doesn't.
They don't, though. And we trust them not to, because it is not reasonable behaviour and it would absolutely not make sense for them to do this.
This is the same.
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.
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 spirit of their request - and the letter of it - will result in a lifetime ban.
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.
The only answer is that as a developer, you are responsible. Yes, we have to make calculated risks. But the buck stops at you. There is nobody else who can take responsibility for the contents of your app.
"use"
If this was "don't conceal or we'll ban you for life", it would be somewhat understandable.
But it's "use or we'll ban you for life" which is just insane. Apple is at the height of their arrogance towards developers.
If you use a private API they will reject the app. If you try and hide the fact you are using private APIs after has told you to stop then they will ban you.
It's all very common sense and not arrogant at all.
Yep. I've migrated away from macOS after using it for a decade over to Linux, and the developer experience is first class.
They are allowed to ban you for literally any reason. What matters is what they do, not the exact phrasing in a random email.
And in practice, they will ban you if you actively try to skirt their rules after they tell you to cut it out.
It's the same reason people hold companies like Apple and Nike accountable for working conditions in their factories even if they hired a third party to run them. Third parties are not the ones putting their brand on the product.
I was under the impression that if you're being annoying and keep trying to submit a build with private API, making App Store Review's life hard, they're going to ban you. In general, you should be reviewing your dependencies yourself to make sure it's doing things that you approve of; if you can't do that after Apple has warned you that it's doing something that's not allowed I don't really have much sympathy for you.
There is also no apparent way to scan your own app to make sure that you are not in violation of this issue. So you're in a position where the only way to see if you are in compliance is to submit to Apple, but that may result in your account being banned.
While review is automated, I would like to believe that account deletion isn't.
> There is also no apparent way to scan your own app to make sure that you are not in violation of this issue. So you're in a position where the only way to see if you are in compliance is to submit to Apple, but that may result in your account being banned.
They literally tell you the symbols that you're not supposed to use: it's easy to check if your dependencies are using them.
I would like to believe that, too, but I don't.
> They literally tell you the symbols that you're not supposed to use: it's easy to check if your dependencies are using them.
Sure, if you have a better-than-average understanding of C (or Objective C), and know how to use the command line to grep strings out of a binary, and know all of the binaries you need to be searching.
This is a rejection for an Electron app, and I'm going to go out on a limb and say that the majority of Electron developers do not have the requisite skills. Hell, I've been programming for a couple of decades now, and I couldn't 100% guarantee that an app I wrote didn't call one of the forbidden APIs, even indirectly.
The rejection email doesn't bother to say where in the code the problem is, so it's apparently not so easy as to be part of an automated process. "Learn what these esoteric commands do, use them correctly on every upstream dependency your app has, make sure you don't call any of these symbols, and if you fuck up you're banned for life" is utter dogshit customer service.
I'll believe it up until the point that "Apple automatically deleted my account because of repeated app submissions" makes the front page of Hacker News. Until then, I have no reason to doubt it as I have never heard of this happening except in clearly malicious cases.
> The rejection email doesn't bother to say where in the code the problem is
I'd argue that any answer to this question would require the skills that you say Electron developers lack. I don't know what your solution to this is, because getting your app past review by claiming ignorance into what your dependencies is doing ("oh no, I totally didn't know this framework was literally malware, can you please let me be on the App Store anyways?") isn't going to work either.
Because Apple knows it doesn't need to attract developers to iOS. They will come no matter what because that's where the mobile market is.
On macOS it's different. There are very few macOS exclusive developers so most of the popular apps are either cross platform (Office, Photoshop, Sublime Text, Chrome, Firefox, Maya, Cubase, Cinema4D, Resolve, etc) or are from Apple. In both cases the Apple dev experience is irrelevant. There are plenty of boutique devs making small products exclusively for macOS (eg: Panic, Bjango, Bohemian) but these are a drop in the ocean. Apple knows this which is why it's making Catalyst to attract iOS devs to macOS. AFAIK the only big developer making macOS exclusive products is Apple itself.
Wait a second. When was this exactly? Are you talking about the Apple II era?
When has Apple ever been developer friendly?
Their ecosystem always had more money for app developers, but I can't think of any point in time when developers weren't shouting to anyone who will listen about Apple's rules.
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.
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 ever was.
At some point the goodwill they built as underdog making great products will run out and some government somewhere will take an anti-trust action.
I'm just hoping it'll happen sooner rather than later.
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 dead end.
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.
IBM had a different approach, which was to make things more open like the Apple ][, and they paid the price for it. For instance, a lot of the weird limitations of the IBM PC were caused by developers bit-banging hardware registers and video memory rather than going through "official" BIOS calls that were less efficient.
I don't personally know the right answer, but this is just the history as I recall it. At the time I preferred the IBM approach, because I could do some friendly bit banging and get stuff done, but my programs were mostly for a severely limited audience and lifespan. Today I try to do things in a way that insulates me from knowing anything about the platform that I'm using.
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.
https://link.springer.com/content/pdf/10.3758/BF03203836.pdf
https://en.wikipedia.org/wiki/Applesoft_BASIC#Extensions
http://nparker.llx.com/a2/as.addons.html
"C is just PEEK and POKE with syntactic sugar." -- Bill Joy
and there is no update.
I worked on an app that competed with a Microsoft app. Our app was actually winning in the marketplace. One year they release a new version of their app with some really cool features at the same time as the latest Windows release. Those features were based on some new APIs released with that version of Windows. Just gave their app a year leap.
Another evil practice was forcing PC makers to pay for a Windows license for each computer sold irrespective of whether the computer shipped with Windows.
Microsoft was pretty evil.
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 are giving Apple a direct advantage. I bet Electron tried to access to them to draw web pages smoothly.
The Windows API availability window gave Windows apps market advantages.
There are other private Apple APIs that do give Apple an advantage against app developers. Those advantages are in accessing physical hardware and possibly associated software, background processing, and integration (iCloud, etc...) But these aren't the bone of contention.
Apple, or Microsoft for that matter, would do the same thing here, because the locked down platform is more valuable/profitable then an open platform.
Developed for Android - at least you can have your app sideloaded if the platform owner decided to remote you.
Or better, make your app a progressive web app. Don't use hardware api not available to the browser and you cannot be removed!
Sure they could have, they had a code signing platform since the mid 90s and could have locked API access only to apps signed by them.
They didn't because it would have been pointless not because they couldn't figure out how.
In a completely fair world a substantial number of executives would probably be in jail.
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 developers want. Apple has already started taking advantage of their position as the gatekeeper of the platform.
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.
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 use internal methods that you'll end up having to support. 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.
Apple uses these APIs to make features no one can fairly compete with, which is detrimental to you, as a user, and to external developers. Imagine if any app could use APIs like the ones that Apple Music uses to have tight integration with Siri, or that Apple Maps uses to show on your lockscreen.
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.
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 of trying to protect it. Linux is for servers.
The fact is that all of MS’s Office competitors early on wrote horrible GUI apps whether it be fir Windows or the Mac.
I don't know what Apple means by "secret APIs", but I'm assuming they mean "undocumented APIs". Those are certainly real things that commonly exist.
> By definition an Application Programmers Interface is the vendors promise to other developers that when you call it
Yes, but those "other developers" may be other engineers in the same company. The APIs they use are still APIs, but are not intended for use by anyone outside the company.
Say Team A within Apple creates a module that is only to be used by Team B and C. Then Teams D creates a module that depends on Team A and B and they release a public API.
Team A should publish an internal documentation and Teams B and C should also not use methods that were not documented by Team A and Team A shouldn’t follow standard semantic versioning. If Teams B and C need some functionality they should inform Team A.
The same goes for Teams B and C. Also, Apple controls the release schedule for any internal teams. If they want to move to ARM tomorrow they can coordinate it within Apple without breaking any third party apps. The only team that has any responsibility to not break external developers is Team D.
If Apple starts allowing external developers to use private functions now their release schedule is tied to when enough major third party developers update their documentation.
Amazon is even a better example. They have a policy that everything should be a service internally and no team should reach “inside” of the implementation of another team.
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?
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.com/electron/electron/issues/20027
Most likely these rejections were not intentionally resumed, but because the machine that is app stores these days is completely non-deterministic, this could still be a big problem.
This time the wrong developer could reach out to the wrong channel and trip some sort of trap that turns this into a "known issue: won't fix + always send automated reply", instead of someone with the right connections getting to the right person and having them go and flip a switch that fixes everything with their pinky finger.
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.
By Apple, or the Electron developers?
Apple's policy towards private APIs has been known for years.
Which is not a homogenous group, both in ideals and for why they'd upvote a submission like this.
> this rejection, and it's backing policy to be nonsensical
They're different things. I personally think the rejection is perfectly sensical in the context of the backing policy, with which I don't fully agree.
If you can't avoid Apple's stores then make damn sure you fall in line as they effectively own you.
I mean, did Electron or Google just refuse to fix this? Are these private APIs things that actually get exercised in the apps being threatened?
It's not so much about culpability or Apple's right to control their app deployment environment, it's that the response seems really disproportionate to the offense and pretty badly misdirected.
A more conspiratorially minded poster might wonder if the real goal here was to dissuade developers from using cross-platform frameworks...
Thank you Apple for keeping things clean!!
This is about submitting an app to the Mac App Store. Apple has had a requirement that apps not use private APIs for a while.
It sounds like Chromium, and hence Electron have had references to some private APIs for a while, but Apple has only recently started enforcing their requirement. (Or perhaps only recently started scanning for these particular APIs.)
It’s a little painful for the developers for this to suddenly pop up like this, but it’s better than all Electron apps suddenly crashing one day, which would have happened sooner or later when one of these APIs changed or was dropped.
The solution is a Chromium fix to avoid using these APIs, and an associated Electron release to incorporate the new version of Chromium.
I wonder if it has been that way in Chromium since Blink was WebKit and maintained largely by Apple with priority on performance on Apple platforms.
Edit: Sorry, no. Only JavaScriptCore is safe for stores, not the entire WebKit project.
So, feel free to use Electron, just understand that your so easy to develop desktop app now hinges on the ability of a few unpaid developers (that's probably not you, or the "full-stack" people at Slack) to continuously keep track with the Chromium source and maintain their no doubt massive patches to its code to remove use of these private APIs.
Indeed, and the article's title is confusingly wrong, as "Apple Store" refers to Apple's retail and online store that sells hardware.
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 (best of all: spell checking for commit messages because all native text fields get it for free.) You can try it on your own machine and compare them.
Now yes Electron has made life very easy for some developers and some apps wouldn't even exist if not for Electron, but why, as a user, should I pick an Electron app over native alternatives?
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 size).
Yikes.
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?
(That isn't to say that the web version of Slack isn't horribly engineered too, but it poses far less of a problem)
The reason why this pattern isn't used more commonly is the fact that right now web browsers simply aren't designed to be used this way unless you start a new instance for just a single app. The second reason is that electron developers are lazy. They only want to test a single browser (or browser version) and are perfectly happy that this means Google can get away with shady things.
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 it's better.
The fact that it works the same on OSX and Linux is even better.
Where else would users complain about undesirable developer trends if not on a developers' community?
For the record, I do think there are problems with Electron, just not the ones usually mentioned. A big (huge!) problem in my opinion is that two windows can't share JS context. It's the reason why VSCode is way behind in multi-monitor support for instance.
Say a somewhat below-average user has 6GB of memory (I'm being generous here; plenty don't have more than 4GB). Today is a worse-than-usual day, and 4GB are taken by everything that isn't Electron because 40 tabs are open for a research paper due tomorrow. That leaves three gigs to spare. Now the user starts up some Electron apps.
- Music player? +400mb
- Note-taking? +300mb
- Messaging? +500mb (thanks, Slack!)
- News? +300mb
- Editor/IDE? +500mb
That's it. No more space. And that's before we even begin talking about what we're putting that dual-core CPU through. Battery life is a joke at this point.
A comparison: My OS, window manager, mail client, password manager, taskbar, music player (mpd+ncmpp+clerk.pl), file manager, system monitor, RSS reader, podcast player, IRC client, and editor/IDE (neovim+language servers with diagnostics, gotos, floating documentation, and refactoring all running) barely use over 1GB of memory, combined. Let that sink in. Essentially, a single electron app using 500mb of memory would increase my memory usage by 40%.
People shouldn't have to throw away/upgrade their computers every four years. I'm still rocking a 2013 HP Elitebook G1 with a Haswell i5 as my secondary machine. It runs just as well as my desktop for anything except heavy websites with JS enabled, compiling, and graphics-intensive work. I plan to either continue using it for another few years or donate it and switch to a more lightweight \$199 Pinebook Pro. Using less powerful hardware forces me to empathize with users who are using tech from the past rather than the future, because that's my job. I build tools for people besides myself to use.
If you must use the web, consider making your "app" start a local web server and launching the users' preferred browser for a more lightweight solution.
I'd pick the native version every time, but there is no native VSCode, Atom, Slack, or Whatsapp.
I use Sublime because it's native and I don't use too many plugins but a lot of people prefer VSCode.
I cannot fathom the indignity required to care about that difference.
Your failure to empathize seems like an odd thing to brag about. Even if you have plenty of memory available, you should be capable of empathizing with people who are short on it.
It’s no different than any other library or toolkit you would link against normally. You wouldn’t be hearing these complaints from a “native” app developer that intentionally picked any other library or runtime that (ab)used private frameworks.
https://www.chromium.org/developers/design-documents/chromiu...
Technical details aside, it describes two methods of performing delegated rendering on Mac. One uses public APIs and causes a "reduction in performance and increase in GPU power consumption." The other uses the reverse-engineered CAContext API.
Because it seems pretty similar.
Also, I wonder if this was code inherited from WebKit, possibly even from Apple engineers.
The definition of anti trust is not “a company does something I don’t like”.
https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...
Is the desktop version of chrome not in the app store? Maybe not.
Chromium and Chrome aren't in Apple app stores.
The oldest copy of the current app store guidelines I could find goes back to 2014:
http://web.archive.org/web/20140903022336/https://developer....
"2.5 Apps that use non-public APIs will be rejected"
However this has been known dating back to 2010, so I'm sure someone can dig up an older version of the agreement that says as much.
The fact that Electron is a much easier way to build apps than Swift, Obj-C, etc has nothing to do with the enforcement of these long-standing rules.
Is this another case where you can break the rules but only if you're rich enough?
1) wxWidgets
2) QT
3) Delphi with Firemonkey
4) Lazarus
Whole bunch of other which you are welcome to Google and explore
Also it depends on your type of application but I am seriously considering using 3D rendering library as a basis for multiplatform GUI. This one does not look too native but it looks like it may be the leanest, fastest option. This would require some groundwork first.
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
On the other hand, plenty of rejections I've anecdotally encountered are far less obvious and boil down to "we say so". Then you get banned while you still wonder. Google have done this a few times to others I know.
Strange times.
However, this is not really about unsigned binaries. These APIs are from OSX itself. This is about access to private APIs. These have no contract and can be changed at any time, as they were not intended for public consumption.
But, if Apple is trying to apply anticompetitive behavior against certain technologies, if this rule is selectively enforced, if there is any bad smell or anything dirty about this process, then Apple is inviting antitrust scrutiny or new laws.
Apple had better make sure it is squeaky clean on this.
In some cases, private APIs are used as implementation details of public APIs. For example, the symbol "NSNextStepFrame" sounds like it might be part of the implementation of NSWindow. In some other cases, Apple has made early versions of some APIs private before later releasing them publicly -- for example, the Catalyst APIs (UIKit on macOS) was a private API for a while before being publicly released, allowing Apple to test the APIs (and potentially make backwards-incompatible changes) before external developers started using it.
It's only anticompetitive if they selectively apply those rules.
It's also pretty much a straw man kind of argument around the public/private API distinction as important to prevent applications from breaking, as it seems to be the rule rather than the exception that lots of apps break on iOS updates anyway.
They don't seem to care that much, but it could be a good way to make sure it's harder for eg Chrome to compete with Safari. Simply make the API they have to use a bit slow and inefficient.
This only affects the App Store, which Chrome quite purposely is not part of and which the vast majority of Apple apps aren't distributed through.
> They don't seem to care that much, but it could be a good way to make sure it's harder for eg Chrome to compete with Safari. Simply make the API they have to use a bit slow and inefficient.
My understanding is that the inefficiencies in question come from a need to bridge from cross-platform code into the public APIs.
For example, one of the private functions mentioned was needed to treat mach ports as file descriptors - not needed if you are using the proper API to deal with ports.
My understanding is the CoreAnimation private calls are because the layers are rendered and composited externally and CA is only being used for display. Because the rest of CA is skipped, it can't determine a list of partial changes and thus performs a lot more work than necessary. The Private calls are being used to force CA to skip rendering parts of parts of the display. Safari doesn't need to do this because they are using the proper API for the entire pipeline.
Here 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.
Only issue was first with the signature of the app, got fixed with later updates.
My app is up in the AppStore with latest Electron 6.
I personally prefer using MAS for such apps, since that means updates are installed automatically overnight without having to deal with other people’s annoying auto-updating software. Wish Chrome itself was in the MAS, so I didn’t have to deal with Google Autoupdater.
WebKit on macOS doesn’t have the limitations that its iOS cousin does… cutting edge API support is a bit spotty but if one looks at how old the versions of Electron being shipped are, that clearly isn’t a problem. More web wrappers should opt for the locally available engine instead of bringing their own.
Electron always uses Chrome whether it is on MacOS or Windows. There was a node-webkit project before Electron, I don't know its status.
That is precisely why I mentioned Microsoft. They have historically gone through great lengths to keep devs happy.
That’s what happens when you focus on developers instead of users. How much smaller would Windows be if they didn’t have all of these backwards compstible hacks? Hell, they had a half dozen different ways to define a string that you actively had to convert back and forth between just to call various APIs and that was back in the early 2000s. I’m sure it’s gotten worse since then.
You don’t have to make developers happy. Developers will go to where the users are. Where is all of the development energy these days? It’s definitely not on Windows. What makes developers “happy” are paying customers.
Microsoft has been trying and failing for years to produce a viable ARM laptops. Partially because of an insistence on backwards compatibility and all of the code bloat that entails. Apple transitioned the Mac platform four times since 1984 and created four successful ARM based platforms in the last decade.
Cross-platform comparability always promises so much, and falls down in the implementation.
Yes electron comes with some overhead. But what you get from paying that price are products that otherwise likely wouldn't exist. Some of these are bad indeed, but some of them are also really good and provide real value.
I think that describes the attitude of electron developers toward their users, you're putting your time and convenience over them.
— https://developer.apple.com/mac-catalyst/
Literally every paragraph of copy on this page emphasizes them as native apps.
and then the app is never written
the overwhelming number of indie apps that are cross platform? Let me just go ahead and try to use inkscape and gimp on my mac.
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 "compile to" native apps for linux and windows and mac without having to write the app 3 times.
If the APIs didn't exist, then there would be no need for Apple to check and there would be no developers tempted to use anything private.
If you have a public function “A” that is implement using private methods B,C,D. The implementor is free to change B, C, D or completely get rid of them to implement A. This is software engineering 101. Apple was able to make multiple cpu transitions doing this. Back in the PPC days, non native apps could run at near native speeds calling public APIs that were implemented by changing the private interface.
Most obviously, they can go in the kernel. They can go in a separate process, using the Mach messaging that Apple so loves. There are other designs, as seen in Multics and VMS, with semi-privileged libraries. One could implement semi-privileged libraries on ARM by switching to a different page table when an attempt is made to run the library code.
For secured forms of code like WebAssembly and the JVM, simply validate at load time that there will not be calls to non-whitelisted library functions.
Would you write a C++ program that called private functions using pointers? Would you write a C# program that called a private method using reflection? Should the dependency maintainer have the expectation of people calling private methods and not break your code?
Every suggestion you have leads to performance issues.
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 reduce power consumption to be more competitive with Apples browser. Apple bans the use of private APIs.
Monopoly laws need to be updated.
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 developer when applications break.
I suggest working on your comprehension 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.
Apple breaks apps CONSTANTLY that use only public APIs, and the users DO NOT BLAME APPLE.
Do you even work in the iOS ecosystem? Because everyone who does knows this. Users don't blame Apple when things break, they blame 3rd party developers.