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

61–70 of 498 posts

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

#61

Post by Elizzy »

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?

Because some of these APIs are useful in an enterprise app setting that aren't distributed via the App Store. Like Disney applications on their turnstile devices at Disney World.

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

#63

Post by josh_carterPDX »

pscarey wrote: post #47
josh_carterPDX wrote: post #15

Didn't Firebase just introduce Remote Config which touts this very thing?

AFAIK Remote Config is just a server side key value store with customisable values based on audiences (e.g. random 50% for A/B testing, all people from Country X). This means all behaviour changes will require code to be deployed in the first place. Also, from Firebase Docs[1] "Don't attempt to circumvent the requirements of your app's target platform using Remote Config." [1] https://firebase.google.com/docs/remote-…

From this....

https://www.youtube.com/watch?v=_CXXVFPO6f0

"Firebase Remote Config allows you to change the look-and-feel of your app, gradually roll out features, run A/B tests, and deliver customized content to certain users, all from the cloud without needing to publish a new version of your app."

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

#64

Post by wildmusings »

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?

You aren't supposed to call private APIs in your code, but your app is definitely making private API calls all the time since the libraries provided by the platform are running in-process.

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

#67

Post by euyyn »

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?

Preventing it in a technical way is far from easy: If your app calls public API X, which as part of its implementation calls private API Y, your compiler only needs a declaration of Y to output the function call / ObjC message send. Nothing in the language prevents it, and the code is executed natively unlike Java.

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

#68

Post by cooper12 »

Nition wrote: post #44
simplehuman wrote: post #13

From https://rollout.io/how-it-works/ : Does Rollout comply to Apple’s Guidelines? Yes. As per Apple’s official guidelines, Rollout.io does NOT alter binaries. ... With over 50 million devices already running our SDK, it is safe to say that Rollout complies with with Apple’s development and App Store guidelines. Ouch. Just like the company's future is in danger.

Heh, "We're in so many apps... it MUST be allowed!"

To be honest, I think the fact that they're used by so many big players is the reason that Apple is requiring removal in future updates rather than outright removing for ToS violations.

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

#69

Post by sjwright »

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.

A topical "special day" feature could easily be defined as a downloadable content blob with zero executable or interpreted code. They probably have a set of special event templates already coded into the application which can then be themed with a few images, colours and text strings.

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

#70

Post by laurieg »

htormey wrote: post #4

I wonder if this is going to hit non native code push solutions like React Native? Or if Apple are going to start cracking down on apps like Facebook, Twitter or Pinterest that do a lot of A/B testing.

Correct me if I'm wrong but you can use React Native without any code push features, can't you?
Post reply on HN