12 ms·

Apple allows hot code push for JS downloaded and run by WebKit

139 points by yaliceme 12y ago

_random_ 12y ago
Many games are constantly downloading multi-megabyte "updates". I bet some of that stuff is Lua.
- mahyarm 12y ago
  No, they catch that kind of stuff in app review. Lua code updates would be a small part of that. They're asset and IAP content, that is why it's multi-megabyte. It comes from experience.
  - anonymoushn 12y ago
    Can they? For instance in love2d the mechanism for distributing a blob of assets after the fact is the same as the mechanism for distributing a blob of code after the fact. I'm not sure I can rewrite my app to be incapable of loading code from mounted archives, though I could rewrite it to not mount any archives until it's done loading code.
    - mahyarm 12y ago
      Well they detected it my company when we did it. We had little lua mini-games that you could download, and they rejected the app for it. If you work really hard to hide it, then you could do it possibly. Like most private API calls are not detected by their tool if you execute it with a composed string based peformSelector: style action for example. And they can't really detect private view manipulation either. But they can also use plain deduction in using your app. As in, 'this wouldn't be possible unless they are downloading code'. They also don't like finding out about hidden shit that is only revealed once the app is approved.
turval 12y ago
This is probably the only feature that gives hybrid apps an actual upper-hand vs their native counterparts. So now I could instantly push an update to my apps by hot-swapping the js code, while a native version would be stuck in a a multi-day approval process. I can imaging there are some scenarios where getting a feature to market before a competitor would make this feature really valuable. One question, it specifically mentions using the WebKit framework, does that mean that this is not allowed under the old UIWebView class?
- AznHisoka 12y ago
  "getting a feature to market before a competitor" Very rarely is that ever important in the mobile app industry.
  - hayksaakian 12y ago
    Is that because it wasn't possible or because it wasn't useful/helpful to do?
    - potatolicious 12y ago
      Not very useful. Mobile apps are pretty trivial to clone (clone poorly, usually), and anything remotely successfully is cloned within days of popping up on the radar. The first-mover advantage is close to zero. The lone exception are things that are intrinsically hard to clone - deep hardware-level integration, native code that stretches the limits of current platform understanding, etc. Which doesn't apply at all to webview-powered apps. At all.
- _random_ 12y ago
  It will be a matter of choice between delivering a mediocre experience constantly or a quality one intermittently.
- teacup50 12y ago
  Of course, this advantage is more than outweighed by having to use JavaScript in the first place.
brianchu 12y ago
This sounds great. It bears noting that this form of code push is routinely implemented in native apps too - I know at least that the Quora and Facebook iOS apps make liberal use of web views (and code push). Native apps can take the opposite hybrid approach - sprinkle in web views where needed inside a native codebase, as opposed to sprinkling in native plugins (and a native wrapper) in a web codebase.
- dgreensp 12y ago
  (I work at Meteor) There's a small point to make here that many iOS apps that use WebViews just do the easy thing and load the content over the Internet, rather than storing it on the phone and fetching updates in the background. This makes sense for dynamic content that requires an Internet connection, but if you want to be able to push changes to the entire UI of your app and have it work offline, you need to do the more complicated thing and figure out how to serve the files from app storage into a WebView. Meteor isn't the first to do this by any means, but it sure makes it easy!
- zw 12y ago
  > ... Facebook iOS apps make liberal use of web views (and code push) The Facebook apps absolutely do not use web code anymore. Their native code is conditionally enabled remotely.
seanalltogether 12y ago
Last I read, Apple was limiting javascript performance in UIWebViews compared to what was available in Safari, is this still the case?
- Sidnicious 12y ago
  No. In iOS 8 apps can use WKWebView, which is accelerated.
  - seanalltogether 12y ago
    Wow, thanks, I can't believe I missed reading about this until now. This framework looks really promising
    - simonh 12y ago
      The only reason it wasn't allowed until now was security. With iOS 8 cross process communication improvements, the JITed JavaScript engine can be used by third party apps in a segregated fashion without sacrificing security.
      - carloscm 12y ago
        Is this also true when using JavaScriptCore directly? Or do you only get JIT compilation in the context of a web view?
        kenferry 12y ago
        Only in a web view. The point is that the JITed code is in an isolated process with few permissions.
        gsnedders 12y ago
        And vitally it can allocate executable memory, which nothing you write can.
