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 <i>build themselves</i> 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.<p>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.<p>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". :)
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.
In other words: webpages function as expected on iOS.<p>... Not to blame the meteor folks for writing it, if they were getting asked it... But wow.<p>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.
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.
This is probably the only feature that gives hybrid apps an actual upper-hand vs their native counterparts.<p>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.<p>I can imaging there are some scenarios where getting a feature to market before a competitor would make this feature really valuable.<p>One question, it specifically mentions using the WebKit framework, does that mean that this is not allowed under the old UIWebView class?
Unless I'm mistaken, two primary restrictions are:<p>1. script must be downloaded only within UIWebView.
2. script must be excuted only within UIWebView.<p>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.
I've been using Trigger.io like this for years, it's very useful.<p>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.
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?<p>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?