Apple allows hot code push for JS downloaded and run by WebKit
meteor.comI 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". :)
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?
You could code both views and show one or the other based on a server-side flag.
And that is rudimentary "code push" isn't it?
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.
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.
[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.
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.
[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.
How can something that is offline somehow get new code? Besides that it sounds exactly like a website.
He's saying it caches the JS and all assets when online so that they can continue to function offline.
That sounds awesome. Are you using localStorage?
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. :-)
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!
> ... 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.
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?
It will be a matter of choice between delivering a mediocre experience constantly or a quality one intermittently.
Companies have been doing this for a long time in the UIWebView. At a previous job, we offered this service and called it "live update". Never ran into any issues with Apple denying apps because of this. Phonegap build has a feature called Hydration that does something similar.
> 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 framework.
edit: I do understand that App Store rules can be confusing and Meteor may need to have this PSA to ensure their developers feel comfortable using their framework. But ultimately it's still nothing new, not news, and probably doesn't belong the HN front page – I'm sure I wasn't the only one who clicked the link thinking it was for native apps only to be disappointed.
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.
"getting a feature to market before a competitor"
Very rarely is that ever important in the mobile app industry.
Is that because it wasn't possible or because it wasn't useful/helpful to do?
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.
Of course, this advantage is more than outweighed by having to use JavaScript in the first place.
Considering all of the languages that can transpile to JS, I wouldn't say that's an issue.
Now the bugs and shortcomings of CSS, that's certainly a knock against hybrid apps :)
Wasting CPU time on a mobile device by 'transpiling' is pie in the sky webdev nonsense.
Why would one transpile on the device rather than on one's dev/deployment/whatever server?
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.
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.
Hmm, 1 at least isn't entirely enforced. (Chrome has its own network layer, and quite obviously supports scripting.)
Very good point.
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.
Don't see the point a blog requiring javascript enabled to load.
Hate how Google's blog engine does this too
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".
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. :)
Fair enough :).
Last I read, Apple was limiting javascript performance in UIWebViews compared to what was available in Safari, is this still the case?
No. In iOS 8 apps can use WKWebView, which is accelerated.
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 implement encryption and dynamic (e.g. database-sourced) web pages.
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.
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.
Is this also true when using JavaScriptCore directly? Or do you only get JIT compilation in the context of a web view?
Only in a web view. The point is that the JITed code is in an isolated process with few permissions.
And vitally it can allocate executable memory, which nothing you write can.
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.
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?
Many games are constantly downloading multi-megabyte "updates". I bet some of that stuff is Lua.
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.
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.
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.
Yet another site that does not load without JS.
Ultimate linkbait title for HN
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.
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.
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?
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.
I would make it say 'Apple allows hot code push for JS downloaded and run by WebKit'
Ok, let's try that.
Better title suggestion: Apple allows sites to be opened in webview
No, "sites" would imply "web sites that you could just as easily open in Safari", which is not what they're talking about here. They're talking about implementing an app in Javascript stored locally (still accessible when you have no connectivity), and then being able to download updates to that code directly from the developer rather than through the app store. A lot of people (including myself) legitimately wondered if Apple permits this, since it bypasses Apple's normal review process for apps. Many of us (especially people like me who aren't regular iOS devs and have only anecdotal knowledge of their rules) didn't realize that Apple has an explicit and intentional exception for Javascript run via webview that applies to more than just web pages.
OK Great, Meteor uses regular HTML5 to store things in the app cache (that you could just as easily do in Safari by the way) and Apple's webview complies with the HTML5 standard. I guess I'm just not that surprised that Apple allows the use of standard HTML5 and UIWebview behaves like a browser.
No, that's not what Meteor does.
http://docs.meteor.com/#appcache " The appcache package stores the static parts of a Meteor application (the client side Javascript, HTML, CSS, and images) in the browser's application cache [...] Hot code pushes are loaded by the browser in the background while the app continues to run. Once the new code has been fully loaded the browser is able to switch over to the new code quickly."
https://github.com/meteor/meteor/wiki/AppCache
"The appcache package is designed to support Meteor's hot code reload feature. "
Appcache is a completely different feature that existed in Meteor long long time ago.
The new feature that works in Phonegap integration is storing the application data in App's local storage (not browser's). Not only these files are accessible before the browser is loaded but also they don't need to be downloaded first time, the initial code is shipped with the standard app bundle.
(I work at Meteor on this exact feature)
When you use a webview you're basically displaying HTML content period. granted it's not on the "web",that's what it is.If webviews implement specs correctly then what they does is basically what any browsers do.And the title IS link baiting.
I didn't think so, it says the source (meteor.com) right beside it which makes it a bit less ambiguous.