24 ms·

Electron apps cannot be submitted to the Apple store

395 points by rdevnull 7y ago

kd3 7y ago
This is absolutely insane. Apple could learn a lot from Microsoft of how to treat developers. God i miss Steve Ballmer
- scarface74 7y ago
  It’s dumb too depend on private APIs and shows a complete lack of understanding how development works. Have you read Raymond Chen’s blog about all of the obscure one off hacks Microsoft has had to add to keep misbehaving apps from breaking?
  - kd3 7y ago
    > Have you read Raymond Chen’s blog about all of the obscure one off hacks Microsoft has had to add to keep misbehaving apps from breaking? That is precisely why I mentioned Microsoft. They have historically gone through great lengths to keep devs happy.
    - scarface74 7y ago
      And where has that gotten them? Slow release cycles, unable to compete in mobile and now Apple alone sells more iOS devices than all Windows manufacturers combined. You create a compelling platform for users and developers will come along. 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.
      - kd3 7y ago
        Microsofts failure in mobile has simply been due to the fact that they weren't able to excite users with hardware. This changed with the Surface line.
        scarface74 7y ago
        Microsoft’s hardware was often the same hardware that ran Android especially from HTC. But as far as the Surface. MS only made $1.329 billion on Surface devices. That’s less than a third of what Apple makes on Macs. Heck that’s less than Apple makes on Watches and AirPods. https://sixcolors.com/post/2019/10/apple-results-64b-in-revenue-on-record-services-income/#more https://sixcolors.com/post/2019/10/apple-results-64b-in-reve... https://www.techradar.com/news/microsofts-surface-sales-keep-getting-stronger-with-a-21-leap https://www.techradar.com/news/microsofts-surface-sales-keep...
- mc3 7y ago
  while (sweaty) { say('Developers'); }
mensetmanusman 7y ago
Is this an attempt by Apple to increase robustness by reducing dependencies on unsigned binaries?
- oyebenny 7y ago
  That is a very specific question.
- outworlder 7y ago
  This is not new. There have been checks for private API usage for as long as I can remember – at least on iOS. It could be the case that there was less enforcement on OSX. 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.
- duskwuff 7y ago
  No. The symbols mentioned in the rejection are all in signed Apple libraries; the problem is that those symbols aren't part of the public/documented/stable API.
- thothamon 7y ago
  I feel Apple is moving into somewhat dangerous territory. If the intent, as documented by internal messages and emails, is purely to protect the consumer by forcing people to use only public APIs, that's one thing. 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.
  - duskwuff 7y ago
    I think the intent of these rules is (and generally has been) to allow Apple to classify APIs into "public" and "private" categories, where the public APIs are documented, and will not change or be removed without plenty of notice, and the private APIs aren't any of those things. 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.
roblabla 7y ago
Well, why the hell is electron/chromium using private APIs? That seems like the real problem here...
- throw_m239339 7y ago
  It's possible electron team isn't even aware chromium is doing that.
- rvz 7y ago
  Its looks as if the Electron team had the assumption that developers would be unlikely to distribute their Electron Mac apps via the App Store, but instead as a DMG or zip which doesn't require Apple reviewing private APIs.
  - duxup 7y ago
    But they had to know it was happening at some point right?
    - jbverschoor 7y ago
      Ofcourse. But developers things they’re above anyone else and know better. At least most of them. And now someone says no to them, so they cry and post stuff.
  - rdevnull 7y ago
    true and the Notarization of the DMGs works fine with electron. Perhaps this is also why Atom is not on the apple store.
- jrochkind1 7y ago
  Another interesting question is how Chrome itself gets approved for the Apple web store then, right? https://apps.apple.com/us/app/google-chrome/id535886823 https://apps.apple.com/us/app/google-chrome/id535886823
  - 7y ago
