5 ms·

Because Electron developers might say "we fixed it" and the app developer might resubmit based on that and now they're banned due to a mistake made by an upstre

Because Electron developers might say "we fixed it" and the app developer might resubmit based on that and now they're banned due to a mistake made by an upstream dependency. It's not like this app developer is intentionally using private APIs. "Resubmitting the same thing and hoping that it doesn't get caught" seems to be a strawman.

saagarjha 7y ago
Hence why you should audit your third-party dependencies in cases like these.
- winkeltripel 7y ago
  I suspect that most devs don't do that. I can't imagine finding the time fir that.
  - josephg 7y ago
    Who do you imagine is responsible for making sure your app doesn’t contain malware? The only answer is that as a developer, you are responsible. Yes, we have to make calculated risks. But the buck stops at you. There is nobody else who can take responsibility for the contents of your app.
    - rdevnull 7y ago
      you simply notarized the app and you know that there is no malware. Also we are talking about ElectronJS and Chromium -- not exactly untreatable sources. Note that apple does check for malware and quality on the upload stage itself (now done via transporter) so it wouldn't even make it to then review state if something is dodgy.
      - josephg 7y ago
        Apple can’t magically tell that there’s no malware in an app you upload. There is no automated scan which can detect all security vulnerabilities or back doors in code. And we’re talking about electron plus hundreds to thousands of npm modules - which contain who knows what. If you pull in some bad modules, directly or transitively, and as a result your app steals my data or worse, that’s on you for shipping malicious code to my computer. There is no one else who can be responsible for that. Not Apple. Not the user. You.
  - JohnFen 7y ago
    I've done that over my entire career. It's always been a requirement. To say you can't find time for it is the same as saying that you can't find time to complete development.
- jonny_eh 7y ago
  How exactly?
  - saagarjha 7y ago
    I would assume that a quick grep through your project for the symbols mentioned would tell you where the issue is.
    - drewbug 7y ago
      what if the function calls are generated with macros or something?
      - saagarjha 7y ago
        grep the generated binary.
      - justinclift 7y ago
        Isn't it literally the responsibility of the developer to figure it out, instead of just ignoring it because it's potentially hard?
    - rdevnull 7y ago
      it would but it wouldn't solve the problem. This would require the developer to modify electron and basically run his own branch. It would then make your package possibly acceptable (but attention here: as Apple clearly stated keeping too use private APIs can get you banned so if you miss something you can lose your access to the apple store) leaving however everyone else using electron with the same problem. So the solution has to come from Electron.
      - JohnFen 7y ago
        > So the solution has to come from Electron. And until it does, developers should not use Electron. There's a number of reasons why I refuse to use Electon-based apps, and this is one of them.
floatingatoll 7y ago
That resubmit approach ways used by at least one camera app years ago who masked their private API usage to secretly include a volume button “take photo” feature. They were told to knock it off (and Apple also added that option to the API at a later date). Between that and the folks who hid MAME in an app or whatever, I think Apple is not simply constructing straw men when they warn that attempts to circumvent the spirit of their request - and the letter of it - will result in a lifetime ban.
- kalleboo 7y ago
  Camera+ didn't use a hidden API - they just used a standard system volume control but placed it offscreen and monitored if the volume changed (and then lower it imperceptibly if you hit 100%). And Apple has still not added an API to do this officially, last I checked all third party camera apps use a similar hack. What changed was just the interpretation of the app store rules - the rules said something like "you're not allowed to use hardware buttons in a non-standard way". Once they added the volume shutter feature to the system camera, now it's not a non-standard way and it's not against the rules.
mihaela 7y ago
In the article, Apple support explained how he might check whether the private APIs are still being called. "It's not like this app developer is intentionally using private APIs" No, he is just incompetent.
- saagarjha 7y ago
  Please don't attack people like this. I'm fairly sure they're here reading the comments, and even if they weren't, you don't need to call them things.
  - LeoNatan25 7y ago
    Sometimes saying the truth is unpleasant. But the fact is, these developers have no idea what they are using, or what runs on the users' machines. They bring a ton of dependencies and have no idea what those involve. If that is not incompetency, what is?

