Apple starts rejecting apps with “hot code push” features • Hacker News Board

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

#81

Post by marak830 » Wed, Mar 08, 2017, 4:56 AM UTC

Nutomic wrote: post #59

obstinate wrote: post #24

Earlier quoted context omitted.

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.

Horribly. I get a few games from the Japanese market, and almost each one requires in immediate internal download and update.

Although those updates never trigger the Android update service, so I'm not sure if they are just downloading more resources of if they are able to request new permissions(I would like to assume not.)

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

#82

Post by mahyarm » Wed, Mar 08, 2017, 4:59 AM UTC

Retr0spectrum wrote: post #51

darren_ wrote: post #19

Earlier quoted context omitted.

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.

It's really sad, because that kind of stuff lets you fix bugs / mitigate outages in the wild without having to wait on apple's schedule.

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

#83

Post by justinhj » Wed, Mar 08, 2017, 5:00 AM UTC

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.

Most likely most games are updating only game related data and graphics files. Very few games actually use internal scripting that would be needed to do code updates

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

#84

Post by htormey » Wed, Mar 08, 2017, 5:01 AM UTC

marpstar wrote: post #45

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.

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 Web…

Code push doesn't push Native code. I think Rollout uses swizzling to send native code over the air to your app and then uses JavaScriptCore to inject it into your app at runtime. This always seemed pretty sketchy to me and I could see why Apple would be annoyed by it (it allows you to push changes which can call private objective c apis).

React Native code push does not push any native code, just JavaScript. Out of the box it does not allow you to push code that can call private API calls at runtime.

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

#85

Post by megous » Wed, Mar 08, 2017, 5:04 AM UTC

Retra wrote: post #27

rocky1138 wrote: post #2

The solution is fairly simple: just stop releasing software on that platform. There are millions of customers on more open platforms, so there's really no need to support them anyway.

All of life's problems are simple when suicide is your backup plan.

Boycott is a valid response no matter how much you try to make false analogies. Pulling app out of app store is by no means equivalent to suicide. At most you change your business.

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

#86

Post by stevebmark » Wed, Mar 08, 2017, 5:10 AM UTC

This has always been a requirement for Apple apps, hasn't it?

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

#87

Post by [deleted] » Wed, Mar 08, 2017, 5:11 AM UTC

dilipray wrote: post #76

"Hi there -- I believe that title isn't quite accurate; Apple specifically is referring to behavior of a library called Rollout which lets people dynamically inject Objective-C/Swift. They are doing hot delivery of native, Objective-C code. It's really not about React Native nor Expo. Expo (and the React Native library we use) doesn't do any of that. We also make sure we don't expose ways to dynamically execute nativ…

[deleted]

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

#88

Post by axemclion » Wed, Mar 08, 2017, 5:13 AM UTC

htormey wrote: post #29

avolcano wrote: post #11

Earlier quoted context omitted.

This was my immediate question too. Microsoft offers a service called CodePush ( https://microsoft.github.io/code-push/ ) for React Native and Cordova apps that presumedly could get caught by this. I don't have enough mobile dev knowledge to know whether or not it uses the same APIs that were mentioned in Apple's rejection letter, though.

Yep. I use code push in several apps. It's gonna be fun times next time I need to submit an app. I think it might be safe because it doesn't push native code and rollout is all about pushing native changes.

PM on the CodePush team here. The rejection notice seems to explicitly call out the native methods that are a cause of the issue. CodePush cannot inject private frameworks or expose any methods that React Native already exposes.

I would also recommend not using CodePush to completely what an app does.

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

#89

Post by axemclion » Wed, Mar 08, 2017, 5:14 AM UTC

htormey wrote: post #80

laurieg wrote: post #70

Earlier quoted context omitted.

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

Sure but a lot of React Native people use code push. I assume React Native is not affected as code push is just pushing JavaScript and not using JavaScript core to swizzle native code into your application like rollout does.

CodePush PM here - note that CodePush cannot push any native code to the app.

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

#90

Post by dylanpyle » Wed, Mar 08, 2017, 5:17 AM UTC

dilipray wrote: post #76

"Hi there -- I believe that title isn't quite accurate; Apple specifically is referring to behavior of a library called Rollout which lets people dynamically inject Objective-C/Swift. They are doing hot delivery of native, Objective-C code. It's really not about React Native nor Expo. Expo (and the React Native library we use) doesn't do any of that. We also make sure we don't expose ways to dynamically execute nativ…

Though the security justification here is limited to private APIs & native code pushing, the first few sentences of the rejection definitely seem like the "spirit" of the terms includes any significant functionality pushing at all. Wouldn't be surprised if they ramp up enforcement on that.