5 ms·

Reading the PDF I really can't understand how the court says there was no harassment.. And 80 app reviews per day? Do they even have time to eat or take a dump

Reading the PDF I really can't understand how the court says there was no harassment.. And 80 app reviews per day? Do they even have time to eat or take a dump?

schappim 6y ago
Yikes! That is less than 6 min per app.
- simonh 6y ago
  Many, possibly the vast majority are probably reviews of minor updates to existing apps.
  - gregoriol 6y ago
    Shouldn't the reviewer check every update? What if the "minor" update contains some rule breaking changes? They can't know/assume from the developer's update description that it is a minor update, and don't have much other information about what has changed. Otherwise it would be very easy to first publish a "normal" app, and then just publish an update with bad stuff added.
    - deleted 6y ago
      [deleted]
    - simonh 6y ago
      They do review every update, but they have a lot of automated tools that help a lot when reviewing minor changes. So for example, if only a few bytes have changed and the binary is only a few bytes different in size they can mostly rely on the tools. That’s probably most bug fix updates right there.
      - gregoriol 6y ago
        Automated tools will probably check private api usage and maybe some basic technical stuff, but they won't be able to catch a feature change. And even if you were right, changing some text or url would pass your test as only a few characters change, but that could make a big difference regarding the feature.
      - _qulr 6y ago
        > So for example, if only a few bytes have changed and the binary is only a few bytes different in size they can mostly rely on the tools. That's not how compiled optimized binaries work, especially not with Apple platforms, ever-changing Xcode and Swift compiler versions, etc. Have you tried comparing the binaries of minor app updates? (I just tried comparing the binaries of my own app updates, where I have the source code and know what changed, but it's not pretty, and not "a few bytes".) Moreover, App Store reviewers are not the least bit qualified to even make this determination with regard to "bytes changed". Two binaries aren't even going to have the same load address for the __TEXT __text segment, and thus a lot of stuff will be different. You think App Store reviewers have any conception of the structure of a Mach-O? Now, one might try to hand-wave and say the "automated tools" will take care of everything, but that's extremely unlikely. Diffing binaries is a skill that requires a human with extensive experience in reverse engineering. If it were totally automated, then all of the securities researchers out there would have those tools too, but they don't. There are of course tools that help a lot, but the human researcher is still essential to the process.
        faeyanpiraat 6y ago
        I assume Apple has access to the source code of the app, so they probably are not comparing binary blobs for changes.
        _qulr 6y ago
        > I assume Apple has access to the source code of the app No, Apple doesn't get our source code. Why would you assume that?
        gregoriol 6y ago
        They don't: you submit a compiled binary for review
        dagmx 6y ago
        Sort of. You submit either a binary blob or LLVM IR. The latter is great because Apple can do the final platform specific compile for you, and build out for new systems as needed.
- echelon 6y ago
  Apple fans act like this process is designed to protect them from malware, but it's so superficial that it couldn't be much better than automated detection methods. In reality, Apple is looking for 1. Loopholes around its walled garden 2. Payments not being taxed 3. Apps not using the latest demanded framework, such as Apple sign in (they're not your users, they're Apple users on loan to you) 4. Political content its Chinese minders will be unhappy about
threeseed 6y ago
Most reviews are just for updates. In which case they are simply checking copy, opening the app and clicking around a bit etc i.e. no more than a few minutes. The longer reviews are reserved for new apps and edge cases.
- _qulr 6y ago
  > The longer reviews are reserved for new apps and edge cases. As an App Store developer myself, I'm not sure it's true. For example, one of my 1.0 releases was "In Review" for all of 14 minutes, which is shorter than many of my minor update releases. On the outside, we don't know how review works. It's mostly speculation. People talk about how they think it should work, but how it actually works is a different matter.
  - matwood 6y ago
    How many apps do you have? Have you had issues with other ones? Was this app under the same account? I'm sure heuristics are used to speed up the process where possible. It's been awhile since I've written native iOS apps, but early on in the App Store days a developer could request an expedited review. We managed to get on this list and stay there for the entire life of the app. Even the dark days of long review times, our app never took more than 24 hours.