Rygu 12y ago
This doesn't come as news to me. Every website can be shown via WK/UIWebViews as a "mobile app". Each javascript therefore is "hot code" being pushed. But I don't think Apple ever disallowed that, on the contrary it was the only way to develop for iPhone 1.
- debergalis 12y ago
  [i work at meteor] After we announced 0.9.2 and hot code push for mobile apps, many of our users wanted to be sure it was kosher. It's easy to get confused about this because the App Store review guidelines suggest that downloading code isn't okay. And many Meteor developers don't have a deep background in the iOS ecosystem. The cool part about 0.9.2 is you can build mobile apps with just your basic Meteor/JS/HTML5 knowledge. Apple's formal developer agreement is both controlling and clarifying, and since it's a bit harder to find we thought it would be good to point Meteor developers at the key part.
bribri 12y ago
Ultimate linkbait title for HN
- dang 12y ago
  I don't see it? In cases of misleading or linkbait titles we're glad to hear suggestions for a better title. There are too many posts here for us to correct everything correctly, so help is welcome.
  - redbergy 12y ago
    While the title isn't necessarily false, it's misleading link bait because people click on it thinking that Apple is now allowing us to push out Swift/Objective-C updates in-app. It's more feasible than ever that this could happen now since they've added the ability to include frameworks inside of your apps where previously you couldn't. The link is referring to using HTML/JS/CSS to update apps, which has been possible since the UIWebView in 2.0 - literally for years and years. You download those files and view them in a web view – technically it's running javascript "hot code" but this isn't news, it's been around since we could develop apps for iOS. A better title might be "Apple allows you to download and view HTML in a web browser inside of your app" but that wouldn't generate many clicks.
    - dunham 12y ago
      Yeah, I found the title misleading, too. What is news to me is the explicit mention of WebViews. I remember this exception previously being for JavaScript in general, which I assume would include JavaScriptCore. Does anyone know if they changed this before or after JavaScriptCore was introduced?
    - dang 12y ago
      Ok, we changed the title to something close to that but with more language from the article itself. If that's not good enough we can edit it again.
      - 12y ago
snfernandez 12y ago
Don't see the point a blog requiring javascript enabled to load.
- maccard 12y ago
  You don't see the point of the blog of a javascript web framework requiring javascript?
  - TeMPOraL 12y ago
    I guess OP doesn't see the point of using a JavaScript framework for, per [0], "what should be text communicating a fucking message". [0] - http://motherfuckingwebsite.com/ http://motherfuckingwebsite.com/
    - kentonv 12y ago
      Probably because it would look odd if Meteor's own web site wasn't build on their own framework. Plus if they fix a typo the page updates in your browser without reloading. Which is at least kind of neat. :)
      - TeMPOraL 12y ago
        Fair enough :).
      - deleted 12y ago
        [deleted]
- skeletonjelly 12y ago
  Hate how Google's blog engine does this too
colinbartlett 12y ago
I've been using Trigger.io like this for years, it's very useful. But don't forget that the app download from the AppStore will have old code which may or may not be a problem when you first open the app.
dozy 12y ago
I once worked for Pyxis Mobile (now Verivo Inc.) which touted a platform which would provide you with native iOS, Android, and BlackBerry (years ago..) apps, which would build themselves at run time based on a database/app meta data. This allowed apps to completely change themselves without a resubmission, while being in-line with Apple's guidelines, and technically be purely native. Between lazy loading and the fact that the interfaces were simple, the system worked well. Point being - I've thought a lot about and seen the result of the "avoid app store submission" value proposition. After all these years, I find the aforementioned value proposition...not that valuable. In my experience it's fine to only be able to push iOS updates on something like a once/week cadence. Of course on Android, you can push daily if you really want to. Ultimately, my thought is that with all of the complications and hard work required to create and maintain a mobile app, this is a tiny piece, and should play little into your decision when choosing to develope natively vs. w/ Meteor/phonegap vs. something else. Of course, the geek in me and the Android fanboy in me loves skirting Apple's "guidelines". :)
- EGreg 12y ago
  Have you ever done A/B testing? That's the real value if you want to actually measure things and improve them. Maybe doing so can even minimize spectacular bugs when you push. And how would you accomplish this A/B iteration with weekly pushes to everyone?
  - ewang1 12y ago
    You could code both views and show one or the other based on a server-side flag.
    - EGreg 12y ago
      And that is rudimentary "code push" isn't it?
      - efdee 12y ago
        I don't think that it is. You include both views in the submitted app and decide to show only one. There's no code push being done.
