17 ms·

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

154 points by arbesfeld 11y ago

ealexhudson 11y ago
I see that lasting almost three weeks before Apple shut it down (assuming anyone uses it...)
- paste0x78 11y 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_Program_Information_4_3_15.pdf 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 11y ago
    I think they are stretching the rule too much, I don't see this lasting very long...
  - ealexhudson 11y 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_s 11y 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.
  - s73v3r 11y 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 11y 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 11y ago
  Apparently it is within the terms of the iOS developer program? They list that in their FAQ near the bottom of the page
  - natch 11y ago
    They are pointing to just one paragraph of the agreement and ignoring other paragraphs that say the opposite.
benthehenten 11y 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_Program_Information_4_3_15.pdf https://developer.apple.com/programs/ios/information/iOS_Pro... [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-mobile-future-powered-by-javascript-70f2d56b1987 https://medium.com/@clayallsopp/a-dynamic-crazy-native-mobil...
- hharnisch 11y 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.
  - arbesfeld 11y 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 11y 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.
    - Touche 11y ago
      Oh, so you're only going to support WebPack? That's disappointing.
Upwad0n 11y ago
Whoa, this is sick!
deleted 11y ago
[deleted]
edgeman27 11y ago
Updated iOS Developer Agreement in 3..2..1..
natch 11y 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.
- tilt 11y ago
  Just to reiterate, it seems legit reading from http://image.slidesharecdn.com/real-worldreactnativees7-150630192554-lva1-app6891/95/real-world-react-native-es7-15-638.jpg 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-Deliver-First-Wave-of-IBM-MobileFirst-for-iOS-Apps.html 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).
  - natch 11y 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.
aaronbrethorst 11y 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_touch http://daringfireball.net/2012/05/more_on_airfoil_speakers_t...
s73v3r 11y 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.
- markcerqueira 11y 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 11y ago
    Agreed. Amazingly, we released our version of this within the hour: https://reploy.io https://reploy.io. And many other frameworks are doing the same thing. http://blog.ionic.io/announcing-ionic-deploy-alpha-update-your-app-without-waiting http://blog.ionic.io/announcing-ionic-deploy-alpha-update-yo....
  - s73v3r 11y 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.
    - markcerqueira 11y ago
      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!
  - maehwasu 11y 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.
edko 11y 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 11y 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 11y ago
Really cool hack! Would hate to see Apple ban this...
ericjang 11y 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 11y 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 11y 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 11y 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.
- arbesfeld 11y 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 11y 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 11y 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
- arbesfeld 11y 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 11y ago
From a business perspective, how many apps use react? I am interested in what is the size of the market for this business?

154 points by arbesfeld 11y ago

ealexhudson 11y ago

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

paste0x78 11y 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_Program_Information_4_3_15.pdf 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 11y ago
  I think they are stretching the rule too much, I don't see this lasting very long...
- ealexhudson 11y 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_s 11y 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.
- s73v3r 11y 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 11y 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 11y ago
Apparently it is within the terms of the iOS developer program? They list that in their FAQ near the bottom of the page
- natch 11y ago
  They are pointing to just one paragraph of the agreement and ignoring other paragraphs that say the opposite.

benthehenten 11y 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_Program_Information_4_3_15.pdf https://developer.apple.com/programs/ios/information/iOS_Pro... [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-mobile-future-powered-by-javascript-70f2d56b1987 https://medium.com/@clayallsopp/a-dynamic-crazy-native-mobil...

hharnisch 11y 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.
- arbesfeld 11y 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 11y 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.
  - Touche 11y ago
    Oh, so you're only going to support WebPack? That's disappointing.

Upwad0n 11y ago

Whoa, this is sick!

deleted 11y ago

[deleted]

edgeman27 11y ago

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

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

tilt 11y ago
Just to reiterate, it seems legit reading from http://image.slidesharecdn.com/real-worldreactnativees7-150630192554-lva1-app6891/95/real-world-react-native-es7-15-638.jpg 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-Deliver-First-Wave-of-IBM-MobileFirst-for-iOS-Apps.html 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).
- natch 11y 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.

aaronbrethorst 11y 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_touch http://daringfireball.net/2012/05/more_on_airfoil_speakers_t...

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

markcerqueira 11y 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 11y ago
  Agreed. Amazingly, we released our version of this within the hour: https://reploy.io https://reploy.io. And many other frameworks are doing the same thing. http://blog.ionic.io/announcing-ionic-deploy-alpha-update-your-app-without-waiting http://blog.ionic.io/announcing-ionic-deploy-alpha-update-yo....
- s73v3r 11y 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.
  - markcerqueira 11y ago
    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!
- maehwasu 11y 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.

edko 11y 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 11y 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 11y ago

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

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

arbesfeld 11y 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 11y 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 11y 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

arbesfeld 11y 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 11y ago

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