gsich 7y ago
Good.
fintler 7y ago
Tracked over at: https://github.com/electron/electron/issues/20027 https://github.com/electron/electron/issues/20027
natch 7y ago
The lesson here is write native apps using the preferred native tools of the platform, and avoid shortcut solutions.
- friedman23 7y ago
  > and avoid shortcut solutions and then the app is never written
  - thefounder 7y ago
    This is true for many apps, especially for non-profit apps.
  - baroffoos 7y ago
    Pretty much. Back when apps were native to the platform they would be windows only. It is insane to require every app developer to have to put in 3x the work to rebuild the app for every single platform using its native tools. I would rather have one app that is 3x better and works everywhere. We just need to solve the massive memory issues with electron.
    - colejohnson66 7y ago
      The memory issues isn’t Electron’s fault; It’s Chromium’s
  - archie2 7y ago
    the overwhelming amount of apps that are native beg to differ
    - friedman23 7y ago
      > the overwhelming amount of apps that are native beg to differ 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.
- TheDong 7y ago
outworlder 7y ago
> I did write back to Apple trying to explain that I am using Electron and I can't really change any of these public-framework usage 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.
- philwelch 7y ago
  Exactly. An application developer chooses his dependencies and has to take responsibility for them. Even if the app store is going to let you pass the buck, it's going to make your customers unhappy.
  - BoorishBears 7y ago
    How is it going to make customers unhappy if your app isn't using the features? 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 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.
    - philwelch 7y ago
      It’s more of a general point that if your application is buggy, the customer isn’t going to give a damn whether the bug is in your code or in somebody else’s code.
      - BoorishBears 7y ago
groovebits 7y ago
Wonder why they couldn't do the same for the iOS appstore. Like js apps based in phonegap
- throw_m239339 7y ago
  Phonegap uses the the browser engine of the platform, therefore it's platform dependant. 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.
- saagarjha 7y ago
  They do, but those apps use WebKit and hence don't rely on private API.
  - kitsunesoba 7y ago
    And similarly, web tech wrapper apps for macOS that use WebKit instead of Chromium are not facing private API usage rejections. 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.
peruvian 7y ago
Probably not a big deal for publishers - most (non-tech) people I know download Electron apps via their own website e.g. Slack, Notion, etc.
- mikl 7y ago
  Even if its just 10% of your users that installed your app from MAS, that’s still a huge problem. 10% of your users you can’t ship an update to and have no easy way of moving to your self-hosted updater, that’s a major problem. 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.
- rdevnull 7y ago
  right but I think the Apple store is still a big market. Let's not forget that even a notarized DMG (required in the Catalina update) still shows a warning "this app was downloaded from the internet" which obviously doesn't trigger in thee apple store.
Razengan 7y ago
As a user I am glad. As is custom for all Electron discussions, someone must point out its flaws. Why the dislike, you ask? A picture is worth a thousand 64-bit words: https://imgur.com/a/XnCOHUD https://imgur.com/a/XnCOHUD 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?
- codedokode 7y ago
  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 size).
  - ajxs 7y ago
    Even that's low. Here's my result of running pmap on an open vscode process. "total 1046516K" Yikes.
    - starbugs 7y ago
      I manage to get these numbers with Sublime Text on a big project. Sublime Text is native.
      - codedokode 7y ago
        It is partly written in Python, as well as plugins.
jmull 7y ago
Putting it together: 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.
- duskwuff 7y ago
  Judging by the history of a related issue on the Electron Github project [1], I suspect that Apple might have given the framework a two-month grace period starting in early September, and that just expired. Or the exception was supposed to be permanent, but something made it stop working. [1]: https://github.com/electron/electron/issues/20027 https://github.com/electron/electron/issues/20027
- dragonwriter 7y ago
  > It sounds like Chromium, and hence Electron have had references to some private APIs for a while 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.
  - LeoNatan25 7y ago
    Apple's WebKit is safe to compile for their stores. The scripts and macros WebKit has disables use of private API unless you are compiling against Apple's internal SDKs. Edit: Sorry, no. Only JavaScriptCore is safe for stores, not the entire WebKit project.
- rdevnull 7y ago
  it seems that the scanning started these days. I had an app build a week ago and I didn't have any API error in the rejection.
