6 ms·

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

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.
      - jsjohnst 7y ago
        If GP is correct, that’s not the case. They are important APIs for someone who wants to maintain their cross-platform abstraction layer without muddying up their codebase.
      - threeseed 7y ago
        This comment makes no sense to me. How are Firefox and Chrome not competitive given that Safari isn't the overwhelmingly dominant browser ?
        yoz-y 7y ago
        “On macOS” is the important part. Safari is by far the most battery friendly browser there and quite possibly has significant market share too. Mozilla has recently managed to reduce their consumption significantly using these APIs: https://mozillagfx.wordpress.com/2019/10/22/dramatically-reduced-power-usage-in-firefox-70-on-macos-with-core-animation/ https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...
        st3fan 7y ago
        They are now because they both use those APIs. You can read about the impact of this specific one here: https://mozillagfx.wordpress.com/2019/10/22/dramatically-reduced-power-usage-in-firefox-70-on-macos-with-core-animation/ https://mozillagfx.wordpress.com/2019/10/22/dramatically-red... Before using those private APIs, with no other options to reach the same performance as Safari, both Chrome and Firefox were in a completely different league.
  - deleted 7y ago
    [deleted]
  - coldtea 7y ago
    > 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.* Spotify and co will care more of getting into that 30% of the mobile market (and the more lucrative 30% at that) by doing whatever they can, than Apple would worry about them leaving because no Electron is allowed...
    - cglace 7y ago
      This isn’t about the mobile market...
      - coldtea 7y ago
        The apps mentioned (Spotify, Slack) are also available on the mobile market. Since they need to have them there, and don't use Electron there already, they can have them in macOS without it trivially.
    - brodyprice 7y ago
      Mobile market? Electron is a framework for desktop apps...
    - michaelmrose 7y ago
      Electron is a tool for the desktop/laptop market where apple has a smaller share yet. It's more like 10%. It's also a market where people are used to manually installing apps. The worst case scenario is that apple loses some revenue and major players avoid the mac app store for desktop apps. Apple who gets most of their money from mobile will not care. App developers will lose some convenience but negligible money and they wont care.
      - DaiPlusPlus 7y ago
        Even so, there is a halo-effect - and customers’ expectations to meet.
  - tekknik 7y ago
    > 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. I personally don’t care. In fact I grow tired of the throw everything in a webview cause we’re lazy mentality. Build a proper app that looks like it’s a mac app. Also I grow tired of the crap performance these “apps” have. I say remove the lot of them and force people to build a proper app. Electron is Flash 2.0
- madeofpalk 7y ago
  The App Store Developer guidelines state that “going to the press won’t get you anywhere”, but there has been countless examples of this just not being the case. Radar goes nowhere, going public does.
  - bilbo0s 7y ago
    I hate to be "that guy", but I can tell you of at least one instance in our case where going public went nowhere. It was more like, case dismissed with prejudice. I don't know about radar. Never tried it. Given my own experiences in the past, I would doubt that radar goes much of anywhere either. Apple just doesn't seem like they move unless and until they want to. But again, I can't say for sure about radar, as I said, I've never gone that route. By far the best route to go is to be in a position where Apple was about to make the change you wanted anyway. But you probably have to get pretty lucky for that to happen.
  - rosybox 7y ago
    > The App Store Developer guidelines state that “going to the press won’t get you anywhere” Where does it state this? https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/
  - threeseed 7y ago
    Radars don't go nowhere. Each one is read and triaged by the product managers. The question is whether there is merit from Apple's perspective in making these APIs public. Because often we find out at WWDC a year later why they didn't make it public and it's because of some foundational rearchitecture.
    - earthboundkid 7y ago
      And I'm sure the managers do a very tasteful ceremony where they read the radars out loud before they print and burn them on the sacred pyre at the end of the month.
      - 7y ago