rubyn00bie 12y ago
In other words: webpages function as expected on iOS. ... Not to blame the meteor folks for writing it, if they were getting asked it... But wow. I personally think the title is a bit click-baity, but that's because it's not really hot code push. It's loading a web view. If this was hot loading new native code that'd be newsworthy or at least interesting.
- mrcwinn 12y ago
  Insofar as pushing new Meteor code up to the server will trigger an update to connected clients, it's hot code push. That's _not_ the same, technically, as a web view displaying a webpage that will update on the next page refresh. Link bait? Maybe, maybe not. There are more interesting discussions to have. :-)
- debergalis 12y ago
  [i work at meteor] Meteor's hot code push on mobile is more sophisticated than this. When you deploy a new version of a Meteor app, clients fetch and save the new client JavaScript bundle along with its static assets. Future launches of the installed app immediately run new code (even offline) without first requiring a round trip to a server.
  - dubcanada 12y ago
    How can something that is offline somehow get new code? Besides that it sounds exactly like a website.
    - mratzloff 12y ago
      He's saying it caches the JS and all assets when online so that they can continue to function offline.
  - ChrisAntaki 12y ago
    That sounds awesome. Are you using localStorage?
suyash 12y ago
Nothing new here, anyone who has written a hybrid app or a mobile web application knew about this day1. One of the advantages over native application development. It has nothing to do with meteor or anything like that.
markive 12y ago
Does this count for technologies like Appcelerator? Or can I work around the standard way Appcelerator works for example by making more Javascript code available through a webkit Ti.UI.Webview or something?
donpark 12y ago
Unless I'm mistaken, two primary restrictions are: 1. script must be downloaded only within UIWebView. 2. script must be excuted only within UIWebView. Not sure why #1 is important to Apple but #2 makes perfect sense. I'm assuming Meteor is downloading scripts then passing them as 'data' to native-side to be cached somewhere until it needs to be injected back into UIWebView for execution.
- m_mueller 12y ago
  This distinction is very important to me, but I'm not sure whether it holds true. Can anyone comment whether e.g. JavascriptCore executed code cannot be hot pushed? Does JavascriptCore count as 'Webkit' in Apple's sense? IMO from a technology standpoint it should, but I'm not sure. What about Javascript that's pushed within databases, i.e. CouchDB? So far I was pretty sure that this isn't allowed, but reading this article I'm not entirely sure either anymore.
- gsnedders 12y ago
  Hmm, 1 at least isn't entirely enforced. (Chrome has its own network layer, and quite obviously supports scripting.)
  - donpark 12y ago
    Very good point.
TheLoneWolfling 12y ago
Yet another site that does not load without JS.

139 points by yaliceme 12y ago

_random_ 12y ago

Many games are constantly downloading multi-megabyte "updates". I bet some of that stuff is Lua.

mahyarm 12y ago
No, they catch that kind of stuff in app review. Lua code updates would be a small part of that. They're asset and IAP content, that is why it's multi-megabyte. It comes from experience.
- anonymoushn 12y ago
  Can they? For instance in love2d the mechanism for distributing a blob of assets after the fact is the same as the mechanism for distributing a blob of code after the fact. I'm not sure I can rewrite my app to be incapable of loading code from mounted archives, though I could rewrite it to not mount any archives until it's done loading code.
  - mahyarm 12y ago
    Well they detected it my company when we did it. We had little lua mini-games that you could download, and they rejected the app for it. If you work really hard to hide it, then you could do it possibly. Like most private API calls are not detected by their tool if you execute it with a composed string based peformSelector: style action for example. And they can't really detect private view manipulation either. But they can also use plain deduction in using your app. As in, 'this wouldn't be possible unless they are downloading code'. They also don't like finding out about hidden shit that is only revealed once the app is approved.

turval 12y ago

This is probably the only feature that gives hybrid apps an actual upper-hand vs their native counterparts. So now I could instantly push an update to my apps by hot-swapping the js code, while a native version would be stuck in a a multi-day approval process. I can imaging there are some scenarios where getting a feature to market before a competitor would make this feature really valuable. One question, it specifically mentions using the WebKit framework, does that mean that this is not allowed under the old UIWebView class?

AznHisoka 12y ago
"getting a feature to market before a competitor" Very rarely is that ever important in the mobile app industry.
- hayksaakian 12y ago
  Is that because it wasn't possible or because it wasn't useful/helpful to do?
  - potatolicious 12y ago
    Not very useful. Mobile apps are pretty trivial to clone (clone poorly, usually), and anything remotely successfully is cloned within days of popping up on the radar. The first-mover advantage is close to zero. The lone exception are things that are intrinsically hard to clone - deep hardware-level integration, native code that stretches the limits of current platform understanding, etc. Which doesn't apply at all to webview-powered apps. At all.
