6 ms·

> App stores should review apps at set frequencies. Developers should know the expected date for their next review so that they can prepare for unexpected conse

> App stores should review apps at set frequencies. Developers should know the expected date for their next review so that they can prepare for unexpected consequences that require direct action. I guarantee bad actors would remove unpermitted functionality right before the review, and put it back after. There's a reason even restaurant food safety inspectors don't tell the restaurant when they're coming. But on the other hand, restaurant food safety inspectors do usually give you a chance to correct the violation before shutting you down (depending on severity anyway).

kwdc 5y ago
Pardon my ignorance, but doesn't Google/Apple have the ability to examine compiled code as hosted on their servers? This implies Google/Apple themselves can perform static and dynamic analysis at their leisure. There is therefore no concept of "remove just before" or otherwise a form of slight-of-hand. Are we still operating under the illusion that Google/Apple have no capability for having suitable tooling around this? I find it difficult to believe. Especially for finding unofficial api use and similar shenanigans.
- jrochkind1 5y ago
  The proposal in the OP is again: > App stores should review apps at set frequencies. Developers should know the expected date for their next review so that they can prepare for unexpected consequences that require direct action. So that would introduce the concept of "remove just before", if stores limited review to expected dates, and developers knew the expected date of review.
rkachowski 5y ago
> I guarantee bad actors would remove unpermitted functionality right before the review, and put it back after. Outside of a dynamic feature flag setup, this would be trivial to detect as Google and Apple completely control the submission process.
- candiodari 5y ago
  No it wouldn't. Have the bad functionality behind a DNS lookup. It fails, app behaves. Developer can change flag and there's little Google/Apple/Amazon can do about it.
  - atatatat 5y ago
    Apple and Google only review the code that runs.......?!
    - ceejayoz 5y ago
      Apps are allowed to load remote resources. Your app can be rejected for talking about off-app payment, but how is a reviewer going to find that if it's talked about in a helpdesk document that's fetched via a HTTP call to a remote server and is temporarily edited to remove that paragraph?
- fasteddie 5y ago
  I once used a very dumb feature flag set up to get around a rule an Apple reviewer told us were breaking, just for review period. The supposed rule violation was around for a year and no one had flagged it except for this one reviewer, and they were clearly interpreting the policy wrong. Easier to make a flag to appease then try and work up the management review chain. This wasn't malware or anything like that, but goes to show limits of automated review.
  - dawnerd 5y ago
    Almost had to do this too. Luckily the part of the app that was in violation was just a web view and the plan was to just hide that part of the page until after it went live. And with OTA updates apps can get a surprisingly large amount around the review process. Although you risk being banned if they catch you!
    - jrochkind1 5y ago

kwdc 5y ago

Pardon my ignorance, but doesn't Google/Apple have the ability to examine compiled code as hosted on their servers? This implies Google/Apple themselves can perform static and dynamic analysis at their leisure. There is therefore no concept of "remove just before" or otherwise a form of slight-of-hand. Are we still operating under the illusion that Google/Apple have no capability for having suitable tooling around this? I find it difficult to believe. Especially for finding unofficial api use and similar shenanigans.

jrochkind1 5y ago
The proposal in the OP is again: > App stores should review apps at set frequencies. Developers should know the expected date for their next review so that they can prepare for unexpected consequences that require direct action. So that would introduce the concept of "remove just before", if stores limited review to expected dates, and developers knew the expected date of review.

rkachowski 5y ago

> I guarantee bad actors would remove unpermitted functionality right before the review, and put it back after. Outside of a dynamic feature flag setup, this would be trivial to detect as Google and Apple completely control the submission process.

candiodari 5y ago
No it wouldn't. Have the bad functionality behind a DNS lookup. It fails, app behaves. Developer can change flag and there's little Google/Apple/Amazon can do about it.
- atatatat 5y ago
  Apple and Google only review the code that runs.......?!
  - ceejayoz 5y ago
    Apps are allowed to load remote resources. Your app can be rejected for talking about off-app payment, but how is a reviewer going to find that if it's talked about in a helpdesk document that's fetched via a HTTP call to a remote server and is temporarily edited to remove that paragraph?
fasteddie 5y ago
I once used a very dumb feature flag set up to get around a rule an Apple reviewer told us were breaking, just for review period. The supposed rule violation was around for a year and no one had flagged it except for this one reviewer, and they were clearly interpreting the policy wrong. Easier to make a flag to appease then try and work up the management review chain. This wasn't malware or anything like that, but goes to show limits of automated review.
- dawnerd 5y ago
  Almost had to do this too. Luckily the part of the app that was in violation was just a web view and the plan was to just hide that part of the page until after it went live. And with OTA updates apps can get a surprisingly large amount around the review process. Although you risk being banned if they catch you!
  - jrochkind1 5y ago