AppHub co-founder here, we realize that this is something that would seem to be prohibited by Apple, but updating JavaScript code is explicitly permitted by the iOS Developer Agreement [1]. This same technology is used by Meteor [2], Trigger.io [3], and Adobe Hydration [4], and also used by Facebook and Palantir [5] in their apps.<p>[1] <a href="https://developer.apple.com/programs/ios/information/iOS_Program_Information_4_3_15.pdf" rel="nofollow">https://developer.apple.com/programs/ios/information/iOS_Pro...</a><p>[2] <a href="http://info.meteor.com/blog/apple-hot-code-push-mobile" rel="nofollow">http://info.meteor.com/blog/apple-hot-code-push-mobile</a><p>[3] <a href="https://trigger.io/" rel="nofollow">https://trigger.io/</a><p>[4] <a href="http://docs.build.phonegap.com/en_US/tools_hydration.md.html" rel="nofollow">http://docs.build.phonegap.com/en_US/tools_hydration.md.html</a><p>[5] <a href="https://medium.com/@clayallsopp/a-dynamic-crazy-native-mobile-future-powered-by-javascript-70f2d56b1987" rel="nofollow">https://medium.com/@clayallsopp/a-dynamic-crazy-native-mobil...</a>
I wish you folks well, and I think this looks neat, but—as others have pointed out—although you follow the letter of the iOS Developer Agreement, I expect Apple will feel you do not follow the spirit of it. They may change the agreement outright, or simply say that use of AppHub falls under the purview of 3.3.2. But, either way, I recommend you have a contingency plan.<p>This whole spirit/letter thing comes up on occasion. Here's a previous example: <a href="http://daringfireball.net/2012/05/more_on_airfoil_speakers_touch" rel="nofollow">http://daringfireball.net/2012/05/more_on_airfoil_speakers_t...</a>
This is awesome (and was seemingly inevitable now that React Native is in play), and it will be really interesting to see what Apple eventually does about this.<p>If they change the terms of service to prevent hot loading app updates via JavaScriptCore they're going to isolate a lot of developers, since so much cool stuff is being developed around JavaScriptCore right now. The rnplay playground app that's currently in the App Store dynamically loads entire apps onto your phone to play around with -- it's so cool, why block things like that from existing?<p>If they do nothing, it's clear a rogue app store distribution ecosystem is going to evolve (case in point ^) which seems like a sub-optimal outcome for everyone.<p>Isn't the only eventuality for Apple to change their app store approval process to allow dynamic updates? I mean it's obviously better for developers, and probably ultimately better for end users as well. I just don't see any way around it with the momentum writing iOS apps in Javascript has right now.
The PhoneGap app (and probably many others) has been pushing JS code without the need of Apple's approval for a long time now, and Apple hasn't had any problem with it. If this is not abused, to do things against the ToS, it is a really nice thing to have.
We released an app onto the store last year that was a UniWebView pointed to an S3 website, constantly updated the code without pushing through the app store. No qualms from Apple.<p>This sounds great!
> Celebrate! This is the last time you'll have to wait for Apple review.<p>This is the great idea! And it works for many. It's easy, though, to get an inconsistent state of the app, where JS bundle would be newer than ObjC part. You should be super careful while npm-installing libs, including react-native itself since most of them consist source code that should be compiled. Maybe it wouldn't be a problem when react-native and most major third-party libraries will be stable
Technically, this looks like a cool hack.<p>I've never found submitting an app for app review to be that big of a deal, if your app is well designed, useful, and not negligent or malicious toward user needs.<p>Your FAQ says what you're doing is explicitly permitted by Apple, and points to section 3.3.2 of the iOS Developer Program Information document.<p>But what about section 3.3.3?<p><pre><code> 3.3.3
Without Apple’s prior written approval or as permitted
under Section 3.3.25 (In App Purchase API), an
Application may not provide, unlock or enable
additional features or functionality through
distribution mechanisms other than the App Store
or VPP/B2B Program Site
</code></pre>
Finally, you do realize that the App store policies are subject to change in order to adapt to hacks like this, right?<p>Again cool hack but it will be interesting to see if it gets out of the starting gate.
The problem with this is not if Apple will allow it or not, but the uncertainty, which is deadly for a platform. No developer who take themselves seriously will want to depend on a platform that may go away. Good for you if Apple lets you get away with it, but that doesn't mean it will be like that forever, nor does it mean all apps using this approach will be accepted. It's case by case, and it's already shitty as is when it comes to approval process, most developers would just decide to follow the directions.
This is pretty neat! However, Apple can bypass this by simply rejecting apps that bundle the AppHub framework, with the claim that apps whose feature updates bypasses app store approval present a security vulnerability.<p>A more useful approach would be to open-source the AppHub framework so users can implement auto-updating themselves, and it would be harder for Apple to catch this.
And this is why we can't have nice things. Someone is going to submit a React Native app to the App Store, use this bullshit to bypass the update review, and either use it to steal information of a user, or post dick pics all over the app.