saagarjha 7y ago

Hence why you should audit your third-party dependencies in cases like these.

winkeltripel 7y ago
I suspect that most devs don't do that. I can't imagine finding the time fir that.
- josephg 7y ago
  Who do you imagine is responsible for making sure your app doesn’t contain malware? The only answer is that as a developer, you are responsible. Yes, we have to make calculated risks. But the buck stops at you. There is nobody else who can take responsibility for the contents of your app.
  - rdevnull 7y ago
    you simply notarized the app and you know that there is no malware. Also we are talking about ElectronJS and Chromium -- not exactly untreatable sources. Note that apple does check for malware and quality on the upload stage itself (now done via transporter) so it wouldn't even make it to then review state if something is dodgy.
    - josephg 7y ago
      Apple can’t magically tell that there’s no malware in an app you upload. There is no automated scan which can detect all security vulnerabilities or back doors in code. And we’re talking about electron plus hundreds to thousands of npm modules - which contain who knows what. If you pull in some bad modules, directly or transitively, and as a result your app steals my data or worse, that’s on you for shipping malicious code to my computer. There is no one else who can be responsible for that. Not Apple. Not the user. You.
- JohnFen 7y ago
  I've done that over my entire career. It's always been a requirement. To say you can't find time for it is the same as saying that you can't find time to complete development.
jonny_eh 7y ago
How exactly?
- saagarjha 7y ago
  I would assume that a quick grep through your project for the symbols mentioned would tell you where the issue is.
  - drewbug 7y ago
    what if the function calls are generated with macros or something?
    - saagarjha 7y ago
      grep the generated binary.
    - justinclift 7y ago
      Isn't it literally the responsibility of the developer to figure it out, instead of just ignoring it because it's potentially hard?
  - rdevnull 7y ago
    it would but it wouldn't solve the problem. This would require the developer to modify electron and basically run his own branch. It would then make your package possibly acceptable (but attention here: as Apple clearly stated keeping too use private APIs can get you banned so if you miss something you can lose your access to the apple store) leaving however everyone else using electron with the same problem. So the solution has to come from Electron.
    - JohnFen 7y ago
      > So the solution has to come from Electron. And until it does, developers should not use Electron. There's a number of reasons why I refuse to use Electon-based apps, and this is one of them.

floatingatoll 7y ago

That resubmit approach ways used by at least one camera app years ago who masked their private API usage to secretly include a volume button “take photo” feature. They were told to knock it off (and Apple also added that option to the API at a later date). Between that and the folks who hid MAME in an app or whatever, I think Apple is not simply constructing straw men when they warn that attempts to circumvent the spirit of their request - and the letter of it - will result in a lifetime ban.

kalleboo 7y ago
Camera+ didn't use a hidden API - they just used a standard system volume control but placed it offscreen and monitored if the volume changed (and then lower it imperceptibly if you hit 100%). And Apple has still not added an API to do this officially, last I checked all third party camera apps use a similar hack. What changed was just the interpretation of the app store rules - the rules said something like "you're not allowed to use hardware buttons in a non-standard way". Once they added the volume shutter feature to the system camera, now it's not a non-standard way and it's not against the rules.

mihaela 7y ago

In the article, Apple support explained how he might check whether the private APIs are still being called. "It's not like this app developer is intentionally using private APIs" No, he is just incompetent.

saagarjha 7y ago
Please don't attack people like this. I'm fairly sure they're here reading the comments, and even if they weren't, you don't need to call them things.
- LeoNatan25 7y ago
  Sometimes saying the truth is unpleasant. But the fact is, these developers have no idea what they are using, or what runs on the users' machines. They bring a ton of dependencies and have no idea what those involve. If that is not incompetency, what is?