Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

> 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).

View on HN

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

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.

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.

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!

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

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.

That's unethical.

It's as unethical as blowing through a broken traffic light stuck on red.

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.

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.

Apple and Google only review the code that runs.......?!

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?

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.

Reply on news.ycombinator.com