3 ms·

Looking back at the number of stupid mistakes, missteps, and general clumsiness which have come out of Apple's App Store review process, it's far more likely th

Looking back at the number of stupid mistakes, missteps, and general clumsiness which have come out of Apple's App Store review process, it's far more likely this is just another boneheaded gaff somewhere on Apple's review team. This is quite clearly one of those cases where people are attributing malice where incompetence of one sort or another is almost certainly the cause. Most likely either: —This should have been nipped in the bud years ago when they added the private APIs to electron. —They are taking a ham-fisted approach to cleaning up some App Store abuses. —They've updated the tools they use to review App Store submissions. Or maybe a little of all of the above. The big problem is Apple is again stumbling around with little or no communications to the developer community, fucking up a lot of developer's lives. This isn't some conscious malicious scheme... just frustrating corporate blindness.

nomel 7y ago
> with little or no communications to the developer community, About the use of private APIs in App Store apps? The communication has been consistent and loud enough that most non-Apple developers are completely aware that using a private API will get your app rejected.
- ogre_codes 7y ago
  I agree with you that private APIs should be off limits, particularly to the author of a library which has broad use. But at this point, Apple's previous inactions sent the wrong message and by acting on this now with zero grace period a lot of developers are left in the lurch. Whether you want to point the finger at Electron or Apple doesn't matter, Apple has the opportunity to make developers lives easier here and instead they are just indifferent to it which is frustrating.
  - dwaite 7y ago
    From reading the issue on GitHub, I see that there was a failure, then it started working, then two months later it started failing again. I suspect there was a two month grace period. The problem would be that they gave that grace period to a developer (like Slack) rather than working with some Electron framework team. I also suspect a reason the tools were revised to reject apps with use of these internal functions is that some of them are going away in March.
    - ogre_codes 7y ago
      > I also suspect a reason the tools were revised to reject apps with use of these internal functions is that some of them are going away in March. This is the thing, there are good reasons Apple should reserve certain libraries as private and not support them. The fact that Electron dipped into private libraries and didn't have a fallback plan for WHEN Apple clamped down on this is just poor planning. That said... a small amount of communications and/ or tolerance from Apple would go a long way towards developer good will here. Lots of small developers getting burned here.
ridiculous_fish 7y ago
This is a good take. In particular ObjC is highly dynamic and a simple `nm` isn't sufficient to catch all private API usage. The strategies for detecting private API usage are evolving.
- saagarjha 7y ago
  FWIW, Electron directly links against the private APIs.

nomel 7y ago

> with little or no communications to the developer community, About the use of private APIs in App Store apps? The communication has been consistent and loud enough that most non-Apple developers are completely aware that using a private API will get your app rejected.

ogre_codes 7y ago
I agree with you that private APIs should be off limits, particularly to the author of a library which has broad use. But at this point, Apple's previous inactions sent the wrong message and by acting on this now with zero grace period a lot of developers are left in the lurch. Whether you want to point the finger at Electron or Apple doesn't matter, Apple has the opportunity to make developers lives easier here and instead they are just indifferent to it which is frustrating.
- dwaite 7y ago
  From reading the issue on GitHub, I see that there was a failure, then it started working, then two months later it started failing again. I suspect there was a two month grace period. The problem would be that they gave that grace period to a developer (like Slack) rather than working with some Electron framework team. I also suspect a reason the tools were revised to reject apps with use of these internal functions is that some of them are going away in March.
  - ogre_codes 7y ago
    > I also suspect a reason the tools were revised to reject apps with use of these internal functions is that some of them are going away in March. This is the thing, there are good reasons Apple should reserve certain libraries as private and not support them. The fact that Electron dipped into private libraries and didn't have a fallback plan for WHEN Apple clamped down on this is just poor planning. That said... a small amount of communications and/ or tolerance from Apple would go a long way towards developer good will here. Lots of small developers getting burned here.

ridiculous_fish 7y ago

This is a good take. In particular ObjC is highly dynamic and a simple `nm` isn't sufficient to catch all private API usage. The strategies for detecting private API usage are evolving.

saagarjha 7y ago
FWIW, Electron directly links against the private APIs.