thomascgalvin 7y ago
The basic concept isn't too disturbing; Apple packages private APIs that have no guaranteed behavior or expectation of support. If you depend on those APIs, it's very possible that your app will break in a future OS update. 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.
- plorkyeran 7y ago
  What's bullshit about banning someone who has been notified that they are in violation of the rules and then tries to hide their use of private APIs rather than stop using them? That's exactly what I would do in Apple's position. Resubmitting the same thing and hoping that it doesn't get caught the next time isn't an honest mistake.
  - albru123 7y ago
    Huh? The problem isn't that the developer itself is trying to cover his misbehavior, but the fact that the developer can get banned for something out of his control.
    - sarah180 7y ago
      The developer is the one who takes responsibility for the submission. Enforcement is meaningless if you can just say "oh I asked you to publish dangerous code, but it's not my fault." 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.
thefounder 7y ago
Does anyone use the Mac appstore?
- rdevnull 7y ago
  I think so :) there are several apps that users prefer to install on the apple store, and even a notarized DMG shows some warnings so..
- rimliu 7y ago
  Yes. That way I can install apps on five computers, I do not have to keep a list and go lookin for them, because they are in one place, and I get regular updates.
therealmarv 7y ago
Wait. Does this mean Slack will be banned soon? Or are they all using Electron 8?
- rdevnull 7y ago
  I am pretty sure the problem will also be in Electron 8.
paggle 7y ago
If Apple doesn’t want third party apps calling private APIs why don’t they simply run third party apps in a sandbox that doesn’t have them exposed?
- saagarjha 7y ago
  Because the private APIs are used by frameworks that are loaded into the same process as the application.
  - paggle 7y ago
    Sorry, can you explain further? I haven't done any mobile development so if you have some resource I can learn more from I would really appreciate it.
ComputerGuru 7y ago
Good. It’s time app developers began to treat Electron like the Goliath of a dependency that it is rather than a cost-free shortcut to launching a cross-platform GUI product. 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.
haecceity 7y ago
Why doesn't Apple change their SDK to make the public APIs non linkable?
- saagarjha 7y ago
  Because they need to link against these symbols themselves. They have used TAPI in the past to keep these symbols out of the public SDK, but it's quite easy to make your own TBD that lets you link against them anyways. (By the way, you posted your comment twice.)
haecceity 7y ago
Why doesn't Apple change their SDK to make their API non linkable?
- paxswill 7y ago
  Because of how Obj-C works, it’s not really possible to have completely hidden classes or methods. You can instantiate classes by name at runtime, and can similarly create a message (aka call a method) at runtime. This is basically the “concealed” option mentioned elsewhere. Because of this dynamism, it’s possible to recreate a header file from the compiled frameworks, and then just compile like normal.
mrb 7y ago
Off topic: this is the first time I see Latin Modern Roman used on a web page. Doesn't look that great on low-DPI screens (13" at 2560x1440) but looks good on high-DPI (530 DPI Pixel 4 XL).
- rdevnull 7y ago
  wow glad you noticed :) is latex CSS and I thought it would make the text look different (it looks like everyone is using Open Sans nowadays :) https://github.com/gurugeek/latexcss/blob/master/latex.css https://github.com/gurugeek/latexcss/blob/master/latex.css
FpUser 7y ago
On one hand I am not fond of Apple in general at all. On the other hand when I see developers using Electron as a GUI layer I think it is pure insanity. It is an absolute resource and performance hog that in my opinion has no place outside of browsers context.
- lostmyoldone 7y ago
  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?
  - ch_sm 7y ago
    I think that’s the sad truth. There are currently no good cross-platform UI Toolkits.
    - zozbot234 7y ago
      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.
  - FpUser 7y ago
    Ones that come to mind right away and support most popular OSs: 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.
burfog 7y ago
Apple could just not have private APIs. At the very least, they could be impossible to access. If they have to exist at all, they could be in a separate library with permissions that prevent it from being read or mapped into memory. 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.
- saagarjha 7y ago
  Apple cannot do this because their (user-space) libraries need to call these internally, and they are mapped into an application's process.
- scarface74 7y ago
  Again this shows a complete lack of understanding how software development works. 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.
  - burfog 7y ago
    Put B,C,D on the other side of a privilege boundary. 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.
    - scarface74 7y ago
      There is always a performance penalty when switching between “rings”. Private methods are an “implementation detail” that shouldn’t be depended on. 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.
