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.
> 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.
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.
It feels like it might be some sort of crime specifically to misrepresent your product as being capable of X and sell it to people who you know will try to use it for X, when X is disallowed by the ToS of the platform. Con-artistry of a sort.
You could see that as "false advertising", but considering they link to the Apple TOS they're not really hiding everything.
And actually, merely adding features doesn't seem to be forbidden as long as the features you add are not "inconsistent with the intended and advertised purpose of the Application as submitted to the App Store"
So let's say you release a file manager and later, surprise! It's also a SNES emulator! Well, then yes, I can see that against the TOS. But if you're just making improvements to your app, I don't see a problem.
I think illegal is the correct word there. I won't comment on the statutes (IANAL).
It was just a hypothetical though. AppHub has plenty of legit use cases under Apple rules, and it's probably not all that dangerous even if you "mis-use" it slightly. AppHub would have to explicitly encourage people to break the rule to run afoul, or Apple would have to organically notice a bunch of apps doing a bunch of outlandish feature flipping.
With the way the CFAA is enforced, you look at a computer in a way someone with money doesn't want you to and it's federal prison worthy. I'm sure an over eager DA could and would try and make the case.
The 'AppHub' stack looks good and can solve lots of problems.
However I think advertising it as a mechanism to get around the App Store review process is a quick way to get noticed by Apple, and not in a good way.
"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.
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.
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.
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
Yes it's a double edged sword, in most cases I would favor the ability to update and fix the application without having to force users to manually install an update.
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.
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.
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.
Webpack is the only loader that does require.ensure to my knowledge. To answer your question; there's also System.import() (SystemJS) and require([]) (any AMD loader like requirejs) that are async module loading.
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.
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 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.
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.
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).
"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."
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.
"..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.
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.
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.
> 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
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).
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.
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.
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.
If Apple wanted that they would just give developers the ability to update without review [or a question when submitting a new binary "Have you made significant updates that changes the functionality of your app and or features to the app you are submitting? Yes/No". They don't even let you distribute public beta through their system without the app being reviewed first because they want complete content control over the software distributed on their devices.
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).
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.
Anyway, there's no way they could lose (too much) control. The "native" part of the apps is still subject to resubmission.
The "react native" part is mostly UI layer/composition and business logic.
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.
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.
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.
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.
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.
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."
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.
[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...