Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple starts rejecting apps with “hot code push” features

forums.developer.apple.com

Post reply on HN
Print view View original

51–60 of 498 posts

Re: Apple starts rejecting apps with “hot code push” features

#51

Post by Retr0spectrum »

darren_ wrote: post #19
trishume wrote: post #5

Hasn't this always been against the App Store terms? I thought the only language you were allowed to download code from the internet and run was Javascript on Apple's VM.

Rollout.io has been offering a product that leverages this to 'hotpatch' binaries, but it looks like this is now considered not in the spirit of the guidelines. Technicals here: https://rollout.io/blog/under-the-hood-2016-update/ It basically goes: * add their SDK, which has the ability to swizzle(swap out the implementation for) arbitrary methods in your app * the swapped in implementations use JavascriptCore to exe…

That's actually quite a clever workaround to the current rules, but rather naive of them to think Apple wouldn't fight back at some point.

Re: Apple starts rejecting apps with “hot code push” features

#52

Post by seanclayton »

empthought wrote: post #14
trishume wrote: post #5

Hasn't this always been against the App Store terms? I thought the only language you were allowed to download code from the internet and run was Javascript on Apple's VM.

The wording of the prohibition has varied over the years. Current wording is: Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exceptions to the foregoing are scripts and code downloaded and run by Apple's built-in…

>The only exceptions to the foregoing are scripts and code downloaded and run by Apple's built-in WebKit framework or JavascriptCore, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.

It looks like this says "If you use download code that is run on JavaScript core (ie, JavaScript), then you can do this so long as you don't change the purpose of your app when you submitted it to the App Store."

Re: Apple starts rejecting apps with “hot code push” features

#54

Post by geofft »

cbhl wrote: post #39
RKearney wrote: post #6

I wonder if Apple will apply this rule to everyone, which would be fair, or if they plan on letting big name developers like Facebook or Google continue to violate the rules without consequence.

I'm not sure if they still do this, but Facebook used to ship both code paths in the app binary for new launches, and give Apple instructions on how to test both code paths (e.g. sign in with this special user/pass combo). So they weren't changing app functionality after App Review approval; it's just that for users some of that functionality was gated on a boolean that was fetched over HTTPS.

Putting code behind a feature flag seems entirely fair and a good idea for developers of any size.

It's also a thing that can easily affect small developers; if your app requires logging into some existing paid account (enterprise software, a bank's app, etc.), the available features depend on what features the account has paid for. So as part of the review, you send Apple credentials for a test account that has all the features enabled. (Without a test account, they couldn't log in at all.)

Re: Apple starts rejecting apps with “hot code push” features

#55

Post by seanclayton »

madeofpalk wrote: post #35
empthought wrote: post #18

Earlier quoted context omitted.

... or JavascriptCore, which is what React Native uses.

..."provided that such scripts and code do not change the primary purpose of the Application"

So you can add features all you want, just make sure you don't change your todo list app to a dating app and all is fine.

Re: Apple starts rejecting apps with “hot code push” features

#56

Post by amluto »

geofft wrote: post #49
eridius wrote: post #21

Earlier quoted context omitted.

The first time I saw Rollout I was shocked it wasn't already banned by the App Store. No matter what they say, I can't imagine how they could do what they claim to do without flagrantly violating the guidelines.

I'm guessing there are two things Apple is worried about. The first is using hot code push to change the purpose of the app after release, e.g., switching a business app into a video game. The second is using hot code push to violate app store review guidelines, like the use of private APIs. You can do hot "code" push techniques that allow the first but not the second, by letting apps update HTML and JS that calls ba…

> The second is using hot code push to violate app store review guidelines, like the use of private APIs.

I've never understood this part. Why doesn't iOS simply prevent apps from calling private APIs?

Re: Apple starts rejecting apps with “hot code push” features

#57

Post by geofft »

qq66 wrote: post #46

I wonder what they define as "code." Uber often rolls out "Kittens for a day" style features, some of which are topical and can't have been designed before the previous app update.

The rejection notice is very clear:

> This includes any code which passes arbitrary parameters to dynamic methods such as dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations(), and running remote scripts in order to change app behavior or call SPI, based on the contents of the downloaded script.

Uber can write a "foo for a day" feature, that downloads some strings and some images from the Uber website, but doesn't actually add any functionality.

Same with any mobile game that has periodic events. You just write code to implement a generic event, write data to describe the event (name, graphics, level data), and do an update when you think of a different kind of event.

Re: Apple starts rejecting apps with “hot code push” features

#58

Post by Jare »

empthought wrote: post #14
trishume wrote: post #5

Hasn't this always been against the App Store terms? I thought the only language you were allowed to download code from the internet and run was Javascript on Apple's VM.

The wording of the prohibition has varied over the years. Current wording is: Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exceptions to the foregoing are scripts and code downloaded and run by Apple's built-in…

I think that wording with the "exception" is from the OSX developer program. As far as I can remember, the iOS info sheet has always been taxative with no exceptions about executable code. Of course all wordings allow Apple to start rejecting a previous approved app if they feel the code/scripts the app is now downloading are in violation.

The explanation in the rollout.io site about why they are fine is intentionally deceptive. They have the guts to link to a document that says "An Application may not download or install executable code." and then quote more friendly excerpts in the hopes that you won't read the actual doc. I can't imagine why Apple has let this go on for so long.

Re: Apple starts rejecting apps with “hot code push” features

#59

Post by Nutomic »

obstinate wrote: post #24
mmmBacon wrote: post #10

Seems like people have been aware of concerns about violating the TOS with these hot patch frameworks. From April 2016 >>Rollout is aware of the concerns within the community that patching apps outside of the App Store could be a violation of Apple’s review guidelines and practices. Rollout notes both on their FAQ site and in a longer blog post that their process is in compliance. https://www.fireeye.com/blog/threat-…

A ton of games do this and it is incredibly annoying. I don't want to download an update, then have to download an update. I only wish the same restriction applied to my Android device.

Google definitely forbids self-updating apps on Google Play. But I'm not sure how well this is enforced.

Re: Apple starts rejecting apps with “hot code push” features

#60

Post by sjwright »

amluto wrote: post #56
geofft wrote: post #49

Earlier quoted context omitted.

I'm guessing there are two things Apple is worried about. The first is using hot code push to change the purpose of the app after release, e.g., switching a business app into a video game. The second is using hot code push to violate app store review guidelines, like the use of private APIs. You can do hot "code" push techniques that allow the first but not the second, by letting apps update HTML and JS that calls ba…

> The second is using hot code push to violate app store review guidelines, like the use of private APIs. I've never understood this part. Why doesn't iOS simply prevent apps from calling private APIs?

Presumably because many private APIs are used behind the scenes by public APIs and the security model must allow applications to run them.
Post reply on HN