11 ms·

What's bullshit about banning someone who has been notified that they are in violation of the rules and then tries to hide their use of private APIs rather than

What's bullshit about banning someone who has been notified that they are in violation of the rules and then tries to hide their use of private APIs rather than stop using them? That's exactly what I would do in Apple's position. Resubmitting the same thing and hoping that it doesn't get caught the next time isn't an honest mistake.

albru123 7y ago
Huh? The problem isn't that the developer itself is trying to cover his misbehavior, but the fact that the developer can get banned for something out of his control.
- sarah180 7y ago
  The developer is the one who takes responsibility for the submission. Enforcement is meaningless if you can just say "oh I asked you to publish dangerous code, but it's not my fault." It's the same reason people hold companies like Apple and Nike accountable for working conditions in their factories even if they hired a third party to run them. Third parties are not the ones putting their brand on the product.
- plorkyeran 7y ago
  There's nothing out of the developer's control about what they submit to the app store.
- LeoNatan25 7y ago
  The developer chose to use Electron, hence the entire endeavor is in their control.
MauranKilom 7y ago
> then tries to hide their use of private APIs rather than stop using them [...] Resubmitting the same thing and hoping that it doesn't get caught the next time isn't an honest mistake. This is missing the point of the post you are replying to. Say you identify five closed API dependencies and remove them. Do you resubmit? If you missed any others, you and all your apps might be banned.
- floatingatoll 7y ago
  Yes, you resubmit.
- saagarjha 7y ago
  How exactly do you miss a dependency?! If it's not your code, then it's a dependency that you need to look at.
  - creatornator 7y ago
    Dependencies of your dependencies! Imagine installing a library that depends on a couple dozen libraries in its own right. You may not have time to inspect every single node in the dependency graph.
    - saagarjha 7y ago
      It's going to sound uncharitable, but if you're clearly being rejected for something that your dependencies is doing wrong you should make time to figure out which one it is.
      - Fr0styMatt88 7y ago
        Is it really difficult to find private API usage? Can they be searched for through static or dynamic analysis? I don’t develop for iOS so I’m genuinely curious. Do they provide automated tools for developers to use? Or a flag that fails your build if you’re trying to call private APIs: For that matter, how are the reviewers catching these API usages? I find it strange that a private API can be used accidentally, without something notifying the developer before they’ve gotten to the stage of submitting their app.
        saagarjha 7y ago
        > I find it strange that a private API can be used accidentally, without something notifying the developer before they’ve gotten to the stage of submitting their app. It's difficult to use private API accidentally. However, it is possible to use a dependency that purposefully uses private API, which is what happened here. > Do they provide automated tools for developers to use? No. > Or a flag that fails your build if you’re trying to call private APIs Kinda, but that doesn't help you if your dependency is trying really hard to use that API and has been precompiled. > For that matter, how are the reviewers catching these API usages? They're running somewhat stupid static analysis and possibly some dynamic analysis? They don't tell you what they do but they're not very good at it and don't generally catch even basic obfuscation. However, if a human finds your private API usage and you look like you're trying to obfuscate it, they won't be nearly as lenient.
kjksf 7y ago
"use or conceal" "use" If this was "don't conceal or we'll ban you for life", it would be somewhat understandable. But it's "use or we'll ban you for life" which is just insane. Apple is at the height of their arrogance towards developers.
- threeseed 7y ago
  This policy has been there since the beginning of the App Store. If you use a private API they will reject the app. If you try and hide the fact you are using private APIs after has told you to stop then they will ban you. It's all very common sense and not arrogant at all.
- heavyset_go 7y ago
  > Apple is at the height of their arrogance towards developers. Yep. I've migrated away from macOS after using it for a decade over to Linux, and the developer experience is first class.
  - jolux 7y ago
    is it possible to write a GUI app that looks native in all common desktop environments yet?
    - dvdkhlng 7y ago
      Qt?
      - jolux 7y ago
        That won't really look native, will it? I thought Qt things looked like Qt things.
        dvdkhlng 7y ago
        As far as my experience goes, it looks pretty native on Windows. Looking at the documentation [0] it also seems to strive for mac-OS native look and feel. [0] https://doc.qt.io/qt-5/macos-issues.html https://doc.qt.io/qt-5/macos-issues.html
freehunter 7y ago
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.
megous 7y ago
Presumably you can't check for violation yourself without submitting.
- saagarjha 7y ago
  Of course you can! How do you think Apple's checking your binaries?
  - megous 7y ago
    Using some internal tool.
    - saagarjha 7y ago
      No, it’s almost certainly just a search for strings and looking through the symbol table.
      - megous 7y ago
        That would be very easy to work around with dlopen and some string obfuscation. It's probably a bit more involved.
        plorkyeran 7y ago
        In practice it is pretty easy to slip things past the automated checks if you try to, which is one of the reasons they threaten you with a permaban for doing so.
    - justinclift 7y ago
      The internal tool is very likely using/parsing otool / ldd output and similar. eg cli tooling that comes with macOS itself
- rdevnull 7y ago
  exactly. Apparently Apple just started now to check against these private APIs.
