13 ms·

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

> 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
      And? That's exactly why internal APIs should be allowed. The problem isn't the usage of an internal API, the problem is the breaking of an internal API. Which is already covered by App Store testing and guidelines which already require your app isn't a broken mess.
throwGuardian 7y ago
This summarizes Apple's attitude to developers. Eventually, you'll run foul of some obscure nonsensical Apple policy, and Apple will not hesitate to show you the finger. And Shame you for your dev choices.
- partiallypro 7y ago
  Apple just rebuilds any popular app and makes it first party anyhow. At some point most developers will stop bothering just for that.
  - kick 7y ago
    Really? Can you link their Sketch and Photoshop replacements? I know some designers who could use those.
    - partiallypro 7y ago
      Apple doesn't rebuild apps that require massive features, but they do often build things into the OS or as base apps that negates the need for apps, some of them wildly popular.
- saagarjha 7y ago
  Calling private API is not nonsensical Apple policy, and you're reducing the instances in which rejection is nonsensical Apple policy.
  - throwGuardian 7y ago
    The post shot to #1 on HN in no time, because the developer community thinks this rejection, and it's backing policy to be nonsensical.
    - saagarjha 7y ago
      > because the developer community Which is not a homogenous group, both in ideals and for why they'd upvote a submission like this. > this rejection, and it's backing policy to be nonsensical They're different things. I personally think the rejection is perfectly sensical in the context of the backing policy, with which I don't fully agree.
ajross 7y ago
Wouldn't a more reasonable path be for Apple to talk directly to Electron and Chromium about the issue and work out a path forward before rattling a banhammer at app developers, though? I mean, did Electron or Google just refuse to fix this? Are these private APIs things that actually get exercised in the apps being threatened? It's not so much about culpability or Apple's right to control their app deployment environment, it's that the response seems really disproportionate to the offense and pretty badly misdirected. A more conspiratorially minded poster might wonder if the real goal here was to dissuade developers from using cross-platform frameworks...
- jbverschoor 7y ago
  Why? It’s very clear what’s wrong. Don’t use private APIs. Thank you Apple for keeping things clean!!
  - imtringued 7y ago
    Chrome and Firefox are using a critical feature that has no equivalent public API. If they didn't then they would end up using 3x as much energy which is important for the battery life of laptops and phones.
- bdcravens 7y ago
  No. Apple is responsible for their platform, not the ecosystem.
kjksf 7y ago
How short are memories. I remember how Microsoft was vilified for supposedly having secret Windows APIs that allowed Microsoft apps to get better performance. That was mostly made up and even if such APIs existed, any program could have used it. Even at the height of corporate arrogance Microsoft didn't dream of banning developers for using undocumented APIs. Apple seems intent on becoming more evil than Microsoft ever was. At some point the goodwill they built as underdog making great products will run out and some government somewhere will take an anti-trust action. I'm just hoping it'll happen sooner rather than later.
- saagarjha 7y ago
  I believe CAContext is private API but performs better than documented alternatives.
- BillinghamJ 7y ago
  Undocumented APIs get broken. That's a big problem for user experience, particularly if it happens to be being done by a framework relied upon by a very high percentage of app use. Seems pretty fair imo
  - DarkmSparks 7y ago
    Is this why so many of the apps on my ipad "need to be updated to work with this version of ios"? and there is no update.
    - saagarjha 7y ago
      No, that's because they're 32-bit apps, which iOS no longer supports.
      - dingo_bat 7y ago
        Which is the same thing.
        7y ago
rdevnull 7y ago
this is exactly what they told me in the follow up message. I am somehow surprised how the bug in electron repository is not given much importance at all.
- saagarjha 7y ago
  > I am somehow surprised how the bug in electron repository is not given much importance at all. By Apple, or the Electron developers?
  - rdevnull 7y ago
    after this post apparently the issue has been upgraded to a bug and someone is working on it. I hope they will find a solution OR at least let everyone know that they shouldn't bother creating MAS packages and upload the apple store. I think it is dangerous as it can get you banned.
