7 ms·

No app is being booted. New updates are being rejected because of private API usage. If Electron fixes their usage of private APIs then this whole storm blows

by st3fan 7y ago

No app is being booted. New updates are being rejected because of private API usage. If Electron fixes their usage of private APIs then this whole storm blows over. Now if Apple introduces a rule that specifically says “non-AppKit apps are not welcome on the store” then let’s panic. But that is not happening here. (I’ll be the first in line to admit that private APIs and App Store rules are mostly limiting creativity and competition )

rubyn00bie 7y ago
+11 and thanks for the clarification, that even lessens the issue IMHO. ... my third and fourth cents. I don't think a lot of folks realize just how rich the ecosystem is for developing a MacOS or iOS application without writing ObjC or Swift. This is really one particular toolkit, that's doing something it's not supposed to, and that's it. You can write MacOS/iOS apps using C, C++, Java, JavaScript, .NET, Ruby, and I'm sure a bunch more each using something _not electron_ and are not having this problem right meow. The real pain I think for most people using Electron is that they're so far removed from the native SDKs it's scary to not know what the fuck really happened. That's fair, but that's also the price for using an abstraction like Electron. If you're not the one making the API calls, then you're opening yourself up to that potential issue and it's going to be scary until you understand it. Personally, I don't think I'm smart enough to understand that many layers of abstraction even if I wanted to; so, I don't use them and just write native code. Edit: Added MacOS or iOS for clarification since my point is the same for both.
- st3fan 7y ago
  This whole thing is about macOS not iOS.
stefan_ 7y ago
Instead of raging at Apple, what all these people shipping Electron apps seem to not have realized yet and are about to learn is that 1) the private API use is not in Electron, its in Chromium 2) and Google won't fix it because they 3) do not distribute through the Mac App store and 4) use private APIs to be competitive with Safari on things like power consumption. Your app now hinges on the ability of developers-that-are-not-you that you are not paying to maintain a private API free fork of Chromium and in the process not break such essential things like display composition where these APIs are used.
- st3fan 7y ago
  The right thing to do for the IOSurface or CALayer API is to file a radar and start a discussion with Apple to make it official. They do listen and this has happened plenty before. Rage tweets or Medium postings probably won’t help much though.
  - DaiPlusPlus 7y ago
    Apple will probably have to. * I understand the prviate API was about reducing power-consumption. * Apple sells itself on superior battery-life compared to Windows laptops. * Unfortunately, the Electron ecosystem is too big to dismiss - there's a lot of software using it that could potentially pull customers away from Apple's App Store if they weren't allowed back-in. * Despite the fact most of those apps are nominally free (Slack, Skype, etc), if they weren't available in the Mac App Store it would mean users would stop seeing the Mac App Store as the place to go for Mac software - thus damaging the brand. In short: if Apple doesn't document this power-management API and make it public then significantly fewer _important_ apps will be available in their Store which is bad for Apple's current long-term vision. If these apps do modify themseles to not use the battery-life API then they'll reduce the computer's battery life which then makes Apple look bad.
    - dwaite 7y ago
      It isn't a power management API. AFAIK Chrome is bridging in its cross-platform rendering at a late stage into CALayer, and the internal functions override CoreAnimation's handling of redrawing dirty layers. Similarly, it is using internal functions to map mach ports onto file descriptors because their cross-platform bits do not understand mach ports.
      - st3fan 7y ago
        Let’s be clear: they are important APIs that would allow non-Safari (WKWebView based really) browsers be competitive on macOS.

by st3fan 7y ago

rubyn00bie 7y ago

+11 and thanks for the clarification, that even lessens the issue IMHO. ... my third and fourth cents. I don't think a lot of folks realize just how rich the ecosystem is for developing a MacOS or iOS application without writing ObjC or Swift. This is really one particular toolkit, that's doing something it's not supposed to, and that's it. You can write MacOS/iOS apps using C, C++, Java, JavaScript, .NET, Ruby, and I'm sure a bunch more each using something _not electron_ and are not having this problem right meow. The real pain I think for most people using Electron is that they're so far removed from the native SDKs it's scary to not know what the fuck really happened. That's fair, but that's also the price for using an abstraction like Electron. If you're not the one making the API calls, then you're opening yourself up to that potential issue and it's going to be scary until you understand it. Personally, I don't think I'm smart enough to understand that many layers of abstraction even if I wanted to; so, I don't use them and just write native code. Edit: Added MacOS or iOS for clarification since my point is the same for both.

st3fan 7y ago
This whole thing is about macOS not iOS.

stefan_ 7y ago

Instead of raging at Apple, what all these people shipping Electron apps seem to not have realized yet and are about to learn is that 1) the private API use is not in Electron, its in Chromium 2) and Google won't fix it because they 3) do not distribute through the Mac App store and 4) use private APIs to be competitive with Safari on things like power consumption. Your app now hinges on the ability of developers-that-are-not-you that you are not paying to maintain a private API free fork of Chromium and in the process not break such essential things like display composition where these APIs are used.

st3fan 7y ago
The right thing to do for the IOSurface or CALayer API is to file a radar and start a discussion with Apple to make it official. They do listen and this has happened plenty before. Rage tweets or Medium postings probably won’t help much though.
- DaiPlusPlus 7y ago
  Apple will probably have to. * I understand the prviate API was about reducing power-consumption. * Apple sells itself on superior battery-life compared to Windows laptops. * Unfortunately, the Electron ecosystem is too big to dismiss - there's a lot of software using it that could potentially pull customers away from Apple's App Store if they weren't allowed back-in. * Despite the fact most of those apps are nominally free (Slack, Skype, etc), if they weren't available in the Mac App Store it would mean users would stop seeing the Mac App Store as the place to go for Mac software - thus damaging the brand. In short: if Apple doesn't document this power-management API and make it public then significantly fewer _important_ apps will be available in their Store which is bad for Apple's current long-term vision. If these apps do modify themseles to not use the battery-life API then they'll reduce the computer's battery life which then makes Apple look bad.
  - dwaite 7y ago
    It isn't a power management API. AFAIK Chrome is bridging in its cross-platform rendering at a late stage into CALayer, and the internal functions override CoreAnimation's handling of redrawing dirty layers. Similarly, it is using internal functions to map mach ports onto file descriptors because their cross-platform bits do not understand mach ports.
    - st3fan 7y ago
      Let’s be clear: they are important APIs that would allow non-Safari (WKWebView based really) browsers be competitive on macOS.