- chongli 7y ago
  I don’t think Apple sees it as in their best interests to support Electron apps that use a private API to which they intend to make breaking changes. Effectively, this hampers their own ability to refactor and rearchitect their own products, all for the benefit of a competitor. Not only that, but if Apple didn’t ban the use of private APIs then they would be blamed whenever one of their updates broke all these popular Electron apps. In a sense it’s like letting squatters onto your land. If you ignore them long enough then at some point society decides they have the right to be there, and then you become the bad guy for deciding to enforce your own property rights.
  - roblabla 7y ago
    What your parent is suggesting is to make those private APIs public, or at least make a public replacement. It's not calling into question the ban, but instead saying that there's a hole in the public API Apple provide and that they should bring in new public APIs to fix that hole. The last time this came up I asked why those APIs were being used, and was sent two interesting links by users skymt and Humphrey, explaining why both Chrome and Firefox use those private APIs: - Chrome explanation: https://www.chromium.org/developers/design-documents/chromium-graphics/mac-delegated-rendering https://www.chromium.org/developers/design-documents/chromiu... - Firefox explanation: https://mozillagfx.wordpress.com/2019/10/22/dramatically-reduced-power-usage-in-firefox-70-on-macos-with-core-animation/ https://mozillagfx.wordpress.com/2019/10/22/dramatically-red... Windows has public APIs for doing those things. It's pretty clear that there's a need for them. Apple should absolutely design a stable solution for those, since there's a clear demand.
    - jolux 7y ago
      I don't think Firefox actually uses those private APIs. Do you have proof of this? That post only mentions CALayer and IOSurface, which are public.
    - chongli 7y ago
      I am not completely familiar with these APIs but from what I gather they are primarily intended for low level rendering and to support them means supporting frameworks that bypass all of Apple’s native APIs. Apple does not want to do this for business reasons. Microsoft does, but they have a different business model than Apple. Apple is in the business of selling their own hardware which means they want exclusive apps. If everything is cross platform then Macs become an overpriced commodity. Why even develop macOS at that point?
sesutton 7y ago
They'll just stop distributing versions through the Mac App store and the Mac App store will become even more irrelevant.
- threeseed 7y ago
  App Store will always be relevant since it's such a popular distribution channel. And one app not being on there isn't going to change that.
- coldtea 7y ago
  They're putting their apps out for the money, not for some principle. If they need to drop Electron to get into the more lucrative 30% of the mobile market, iOS users, they'll do it as fast as they can...
  - cormacrelf 7y ago
    Electron doesn’t run on iPhone?
    - httpsterio 7y ago
      it does with cordova
      - cormacrelf 7y ago
        Nope, Electron is a platform that Cordova runs on.
  - tracker1 7y ago
    Many of the apps in question are free apps... I tend to have Spotify and VS Code open most of the day. Then again, I replaced Mac on my home desktop with Linux, and getting rid of my rmbp in a few weeks.
    - coldtea 7y ago
snowwrestler 7y ago
I don't see why Google would be inclined to fix anything related to iOS because they seem to be currently deploying a multi-channel strategy to put pressure on Apple to let Chrome be loaded as a native app alternate browser. From Google's perspective, Chromium-based apps being booted from the iOS App Store is probably a fantastic thing if it leads to articles like the one linked up top here. "Apple makes it hard to use the web" is a much better message for Google than "Apple doesn't let users install Chrome so we can't collect as much data from iOS users as we do everywhere else." Even though the latter is the truth behind their push to get Chrome natively onto iOS.
- st3fan 7y ago
  This is about macOS not iOS. Electron and Chromium on iOS is not a thing.