_random_ 12y ago
It will be a matter of choice between delivering a mediocre experience constantly or a quality one intermittently.
teacup50 12y ago
Of course, this advantage is more than outweighed by having to use JavaScript in the first place.

brianchu 12y ago

This sounds great. It bears noting that this form of code push is routinely implemented in native apps too - I know at least that the Quora and Facebook iOS apps make liberal use of web views (and code push). Native apps can take the opposite hybrid approach - sprinkle in web views where needed inside a native codebase, as opposed to sprinkling in native plugins (and a native wrapper) in a web codebase.

dgreensp 12y ago
(I work at Meteor) There's a small point to make here that many iOS apps that use WebViews just do the easy thing and load the content over the Internet, rather than storing it on the phone and fetching updates in the background. This makes sense for dynamic content that requires an Internet connection, but if you want to be able to push changes to the entire UI of your app and have it work offline, you need to do the more complicated thing and figure out how to serve the files from app storage into a WebView. Meteor isn't the first to do this by any means, but it sure makes it easy!
zw 12y ago
> ... Facebook iOS apps make liberal use of web views (and code push) The Facebook apps absolutely do not use web code anymore. Their native code is conditionally enabled remotely.

seanalltogether 12y ago

Last I read, Apple was limiting javascript performance in UIWebViews compared to what was available in Safari, is this still the case?

Sidnicious 12y ago
No. In iOS 8 apps can use WKWebView, which is accelerated.
- seanalltogether 12y ago
  Wow, thanks, I can't believe I missed reading about this until now. This framework looks really promising
  - simonh 12y ago
    The only reason it wasn't allowed until now was security. With iOS 8 cross process communication improvements, the JITed JavaScript engine can be used by third party apps in a segregated fashion without sacrificing security.
    - carloscm 12y ago
      Is this also true when using JavaScriptCore directly? Or do you only get JIT compilation in the context of a web view?
      - kenferry 12y ago
        Only in a web view. The point is that the JITed code is in an isolated process with few permissions.
        gsnedders 12y ago
        And vitally it can allocate executable memory, which nothing you write can.

Rygu 12y ago

This doesn't come as news to me. Every website can be shown via WK/UIWebViews as a "mobile app". Each javascript therefore is "hot code" being pushed. But I don't think Apple ever disallowed that, on the contrary it was the only way to develop for iPhone 1.

debergalis 12y ago
[i work at meteor] After we announced 0.9.2 and hot code push for mobile apps, many of our users wanted to be sure it was kosher. It's easy to get confused about this because the App Store review guidelines suggest that downloading code isn't okay. And many Meteor developers don't have a deep background in the iOS ecosystem. The cool part about 0.9.2 is you can build mobile apps with just your basic Meteor/JS/HTML5 knowledge. Apple's formal developer agreement is both controlling and clarifying, and since it's a bit harder to find we thought it would be good to point Meteor developers at the key part.

bribri 12y ago

Ultimate linkbait title for HN

dang 12y ago
I don't see it? In cases of misleading or linkbait titles we're glad to hear suggestions for a better title. There are too many posts here for us to correct everything correctly, so help is welcome.
- redbergy 12y ago
  While the title isn't necessarily false, it's misleading link bait because people click on it thinking that Apple is now allowing us to push out Swift/Objective-C updates in-app. It's more feasible than ever that this could happen now since they've added the ability to include frameworks inside of your apps where previously you couldn't. The link is referring to using HTML/JS/CSS to update apps, which has been possible since the UIWebView in 2.0 - literally for years and years. You download those files and view them in a web view – technically it's running javascript "hot code" but this isn't news, it's been around since we could develop apps for iOS. A better title might be "Apple allows you to download and view HTML in a web browser inside of your app" but that wouldn't generate many clicks.
  - dunham 12y ago
    Yeah, I found the title misleading, too. What is news to me is the explicit mention of WebViews. I remember this exception previously being for JavaScript in general, which I assume would include JavaScriptCore. Does anyone know if they changed this before or after JavaScriptCore was introduced?
  - dang 12y ago
    Ok, we changed the title to something close to that but with more language from the article itself. If that's not good enough we can edit it again.
    - 12y ago

snfernandez 12y ago

Don't see the point a blog requiring javascript enabled to load.

maccard 12y ago
You don't see the point of the blog of a javascript web framework requiring javascript?
- TeMPOraL 12y ago
  I guess OP doesn't see the point of using a JavaScript framework for, per [0], "what should be text communicating a fucking message". [0] - http://motherfuckingwebsite.com/ http://motherfuckingwebsite.com/
  - kentonv 12y ago
    Probably because it would look odd if Meteor's own web site wasn't build on their own framework. Plus if they fix a typo the page updates in your browser without reloading. Which is at least kind of neat. :)
    - TeMPOraL 12y ago
      Fair enough :).
    - deleted 12y ago
      [deleted]
