

Ask HN: Mobile dev - Bypass apps and go straight to HTML5? - hymanroth

Assuming a mobile service needs to be launched in 6 months time, does it make sense to go straight to HTML5? Will the market be ready?<p>The recent release of the first version of JQuery mobile looks promising, for example.<p>There is a huge temptation to bypass native apps altogether (even with tools like PhoneGap). Not only does one avoid the app approval process, but, just like having to download plugins causes friction for desktop websites, giving users the opportunity  to directly interact with a mobile-specific site as if it were a native app sounds like a big win all round.
======
tomerico
The App Store / Marketplace is a very important distribution channel, which I
wouldn't be so quick to dismiss.

Downloading an app in today's modern phone is almost as frictionless as
entering a website.

~~~
Udo
For the average developer, using the App Store as a distribution channel is
like playing Russian Roulette with your resources. If you don't have
considerable marketing money to ensure your app makes it to the top of the
iTunes category, your app will simply be buried beneath the horrible user
interface of the App Store. It's a little better as far as Android is
concerned but not much.

An app store is great for consumers, it sucks for developers. Especially the
iOS AppStore where people spend huge amounts of time and money for an app that
has a good chance of being rejected for any number of arbitrary reasons. And
vendors like Apple go to great lengths to make extra sure your app code is not
portable to other platforms, so it's not like you can share significant
amounts of code between, say, Android, Windows, and iOS apps.

Enter HTML (5) mobile apps, which work basically the same across all
platforms. Sure, you have to make adjustments for different capabilities, but
that will even out over the next few years. Basically HTML 5 finally fulfills
the promise of Java after all these years. Of course, there are a lot of apps
that simply cannot be built with HTML yet, especially games...

~~~
raquo
App store is a great _distribution_ , not _marketing_ mechanism. You still
have to do your own marketing. It's just very easy for people to buy an app by
tapping a button. And it's the default. Many people would be suspicious of
apps trying to charge them in Safari.

Of course, if you have a non-mobile web app and are offering a mobile
companion, web version it's fine, but if you're building a standalone iDevice
app that you want to charge for, AppStore is the only viable option.

------
chunkyslink
Here is an example of where exactly what you are asking has been done to good
effect.

By inserting a line of code in your normal website, we detect which device you
are on and redirect you to a HTML5 + Jqtouch version of the site which acts
and looks a lot like a native app (especially on the iphone)

See <http://www.pocketdiner.co.uk>

We've had no problems so far so the answer to your question is yes - HTML5 is
mature enough for mobile devices from our experience.

~~~
vladoh
This is a perfect example why web apps are still nowhere near native apps. For
example (testing with a HTC Desire):

\- The transitions are very slow and response times are too big.

\- Pinch zooming a picture results in corrupting the design - overlapping
buttons and labels and so on...

\- You cannot use the Menu button

\- You need a constant Internet connection to be able to work with the
application

\- The address bar shows all the time and takes a lot of place on the screen

~~~
pornel
HTML5 has offline cache.

WebKit has CSS has transitions, which are hardware-accelerated (at least on
iPhone).

WebKit has <meta name=viewport> hack (hopefully standardized as @viewport) and
touch events can be used to control zooming.

In iOS pages bookmarked on home screen are allowed to hide addressbar
completely.

------
jasonkester
I guess it depends on the app, but be warned that performance of HTML5 on
mobile devices such as the iPad is orders of magnitude worse than in native
apps.

So even something straightforward like, say, smoothly animating a pinch zoom
on an image, is just shy of impossible on a mobile browser. Add any complexity
to your scene, then try to animate it and you'll quickly start reconsidering
building a native app.

Sound is another non-starter in an HTML5 app. iPhone (& iPod touch) will only
play audio fullscreen. iPad's Safari will play one audio clip at a time, but
only as a direct result of a user action. Video is also out, since Apple
devices will only play it fullscreen.

Depending on what you're building, you might not need any form of animation or
sound. But if you do, now is not the time to make the move to HTML5 if you
want your thing to work on mobile devices.

~~~
illumen
It's not that slow. I know this because I've done it. You just need to use the
HW accelerated transforms/animations. They're pretty easy to use, and
documented. There are some undocumented css things which cause slow downs
though.

Animation is as fast as lightning, with expert timing. In fact it's a little
bit frighting what you can do with it. If you use js setTimer based animation
it's not that great though. You need to use the css animation stuff really.

Audio can be played with no user action - again I know this from direct
experience.

Only the small devices play video full screen (currently... I can't comment on
upcoming IOS releases ;). The ipad can play them without going fullscreen.

You can't just use links, with click events. Understanding how touch input
works with multiple fingers moving on the screen, not waiting for releases is
different than understanding interfaces with a big screen and one accurate
mouse pointer.

Expect to pay top £/$ for good iOS html5/css/js/svg/canvas developers that
also have experience on iOS/android/nokia/palm... if you can find them.