nickpeterson 7y ago
Apple does not like platforms that make it easy to publish lowest common denominator apps for iOS. It makes for garbage apps that look the same on iOS and Android and presents a false equivalency. They know most companies care about iOS customers than Android so this forces companies to spend more making the iOS app better than the Android app.
- saagarjha 7y ago
  Apple did not ban this app for being "garbage"–it's not even an iOS/Android app.
bdcravens 7y ago
There's no drama here. The oldest copy of the current app store guidelines I could find goes back to 2014: http://web.archive.org/web/20140903022336/https://developer.apple.com/app-store/review/guidelines/ 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.
- fortran77 7y ago
  Why does Electron need to use non-public APIs?
  - bdcravens 7y ago
    My understanding is that it's Chromium that uses these (ostensibly for performance), not Electron, but Chromium is a dependency of Electron.
  - lostmyoldone 7y ago
    According to a previous poster, the public API cause excessive power drain and is a fair bit slower. Since Apple usually use the argument of how the OS and API's are built to draw less power, it's quite peculiar that they can't find a more constructive solution than threatening to ban people and companies from the app store.
- ken 7y ago
  I think half the drama is that there are Electron apps in Apple's app stores already, e.g., a quick grep of Slack.app shows it contains all of these symbols in "Electron Framework.framework", yet it was apparently approved. Is this another case where you can break the rules but only if you're rich enough?
vunie 7y ago
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 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.
- scarface74 7y ago
  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 developer when applications break.
  - erichocean 7y ago
    > users will blame you not the developer when applications break 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.
  - vunie 7y ago
    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.
    - scarface74 7y ago
_coveredInBees 7y ago
I'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.
- rdevnull 7y ago
  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.
  - z3t4 7y ago
    This is a problem with licensees like MIT. The essential features will be proprietary.
The_rationalist 7y ago
Electron apps can be submitted to the Apple store... Slack has recently been updated for example. This seems to only affect some developers, especially electron <= 5
- rdevnull 7y ago
  5 doesn't work either (others having the same issue in GitHub even got rejected with electron 3). Slack was updated a few days ago (I also had no such an error then). Also let's not forget that Slack is #1 in the App Store for the category business so is certainly not treated like a small app from an unknown developer ;)
- pier25 7y ago
  It would be a PR disaster for Apple and the MAS to block Slack from updating its Electron app.
- ken 7y ago
  Does Slack use private APIs?
  - The_rationalist 7y ago
    No electron application use private APIs, it's the embedded chromium that do.
thrower123 7y ago
So there goes one of the primary reasons to use Electron... Cross-platform comparability always promises so much, and falls down in the implementation.
ilaksh 7y ago
That's what you get for supporting the Apple ecosystem. Its a closed system.
greggman2 7y ago
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/issues/20027 https://github.com/electron/electron/issues/20027
- lostmyoldone 7y ago
  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.
  - saagarjha 7y ago
    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.
personjerry 7y ago
Does this apply to React Native apps?
- ptlu 7y ago
  React Native doesn't use Chromium under the hood, it renders using native iOS/Android components not a web view like Electron.
rado 7y ago
Good.
rs23296008n1 7y ago
At least Apple in this case actually provided a reason and list of APIs it is unhappy with. Armed with this you could either in theory or actuality chase through the maze of your app's dependencies. If this happened to me I'd then have a fighting chance of moving forward. 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.
flipetty 7y ago
why not contact Electron for this problem? There must be thousands of people having this at the moment
- saagarjha 7y ago
  They did: https://github.com/electron/electron/issues/20027 https://github.com/electron/electron/issues/20027
ghego1 7y ago
While this decision looks rational and technically solid on the surface, it makes the Mac platform, and in particular the Mac app store, even less appealing to developers. 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.
deleted 7y ago
[deleted]
jasonmp85 7y ago
So stop using Electron?
deleted 7y ago
[deleted]
paulie_a 7y ago
Hopefully this will happen everywhere. Electron apps are shit. If you don't want to write a native app. Don't support that platform.
fookitty 7y ago
Well to be honest and at the risk of getting down voted I think a fair amount of readers will agree that you shouldn't submit Electron apps not only on the Apple store but also elsewhere, it may be a good way to get a prototype out of the office but that's about it
YoannMoinet 7y ago
I was able to submit my app after an upgrade to Electron 6 with no issue whatsoever. 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.

