5 ms·

> 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 w

> 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
    > And with OTA updates apps can get a surprisingly large amount around the review process. Right, which is exactly why the OP's suggestion would not work, that Apple should always tell you in advance when they plan to do post-release review.
- ottermax8 5y ago
  That's so great--when you do 100 submissions, you're sure to get some really bad reviewer who is just trying to improve their metrics. We had to take out a bunch of functionality to get it approved... didn't want to spend time fighting up the chain and the upper folks don't even care.
- tantalor 5y ago
  That's unethical.
  - deleted 5y ago
    [deleted]
  - Decker87 5y ago
    It's as unethical as blowing through a broken traffic light stuck on red.
- cptskippy 5y ago
  It doesn't seem like there's a single reviewer involved. Whenever we've encountered this behavior with reviewers blocking, simply resubmitting seems to "fix" the issue.
jclardy 5y ago
Any mobile dev can just setup firebase remote config and get a "dynamic feature flag" setup for free, with no backend experience required. Then add a few if statements, turn it off during your review period and back on when done. Go one small step further and disable the offending feature during review only for the next build version and you don't even disrupt existing users.

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
  > And with OTA updates apps can get a surprisingly large amount around the review process. Right, which is exactly why the OP's suggestion would not work, that Apple should always tell you in advance when they plan to do post-release review.
ottermax8 5y ago
That's so great--when you do 100 submissions, you're sure to get some really bad reviewer who is just trying to improve their metrics. We had to take out a bunch of functionality to get it approved... didn't want to spend time fighting up the chain and the upper folks don't even care.
tantalor 5y ago
That's unethical.
- deleted 5y ago
  [deleted]
- Decker87 5y ago
  It's as unethical as blowing through a broken traffic light stuck on red.
cptskippy 5y ago
It doesn't seem like there's a single reviewer involved. Whenever we've encountered this behavior with reviewers blocking, simply resubmitting seems to "fix" the issue.

jclardy 5y ago

Any mobile dev can just setup firebase remote config and get a "dynamic feature flag" setup for free, with no backend experience required. Then add a few if statements, turn it off during your review period and back on when done. Go one small step further and disable the offending feature during review only for the next build version and you don't even disrupt existing users.