
AppHub – Update React Native Apps Without Re-Submitting to Apple - arbesfeld
https://apphub.io/
======
benthehenten
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...](https://developer.apple.com/programs/ios/information/iOS_Program_Information_4_3_15.pdf)

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

[3] [https://trigger.io/](https://trigger.io/)

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

[5] [https://medium.com/@clayallsopp/a-dynamic-crazy-native-
mobil...](https://medium.com/@clayallsopp/a-dynamic-crazy-native-mobile-
future-powered-by-javascript-70f2d56b1987)

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

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

~~~
teacup50
Yes, but as a developer, you're less likely to ship regressions in the first
place if your deployment process involves more structure (beta testing,
internal code freezes, release branches containing only bug fixes, etc) than
'git push'.

Of course, that runs counter to the "continual deployment" idea popular in web
circles, but _that 's the entire point_.

~~~
awinder
This doesn't prescribe which branch you do the git push to though. I'm sure
you could just as easily set up a branching scheme where you went through
testing and internal releases, and launched new code off a stable branchline

------
aaronbrethorst
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...](http://daringfireball.net/2012/05/more_on_airfoil_speakers_touch)

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

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

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

~~~
paste0x78
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...](https://developer.apple.com/programs/ios/information/iOS_Program_Information_4_3_15.pdf)

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

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

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

------
mikewhy
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!

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

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

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

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

~~~
s73v3r
This:

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

says otherwise.

~~~
balls187
The key verbiage is "release" vs "updates."

You still have to go through the initial App Store Release process initially.
After that, using this framework you can push updates directly, rather than
waiting the requisite 5 business days[1]. As an app developer, being able to
push updates (read: bug fixes) immediately is a blessing--we live and die by
our reviews, and a bad update can cause an avalanche of negative reviews.
Waiting 5 days[2] for a fix to go live can seem like an eternity.

1\. It was 5 business days when I was an IOS Developer in 2012.

2\. For all updates it was 5 business days. There were rumors that if you had
a evangelist at Apple you were on real good terms with, they could fast track
the update for you, if it was a rare occurrence.

~~~
s73v3r
I really don't see Apple making that distinction.

~~~
balls187
Nor do I.

Best case, this is a minor annoyance to Apple, and they don't bother.

Worst case, a bad actor abuses this forcing Apple to immediately pull any and
all apps built ontop of this.

For anything other than an MVP, I wouldn't risk it.

~~~
bryanlarsen
Hopefully AppHub can mitigate the worst case scenario to "you have to fall
back to standard Apple update procedures".

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

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

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

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

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

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

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

~~~
s73v3r
"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.

~~~
markcerqueira
It means that this isn't a mind-boggling amazing idea. This is like taking A/B
testing to its logical extreme where you can just inject new tests (code) into
an existing product.

Also, since you were so kind to reply, why don't you explain what this means:
"use it to steal information of a user, or post dick pics all over the app."

Thanks!

------
Upwad0n
Whoa, this is sick!