395 points by rdevnull 7y ago

kd3 7y ago

This is absolutely insane. Apple could learn a lot from Microsoft of how to treat developers. God i miss Steve Ballmer

scarface74 7y ago
It’s dumb too depend on private APIs and shows a complete lack of understanding how development works. Have you read Raymond Chen’s blog about all of the obscure one off hacks Microsoft has had to add to keep misbehaving apps from breaking?
- kd3 7y ago
  > Have you read Raymond Chen’s blog about all of the obscure one off hacks Microsoft has had to add to keep misbehaving apps from breaking? That is precisely why I mentioned Microsoft. They have historically gone through great lengths to keep devs happy.
  - scarface74 7y ago
    And where has that gotten them? Slow release cycles, unable to compete in mobile and now Apple alone sells more iOS devices than all Windows manufacturers combined. You create a compelling platform for users and developers will come along. 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.
    - kd3 7y ago
      Microsofts failure in mobile has simply been due to the fact that they weren't able to excite users with hardware. This changed with the Surface line.
      - scarface74 7y ago
        Microsoft’s hardware was often the same hardware that ran Android especially from HTC. But as far as the Surface. MS only made $1.329 billion on Surface devices. That’s less than a third of what Apple makes on Macs. Heck that’s less than Apple makes on Watches and AirPods. https://sixcolors.com/post/2019/10/apple-results-64b-in-revenue-on-record-services-income/#more https://sixcolors.com/post/2019/10/apple-results-64b-in-reve... https://www.techradar.com/news/microsofts-surface-sales-keep-getting-stronger-with-a-21-leap https://www.techradar.com/news/microsofts-surface-sales-keep...
mc3 7y ago
while (sweaty) { say('Developers'); }

mensetmanusman 7y ago

Is this an attempt by Apple to increase robustness by reducing dependencies on unsigned binaries?

oyebenny 7y ago
That is a very specific question.
outworlder 7y ago
This is not new. There have been checks for private API usage for as long as I can remember – at least on iOS. It could be the case that there was less enforcement on OSX. 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.
duskwuff 7y ago
No. The symbols mentioned in the rejection are all in signed Apple libraries; the problem is that those symbols aren't part of the public/documented/stable API.
thothamon 7y ago
I feel Apple is moving into somewhat dangerous territory. If the intent, as documented by internal messages and emails, is purely to protect the consumer by forcing people to use only public APIs, that's one thing. 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.
- duskwuff 7y ago
  I think the intent of these rules is (and generally has been) to allow Apple to classify APIs into "public" and "private" categories, where the public APIs are documented, and will not change or be removed without plenty of notice, and the private APIs aren't any of those things. 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.

roblabla 7y ago

Well, why the hell is electron/chromium using private APIs? That seems like the real problem here...

throw_m239339 7y ago
It's possible electron team isn't even aware chromium is doing that.
rvz 7y ago
Its looks as if the Electron team had the assumption that developers would be unlikely to distribute their Electron Mac apps via the App Store, but instead as a DMG or zip which doesn't require Apple reviewing private APIs.
- duxup 7y ago
  But they had to know it was happening at some point right?
  - jbverschoor 7y ago
    Ofcourse. But developers things they’re above anyone else and know better. At least most of them. And now someone says no to them, so they cry and post stuff.
- rdevnull 7y ago
  true and the Notarization of the DMGs works fine with electron. Perhaps this is also why Atom is not on the apple store.
jrochkind1 7y ago
Another interesting question is how Chrome itself gets approved for the Apple web store then, right? https://apps.apple.com/us/app/google-chrome/id535886823 https://apps.apple.com/us/app/google-chrome/id535886823
- 7y ago

gsich 7y ago

Good.

fintler 7y ago

Tracked over at: https://github.com/electron/electron/issues/20027 https://github.com/electron/electron/issues/20027

natch 7y ago

The lesson here is write native apps using the preferred native tools of the platform, and avoid shortcut solutions.