skeletonjelly 12y ago
Hate how Google's blog engine does this too

colinbartlett 12y ago

I've been using Trigger.io like this for years, it's very useful. But don't forget that the app download from the AppStore will have old code which may or may not be a problem when you first open the app.

dozy 12y ago

I once worked for Pyxis Mobile (now Verivo Inc.) which touted a platform which would provide you with native iOS, Android, and BlackBerry (years ago..) apps, which would build themselves at run time based on a database/app meta data. This allowed apps to completely change themselves without a resubmission, while being in-line with Apple's guidelines, and technically be purely native. Between lazy loading and the fact that the interfaces were simple, the system worked well. Point being - I've thought a lot about and seen the result of the "avoid app store submission" value proposition. After all these years, I find the aforementioned value proposition...not that valuable. In my experience it's fine to only be able to push iOS updates on something like a once/week cadence. Of course on Android, you can push daily if you really want to. Ultimately, my thought is that with all of the complications and hard work required to create and maintain a mobile app, this is a tiny piece, and should play little into your decision when choosing to develope natively vs. w/ Meteor/phonegap vs. something else. Of course, the geek in me and the Android fanboy in me loves skirting Apple's "guidelines". :)

EGreg 12y ago
Have you ever done A/B testing? That's the real value if you want to actually measure things and improve them. Maybe doing so can even minimize spectacular bugs when you push. And how would you accomplish this A/B iteration with weekly pushes to everyone?
- ewang1 12y ago
  You could code both views and show one or the other based on a server-side flag.
  - EGreg 12y ago
    And that is rudimentary "code push" isn't it?
    - efdee 12y ago
      I don't think that it is. You include both views in the submitted app and decide to show only one. There's no code push being done.

rubyn00bie 12y ago

In other words: webpages function as expected on iOS. ... Not to blame the meteor folks for writing it, if they were getting asked it... But wow. I personally think the title is a bit click-baity, but that's because it's not really hot code push. It's loading a web view. If this was hot loading new native code that'd be newsworthy or at least interesting.

mrcwinn 12y ago
Insofar as pushing new Meteor code up to the server will trigger an update to connected clients, it's hot code push. That's _not_ the same, technically, as a web view displaying a webpage that will update on the next page refresh. Link bait? Maybe, maybe not. There are more interesting discussions to have. :-)
debergalis 12y ago
[i work at meteor] Meteor's hot code push on mobile is more sophisticated than this. When you deploy a new version of a Meteor app, clients fetch and save the new client JavaScript bundle along with its static assets. Future launches of the installed app immediately run new code (even offline) without first requiring a round trip to a server.
- dubcanada 12y ago
  How can something that is offline somehow get new code? Besides that it sounds exactly like a website.
  - mratzloff 12y ago
    He's saying it caches the JS and all assets when online so that they can continue to function offline.
- ChrisAntaki 12y ago
  That sounds awesome. Are you using localStorage?

suyash 12y ago

Nothing new here, anyone who has written a hybrid app or a mobile web application knew about this day1. One of the advantages over native application development. It has nothing to do with meteor or anything like that.

markive 12y ago

Does this count for technologies like Appcelerator? Or can I work around the standard way Appcelerator works for example by making more Javascript code available through a webkit Ti.UI.Webview or something?

donpark 12y ago

Unless I'm mistaken, two primary restrictions are: 1. script must be downloaded only within UIWebView. 2. script must be excuted only within UIWebView. Not sure why #1 is important to Apple but #2 makes perfect sense. I'm assuming Meteor is downloading scripts then passing them as 'data' to native-side to be cached somewhere until it needs to be injected back into UIWebView for execution.

m_mueller 12y ago
This distinction is very important to me, but I'm not sure whether it holds true. Can anyone comment whether e.g. JavascriptCore executed code cannot be hot pushed? Does JavascriptCore count as 'Webkit' in Apple's sense? IMO from a technology standpoint it should, but I'm not sure. What about Javascript that's pushed within databases, i.e. CouchDB? So far I was pretty sure that this isn't allowed, but reading this article I'm not entirely sure either anymore.
gsnedders 12y ago
Hmm, 1 at least isn't entirely enforced. (Chrome has its own network layer, and quite obviously supports scripting.)
- donpark 12y ago
  Very good point.

TheLoneWolfling 12y ago

Yet another site that does not load without JS.