Live data from Hacker News

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

apphub.io

21–30 of 69 posts

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

#21

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.met…

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

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

#22

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.met…

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.

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

#23
post #21

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.met…

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

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

#24
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...

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

#25
post #21

Earlier quoted context omitted.

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

Is it illegal? I would expect it to maybe break the ToS or something contract related, not be criminal.

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

#27

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

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 Applicatio…

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.

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

#28
post #12

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 app…

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 S…

This:

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

says otherwise.

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

#29
post #26

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.

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.

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

#30
post #28

Earlier quoted context omitted.

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 S…

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

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.

Post reply on HN