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

101–110 of 498 posts

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

#101

Post by irontoby »

marak830 wrote: post #81
Nutomic wrote: post #59

Earlier quoted context omitted.

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

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 deny. But an app can't grant itself new permissions without going through the official update process.

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

#102

Post by [deleted] »

darren_ wrote: post #19
trishume wrote: post #5

Hasn't this always been against the App Store terms? I thought the only language you were allowed to download code from the internet and run was Javascript on Apple's VM.

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…

[deleted]

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

#103

Post by jameside »

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 those libraries because it doesn't expose uncontrolled access to native APIs at runtime. Instead, the developer writes native modules that define some functions the app can call from JavaScript, like setting a timer or playing a sound. This is the same strategy that "hybrid" apps that use a UIWebView/WKWebView have been using for many years. From a technical perspective, React Native is basically a hybrid app except that it calls into more UI APIs.

Technically it is possible for a WebView app or a React Native app also to contain code that exposes uncontrolled access to native APIs. This could happen unintentionally; someone using React Native might also use Rollout. But this isn't something specific to or systemic about React Native nor WebViews anyway.

One nice thing about Expo, which uses React Native, is that we don't expose uncontrolled or dynamic access to native APIs and take care of this issue for you if your project is written only in JS. We do a lot of React Native work and are really involved in the community and haven't heard of anyone using Expo or React Native alone having this issue.

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

#104

Post by tuananh »

recursive wrote: post #50
cynix wrote: post #22

Earlier quoted context omitted.

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

What does Uber do?

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

#105

Post by nickm12 »

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…

I think the part that you're running afoul of is where it says:

"new apps presenting new questions may result in new rules at any time."

Good luck to you, but it's Apple's sandbox and your product appears to thwart the principles that the Apple App Store has been run on for nearly a decade.

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

#106

Post by jameside »

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.

I posted some thoughts on why this isn't about React Native here: https://news.ycombinator.com/item?id=13818211.

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

#110

Post by 234dd57d2c8dba »

This is the future everyone is choosing. You don't own your devices, you don't own the apps you write, and you're not smart enough to be able to decide what is "good" code vs "bad" code. Just let the algorithms, corporations, and governments decide what is best for you. It's much easier that way, after all.
Post reply on HN