vbezhenar 7y ago
Apparently Apple silently whitelisted Electron for some time.

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
    And? That's exactly why internal APIs should be allowed. The problem isn't the usage of an internal API, the problem is the breaking of an internal API. Which is already covered by App Store testing and guidelines which already require your app isn't a broken mess.

throwGuardian 7y ago

This summarizes Apple's attitude to developers. Eventually, you'll run foul of some obscure nonsensical Apple policy, and Apple will not hesitate to show you the finger. And Shame you for your dev choices.

partiallypro 7y ago
Apple just rebuilds any popular app and makes it first party anyhow. At some point most developers will stop bothering just for that.
- kick 7y ago
  Really? Can you link their Sketch and Photoshop replacements? I know some designers who could use those.
  - partiallypro 7y ago
    Apple doesn't rebuild apps that require massive features, but they do often build things into the OS or as base apps that negates the need for apps, some of them wildly popular.
saagarjha 7y ago
Calling private API is not nonsensical Apple policy, and you're reducing the instances in which rejection is nonsensical Apple policy.
- throwGuardian 7y ago
  The post shot to #1 on HN in no time, because the developer community thinks this rejection, and it's backing policy to be nonsensical.
  - saagarjha 7y ago
    > because the developer community Which is not a homogenous group, both in ideals and for why they'd upvote a submission like this. > this rejection, and it's backing policy to be nonsensical They're different things. I personally think the rejection is perfectly sensical in the context of the backing policy, with which I don't fully agree.

ajross 7y ago

Wouldn't a more reasonable path be for Apple to talk directly to Electron and Chromium about the issue and work out a path forward before rattling a banhammer at app developers, though? I mean, did Electron or Google just refuse to fix this? Are these private APIs things that actually get exercised in the apps being threatened? It's not so much about culpability or Apple's right to control their app deployment environment, it's that the response seems really disproportionate to the offense and pretty badly misdirected. A more conspiratorially minded poster might wonder if the real goal here was to dissuade developers from using cross-platform frameworks...

jbverschoor 7y ago
Why? It’s very clear what’s wrong. Don’t use private APIs. Thank you Apple for keeping things clean!!
- imtringued 7y ago
  Chrome and Firefox are using a critical feature that has no equivalent public API. If they didn't then they would end up using 3x as much energy which is important for the battery life of laptops and phones.
bdcravens 7y ago
No. Apple is responsible for their platform, not the ecosystem.

kjksf 7y ago

How short are memories. I remember how Microsoft was vilified for supposedly having secret Windows APIs that allowed Microsoft apps to get better performance. That was mostly made up and even if such APIs existed, any program could have used it. Even at the height of corporate arrogance Microsoft didn't dream of banning developers for using undocumented APIs. Apple seems intent on becoming more evil than Microsoft ever was. At some point the goodwill they built as underdog making great products will run out and some government somewhere will take an anti-trust action. I'm just hoping it'll happen sooner rather than later.

saagarjha 7y ago
I believe CAContext is private API but performs better than documented alternatives.
BillinghamJ 7y ago
Undocumented APIs get broken. That's a big problem for user experience, particularly if it happens to be being done by a framework relied upon by a very high percentage of app use. Seems pretty fair imo
- DarkmSparks 7y ago
  Is this why so many of the apps on my ipad "need to be updated to work with this version of ios"? and there is no update.
  - saagarjha 7y ago
    No, that's because they're 32-bit apps, which iOS no longer supports.
    - dingo_bat 7y ago
      Which is the same thing.
      - 7y ago

rdevnull 7y ago

this is exactly what they told me in the follow up message. I am somehow surprised how the bug in electron repository is not given much importance at all.

saagarjha 7y ago
> I am somehow surprised how the bug in electron repository is not given much importance at all. By Apple, or the Electron developers?
- rdevnull 7y ago
  after this post apparently the issue has been upgraded to a bug and someone is working on it. I hope they will find a solution OR at least let everyone know that they shouldn't bother creating MAS packages and upload the apple store. I think it is dangerous as it can get you banned.

vbezhenar 7y ago

Apparently Apple silently whitelisted Electron for some time.