

Apple allows hot code push for JS downloaded and run by WebKit - yaliceme
https://www.meteor.com/blog/2014/10/02/Apple-hot-code-push-mobile

======
dozy
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
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
You could code both views and show one or the other based on a server-side
flag.

~~~
EGreg
And that is rudimentary "code push" isn't it?

~~~
efdee
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.

------
Rygu
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
[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.

------
rubyn00bie
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.

~~~
debergalis
[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
How can something that is offline somehow get new code? Besides that it sounds
exactly like a website.

~~~
mratzloff
He's saying it caches the JS and all assets when online so that they can
continue to function offline.

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

------
turval
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?

~~~
redbergy
> 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.

~~~
cpncrunch
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 :)

~~~
yaliceme
(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.

------
donpark
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.

~~~
gsnedders
Hmm, 1 at least isn't entirely enforced. (Chrome has its own network layer,
and quite obviously supports scripting.)

~~~
donpark
Very good point.

------
colinbartlett
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.

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

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

~~~
TeMPOraL
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
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
Fair enough :).

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

~~~
Sidnicious
No. In iOS 8 apps can use WKWebView, which is accelerated.

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

~~~
dunham
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.

~~~
Jare
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.

------
suyash
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
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?

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

~~~
mahyarm
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
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
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.

------
TheLoneWolfling
Yet another site that does not load without JS.

------
bribri
Ultimate linkbait title for HN

~~~
dang
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
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.

~~~
dang
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.

~~~
bribri
I would make it say 'Apple allows hot code push for JS downloaded and run by
WebKit'

~~~
dang
Ok, let's try that.