friedman23 7y ago
> and avoid shortcut solutions and then the app is never written
- thefounder 7y ago
  This is true for many apps, especially for non-profit apps.
- baroffoos 7y ago
  Pretty much. Back when apps were native to the platform they would be windows only. It is insane to require every app developer to have to put in 3x the work to rebuild the app for every single platform using its native tools. I would rather have one app that is 3x better and works everywhere. We just need to solve the massive memory issues with electron.
  - colejohnson66 7y ago
    The memory issues isn’t Electron’s fault; It’s Chromium’s
- archie2 7y ago
  the overwhelming amount of apps that are native beg to differ
  - friedman23 7y ago
    > the overwhelming amount of apps that are native beg to differ 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.
TheDong 7y ago

outworlder 7y ago

> I did write back to Apple trying to explain that I am using Electron and I can't really change any of these public-framework usage 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.

philwelch 7y ago
Exactly. An application developer chooses his dependencies and has to take responsibility for them. Even if the app store is going to let you pass the buck, it's going to make your customers unhappy.
- BoorishBears 7y ago
  How is it going to make customers unhappy if your app isn't using the features? 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 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.
  - philwelch 7y ago
    It’s more of a general point that if your application is buggy, the customer isn’t going to give a damn whether the bug is in your code or in somebody else’s code.
    - BoorishBears 7y ago

groovebits 7y ago

Wonder why they couldn't do the same for the iOS appstore. Like js apps based in phonegap

throw_m239339 7y ago
Phonegap uses the the browser engine of the platform, therefore it's platform dependant. 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.
saagarjha 7y ago
They do, but those apps use WebKit and hence don't rely on private API.
- kitsunesoba 7y ago
  And similarly, web tech wrapper apps for macOS that use WebKit instead of Chromium are not facing private API usage rejections. 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.

peruvian 7y ago

Probably not a big deal for publishers - most (non-tech) people I know download Electron apps via their own website e.g. Slack, Notion, etc.

mikl 7y ago
Even if its just 10% of your users that installed your app from MAS, that’s still a huge problem. 10% of your users you can’t ship an update to and have no easy way of moving to your self-hosted updater, that’s a major problem. 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.
rdevnull 7y ago
right but I think the Apple store is still a big market. Let's not forget that even a notarized DMG (required in the Catalina update) still shows a warning "this app was downloaded from the internet" which obviously doesn't trigger in thee apple store.

Razengan 7y ago

As a user I am glad. As is custom for all Electron discussions, someone must point out its flaws. Why the dislike, you ask? A picture is worth a thousand 64-bit words: https://imgur.com/a/XnCOHUD https://imgur.com/a/XnCOHUD 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?

codedokode 7y ago
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 size).
- ajxs 7y ago
  Even that's low. Here's my result of running pmap on an open vscode process. "total 1046516K" Yikes.
  - starbugs 7y ago
    I manage to get these numbers with Sublime Text on a big project. Sublime Text is native.
    - codedokode 7y ago
      It is partly written in Python, as well as plugins.

jmull 7y ago

Putting it together: 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.

duskwuff 7y ago
Judging by the history of a related issue on the Electron Github project [1], I suspect that Apple might have given the framework a two-month grace period starting in early September, and that just expired. Or the exception was supposed to be permanent, but something made it stop working. [1]: https://github.com/electron/electron/issues/20027 https://github.com/electron/electron/issues/20027
dragonwriter 7y ago
> It sounds like Chromium, and hence Electron have had references to some private APIs for a while 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.
- LeoNatan25 7y ago
  Apple's WebKit is safe to compile for their stores. The scripts and macros WebKit has disables use of private API unless you are compiling against Apple's internal SDKs. Edit: Sorry, no. Only JavaScriptCore is safe for stores, not the entire WebKit project.
rdevnull 7y ago
it seems that the scanning started these days. I had an app build a week ago and I didn't have any API error in the rejection.

thomascgalvin 7y ago

The basic concept isn't too disturbing; Apple packages private APIs that have no guaranteed behavior or expectation of support. If you depend on those APIs, it's very possible that your app will break in a future OS update. 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.

