AppHub – Update React Native Apps Without Re-Submitting to Apple

by arbesfeld • 11 years ago

154 67 11 years ago

ealexhudson2• 11 years ago

I see that lasting almost three weeks before Apple shut it down (assuming anyone uses it...)

paste0x78• 11 years ago

Apple does allow it as long as they are only pushing html / js. IPA changes would still need to go though Apple. From Apples guidelines: https://developer.apple.com/programs/ios/information/iOS_Pro...

"The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework or JavascriptCore, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store."

Sephiroth87• 11 years ago

I think they are stretching the rule too much, I don't see this lasting very long...

ealexhudson2• 11 years ago

Sure, but this is a case of the letter versus the spirit - and as a blatant end-run around the app store application process (they advertise it as a feature) I don't see those terms lasting too long. And/or any app that changes too much stuff on download will get pulled very quickly.

Apple don't have a track record of interpreting their terms particularly generously.

murukesh_s2• 11 years ago

"..and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store."

That seems to be a reasonable clause, and should actually benefit everyone, provided the developers stick to the rule and don't abuse that option.

s73v3r5• 11 years ago

Reading through their page, it gives the impression that they fully intend for people to use it for adding/changing features. The guidelines explicitly state this is not allowed.

untog• 11 years ago

That's what they say now, yes. But reading between the lines it's pretty clear they don't want behaviour like this.

jbob2000• 11 years ago

Apparently it is within the terms of the iOS developer program? They list that in their FAQ near the bottom of the page

natch3• 11 years ago

They are pointing to just one paragraph of the agreement and ignoring other paragraphs that say the opposite.

benthehenten2• 11 years ago

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.

[1] https://developer.apple.com/programs/ios/information/iOS_Pro...

[2] http://info.meteor.com/blog/apple-hot-code-push-mobile

[3] https://trigger.io/

[4] http://docs.build.phonegap.com/en_US/tools_hydration.md.html

[5] https://medium.com/@clayallsopp/a-dynamic-crazy-native-mobil...

hharnisch• 11 years ago

It looks like you're sending the whole JS bundle when doing a deploy, do you think you'll support async loading? Would help with massive applications and other speed related optimizations.

arbesfeld3• 11 years ago

Great question! Our iOS SDK asynchronously downloads new JS bundles and images, and then loads the updates when your app is restarted. There are definitely some speed optimizations that we can make in the future, such as using diffs to apply updates.

We're excited to open source the iOS SDK in the future so that everyone can take a look and contribute.

vjeux• 11 years ago

Right now React Native packager bundles everything in one file but we're actively working on splitting it into many different files and supporting require.ensure() in order to asynchronously load modules.

murukesh_s2• 11 years ago

"Use git push to update your app without re-submitting to Apple." - That's the prominent tagline in your home page. Isn't that too direct? One suggestion - wording it without being too obvious could prevent your from a possible ban, and an even worser outcome of Apple changing their policies.

doe88• 11 years ago

but updating JavaScript code is explicitly permitted by the iOS Developer Agreement [1].

With the following caveat though:

[3.3.2] provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.

andrewljohnson2• 11 years ago

Yep, "feature flipping" can lead to app rejections and getting booted from the store.

* If the AppHub founders think this is a real danger, then you'd expect bold and strenuous documentation.

* But, I wonder if the AppHub authors believe that people should ignore this rule, because practically speaking it's hard to get caught. They wouldn't say so, of course, because encouraging people to break Apple ToS is illegal.

teacup502• 11 years ago

Apple aside, doing this kind of thing silently sucks for users -- one of the benefits of native applications over the web is having control over when updates containing potential regressions are inserted into your workflow.

awinder2• 11 years ago

Couldn't this also aide in correcting regressions at the same time?

mokkun• 11 years ago

Totally agree with this. As a dev it might sound like a cool thing, but as a user it sucks. Many, many times I found myself not updating an app because I won't agree with the changes (UI, new features, etc) or new permissions that were required.

Upwad0n• 11 years ago

Whoa, this is sick!

edgeman27• 11 years ago

Updated iOS Developer Agreement in 3..2..1..

natch3• 11 years ago

Technically, this looks like a cool hack.

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.

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.

But what about section 3.3.3?

    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

Finally, you do realize that the App store policies are subject to change in order to adapt to hacks like this, right?

Again cool hack but it will be interesting to see if it gets out of the starting gate.

tilt2• 11 years ago

Just to reiterate, it seems legit reading from http://image.slidesharecdn.com/real-worldreactnativees7-1506...

Now, to add something to the matter, "direct update" is something that Apple already hosts in its App Store through Cordova apps and its commercial versions (i.e. MobileFirst) https://www.apple.com/pr/library/2014/12/10Apple-and-IBM-Del...

