Lots of iPhone application developers are frustrated with the process to get new apps into your hands. It takes about three weeks lately for an app to get approved and into the iTunes store.
Lately I’ve noticed that some developers are avoiding building apps and, instead, are building custom web pages that are designed specifically for the iPhone. I’m not the only one, Marshall Kirkpatrick, over at ReadWriteWeb is seeing the same trend and yesterday featured several services that are building iPhone web experiences but not apps.
Examples you might be already using are Twitter’s mobile site, or Techmeme’s mobile site.
But yesterday another one came along from Nextstop, which is a cool new app for sharing cool things to do near you (great for travelers to check out) and they, too, decided on HTML5 instead of doing an iPhone app. So, I visited them in their San Francisco offices and learned why they made the choices they did, got a demo of the new mobile site they built using HTML5, and also talked about what their view of what’s happening in the larger mobile industry is.
Some reasons Nextstop likes HTML5:
1. Rapid iteration. If they code a new feature tonight, you get it tonight. No waiting three weeks for you to get their latest.
2. It prepares their systems for building a native app. Why? Because apps can include a Safari browser instance inside, so all of this work is reusable, even if they do a native app.
3. It’s easier to build and debug because you don’t need to do a lot of specialized coding to make the native app work properly.
4. It fits into the greater web easier for users. In an iPhone app it can be jarring to take users out to a web browser, but if they already are in the browser they are used to going to other pages and back again using Safari’s navigation.
Anyway, if you want to learn more about the latest thinking of iPhone app developers, this is a good video to watch.
It's nice that applications are moving back to the browser. As a standalone you have to worry about space (when applicable), cross-os support if you want to extend your audience, and all kinds of other development troubles (not even including the apple application review process), but as a Web app – as long as you're using the proper box models and all those other nice little standards, it should easily be viewable in not just the iPhone's webkit-based browser, but the browser on the Android and any future smart phone capable of working with HTML5.
This makes the web the best application platform, in my opinion anyway – and it's nice to see how its being embraced more and more, even for mobile applications.
Q: “iPhone developers abandoning app model for HTML5?”
A: No.
Some will, the vast majority won't. Nextstop's point is valid: the turnaround time from code complete to customer delivery is far smaller with a web app than the AppStore. However, the experience I (or any other developer) can deliver with WebKit pales in comparison the the full blown native SDK.
Q. Are breathless leading questions used to drum up more page views?
A. Yes.
One of the things I liked about the direction of basic computing was that a lot of it was going to online applications and development therein, be it HTML5, iterations of FLEX – Love it. Embrace it – iPhone is no exception.
The AppStore is a huge step back for this – for an obvious reason ($) or two (control); but in the long tail of all things digital, de-centralization from the node has always been the MO for computing. Mobile needs to go that way as well; and I hope it happens sooner than later in the mind of the consumer & the developer.
Do you need an iPhone app for Twitter or text/web applications (Facebook, TechCrunch)? No
Do you need an iPhone app that will call on hardware e.g Google voice. Yes
Do you need an iPhone app if you want to get paid easily? Yes. (although you can make people pay to access you mobile site, it will be very difficult).
Do you need an iPhone app for an application that works primarily offline? e.g. Games? Yes
I do not believe there is a one size fits all here. It will depend on the app that is being built.
Seems like a logical progression. Look at what happened to the PC. Who would have thought a web-based solution could threaten such full-featured packages such as Word or Excel?
The question is how long it will take for mobile browsers to normalize and support phone features such as GPS, camera, and phone.
remember when “reactions” were blog posts? this is all filler down there (look down).
This isn't a surprise at all.
First, anyone who's used Google's HTML5 applications on an iPhone knows that the user experience is pretty damn good for MOST applications out there. Latitude, GMail, Reader, Picasa, Docs – they all demonstrate a very compelling user experience – yes – even offline.
Second, what developer in his right mind wants to write native apps and port them between the iPhone, Android, Palm Pre, Blackberry, Windows Mobile, and Symbian? How about a single target environment? Hello? Didn't we learn anything from the dominance of AJAX applications on the desktop over the last 5 years? Why should mobile applications be any different?? Enterprise developers will definitely embrace this.
Finally, as an aside, there are 5 features that don't translate to HTML5 web applications quite yet…
(1) push notification
(2) local data access [ iPhone Contacts, photo library, etc.]
(3) large content caching [multimedia and large datasets]
(4) rich 3D graphics
(5) rich input [gestures, gyroscopic positioning, audio, video, etc]
This is good stuff Robert. I think these guys are pointing out the weakness in iPhone development and a reasonable alternative to still create apps w/o dealing with the Apple garbage. A nice benefit here is HTML5 can be used on any phone including Android and others.
I know there are pluses and minuses to using strictly a browser but they can be worked around.
We use a mix for our TripChill service. Most of our user experience is web based; we have iPhone and Android web interfaces that behave very similarly to native apps. We use a native app for specific functionality that cannot be accessed through the browser, and with a browser plugin for native apps you can merge the experiences together.
I’ve built Objective-C apps, and I’ve built HTML/CSS apps. The ObjC apps still “feel” better than the HTML apps, at least to me.
I’ve also built a hybrid app that is mostly HTML/CSS wrapped in a UIWebView with bridge calls back & forth from ObjC to javascript to play sounds natively, etc.
(Frozen Bubble 2 – http://frozenbubble.weebly.com/ )
The new webkit CSS hardware-accelerated animation is fast, but has some delays getting things moving when you apply it.
I’m still leaning towards ObjC, even though it’s not the friendliest language in the world…
And the most obvious advantage which is that you don't have to have an iPhone to use these web experiences
I totally agree. We had a debate about this at my technology BrainTrust (here's a link to the published debate http://bit.ly/6FU9Sg)
This is good work, especially with the local storage. In general though, I still don't see developers moving over to HTML5. There are a number of problems — no access to 3D hardware, no access to the slick UI APIs that make the iPhone what it is, and in general a more cumbersome launch experience. Further, many of the problems with native apps mentioned here are overblown: both Safari and maps can be seamlessly integrated with native apps via embedded web/map views.
But the most important thing is, HTML5 apps just don't have the right “mouthfeel.” I think if most consumers had a choice between an HTML5 app and its native counterpart, they'd go native every time. And that's what matters.
Interesting and timely – I just wrote post yesterday Robert on how Apple needs to launch AdWords for iTunes to help drive adoption, and how much a threat that was to Google. (http://www.appolicious.com/articles/1004-why-ap…) . Clearly this behavior is in Google's best interest.
As some of your commenters have noted it's not one-size-fits-all here — for plenty of services html5 will be fine. But I believe that over the next 12 months we'll see an order of magnitude improvement in the quality of apps, their use of all of the features of the iPhone, as corporate America starts to invest against the platform big time. It will be tough to get traction imo for vast majority of developers without developing Apps. Which is also why Google is launching their own unified hw/os platfore (fleshed out more in my post).
Great post Robert!
This debate about apps vs browser is better framed as cached vs cloud.
We think people will have both – the app element is vital as a way to get a presence on the most valuable real estate in the world – peoples home screens – so we expect the smart thinking to focus on what the right balance is
I spoke about this at a London event last week http://bit.ly/7JBaNd
I agree wholeheartedly about the need to shift back to a browser model – it does make development a whole lot easier. In fact, for a lot of brands, their flag-ship apps can make the positive trade-off in favor of rapid iteration while sacrificing some of the native bells and whistles.
But my issue is more with distribution – app store distribution model hampers discoverability and cross-linking (URL parameters that track effectiveness of DR marketing campaigns don't work well on the app store). My guess is, as long as the app store model for new-app discovery competes with the web model, neither model will together create as much value as an open model, i.e. web model.
Good post by Gruber – Daring Fireball – Web apps vs native and frameworks – http://daringfireball.net/2009/12/pastrykit
In that case, don't we simply need to make a Web “App Store?”
In a way it is ironic that on the desktop the whole industry has been moving aggressively to the Web model to even have desktop applications such as word processing, spreadsheet, and presentation reimplemented for Web. And somehow on Mobile (i.e. iPhone) the industry has be equally aggressive in recreating the client/server type of application.
In the long run, I think and hope that Web will win.
Another handy thing about mobile web apps: they often can double as sidebar widgets.
This is something Brian Suda and I have been following closely over the last few episodes of North Atlantic Radio, particularly when it comes to games on the iPhone. Over the last few months we've seen technical demos (the Another World level using the HTML5 canvas) and fully-fledged games (Pie Guy) appear. The future appears especially bright when you think of the possibilities of WebGL (native 3D graphics in the browser).
The problem iPhone games developers face now is how to use sound in their web apps. While Mobile Safari supports HTML 5's audio element, you can't use it to play sounds upon certain actions. Playing the contents of an audio element brings up the Quicktime modal overlay, so there's no way to play sound in the background.
There's only so much you can do with a silent game. I hope Apple updates Mobile Safari soon to allow for programmatic non-modal access to HTML 5 audio elements.
Unfortunately, the Nextstop web site requires an iPhone. On an iPod, you just get a never-ending swirly…
Wait, sorry? “Recreating the client/server type of application”?
The web development model is client/server, with thin clients (browsers). Native app development is not a client/server model in many cases (where's the “Server” in, say, an ebook?)
I've been saying it all along: In the PC/desktop world, browser-based apps are the norm. You don't have a Mac OS desktop Twitter app and a Windows Twitter app, nor a Facebook desktop app for different OS's. Why is the mobile app world moving in the opposite direction???
That's what people said about Desktop app vs. Web apps.
It's interesting that just this morning one of my colleagues called my attention to the fact that Apple itself has used HTML5 for at least one of its published apps, the iPhone Help app. Interestingly, it incorporated a third-party library called PastryKit which enables developers using HTML5 +CSS to overcome three major design limitations of such apps:
* inability to hide the Safari address bar at the top of the app
* inability to use a fixed-in-place toolbar that doesn't disappear when scrolling
* loss of the sexy “flinging” of scrollable fields for fast movement
The library is apparently an Apple product and isn't directly available (though you can download the compact JavaScript and CSS from the sub-links to the Help app/site). It would be nice of Apple to release this library to developers, though it's not always clear on what basis they make such decisions.
My paycheck comes from doing Rails development.
As pxlated said (and danshafer mentions), Daring Fireball explains Apple's own 'PastryKit' framework used by the built-in Help section on the iPphone/iPod Touch which really shows what is possible from 'basic' CSS/JS/HTML
http://daringfireball.net/2009/12/pastrykit
It looks great!
The biggest draw of native iphone apps for the developers is the clear-cut business model and the marketing leverage of the app store. So while you get technical advantages going the HTML5 route, the entire business proposition is negated.
btw: one way you can hide the address bar is some simple JavaScript:
create a function :
function hideAddressBar() { window.scrollTo(0, 1); }
then set this to trigger when the page loads using :
onload='hideAddressBar()' in your body tag.
It's a bit of a hack, as it doesn't actually remove it, but it does pop it out of the way when the page loads (you can scroll back down to view it – rather like a search bar on some apps)
Apple: You have the browser! You don't need to make apps!
Developers: Yes we do!
Apple: Ooooookay, you asked for it…
Developers: Aww, fine, we'll use the browser.
Sure – that would work. In fact Apple could do one better – open up the apis to the app store catalog – not necessarily more information than is available today, but in an easy-to-integrate api format. My bet is this will allow 3rd party developers to build store-fronts and other app aggregation/discovery applications. Social app discovery (a la social music discovery) doesn't work very well (yes Chorus and others are trying) largely due to this. If there was an open webservices-based api, the total innovation around apps will be to an extent Apple alone cannot foster.
Apple realized that it could not by itself build all flavors of apps that its users want. I'm guessing it'll soon realize it cannot build all the app stores its users and publishers want.
“Yup….Yup…Yup….” Really gets annoying after the 852nd time you said it. You really need to work on your interviewing skills man. The guys in front of the camera should really be what I notice – not your inane little comments and annoying mannerisms.
If people won't buy your app in the app store, and the app can be built in HTML5 then you may as well.
It is an easier process, and web developers are cheap.
We're seeing similar trends in the clients that ask us to mobilize their web sites or extend their business into the mobile space. We offer native app versions and mobile web versions, go through the pros & cons, & most clients go for the web apps because they can still look attractive, they work on all phones, they do what the client needs them to do, and they're cheaper to build.
And yes, this has strong echoes of the desktop apps vs web apps of yesterday.
Perhaps both are a good idea.
I'm having my first app developed, and whilst it's sometimes frustrating but oftimes fun, it's a good idea to also provide for a mobile browser via a m.domain or similar, so your users on an Android (unless of course you do an Android app) or whatever can get a nice breezy mobile experience from a browser.
Cool post again Robert.
And your app work on Android. See http://not-now-nigel.blogspot.com/2009/12/cosy-…. This is an offline graphical web app for iPhone that uses HTML5 touch and canvas. I ran this today on an HTC running Android. Because the HTC browser is based on WebKit like Safari, they both speak the same HTML5 extensions.
And you don't need a MAC.
And your app work on Android. See http://not-now-nigel.blogspot.com/2009/12/cosy-…. This is an offline graphical web app for iPhone that uses HTML5 touch and canvas. I ran this today on an HTC running Android. Because the HTC browser is based on WebKit like Safari, they both speak the same HTML5 extensions.
And you don't need a MAC.
Oh yeah, i guess then everything is true, since something else mildly similar came true.
What great logic you like to employ. I guess if you can't analyse the situation properly, then why not just guess?
Thanks for the great discussion around this topic — and Robert, thanks for coming by yesterday, we really enjoyed the conversation.
I thought a bit more about the question you asked regarding tips for developing mobile html5 apps and wrote a short blog post about it:
http://blog.nextstop.com/2009/12/3-tips-for-dev…
I hope someone finds this helpful, and I'd love to hear any other favorite tips html5 developers have.
I like this approach, because I don't have an Apple machine. What's important to me is if does iphones OS supports the local storage of HTML 5?
If they turn to html5, that would be better in terms of universal standards, in my opinion.
Since Safari in iPhone supports “tabs”, I can also run apps simultaneously within Safari… something that is (still) not possible with native apps.
Maps (location sharing) works well: http://servletsuite.blogspot.com/2009/12/how-to…
The big plus: it is the same code for Android and S60
The business proposition for web apps is negated?? How? Any company who develops a great web app and applies sound marketing practices have everything to gain over having a native app sold through Apple. The biggest one of all being that Apple doesn't own 30% of your app's sales.
Poorly skilled, lazy and non-creative web developers are cheap. Boat loads of those in India. Top developers with passion and creativity are not cheap.
Poorly skilled, lazy and non-creative web developers are cheap. Boat loads of those in India. Top developers with passion and creativity are not cheap.
“I think if most consumers had a choice between an HTML5 app and its native counterpart, they'd go native every time”. That's not true at all. It all depends on the purpose of the app and what capabilities it needs to deliver to the customer. If the web app can provide all the important features that are available in the native app, users will actually tend to go with the web app and NOT the native app. I have had customers who literally hate having to download software to get bugfixes and newer versions. When they want something fixed, they want it fixed now and available instantly. You'll never get that with a native app.
Which is precisely what my company is building.
Which is precisely what my company is building.