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". :)
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?
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.
... 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.
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.
Link bait? Maybe, maybe not. There are more interesting discussions to have. :-)
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!
The Facebook apps absolutely do not use web code anymore. Their native code is conditionally enabled remotely.
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?
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.
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 :)
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.
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.
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?
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.
Very rarely is that ever important in the mobile app industry.
Now the bugs and shortcomings of CSS, that's certainly a knock against hybrid apps :)
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.
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.
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?
If that's not good enough we can edit it again.
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.
https://github.com/meteor/meteor/wiki/AppCache
"The appcache package is designed to support Meteor's hot code reload feature. "
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)
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.