Live data from Hacker News

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

meteor.com

31–40 of 74 posts

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

#34
post #31

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

You don't see the point of the blog of a javascript web framework requiring javascript?

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/

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

#35
post #6

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.

(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!

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

#36
post #27

Earlier quoted context omitted.

Wow, thanks, I can't believe I missed reading about this until now. This framework looks really promising

Unfortunately, due to sandboxing rules added around beta4, WKWebView doesn't allow access to any local files, making it nearly worthless for hybrid apps, ebook viewers, etc. The only workaround that I know of is to run a webserver on a background thread and point the WKWebView at it. Hopefully Apple fixes this in a future release. Also, WKWebView doesn't work with NSURLProtocol, which a lot of companies use to implem…

My distant but intense interest in the future of hybrid apps just took a nosedive. Do you know if any of the major players (Phonegap, CocoonJS, etc) implement the web server approach? It doesn't seem too difficult, but it sure must be a hassle.

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

#37
post #2

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

> One question, it specifically mentions using the WebKit framework, does that mean that this is not allowed under the old UIWebView class? This is nothing new. We have been using UIWebView to download JS code in our App Store apps since iOS 3. You can use UIWebView or WKWebView. I don't understand why this is on the front page of HN except that someone over at Meteor is doing a good job at drawing attention to their…

I see at least 3 commenters in this thread work at Meteor. It would be interesting to see exactly who upvoted it.

On a separate note: you can get away with downloading interpreted code in an iOS app, as long as you don't broadcast the fact to Apple :)

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

#38
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". :)

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

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

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

#40

Earlier quoted context omitted.

> One question, it specifically mentions using the WebKit framework, does that mean that this is not allowed under the old UIWebView class? This is nothing new. We have been using UIWebView to download JS code in our App Store apps since iOS 3. You can use UIWebView or WKWebView. I don't understand why this is on the front page of HN except that someone over at Meteor is doing a good job at drawing attention to their…

I see at least 3 commenters in this thread work at Meteor. It would be interesting to see exactly who upvoted it. On a separate note: you can get away with downloading interpreted code in an iOS app, as long as you don't broadcast the fact to Apple :)

(blog post author)

We actually never upvote our own stories or ask others to. It's hard not be curious about the comments, though, and we make a point to identify ourselves in our replies.

Post reply on HN