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

111–120 of 498 posts

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

#111

Post by ma2rten »

adjunct wrote: post #98

I'm Erez Rusovsky, the CEO of Rollout.io Rollout's mission has always been, and will always be about helping developers create and deploy mobile apps quickly and safely. Our current product has been a life saver for hundreds of apps by allowing them to patch bugs in live apps. We were surprised by Apple's actions today. From what we've been able to gather, they seem to be rejecting any app which utilizes a mechanism…

You were relying on a huge loophole. The code runs inside JavascriptCore but it injects native code into the app.

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

#112

Post by santiagobasulto »

jameside wrote: post #103
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…

Hi, I work on Expo (YC S16) and also am a core contributor to React Native. Apple's message reads to me that they're concerned about libraries like Rollout and JSPatch, which expose uncontrolled and direct access to native APIs (including private APIs) or enable dynamic loading of native code. Rollout and JSPatch are the only two libraries I've heard to be correlated with the warning. React Native is different from t…

James, do you know if they're going to go agains the Exponent app per-se?

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

#113

Post by marak830 »

irontoby wrote: post #101
marak830 wrote: post #81

Earlier quoted context omitted.

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

Games updating DLC is nothing new and is not what this is about. Google did recently change the Android permission model; previously, apps had to request all their permissions at install time and it was all-or-nothing (and frankly, hardly anyone bothered to look them over.) Now, certain permissions have to be requested when they're needed (at least for recent versions of the SDK) and the user can choose to allow or d…

See I do trust that - but only to an extent.

I always wonder when seeing one update, if there is a 0 day that can bypass that. On a technical level I know I run the same risk with my PC, but at the same time, it's more difficult for me to examine processes and startups in my android.

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

#114

Post by jameside »

santiagobasulto wrote: post #112
jameside wrote: post #103

Earlier quoted context omitted.

Hi, I work on Expo (YC S16) and also am a core contributor to React Native. Apple's message reads to me that they're concerned about libraries like Rollout and JSPatch, which expose uncontrolled and direct access to native APIs (including private APIs) or enable dynamic loading of native code. Rollout and JSPatch are the only two libraries I've heard to be correlated with the warning. React Native is different from t…

James, do you know if they're going to go agains the Exponent app per-se?

Oh, no, I don't have reason to believe so.

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

#115

Post by Twisell »

jeswin wrote: post #92
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…

The problem with Apple that you and your customers need to be aware of (or concerned about), is that once a number of your customers sidestep Apple policies w.r.t. pushing or changing features via JavaScript, Apple will change their policies to close that loophole. It's only a matter of time before companies take advantage of this path to sidestep app store approvals.

As a client I'm pretty baffled that some developer had specifically bypassed something that I see as a security measure.

If an app is modified on the fly to use an undocumented and maybe "forbidden by apple" method in order to bypass security features or worse spy on me I'm clearly not ok.

Do you really think the apple ecosystem work because clients see AppStore as a evil cage and that the external developers are all angels with good intentions?

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

#116

Post by ChuckMcM »

adjunct wrote: post #98

I'm Erez Rusovsky, the CEO of Rollout.io Rollout's mission has always been, and will always be about helping developers create and deploy mobile apps quickly and safely. Our current product has been a life saver for hundreds of apps by allowing them to patch bugs in live apps. We were surprised by Apple's actions today. From what we've been able to gather, they seem to be rejecting any app which utilizes a mechanism…

My guess is that somewhere in the giant dump of CIA malware there is an exploit that uses this to hijack an iPhone. They are pretty explicit about what they don't like and how it would be exploited.

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

#117

Post by malandrew »

ChuckMcM wrote: post #116
adjunct wrote: post #98

I'm Erez Rusovsky, the CEO of Rollout.io Rollout's mission has always been, and will always be about helping developers create and deploy mobile apps quickly and safely. Our current product has been a life saver for hundreds of apps by allowing them to patch bugs in live apps. We were surprised by Apple's actions today. From what we've been able to gather, they seem to be rejecting any app which utilizes a mechanism…

My guess is that somewhere in the giant dump of CIA malware there is an exploit that uses this to hijack an iPhone. They are pretty explicit about what they don't like and how it would be exploited.

I'm wondering if one route to preventing this being an issue is to prevent any hot code fixes to specific devices. If you have to hot code push to all devices running a specific version, I reckon that would put a damper on the actions of an institution trying to target a specific person. It's a lot harder to try and be sneaky when a change has such a large impact. That said, I'm not sure this restriction alone would be enough.

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

#120

Post by JohnBooty »

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…

> I'm guessing there are two things Apple is worried about.

I'm sure it worries about them but there's a much larger, riskier scenario.

Once you start downloading and executing binary code from untrusted sources (i.e., not the App Store) anything can go wrong.

1. An iOS app doesn't care about security, and it hot-loads code from some non-https source and gets man-in-the-middle'd 2. An iOS app hot-loads code in a secure manner, but the server from which the code is served becomes cot mpromised 3. A malicious employee at an iOS app vendor pushes harmful code out via her company's app

Now, I'm not a fan of Apple's policies. I think there should be a "guys, I know what I'm doing" mode where I'm allowed to download code from untrusted sources. Just like Android or MacOS.

However, I sympathize with them here. For nearly a decade people have been downloading code from the App Store with the understanding that it is safe to do so. Even I appreciate this much of the time... I'm an engineer but I'm busy. I can't audit every app I download. I wish there were other options, but I find huge value in the fact that I don't have to worry about an App Store app screwing my device. And it's a big reason why I recommend iOS despite its flaws to older family members.

Post reply on HN