Oh, Mario Run! What are you gonna do?
Apple starts rejecting apps with “hot code push” features
41–50 of 498 posts
Re: Apple starts rejecting apps with “hot code push” features
#42> 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
I would have expected dlopen and dlsym are blacklisted - you can trivially use dlsym to access any blacklisted API. Similarly, I thought SPI ("system programming interface" = private API) was all blacklisted. Am I misreading the message?
That said, if this is what they're focused on, it seems like it actively does not impact any apps that hot-push HTML code (e.g., PhoneGap / Cordova).
If the only reports are coming from Rollout.io, my guess is that the latest Rollout SDK uses one of these functions (I'd bet method_exchangeImplementations(), i.e., swizzling) with a dynamic parameter, and that the SDK can be changed to just stop doing that.
Re: Apple starts rejecting apps with “hot code push” features
#43[deleted]
Re: Apple starts rejecting apps with “hot code push” features
#44From 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!"
Re: Apple starts rejecting apps with “hot code push” features
#45I 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.
To date, Apple's Developer Program Guidelines states (in Section 3.3.2):
> 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 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.
Personally, I think that Cordova hybrid apps will continue to be okay, but I don't know about something like React Native...
Re: Apple starts rejecting apps with “hot code push” features
#46I 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.
Re: Apple starts rejecting apps with “hot code push” features
#47Didn'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."
Re: Apple starts rejecting apps with “hot code push” features
#48From 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.
I would be cashing out now...!
Re: Apple starts rejecting apps with “hot code push” features
#49From 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.
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 back into pre-existing native code. That's what Cordova / PhoneGap does. I'd guess that Apple will just ban the app and the developer if they catch it.
It appears that Rollout started using some API that would enable it to do the second, and Apple is preemptively making sure that it doesn't happen. The wording of the rejection is based on passing computed parameters to introspection routines.
Re: Apple starts rejecting apps with “hot code push” features
#50From 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.
> Rollout lets you push code-level changes to native iOS apps, without waiting on the App Store. What did they expect when their entire business model is based on something that's literally the opposite of what the review guideline allows?
Uber is still doing kind of ok.