4 ms·

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

by 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.
  - tilt 11y ago
    Same sentiment here. Let's hope you're 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.
benthehenten 11y 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.
- s73v3r 11y ago
  This: "Stop waiting weeks for Apple to review your app. Just add our iOS framework and start pushing updates." says otherwise.
  - balls187 11y ago
    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 11y ago
      I really don't see Apple making that distinction.
      - balls187 11y ago
        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.

by natch 11y ago

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.
- tilt 11y ago
  Same sentiment here. Let's hope you're 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.

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

s73v3r 11y ago
This: "Stop waiting weeks for Apple to review your app. Just add our iOS framework and start pushing updates." says otherwise.
- balls187 11y ago
  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 11y ago
    I really don't see Apple making that distinction.
    - balls187 11y ago
      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.