asveikau 7y ago
You assume it isn't an honest mistake. Most people submitting electron apps won't have knowledge of the browser engine layer and its calls to Apple APIs and probably will have some difficulty assessing whether or not they have resolved the issue. That doesn't make them bad people. They are not malicious or trying to hide things. Apple's scripts should give them more chances until they get it right.

albru123 7y ago

Huh? The problem isn't that the developer itself is trying to cover his misbehavior, but the fact that the developer can get banned for something out of his control.

sarah180 7y ago
The developer is the one who takes responsibility for the submission. Enforcement is meaningless if you can just say "oh I asked you to publish dangerous code, but it's not my fault." It's the same reason people hold companies like Apple and Nike accountable for working conditions in their factories even if they hired a third party to run them. Third parties are not the ones putting their brand on the product.
plorkyeran 7y ago
There's nothing out of the developer's control about what they submit to the app store.
LeoNatan25 7y ago
The developer chose to use Electron, hence the entire endeavor is in their control.

MauranKilom 7y ago

> then tries to hide their use of private APIs rather than stop using them [...] Resubmitting the same thing and hoping that it doesn't get caught the next time isn't an honest mistake. This is missing the point of the post you are replying to. Say you identify five closed API dependencies and remove them. Do you resubmit? If you missed any others, you and all your apps might be banned.

floatingatoll 7y ago
Yes, you resubmit.
saagarjha 7y ago
How exactly do you miss a dependency?! If it's not your code, then it's a dependency that you need to look at.
- creatornator 7y ago
  Dependencies of your dependencies! Imagine installing a library that depends on a couple dozen libraries in its own right. You may not have time to inspect every single node in the dependency graph.
  - saagarjha 7y ago
    It's going to sound uncharitable, but if you're clearly being rejected for something that your dependencies is doing wrong you should make time to figure out which one it is.
    - Fr0styMatt88 7y ago
      Is it really difficult to find private API usage? Can they be searched for through static or dynamic analysis? I don’t develop for iOS so I’m genuinely curious. Do they provide automated tools for developers to use? Or a flag that fails your build if you’re trying to call private APIs: For that matter, how are the reviewers catching these API usages? I find it strange that a private API can be used accidentally, without something notifying the developer before they’ve gotten to the stage of submitting their app.
      - saagarjha 7y ago
        > I find it strange that a private API can be used accidentally, without something notifying the developer before they’ve gotten to the stage of submitting their app. It's difficult to use private API accidentally. However, it is possible to use a dependency that purposefully uses private API, which is what happened here. > Do they provide automated tools for developers to use? No. > Or a flag that fails your build if you’re trying to call private APIs Kinda, but that doesn't help you if your dependency is trying really hard to use that API and has been precompiled. > For that matter, how are the reviewers catching these API usages? They're running somewhat stupid static analysis and possibly some dynamic analysis? They don't tell you what they do but they're not very good at it and don't generally catch even basic obfuscation. However, if a human finds your private API usage and you look like you're trying to obfuscate it, they won't be nearly as lenient.

kjksf 7y ago

"use or conceal" "use" If this was "don't conceal or we'll ban you for life", it would be somewhat understandable. But it's "use or we'll ban you for life" which is just insane. Apple is at the height of their arrogance towards developers.

threeseed 7y ago
This policy has been there since the beginning of the App Store. If you use a private API they will reject the app. If you try and hide the fact you are using private APIs after has told you to stop then they will ban you. It's all very common sense and not arrogant at all.
heavyset_go 7y ago
> Apple is at the height of their arrogance towards developers. Yep. I've migrated away from macOS after using it for a decade over to Linux, and the developer experience is first class.
- jolux 7y ago
  is it possible to write a GUI app that looks native in all common desktop environments yet?
  - dvdkhlng 7y ago
    Qt?
    - jolux 7y ago
      That won't really look native, will it? I thought Qt things looked like Qt things.
      - dvdkhlng 7y ago
        As far as my experience goes, it looks pretty native on Windows. Looking at the documentation [0] it also seems to strive for mac-OS native look and feel. [0] https://doc.qt.io/qt-5/macos-issues.html https://doc.qt.io/qt-5/macos-issues.html

freehunter 7y ago

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.

megous 7y ago

Presumably you can't check for violation yourself without submitting.

saagarjha 7y ago
Of course you can! How do you think Apple's checking your binaries?
- megous 7y ago
  Using some internal tool.
  - saagarjha 7y ago
    No, it’s almost certainly just a search for strings and looking through the symbol table.
    - megous 7y ago
      That would be very easy to work around with dlopen and some string obfuscation. It's probably a bit more involved.
      - plorkyeran 7y ago
        In practice it is pretty easy to slip things past the automated checks if you try to, which is one of the reasons they threaten you with a permaban for doing so.
  - justinclift 7y ago
    The internal tool is very likely using/parsing otool / ldd output and similar. eg cli tooling that comes with macOS itself
rdevnull 7y ago
exactly. Apparently Apple just started now to check against these private APIs.

asveikau 7y ago

You assume it isn't an honest mistake. Most people submitting electron apps won't have knowledge of the browser engine layer and its calls to Apple APIs and probably will have some difficulty assessing whether or not they have resolved the issue. That doesn't make them bad people. They are not malicious or trying to hide things. Apple's scripts should give them more chances until they get it right.