plorkyeran 7y ago
What's bullshit about banning someone who has been notified that they are in violation of the rules and then tries to hide their use of private APIs rather than stop using them? That's exactly what I would do in Apple's position. Resubmitting the same thing and hoping that it doesn't get caught the next time isn't an honest mistake.
- albru123 7y ago
  Huh? The problem isn't that the developer itself is trying to cover his misbehavior, but the fact that the developer can get banned for something out of his control.
  - sarah180 7y ago
    The developer is the one who takes responsibility for the submission. Enforcement is meaningless if you can just say "oh I asked you to publish dangerous code, but it's not my fault." 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.

thefounder 7y ago

Does anyone use the Mac appstore?

rdevnull 7y ago
I think so :) there are several apps that users prefer to install on the apple store, and even a notarized DMG shows some warnings so..
rimliu 7y ago
Yes. That way I can install apps on five computers, I do not have to keep a list and go lookin for them, because they are in one place, and I get regular updates.

therealmarv 7y ago

Wait. Does this mean Slack will be banned soon? Or are they all using Electron 8?

rdevnull 7y ago
I am pretty sure the problem will also be in Electron 8.

paggle 7y ago

If Apple doesn’t want third party apps calling private APIs why don’t they simply run third party apps in a sandbox that doesn’t have them exposed?

saagarjha 7y ago
Because the private APIs are used by frameworks that are loaded into the same process as the application.
- paggle 7y ago
  Sorry, can you explain further? I haven't done any mobile development so if you have some resource I can learn more from I would really appreciate it.

ComputerGuru 7y ago

Good. It’s time app developers began to treat Electron like the Goliath of a dependency that it is rather than a cost-free shortcut to launching a cross-platform GUI product. 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.

haecceity 7y ago

Why doesn't Apple change their SDK to make the public APIs non linkable?

saagarjha 7y ago
Because they need to link against these symbols themselves. They have used TAPI in the past to keep these symbols out of the public SDK, but it's quite easy to make your own TBD that lets you link against them anyways. (By the way, you posted your comment twice.)

haecceity 7y ago

Why doesn't Apple change their SDK to make their API non linkable?

paxswill 7y ago
Because of how Obj-C works, it’s not really possible to have completely hidden classes or methods. You can instantiate classes by name at runtime, and can similarly create a message (aka call a method) at runtime. This is basically the “concealed” option mentioned elsewhere. Because of this dynamism, it’s possible to recreate a header file from the compiled frameworks, and then just compile like normal.

mrb 7y ago

Off topic: this is the first time I see Latin Modern Roman used on a web page. Doesn't look that great on low-DPI screens (13" at 2560x1440) but looks good on high-DPI (530 DPI Pixel 4 XL).

rdevnull 7y ago
wow glad you noticed :) is latex CSS and I thought it would make the text look different (it looks like everyone is using Open Sans nowadays :) https://github.com/gurugeek/latexcss/blob/master/latex.css https://github.com/gurugeek/latexcss/blob/master/latex.css

FpUser 7y ago

On one hand I am not fond of Apple in general at all. On the other hand when I see developers using Electron as a GUI layer I think it is pure insanity. It is an absolute resource and performance hog that in my opinion has no place outside of browsers context.

lostmyoldone 7y ago
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?
- ch_sm 7y ago
  I think that’s the sad truth. There are currently no good cross-platform UI Toolkits.
  - zozbot234 7y ago
    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.
- FpUser 7y ago
  Ones that come to mind right away and support most popular OSs: 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.

burfog 7y ago

Apple could just not have private APIs. At the very least, they could be impossible to access. If they have to exist at all, they could be in a separate library with permissions that prevent it from being read or mapped into memory. 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.

saagarjha 7y ago
Apple cannot do this because their (user-space) libraries need to call these internally, and they are mapped into an application's process.
scarface74 7y ago
Again this shows a complete lack of understanding how software development works. 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.
- burfog 7y ago
  Put B,C,D on the other side of a privilege boundary. 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.
  - scarface74 7y ago
    There is always a performance penalty when switching between “rings”. Private methods are an “implementation detail” that shouldn’t be depended on. 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.

nickpeterson 7y ago