Reading the PDF I really can't understand how the court says there was no harassment.. And 80 app reviews per day? Do they even have time to eat or take a dump?

schappim 6y ago

Yikes! That is less than 6 min per app.

simonh 6y ago
Many, possibly the vast majority are probably reviews of minor updates to existing apps.
- gregoriol 6y ago
  Shouldn't the reviewer check every update? What if the "minor" update contains some rule breaking changes? They can't know/assume from the developer's update description that it is a minor update, and don't have much other information about what has changed. Otherwise it would be very easy to first publish a "normal" app, and then just publish an update with bad stuff added.
  - deleted 6y ago
    [deleted]
  - simonh 6y ago
    They do review every update, but they have a lot of automated tools that help a lot when reviewing minor changes. So for example, if only a few bytes have changed and the binary is only a few bytes different in size they can mostly rely on the tools. That’s probably most bug fix updates right there.
    - gregoriol 6y ago
      Automated tools will probably check private api usage and maybe some basic technical stuff, but they won't be able to catch a feature change. And even if you were right, changing some text or url would pass your test as only a few characters change, but that could make a big difference regarding the feature.
    - _qulr 6y ago
      > So for example, if only a few bytes have changed and the binary is only a few bytes different in size they can mostly rely on the tools. That's not how compiled optimized binaries work, especially not with Apple platforms, ever-changing Xcode and Swift compiler versions, etc. Have you tried comparing the binaries of minor app updates? (I just tried comparing the binaries of my own app updates, where I have the source code and know what changed, but it's not pretty, and not "a few bytes".) Moreover, App Store reviewers are not the least bit qualified to even make this determination with regard to "bytes changed". Two binaries aren't even going to have the same load address for the __TEXT __text segment, and thus a lot of stuff will be different. You think App Store reviewers have any conception of the structure of a Mach-O? Now, one might try to hand-wave and say the "automated tools" will take care of everything, but that's extremely unlikely. Diffing binaries is a skill that requires a human with extensive experience in reverse engineering. If it were totally automated, then all of the securities researchers out there would have those tools too, but they don't. There are of course tools that help a lot, but the human researcher is still essential to the process.
      - faeyanpiraat 6y ago
        I assume Apple has access to the source code of the app, so they probably are not comparing binary blobs for changes.
        _qulr 6y ago
        > I assume Apple has access to the source code of the app No, Apple doesn't get our source code. Why would you assume that?
        gregoriol 6y ago
        They don't: you submit a compiled binary for review
        dagmx 6y ago
        Sort of. You submit either a binary blob or LLVM IR. The latter is great because Apple can do the final platform specific compile for you, and build out for new systems as needed.
echelon 6y ago
Apple fans act like this process is designed to protect them from malware, but it's so superficial that it couldn't be much better than automated detection methods. In reality, Apple is looking for 1. Loopholes around its walled garden 2. Payments not being taxed 3. Apps not using the latest demanded framework, such as Apple sign in (they're not your users, they're Apple users on loan to you) 4. Political content its Chinese minders will be unhappy about

threeseed 6y ago

Most reviews are just for updates. In which case they are simply checking copy, opening the app and clicking around a bit etc i.e. no more than a few minutes. The longer reviews are reserved for new apps and edge cases.

_qulr 6y ago
> The longer reviews are reserved for new apps and edge cases. As an App Store developer myself, I'm not sure it's true. For example, one of my 1.0 releases was "In Review" for all of 14 minutes, which is shorter than many of my minor update releases. On the outside, we don't know how review works. It's mostly speculation. People talk about how they think it should work, but how it actually works is a different matter.
- matwood 6y ago
  How many apps do you have? Have you had issues with other ones? Was this app under the same account? I'm sure heuristics are used to speed up the process where possible. It's been awhile since I've written native iOS apps, but early on in the App Store days a developer could request an expedited review. We managed to get on this list and stay there for the entire life of the app. Even the dark days of long review times, our app never took more than 24 hours.