The recent release of the first version of JQuery mobile looks promising, for example.
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.
Downloading an app in today's modern phone is almost as frictionless as entering a website.
Otherwise, build native apps.
If you can name one successful app that's just a webview then this might be an option.
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...
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.
Of course, there are a lot of apps that simply
cannot be built with HTML yet, especially
games...
Depends on the game - many genres do not require a lot of processing power (e.g. puzzle games, many turn-based games).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.
- 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
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.
This would seem to be one of the biggest issues. Regardless of the function of the app, having it become really laggy/jumpy when connection loss occurs would be a non-starter for me.
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.
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.
That sort of thing is trivial in a browser, but it just falls down on apple devices. If you have counterexamples, you can save me a lot of grief, so please share them.
I've tackled these issues personally, and at my company (iPad app). Keep in mind that your users will demand that your app at least feel native, if not the same UI controls. You think that you'll have the freedom to run on each platform, but in reality you'll be dealing with the quirks of each platform and that will set you back some dev time. Webkit is not 100% the same on each browser
What Phonegap gives you is a demarcation point to drop in your HTML code - and that's it. If you need API access for accelerometer, vibrate, etc then Phonegap can help. If your app is focused more on the user experience, then Phonegap cannot help you.
Do you really want to launch an app that will feel awkward on every platform, or just develop a native app for each major platform? That platform space isn't as large as you might think - iOS, Android, <pick your consumer markets third>
I'm a mobile product manager by day, my contact info is in my profile if you have any more questions.
Basically I'm asking whether HTML5 will be mature enough both in terms of functionality and browser market share in around 6 months time.
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).
What if you just wanted to present an existing web service to mobile users in an "app-like" UI?
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)
The idea of adding native wrappers around a pure HTML/JS implementation sounds very interesting - like having your cake and eating it....
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.
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.
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
wv = Ti.UI.createWebView({url:index.html}); win = Ti.UI.createWindow(); win.add(wv); win.open();
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.
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.
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.
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...
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.