Live data from Hacker News

Apple starts rejecting apps with “hot code push” features

forums.developer.apple.com

131–140 of 498 posts

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

#131

Just imagine www didn't exist and Apple already had ios and apps. If someone came up with the idea of www and an app called web browser , would apple accept it in the app store? They would only accept it if they build it themselves. At some point is there a risk that Apple may also start to ban the web browser, despite that it's under strict control on IOS?

This is why you don't build on someone else's platform.

Apple/Google/Platform Owner will always do what's right for them, not the customer, and not the developer, for example banning Amazon from selling books in their kindle app, not allowing competing browsers (they recognise the power of the web as a platform), not allowing competing sales mechanisms (where they don't get a cut), and here not allowing developers to update their apps except through the store mechanism. I have some sympathy with Apple here, and see why they're doing it (they have to control what software is installed for security reasons as well as platform protection), but this is all about control over what you install on your own device. Sometimes their actions will be in the best interests of customers, even if not the best interests of developers, but most of the time their actions are simply aimed at preserving their control of the platform and control of the money flowing through it.

The web is the one exception to this rule which works across all platforms and devices (because it is so dumb and simple), and has survived attempts to corral it to a walled-in commercial offering remarkably well.

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

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

If only. You are using a technical hack to modify _native_ apps. The Apple Guidelines aren't strictly set in stone; the intent is clear: you can't remotely modify how native apps work, even if you do it through a JS delivery mechanism.

Sorry for your loss, but in glad Apple is doing this and apps will be safer.

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

#134

Just imagine www didn't exist and Apple already had ios and apps. If someone came up with the idea of www and an app called web browser , would apple accept it in the app store? They would only accept it if they build it themselves. At some point is there a risk that Apple may also start to ban the web browser, despite that it's under strict control on IOS?

I strongly doubt Apple would ever ban web browsers. The amount browsing done on iOS is too significant, it wouldn't make sense to ban them.

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

#135

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

This appears to affect apps using JSPatch which is not pushing Objective-C but JavaScript. Source: https://github.com/bang590/JSPatch/issues/746 (in Chinese)

The key part of JSPatch is that it exposes arbitrary, uncontrolled access to native APIs. You could use it to call private APIs even because Objective-C doesn't distinguish between public and private APIs at runtime, so Xcode's compiler checks and Apple's static analysis can't anticipate which APIs are possibly called.

In contrast, React Native doesn't expose uncontrolled access to native APIs. You write regular Objective-C methods that are callable from JavaScript, and within your Objective-C methods you write regular Objective-C that is statically checked by Xcode and Apple.

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

#137

About time, as an user it's fucking annoyng when you download an app but will refuse to work unless you're online even when it has zero needs for it

To be fair that's just bad UX, there is no necessity for apps using rollout to access the internet as (I hope) rollout caches the app.

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

#138

Just imagine www didn't exist and Apple already had ios and apps. If someone came up with the idea of www and an app called web browser , would apple accept it in the app store? They would only accept it if they build it themselves. At some point is there a risk that Apple may also start to ban the web browser, despite that it's under strict control on IOS?

This is why you don't build on someone else's platform. Apple/Google/Platform Owner will always do what's right for them, not the customer, and not the developer, for example banning Amazon from selling books in their kindle app, not allowing competing browsers (they recognise the power of the web as a platform), not allowing competing sales mechanisms (where they don't get a cut), and here not allowing developers to…

I agree - they're definitely putting the customer's security first. If people want to use an open environment, the web browser is always available on iOS anyway. Apple are completely within their rights to restrict their application platform.

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

#139
post #91
post #82

Earlier quoted context omitted.

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.

This is true. The problem is bad actors can use this to bypass Apple's review. As an iOS app publisher I slightly regret this inconvenience. As an iPhone user, I appreciate Apple looking out for my security.

Apple's review isn't that useful in this case as a pre-check, it is possible to avoid it if you want. Apple review does automated code checks & a reviewer manually using your app. With that review process you can deliver executable code after the fact in any way you want and only get caught after the fact if it's even noticeable. You can even get sneaky and add some security exploit to make it look like a mistake.

It's much like the argument 'if you ban guns only criminals will have guns' and it's quite true in this case.

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

#140

What will happen to YouTube? YouTube has been pushing new functionality ahead of updates for me recently. For example, the new "double tap to rewind 10 seconds" feature appeared at random one day (without an any updates)...then eventually the feature is announced in an App Store update. Or is the app review process more subjective?

Hmm, I definitely had to install an update for the YouTube app to receive the double tap to rewind/fast-forward.
Post reply on HN