shantly 7y ago
> 4) use private APIs to be competitive with Safari on things like power consumption. Uh, if that's the case then I think they're barking up the wrong tree. Just given. How that's going for them.
sieabahlpark 7y ago
Makes me think this is a move by Google to make Android more appealing.
elcritch 7y ago
Or perhaps fork Electron to provide a version which uses Safari or even WPE [1]. I’m using WPE in an embedded device since it has better memory and GPU usage than chromium. 1: https://webkit.org/wpe/ https://webkit.org/wpe/

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.
    - jsjohnst 7y ago
      If GP is correct, that’s not the case. They are important APIs for someone who wants to maintain their cross-platform abstraction layer without muddying up their codebase.
    - threeseed 7y ago
      This comment makes no sense to me. How are Firefox and Chrome not competitive given that Safari isn't the overwhelmingly dominant browser ?
      - yoz-y 7y ago
        “On macOS” is the important part. Safari is by far the most battery friendly browser there and quite possibly has significant market share too. Mozilla has recently managed to reduce their consumption significantly using these APIs: https://mozillagfx.wordpress.com/2019/10/22/dramatically-reduced-power-usage-in-firefox-70-on-macos-with-core-animation/ https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...
      - st3fan 7y ago
        They are now because they both use those APIs. You can read about the impact of this specific one here: https://mozillagfx.wordpress.com/2019/10/22/dramatically-reduced-power-usage-in-firefox-70-on-macos-with-core-animation/ https://mozillagfx.wordpress.com/2019/10/22/dramatically-red... Before using those private APIs, with no other options to reach the same performance as Safari, both Chrome and Firefox were in a completely different league.
- deleted 7y ago
  [deleted]
- coldtea 7y ago
  > 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.* Spotify and co will care more of getting into that 30% of the mobile market (and the more lucrative 30% at that) by doing whatever they can, than Apple would worry about them leaving because no Electron is allowed...
  - cglace 7y ago
    This isn’t about the mobile market...
    - coldtea 7y ago
      The apps mentioned (Spotify, Slack) are also available on the mobile market. Since they need to have them there, and don't use Electron there already, they can have them in macOS without it trivially.
  - brodyprice 7y ago
    Mobile market? Electron is a framework for desktop apps...
  - michaelmrose 7y ago
    Electron is a tool for the desktop/laptop market where apple has a smaller share yet. It's more like 10%. It's also a market where people are used to manually installing apps. The worst case scenario is that apple loses some revenue and major players avoid the mac app store for desktop apps. Apple who gets most of their money from mobile will not care. App developers will lose some convenience but negligible money and they wont care.
    - DaiPlusPlus 7y ago
      Even so, there is a halo-effect - and customers’ expectations to meet.
- tekknik 7y ago
  > 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. I personally don’t care. In fact I grow tired of the throw everything in a webview cause we’re lazy mentality. Build a proper app that looks like it’s a mac app. Also I grow tired of the crap performance these “apps” have. I say remove the lot of them and force people to build a proper app. Electron is Flash 2.0
madeofpalk 7y ago
The App Store Developer guidelines state that “going to the press won’t get you anywhere”, but there has been countless examples of this just not being the case. Radar goes nowhere, going public does.
- bilbo0s 7y ago
  I hate to be "that guy", but I can tell you of at least one instance in our case where going public went nowhere. It was more like, case dismissed with prejudice. I don't know about radar. Never tried it. Given my own experiences in the past, I would doubt that radar goes much of anywhere either. Apple just doesn't seem like they move unless and until they want to. But again, I can't say for sure about radar, as I said, I've never gone that route. By far the best route to go is to be in a position where Apple was about to make the change you wanted anyway. But you probably have to get pretty lucky for that to happen.
- rosybox 7y ago
  > The App Store Developer guidelines state that “going to the press won’t get you anywhere” Where does it state this? https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/
- threeseed 7y ago
  Radars don't go nowhere. Each one is read and triaged by the product managers. The question is whether there is merit from Apple's perspective in making these APIs public. Because often we find out at WWDC a year later why they didn't make it public and it's because of some foundational rearchitecture.
  - earthboundkid 7y ago
    And I'm sure the managers do a very tasteful ceremony where they read the radars out loud before they print and burn them on the sacred pyre at the end of the month.
    - 7y ago