~~~
Tichy
Any idea where the market is for such developers? I intent to go the HTML app
route, but I worry a little that I won't be able to get contracts for creating
apps because I lack experience with the native side.

------
ivanzhao
For my upcoming game/app (threewiki.com) I actually built all three versions :
)

First the complete, native iPhone version, then realizing that parsing HTML
and storing with Cocoa is a pain. (Core Data is pretty good but too
bureaucratic for simple things).

So in my second version, I moved all the data logics to an App Engine server,
and just leave the app with a thin UIWebView layer in most cases, and only
stores the user token on the phone. Mobile Webkit is pretty accurate but I
didn't like how the animation turns out, just doesn't "feel" right. Besides,
scrolling is much slower in UIWebView than the native UITableView, and you
cannot change the tap-link style in UIWebView except a simple color overlay.

Then comes my final version, in which I use UIWebView for static content, and
use UITableView & custom views/animation when there's interaction, and all
model logics and data processing done on the server.

The app feels super smooth now. And it would be super easy to update because
pretty much all the logics in on the server, so app is essentially a pretty
"portal". Take a look of the video if you are interested threewiki.com

------
jraines
Why not both? I'm sure it's similarly easy in PhoneGap, but here's how easy it
is to package a 1 page HTML5 app in Appcelerator Titanium for submission to
App Store or Android Market:

wv = Ti.UI.createWebView({url:index.html}); win = Ti.UI.createWindow();
win.add(wv); win.open();

------
kolinko
I'd say - build an HTML5 app, but add native wrappers (just Webkit) so you can
push it to App Store or Android Store. That's what I'm doing now (after a
couple of native apps).

on iPhone webapps are still not as good as native ones - you can't put them on
App Store (a large audience) and they don't handle multitasking well.

Assuming your app can be done in HTML5.. if it's a game or it requires a lot
of integration with platform then native is the way to go (duh)

~~~
hymanroth
Sure, cycle intensive use cases will probably use native code for a long time
to come.

The idea of adding native wrappers around a pure HTML/JS implementation sounds
very interesting - like having your cake and eating it....

------
yojimbo311
Mobile Web Applications require an extra bit of awareness and effort from
users on the platforms that have browsers good enough to utilize them. I
haven't personally seen great adoption rates for them, but they do afford
benefits development wise, especially if your goal is to create and launch a
cross-platform application quickly. It's certainly a possibility that mobile
web applications may get more user awareness with better discovery tools, but
the general momentum of user interest has really centered on native
applications. Mostly because users, that I have experience with, find using
native applications a better experience to web applications, but also because
the ecosystem around them has matured quite a bit to make finding and
acquiring them so much easier.

There are a number of native applications that simply serve up mobile web
applications and that grants them several of the advantages of native
applications, though not all, from a discovery, capability and usability
perspective. Users typically notice that their experience is sub-par compared
to truly native applications, but good ones can get close enough that it
doesn't make a huge impact compared to the benefits. You will of course still
have to deal with app store/market place submission, but you could always
launch the application as a web app until the native version is available,
allowing you to even provide the native versions after your intended launch
date. Generally speaking it affords you a lot of flexibility for your effort,
but I would caution that HTML5 based applications really only work for focused
tasks that do not need to rely on native features the varying phones provide.

The questions you really need to ask to make a solid decision on which path to
take are, how many platforms are you really targeting and do they all need to
be supported immediately? Are there any native features of the phones you're
targeting that need/should to be leveraged to make your application useful and
successful in accomplishing its primary task? How much effort are you willing
to put into supporting and maintaining the application(s)? If all your answers
lead to having to support a lot for a little and your application is simple
enough to not need native features then an HTML5 implementation would probably
make the most sense.

~~~
hymanroth
Excellent comment, thanks. We would require location and touch functionality.
The core use case is really quite simple: users provide both text and
numerical feedback based on their location - that's basically it. Nothing
fancy. It needs to quick and easy to use, work on as many platforms as
possible, and - given the nature of the application - is unlikely to be
downloaded prior to when it's needed. People are more likely to use it "on
impulse" and that's another reason we like the idea of accessing the service
as you would a web site.

------
eelco
It depends a lot on the use case of your application. The size of the task,
the amount of return use, etc. For one-off, low usage apps a web app can be
the better choice.

Also, it depends on how good you want the app to look and behave. With HTML
you don't have as much control over how content is loaded, animated, etc. Be
prepared to deal with really hard to debug crashes if you're making a heavy
app.

Last, but not least, the frameworks: the amount of effort that has been put
into the native frameworks makes up for a lot of the (perceived?) ease of
using HTML, but having to invent a lot of wheels. But again, it really really
really depends on what your app will be doing.

------
ZeroMinx
Is it possible to wrap a HTML5 site into an application? I mean, to make it
appear as an app on the phone, even in the app store, but it's just using the
browser to connect to the HTML5 site?

