Live data from Hacker News

Apple starts rejecting apps with “hot code push” features

forums.developer.apple.com

181–190 of 498 posts

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

#181
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.

They should pull the Facebook app for this. But I'll eat my hat if they do.

unfortunately, just like any other private platform, they don't need to be consistent or follow the rules all the time.

I say, don't go native unless you must (for performance reasons etc). push the web forward instead!

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

#182

I've recently been looking into React-Native. I'm hesitent to commit because i believe there's 'hot code push' potential and Apple will be a b *h about it. I not sure if this is the case thou.

> i believe there's 'hot code push' potential

It's called CodePush, and it's a plugin for React Native (does not come with it). It is developed by Microsoft: https://microsoft.github.io/code-push/

Doubt it would get taken down.

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

#183
post #174

That game that is topping the charts "Legacy", explicitly says when you start it that it's downloading patches. Wonder why it isn't blocked?

Patches could be assets - updated map data - updated textures - updated AI scripts? I don't think these need a full app store update as it's not changing the game from a game to a dating app (for example).

Still, how do they avoid someone writing an ad-hoc interpreter and reading code from e.g. PNG images? Data == code, as we know.

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

#184
post #180

Could this have anything to do with Wikileak's release of iOS hacks by the CIA?

Probably not, the timing is too tight, and if Apple were aware of active exploitation, they would probably compeltely remove / block affected apps, instead of giving the devs a notice to improve the next release.

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

#185
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…

> We are contacting Apple in order to get further clarification on why Rollout doesn't fall under the clause that lets developers push JS to live apps as long as it does not modify the original features and functionality of the app.

As a security-conscious user, live patching is awful. Nothing guarantees me that the benign app I've been granting various permissions to doesn't get altered by a fourth party adversary through coercion or hacking and gets wiretapped by a malicious dynamic payload.

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

#186
post #172

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…

I do wonder why, if they're _really_ fine with that, why they're not fine with browsers with different rendering engines on iOS. Since they're not, I wouldn't have _too much_ faith in other things not being rejected.

Simple: JIT compilers are banned and so that excludes any modern browser's JavaScript implementation from iOS. But anyone using Apple's JavaScriptCore has nothing to fear.

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

#187
post #142

From my understanding people are giving rollout push rights to their app store accounts? So rollout can hijack all the apps it controls? It's a hell of a central authority, a security nightmare waiting to happen.

No, it allows apps to be modified by the apps pulling JS code from rollout's servers. App reviews would be way too slow, and they are exactly the problem that rollout solves. However, review times have improved a lot since then. ADDITION: It works by "swizzling" methods, which is a valid mechanism in Apple's runtimes (like in Ruby or many other dynamic languages). In Swift, this will only work in subclasses of NSObje…

Ok, so there's no direct access to your App Store but idea is same - rollout can "hot fix" aka pwn all users at once. I'd be angry if I were apple too.

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

#188

Earlier quoted context omitted.

They don't 'see' the code. They run a program on the binary for some obvious checks and do a QA smoke test of the app itself.

You are thinking "source code". "Code" is another term for what you are referring to as "binary".

Recently Apple added (and actively encourages) the ability for developers to upload bytecode to the App Store instead of ARM binaries so Apple can more easily dynamically recompile for new architectures and optimisations. Of course bytecode is considerably easier to revert back into readable source-code (especially as Swift/ObjectiveC retain (some) symbol names in compiled output) - so it's not outside the realm of possibility that an unscrupulous Apple team is disassembling cool apps to see how they work then re-implement them for the next release of iOS.

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

#189
post #185
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…

> We are contacting Apple in order to get further clarification on why Rollout doesn't fall under the clause that lets developers push JS to live apps as long as it does not modify the original features and functionality of the app. As a security-conscious user, live patching is awful. Nothing guarantees me that the benign app I've been granting various permissions to doesn't get altered by a fourth party adversary t…

Nothing guarantees that. There have been RCE exploits on iOS.

One could argue that live patching allowed companies to fix or mitigate security problems faster than Apples (awful) app store policy (and timescale) would otherwise allow.

Post reply on HN