chongli 7y ago
I don’t think Apple sees it as in their best interests to support Electron apps that use a private API to which they intend to make breaking changes. Effectively, this hampers their own ability to refactor and rearchitect their own products, all for the benefit of a competitor. Not only that, but if Apple didn’t ban the use of private APIs then they would be blamed whenever one of their updates broke all these popular Electron apps. In a sense it’s like letting squatters onto your land. If you ignore them long enough then at some point society decides they have the right to be there, and then you become the bad guy for deciding to enforce your own property rights.
- roblabla 7y ago
  What your parent is suggesting is to make those private APIs public, or at least make a public replacement. It's not calling into question the ban, but instead saying that there's a hole in the public API Apple provide and that they should bring in new public APIs to fix that hole. The last time this came up I asked why those APIs were being used, and was sent two interesting links by users skymt and Humphrey, explaining why both Chrome and Firefox use those private APIs: - Chrome explanation: https://www.chromium.org/developers/design-documents/chromium-graphics/mac-delegated-rendering https://www.chromium.org/developers/design-documents/chromiu... - Firefox explanation: https://mozillagfx.wordpress.com/2019/10/22/dramatically-reduced-power-usage-in-firefox-70-on-macos-with-core-animation/ https://mozillagfx.wordpress.com/2019/10/22/dramatically-red... Windows has public APIs for doing those things. It's pretty clear that there's a need for them. Apple should absolutely design a stable solution for those, since there's a clear demand.
  - jolux 7y ago
    I don't think Firefox actually uses those private APIs. Do you have proof of this? That post only mentions CALayer and IOSurface, which are public.
  - chongli 7y ago
    I am not completely familiar with these APIs but from what I gather they are primarily intended for low level rendering and to support them means supporting frameworks that bypass all of Apple’s native APIs. Apple does not want to do this for business reasons. Microsoft does, but they have a different business model than Apple. Apple is in the business of selling their own hardware which means they want exclusive apps. If everything is cross platform then Macs become an overpriced commodity. Why even develop macOS at that point?

sesutton 7y ago

They'll just stop distributing versions through the Mac App store and the Mac App store will become even more irrelevant.

threeseed 7y ago
App Store will always be relevant since it's such a popular distribution channel. And one app not being on there isn't going to change that.
coldtea 7y ago
They're putting their apps out for the money, not for some principle. If they need to drop Electron to get into the more lucrative 30% of the mobile market, iOS users, they'll do it as fast as they can...
- cormacrelf 7y ago
  Electron doesn’t run on iPhone?
  - httpsterio 7y ago
    it does with cordova
    - cormacrelf 7y ago
      Nope, Electron is a platform that Cordova runs on.
- tracker1 7y ago
  Many of the apps in question are free apps... I tend to have Spotify and VS Code open most of the day. Then again, I replaced Mac on my home desktop with Linux, and getting rid of my rmbp in a few weeks.
  - coldtea 7y ago

snowwrestler 7y ago

I don't see why Google would be inclined to fix anything related to iOS because they seem to be currently deploying a multi-channel strategy to put pressure on Apple to let Chrome be loaded as a native app alternate browser. From Google's perspective, Chromium-based apps being booted from the iOS App Store is probably a fantastic thing if it leads to articles like the one linked up top here. "Apple makes it hard to use the web" is a much better message for Google than "Apple doesn't let users install Chrome so we can't collect as much data from iOS users as we do everywhere else." Even though the latter is the truth behind their push to get Chrome natively onto iOS.

st3fan 7y ago
This is about macOS not iOS. Electron and Chromium on iOS is not a thing.

shantly 7y ago

> 4) use private APIs to be competitive with Safari on things like power consumption. Uh, if that's the case then I think they're barking up the wrong tree. Just given. How that's going for them.

sieabahlpark 7y ago

Makes me think this is a move by Google to make Android more appealing.

elcritch 7y ago

Or perhaps fork Electron to provide a version which uses Safari or even WPE [1]. I’m using WPE in an embedded device since it has better memory and GPU usage than chromium. 1: https://webkit.org/wpe/ https://webkit.org/wpe/