Apple does not like platforms that make it easy to publish lowest common denominator apps for iOS. It makes for garbage apps that look the same on iOS and Android and presents a false equivalency. They know most companies care about iOS customers than Android so this forces companies to spend more making the iOS app better than the Android app.

saagarjha 7y ago
Apple did not ban this app for being "garbage"–it's not even an iOS/Android app.

bdcravens 7y ago

There's no drama here. The oldest copy of the current app store guidelines I could find goes back to 2014: http://web.archive.org/web/20140903022336/https://developer.apple.com/app-store/review/guidelines/ 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.

fortran77 7y ago
Why does Electron need to use non-public APIs?
- bdcravens 7y ago
  My understanding is that it's Chromium that uses these (ostensibly for performance), not Electron, but Chromium is a dependency of Electron.
- lostmyoldone 7y ago
  According to a previous poster, the public API cause excessive power drain and is a fair bit slower. Since Apple usually use the argument of how the OS and API's are built to draw less power, it's quite peculiar that they can't find a more constructive solution than threatening to ban people and companies from the app store.
ken 7y ago
I think half the drama is that there are Electron apps in Apple's app stores already, e.g., a quick grep of Slack.app shows it contains all of these symbols in "Electron Framework.framework", yet it was apparently approved. Is this another case where you can break the rules but only if you're rich enough?

vunie 7y ago

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

scarface74 7y ago
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 developer when applications break.
- erichocean 7y ago
  > users will blame you not the developer when applications break 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.
- vunie 7y ago
  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.
  - scarface74 7y ago

_coveredInBees 7y ago

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

rdevnull 7y ago
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.
- z3t4 7y ago
  This is a problem with licensees like MIT. The essential features will be proprietary.

The_rationalist 7y ago

Electron apps can be submitted to the Apple store... Slack has recently been updated for example. This seems to only affect some developers, especially electron <= 5

rdevnull 7y ago
5 doesn't work either (others having the same issue in GitHub even got rejected with electron 3). Slack was updated a few days ago (I also had no such an error then). Also let's not forget that Slack is #1 in the App Store for the category business so is certainly not treated like a small app from an unknown developer ;)
pier25 7y ago
It would be a PR disaster for Apple and the MAS to block Slack from updating its Electron app.
ken 7y ago
Does Slack use private APIs?
- The_rationalist 7y ago
  No electron application use private APIs, it's the embedded chromium that do.

thrower123 7y ago

So there goes one of the primary reasons to use Electron... Cross-platform comparability always promises so much, and falls down in the implementation.

ilaksh 7y ago

That's what you get for supporting the Apple ecosystem. Its a closed system.

greggman2 7y ago

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/issues/20027 https://github.com/electron/electron/issues/20027

lostmyoldone 7y ago
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.
- saagarjha 7y ago
  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.

personjerry 7y ago

Does this apply to React Native apps?

ptlu 7y ago
React Native doesn't use Chromium under the hood, it renders using native iOS/Android components not a web view like Electron.

rado 7y ago

Good.

rs23296008n1 7y ago

At least Apple in this case actually provided a reason and list of APIs it is unhappy with. Armed with this you could either in theory or actuality chase through the maze of your app's dependencies. If this happened to me I'd then have a fighting chance of moving forward. 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.

flipetty 7y ago

why not contact Electron for this problem? There must be thousands of people having this at the moment

saagarjha 7y ago
They did: https://github.com/electron/electron/issues/20027 https://github.com/electron/electron/issues/20027

ghego1 7y ago

While this decision looks rational and technically solid on the surface, it makes the Mac platform, and in particular the Mac app store, even less appealing to developers. 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.

deleted 7y ago

[deleted]

jasonmp85 7y ago

So stop using Electron?

deleted 7y ago

[deleted]

paulie_a 7y ago

Hopefully this will happen everywhere. Electron apps are shit. If you don't want to write a native app. Don't support that platform.

fookitty 7y ago

Well to be honest and at the risk of getting down voted I think a fair amount of readers will agree that you shouldn't submit Electron apps not only on the Apple store but also elsewhere, it may be a good way to get a prototype out of the office but that's about it

YoannMoinet 7y ago

I was able to submit my app after an upgrade to Electron 6 with no issue whatsoever. 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.