~~~
Tichy
Yes - that is for example what tools like PhoneGap are helping with.

------
apl
What about monetization? If it's ad-based, alright; however, in many cases the
simple payment process offered by iTunes, for instance, is essential.

~~~
hymanroth
Good point. I should have mentioned monetization is not an issue. In other
words, if what we aim to build were in an app store it would be free anyway.

Basically I'm asking whether HTML5 will be mature enough both in terms of
functionality and browser market share in around 6 months time.

~~~
andrewf
Never mind six months from now - if you're thinking native app, then you've
got a particular set of phones in mind. Take a look at the state of the
browser on them now.

------
wahnfrieden
From my tests on the iPhone, Mobile Safari-based web apps do not have
responsive interfaces as compared to native ones. Safari adds a delay when you
do things like tap link or button - I'm not sure why, it's probably to
disambiguate tapping the link with some other action, since Safari can expect
the user to be scrolling and zooming as well on top of any interface element.

Because of this, I find UI that mimics native apps in Safari to be a
frustrating experience. Everything looks perfectly native, but all the
behavior and touch feedback is slightly off.

Until Apple changes Safari or JQuery Mobile figures out how to get more
responsive interaction out of it, I think this mimicking the native iPhone UI
is missing the point - UI is about much more than visual theme. Stick to non-
platform-specific web app design in the meantime (see Google's Mobile Safari-
based apps, for instance).

~~~
pornel
Delay can be avoided by using touch events instead of emulated mouse events.

~~~
wahnfrieden
Ah nice: onTouchStart, onTouchEnd.

------
colinplamondon
I've never, ever seen an HTML5 app that comes even close to being as smooth as
a native app. HTML5 is not a comparable option for the foreseeable future.

It's best to build a simple native app for iOS that covers the core of your
service, and then an Android app if your audience is particularly likely to
have Android phones.

EDIT: Also, the approval process is a non-issue now, it takes a week at most
to be approved, and 2-3 days if you email ask them to expedite. The problems
with long delays are long over, starting early last year things started
improving exponentially.

------
51Cards
That of course depends on the target audience of the application but in
general I would say not quite yet. We have a mobile app we launched recently
and we have the benefit of being on-hand when customers use it (at trade
shows). There are still a very high percentage of old WinMo and BB phones out
there that we had to code for. Now we did make a version of our app in HTML
but it is very basic to support the old browsers. I really look forward to the
day when we can just do a one for all (or one for 99%) application.

------
stephenou
Even though the technology behind HTML5 mobile app seems solid, there's still
a big hole in the business aspect - no effective way to generate revenue.
There's nothing near the App Store in terms of audience reach in the web
space.

Put it in more perspective: Look how much iOS developers vs. general web
developers are making. And I've also heard an iPhone app has more paid users
than a web app (with the similar functionality)'s free users.

------
drpancake
It depends how technically interesting your app is. If it's just an RSS
reader, then HTML5 is probably the way to go.

But you've got the factor in the audience that the App Store gives you. AFAIK
there's currently no decent way of discovering mobile web apps (unless you
count Google?)

Perhaps PhoneGap is a good compromise, but I've not seen how well it works in
practice...

------
karterk
From a marketing perspective - I know lots of people and blogs who monitor the
app store for new apps and try them out. An HTML5 app means that you will not
have access to this crowd.

~~~
Xybo
One thing I constantly see in the mobile deployment conversation is a focus on
only end-user. There is a huge corporate enterprise market there as well.
Since this is where I make my money, my decision tree is a bit different.
Corporate clients generally target a more limited number of devices. Also, the
app store would not be a likely repository for MIS to deploy from. There is a
much bigger market than the end-user only apps that most of these points
reference. HTML5 and webkit make good sense on the enterprise Intranet.

------
daleharvey
making web apps as polished as web apps is very hard, however you get a lot of
the way there and its 10% of the effort.

You can still do distribution through the appstore with a uiwebview, I am not
sure exactly how stringent apple are in this regard.

However its fairly obvious that html(5) is the future of these things, and the
turnaround on html applications is far far faster, so yeh I would recommend
going html5 until you have strong signals that a native app is needed.

------
paramendra
Amen.

------
shareme
Depends upon what the device market breakdown among your potential customers..

Symbian-everything before ^3 devices not fully html5 WM-everything before WM7
not fully html5 BB-everything past 4.4 is almost full html5 Android- 2.1 and
beyond is full html5 iPhone iOS 4 is full html5

I would start examining frameworks such as PhoneGap, QuickConnect, etc to see
which covers the best as far as html5.

Of course this depends upon whether you need to access native device features
as at the moment the un-spec HTML5 through webkit only has camera, audio,
geolocation, sms.

~~~
jawee
How do you call WM7 fully html5?

------
robwgibbons
I say build it in HTML5 then ship it with PhoneGap. You'll have the best of
both worlds.