Not sure how many React Native projects are hosting their bundles outside theirs apps in the wild, but there are already apps released on the store (as per Facebook Groups, Ads Manager).

Still, I agree things might change (on the Apple's side).

natch3• 11 years ago

Yeah I think I'd like to see this work. If it's used for good things. Not sure who is right about whether it's allowed in the current terms; it depends on how you read it. My prediction though is that Apple will see it as enough of a threat to their control that they will either disallow it outright under their own reading of the terms, or they will tweak the terms to disallow it. But then... need I say... I could be wrong.

benthehenten2• 11 years ago

AppHub is not trying to circumvent the Apple release process, rather, we want to make distributing updates as frictionless as possible. The main advantages we give developers are instant updates and staged rollouts (deploying new features to a percentage of users).

Glad you pointed out Section 3.3.3 of the Developer Agreement. From our understanding, it is intended to prevent developers from trying to avoid the App Store fees. As always, it will be up to developers to follow Apple's guidelines in their iOS apps.

s73v3r5• 11 years ago

This:

"Stop waiting weeks for Apple to review your app. Just add our iOS framework and start pushing updates."

says otherwise.

aaronbrethorst• 11 years ago

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.

This whole spirit/letter thing comes up on occasion. Here's a previous example: http://daringfireball.net/2012/05/more_on_airfoil_speakers_t...

s73v3r5• 11 years ago

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.

markcerqueira2• 11 years ago

Yes, but if AppHub didn't build this, someone else would. Just because something isn't the "safest" idea doesn't mean we shouldn't stop experimenting.

Also, how would this make it easier to steal user information or share your stash of dick pics? Sounds like a lot of FUD to me.

jsierles• 11 years ago

Agreed. Amazingly, we released our version of this within the hour: https://reploy.io. And many other frameworks are doing the same thing. http://blog.ionic.io/announcing-ionic-deploy-alpha-update-yo....

s73v3r5• 11 years ago

"Yes, but if AppHub didn't build this, someone else would."

What exactly does that mean? My statement doesn't change just because someone else made it.

maehwasu• 11 years ago

It's not about whether someone else would build this. It's about whether Apple will take draconian steps to stop any of the hotloaders from working.

mbrock• 11 years ago

Well, the basic functionality is already trivial to implement yourself: you just point React Native at your https URL and use HTML5 Application Cache. We're doing it just because it's the easiest way to develop with React Native.

edko• 11 years ago

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.

sintaxi• 11 years ago

Indeed, we've been advocating this approach since Aug 2, 2008. But to be more specific, when PhoneGap was first developed it would load the HTML/CSS/JavaScript from a server just like a chrome-less browser with the url hard coded. Unfortunately Apple started to reject apps that used PhoneGap because they felt it violated this rule which forced us to change how it works to have the web assets already packaged in the application.

We later found out that Apple thought PhoneGap was our own custom version of webkit which is what actually concerned them more. Once they came to learn more about the implementation detail on how PhoneGap works it started to become accepted but this was a very long process.

To clarify, 1) Apple hasn't always approved apps packaged with PhoneGap. 2) PhoneGap hasn't always taken this approach (although this was the initial design).

kzhaouva• 11 years ago

Really cool hack! Would hate to see Apple ban this...

ericjang• 11 years ago

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.

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.

AlwaysBCoding• 11 years ago

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.

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?

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.

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.

mikewhy• 11 years ago

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.

This sounds great!

volaski• 11 years ago

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.

arbesfeld3• 11 years ago

AppHub cofounder here -- I'm glad you brought this up.

A developer who chooses to use AppHub is not depending on the platform. If AppHub goes away (which we hope will never happen!), our iOS SDK defaults to using the App Store build. Moreover, developers can implement their own "AppHub server" if they so choose, so they're not locked in to using our service.

We're excited to open source the iOS SDK when we launch to the public so that developers can audit the code and assure themselves that they're not depending on our platform.

bigiain• 11 years ago

My uncertainty is more around what Apple's going to do the first time someone publishes a free FlappyBird clone, then when it's got several million or tens of million downloads magically turns it into a spambot or a million-strong pocket DDoS zombie army.

potomushto• 11 years ago

Celebrate! This is the last time you'll have to wait for Apple review.

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

arbesfeld3• 11 years ago

Yep, so true! Our dashboard makes it super clear to deploy JS bundles that are versioned to specific App Store releases, and we provide an API for testing new JS bundles on old App Store releases.

I'd love to have you try it out - ping me at (matt at apphub.io).

BradRuderman• 11 years ago

From a business perspective, how many apps use react? I am interested in what is the size of the market for this business?

AppHub – Update React Native Apps Without Re-Submitting to Apple

Related Stories