Well, that was an interesting ride. Besides passionate agreements, my previous post also elicited passionate disagreements.
My post could be construed as a rant. Hell, parts of it were a rant. (Nobody said this blogging stuff is easy, especially when you’re passionate about something. But if I can’t speak my mind here, what’s the point of having a blog?)
Several people I respect a lot said that I’d made a stupid mistake and was just plain wrong. After some thought I decided they are right.
I was wrong about Web apps being able to replace native apps right now. I was wrong about the iPhone developers’ mindset. They aren’t stupid.
Special thanks go to Dion Almaer and Faruk Ates, who took the time and trouble to write a factual rebuttal of some points, as well as Andrew Hedges, who provided me with a few examples when I needed them most.
While writing the current article I figured out there’s a whole lot of undigested information in my head that I instinctively used in my previous article but didn’t bother to explain properly. This is especially true for payments and the general state of Web technologies on mobile.
Despite my mistakes the whole thing seems to have kick-started a solid, sensible discussion about the differences between native apps and Web apps, and which one is better under which circumstances. I’d like to continue that discussion.
My original idea was: with a few exceptions, native apps could just as well be written as Web apps. That would bring much better interoperability as well as avoiding Apple’s insane App Store approval process.
Now let’s see exactly where I was right and where I was wrong.
It’s all about the money
The strongest argument against my idea is that the App Store offers an easy and convenient way of making money with your apps. I did in fact think about this a lot while writing the original article, but in the end decided not to mention it. That was a mistake.
Mobile payments are a complicated subject that I have my own thoughts about; thoughts I planned to discuss in a later blog entry.
I feel that the mobile operators have the strongest cards when it comes to mobile payments because they are already billing everybody and are already able to identify people through their SIM card. Their system has to be extended in order to accomodate online payments, but that seems doable. In fact, Vodafone is already doing it.
Since Vodafone is my main client now, my plan was to get some more publishable info about how it will work and how it impacts Web development before blogging about it. This crisis has forced my hand, however, so I can’t offer you the level of detail I wanted.
Suffice it to say that a system that might fulfill the same function as the App Store, but works throughout the Web on (presumably) all Vodafone devices (and possibly many more), is probably coming.
This idea was in the front of my mind while I wrote the article, but I did not realise that I had not yet explained it to my readers, nor that a system that’s not yet there has no bearing on a comparison in the present.
In addition, I have some qualms about the whole payment concept. I guess I’m just old-fashioned and long for the days where developers would develop just for the heck of it and worry about money later.
Frankly, I hadn’t factored immediate payments in my mental model of an app developer. And I should have, even though my inner geek is saddened by the thought.
Thus I’m forced to concede this point. Right now, getting paid is a lot easier through the App Store than through any other system.
Getting attention
Then comes the discoverability argument. Apparently, getting attention through the App Store is the superior way of disseminating your app. I’d like some more data on that point.
The question is: How do users find their apps?
- By searching the App Store,
- because friends give them tips,
- or because of old-fashioned marketing?
I have no idea what the answer is. Anyone? I myself started with searching, and have now mostly gone to friends’ referrals, but I have no idea how representative I am.
The discoverability argument only makes sense if the answer is searching. Friends’ referrals and marketing work just as well for Web apps.
So I’m undecided pending further data.
Device APIs
As I said in the original article, device APIs that give access to device functionality like the camera, the file system, the address book, and so on, are coming. There are some security considerations, and the user will have to give permission for most forms of access, but those problems will be solved.
Geolocation is accessible from the browser already. That’s a start, but it’s not enough.
An app that requires access to device APIs will have to be native for now. Only simple location-based systems are possible on the Web side of things.
My problem is that I’ve been living with device APIs as a reality for months now, and have seen a few simple examples. I just plain forgot they’re not actually there yet.
Sorry about that.
Offline Web apps
Let’s debunk one argument. It is perfectly possible to write an offline Web app for Safari iPhone. The browser supports appcache and local storage for storing the application and its data, respectively.
Both Web apps and native apps can work offline. Thus this argument has no value.
Interoperability
Let’s chalk up one inevitable point for Web apps. They beat native apps hands down when it comes to interoperability.
To my way of thinking this is an extremely important point. A large part of my previous post was born out of exasperation that I had to explain interoperability yet again.
Could people please be made to see the value of interoperability instantaneously and naturally? Maybe implant something in their heads or something? It’d save me a lot of energy. Thanks.
Interoperability is trumped by UX in the long run, and also by easy payments and lack of device APIs in the short run.
I still feel that the developers of some iPhone apps, especially those that give quick access to specific online data (tweets or train times, for instance), would have been better off publishing something interoperable. They’re competing against similar apps, and being used by 0.1% of the entire mobile Web has much more potential value than being bought by 1% of the iPhone platform.
UX
Then we come to UX. UX is really the crux of the matter. All other problems can be solved, but UX-wise a native app will likely retain an indefinite advantage over Web apps. Still, the question is whether should give up interoperability for UX’s sake in all cases.
In my original article I already cautioned that graphic- and processor-heavy games were a special case. They cannot be ported to the Web. Whatever else it is, the browser is no immersive game platform.
But I might have overestimated the current state of Safari iPhone as a platform. Two commenters pointed out two immediate problems.
- Safari iPhone doesn’t support
position: fixed, which makes it hard to create anything remotely resembling a static menu bar. - When you set a click event handler on anything, it flashes when the user touches it.
No doubt some research will turn up many more such problems.
They are just browser compatibility problems, though, and I never consider browser compatibility problems show-stoppers. (No good Web developer does, but my case may be a bit more extreme than most.)
I’m going to work on the flash problem later. I have to do massive event research on mobile and desktop anyway, and the iPhone’s event model, especially where it concerns the touch action, is high on my priority list.
But if it can’t be solved, would that matter? Shouldn’t we treat it as the equivalent of the dotted outline; a sure-fire way of letting the user know he has in fact clicked on something? Should we deliberately decide to leave the effect alone, because it’s a platform usability and/or accessibility feature?
Questions, questions. These things are not as simple as they look.
Trade-off
As to position: fixed, Andrew Hedges said:
One clever developer came up with a nearly native feeling workaround using JavaScript and hardware accelerated CSS transitions, but “nearly native feeling” is just a little worse than native.
... if your goal is to emulate a native app perfectly. If that goal is so important to you that you’re willing to sacrifice interoperability for UX brilliance, yes, then a native app is the way to go.
But there’s a trade-off involved here. Do you want perfect UX, or do you want decent interoperability? Does it make sense for every single app to choose UX over interoperability? As I said above, I feel there’s a category of apps where the latter might be more important.
After all, a nearly native feeling app, or even an app that feels distinctly non-native, can be a perfect tool for a specific set of actions if it’s easy to use.
Does the pure look-and-feel, the cool extras, matter that much in every situation? Experience on the Web suggests this is not the case. Ugly websites can be very popular. As long as users can do what they want to do in a reasonably convenient way, they’re willing to put up with lack of polish.
Flashback to eleven years ago. The graphic designer tells me to publish the entire body text as a JPG because her choice of fonts is not available on browsers. I, an intern having no say in the matter, do it, but feel dirty.
Are we walking into the same trap with native UX? Are we sacrificing too much interoperability on the altar of eye candy? I would not be surprised if that turns out to be the case for some apps.
Web developer on mobile
Right now is a lousy time to be a Web developer passionate about the mobile space.
I hate you
On the one hand the mobile Web is postponed yet again by the success of a proprietary system. An excellent system, but still proprietary. It sucks up far too much energy that could have gone to an interoperable mobile Web.
Worse, Apple’s success has caused every single mobile player to hurriedly start working on an app store, and the situation is getting ridiculous. There are now two to four new app stores being opened every month. The pace will slacken somewhat in a little while, but the situation has already grown preposterous.
I love you
On the other hand, many of these app stores work with Web technologies. They all support slightly different things, but hey, they resemble each other. And they definitely work with HTML, CSS, and JavaScript.
Web is hip on the mobile space. Most players have declared their love for Web technologies in some way or another.
Vodafone, Opera, and Microsoft go for W3C Widgets, and BlackBerry might add support in the not-too-distant future, as might Nokia. Of course they do not use exactly the same W3C Widgets — yet. But the emergence of a proper standard will help here. The players are eager for it, and chances are it will be implemented fairly decently across all platforms.
Palm goes for native apps written in Web technologies. Nokia has the Web Runtime Dashboard-like system, SonyEricsson recently announced a Phonegap-based Web system.
Even NetFront has a widget manager that works with Web standards, although you cannot scroll widgets, which makes the whole exercise a bit pointless.
If we count Apple’s original interest in Web standards, only Google hasn’t given a peep. Sure, their mobile browser is good, but otherwise they don’t seem to really care about mobile Web technologies beyond viewing sites. But maybe something is brewing there.
I either love or hate you
The real point here, the one that I wanted to think about a bit more, is that right now Web standards are the weapons of choice of the losers in the mobile game.
Apple and Google are the big winners right now, and they don’t use Web standards beyond providing an excellent browser.
All other players, however, the ones that are threatened by Apple’s and Google’s rapid ascent, go for Web standards big time. Is that a good or a bad sign? I just don’t know yet, that’s why I’d have preferred to discuss this point later on.
I hate you
The outreach of these losing companies that bet on Web standards to Web developers is shockingly bad. Everybody wants Web technologies. Nobody cares about Web developers.
Opera is doing its best, but it’s not getting real support from other companies yet.
I suppose my own hiring by Vodafone comes next, but I’m not there as a developer relations manager, although I definitely should write some serious stuff about widget development. So I’m partly to blame personally for the whole mess.
I was especially baffled by the Palm case. Here’s this (formerly) major phone vendor that’s gambling its entire existence as a company on the Web as a platform — as an OS, even — but other than opening a blog and saying there’s this really cool JavaScript library it did not do anything to connect to those people that were its natural allies: the Web developers.
In fact, I doubted my sanity for a while because I just did not understand what was going on. Did Palm figure it didn’t need us because it already had plenty webOS developers? Or was it being stupid?
I love you
Then Dion Almaer and Ben Galbraith moved to Palm as developer relations managers, and everything fell into place. Palm admitted it had made a mistake and was improving relations with Web developers by hiring people who could do the job.
We are worth wooing, after all. Cool! Still, it makes me dizzy.
I hate you. I love you. I hate you. I love you.
Make up your fucking mind, mobile space!
Are iPhone developers stupid?
So that was the mindset I was in while writing the original article and dissing iPhone developers royally.
Although, as I said earlier, some people I respect a lot disagreed with me, and led me to write this article, another bunch of people I respect a lot agreed with my original post.
We once again have to wage a war for the soul of a platform, and point out time and again that Web standards are the way to go if you’re looking for interoperability, and maybe even if you’re not. We know the whole score by heart now.
I see the possibility of making the same mistakes as on desktop, fighting the same battles, waiting the same amount of time, before the mobile Web really takes of. It saddens me. And it angers me.
That led me to lash out to iPhone developers. From the reactions I got it became clear that some of them did consider Web standards, but decided to go native anyway.
That’s fine by me. As long as you think about it.
But the thinking bit is what I have my doubts about. Chris Heilmann tweeted:
I'm just saying, I've been to the iphone developer camp and 1 of 40 hacks used web standards. It is just not on the radar.
That’s what I’m afraid of: iPhone developers not even considering Web apps.
Are iPhone developers stupid? No. I was wrong about that.
But they might become stupid later on, when the Web has become a totally viable alternative, but they refuse to consider it.
Comments are closed.