9 ms·

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

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.
    - skrebbel 11y ago
      They take pull requests
    - spicyj 11y ago
      No one said anything about webpack. If you have another async module loading syntax you'd prefer I'm sure we'd be happy to look at it.
      - Touche 11y ago
        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.
        spicyj 11y ago
        React Native has its own packager, at least for now.
murukesh_s 11y ago
"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.
doe88 11y ago
> 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.
- andrewljohnson 11y ago
  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.
  - habitue 11y ago
    Is it illegal? I would expect it to maybe break the ToS or something contract related, not be criminal.
    - derefr 11y ago
      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.
      - eloisant 11y ago
        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.
teacup50 11y ago
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 11y ago
  Couldn't this also aide in correcting regressions at the same time?
  - robmcm 11y ago
    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.
  - teacup50 11y ago
    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 11y ago
      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
- mokkun 11y ago
  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.

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.
  - skrebbel 11y ago
    They take pull requests
  - spicyj 11y ago
    No one said anything about webpack. If you have another async module loading syntax you'd prefer I'm sure we'd be happy to look at it.
    - Touche 11y ago
      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.
      - spicyj 11y ago
        React Native has its own packager, at least for now.

murukesh_s 11y ago

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

doe88 11y ago

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

andrewljohnson 11y ago
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.
- habitue 11y ago
  Is it illegal? I would expect it to maybe break the ToS or something contract related, not be criminal.
  - derefr 11y ago
    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.
    - eloisant 11y ago
      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.

teacup50 11y ago

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 11y ago
Couldn't this also aide in correcting regressions at the same time?
- robmcm 11y ago
  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.
- teacup50 11y ago
  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 11y ago
    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
mokkun 11y ago
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.