iPhone native Apps redux
Again, my apologies to those many who posted long, (or not so long) well thought out responses to my initial post. Like Hendrik, I found the level if discourse commendable.
One thing I didn’t actually talk about in my original article is that even if I wanted to, I can’t write iPhone native apps — well, I could write them but it would be pointless, because despite writing applications for the Mac OS for 15 years, through bad times and good, being a non US resident or company, I am not being accepted as a developer. But that’s not remotely what motivated my position.
The responses, which I’d have to tote up as at least 50% in disagreement, addressed several of my points, and I want to take a look at the nature of those responses in detail in a moment. But, I think, and this may well have to do with my poor advancement of it, almost no one seemed to really get my core point.
What characterizes the iPhone is that it is a web native device. It is essentially always on (edge cases like subway rides, plane trips and overseas travel aside). It knows where you are. It is equipped with as good a web browser as available on any device. And yet the vast majority of the applications I’ve looked at, or read about, live in there own little sandbox. One of the keys to mobile design is context. Providing relevant services and information based on where you are, and what you are doing. And most iPhone apps I’ve seen or read about just don’t tap into the mobile context.
Let’s take something so humble as a shopping list. There are several shopping list apps available for the iPhone. But imagine this scenario — you are at your desk writing a list of things to buy for your weekly groceries. Hang on, my list is on my iPhone — so I need to get out and use my phone — where using the laptop or desktop might make more sense in this context. Or, I’m on my way to the shops, and my wife remembers something we need — do I have it on my list? She has to ring me and ask. Or send an SMS. But, if my list is in the cloud, she can just check and update my list from her phone, her laptop, or whatever. Even something so humble as a shopping list can become web native. Now, of course, you can have a native iPhone app with this web connectedness — but, frankly, why bother — what do you really get as a developer or user from that? Yes, that’s the subject of many of the critical comments to my inital post, and I’ll turn in a moment to addressing those criticisms.
Commenters addressed a number of my points over and over again. One was how native app performance is far superior to web app performance. Another common one was that the iPhone isn’t always connected, and so when not connected, webapps are useless. Another was that webapp frameworks are anaemic in comparison with CocaTouch.
Then there were a number of criticisms of my analysis of the business models around native apps.
Lastly there were a number of miscellaneous comments and critiques, which I’ll turn to at the end.
As I mentioned, often more than one person, sometimes several, made the same basic response to my initial argument — I’ll try to credit and quote all those points as I address each general area of criticism in turn.
So, let’s begin with probaby the most commonly raised issue — that of performance.
Performance
Probably the most commonly made point was that native apps were fundamentally better than web apps because of their performance.
Blucaso wrote
Sometimes the difference between a web app and native app is not WHAT it can do, but HOW FAST it can do it
No download time, no lag on screen changes
Alex wrote
So, the greater speed of a local app makes a difference in usability. A big difference.
flo wrote
native apps are faster, even with the improved speed of mobile safari in 2.0
joeboy wrote
Network performance will alter the user experience, the native iphone app will feel MUCH faster than the web app. The web app has to be downloaded from the web every time the user does anything on it (or loads a new page on it anyhow): all the images, css, javascript libraries and markup have to be downloaded for it to work [we’ll see in a moment that this is not the case necessarily]. Native apps only have to be downloaded once, so that when you use them they only have to use the network to get the information that you actually need. This dramatically improves the user experience by making the app far more responsive. It also has the additional benefit of increasing battery life. Win Win.
There’s two aspects to this issue. Firstly — this is an assertion, that sounds plausible — but is it necessarily true? Then, there is a second, deeper point. Even if it is true, it doesn’t need to be. Let me address each of these in turn.
First up — try this little experiment. Add a Facebook icon to your home screen from Fcebook.com. Now, using this icon, log into Facebook. Next, do the same thing with the Facebook native iPhone app. Is there really all that much of a difference? The simple answer is no. I suspect in part, this is because Facebook have worked hard to optimize the performance of iphone.facebook.com (if you want to learn more about optimizing for iPhone, Niall Kennedy has a good summary of Yahoo’s Exceptional Pergormance Group’s analysis of this issue.) My point is, the perceived, and commonly advanced advantage in performance of native versus web apps is certainly less cut and dried than most asserted in their responses.
But, and far more importantly — mobile Safari does not cache web applications, nor give access in any meaningful sense to client side storage for web applications. Yet it easily could (and I am sure in the not too distant future will) do so.
Webkit already supports HTML5 client side data storage in their nightlies, and Safari 4 previews are already demonstrating a “Save as Webapp” functionality that turns websites into double clickable applications, which would make even more sense on the iPhone than on the desktop.
This is the future, and it is in essence one of the main reasons why I called the iPhone native apps a “great leap backwards”. Given the phenomenal amount of work that has gone into the iPhone SDK, had that effort been focussed on adding these features to the iPhone instead, they’d very likely be here already.
In fact, Manuel R. Ciosici made this very point
Why couldn’t Apple design a way to store webapps locally so that we wouldn’t be tied to the cloud? An update button in the webapp would suffice the need to update the app (or the app could update itself through AJAX if web is available).
Connectedness
A second, commonly raised concern was of network availability.
Blucaso, in his (or her) excellent detailed post wrote
The idea that the internet is always available is still a faulty assumption. No wifi and no signal = no internet. Suddenly all your web apps cease functioning
Alex wrote
What about other subway systems? What about on airplanes? This is iPhone time, but there’s no internet access. (Yes, internet access is coming on airplanes. What will it be? $10/hour? I’d rather have my apps, most of the time. I’ll use them to download the things I want quickly, and then read things offline.)
Well, as soon as we address the performance issue, with local caching of application files, and data, this issue simly goes away. This very objection applies to any web based application — for example Google Docs — until of course, something like Google Gears turns up, or browsers start supporting HTML5 client side storage natively (as Webkit and Firefox do or soon will do).
I hope this goes a long way to addressing the two significant technical concerns, performance and connectivity that were raised several times. To be honest, native apps both now, and probably for some time to come, will have an edge when it comes to performance. And where performance is an issue — for example games with intensive rendering, well, there’s little choice. But in most cases, performance really isn’t a deal breaker. It is of course where you need to pull the entire application across the network each time it loads, but it’s not where things like computation and other processing is involved.
Business models
A second main area folks addressed in their comments was that of business models.
Once more, Blucaso dealt with this in detail
One [criticism] is that shareware “conversion” rate you cite. Well, as you know, there isn’t a shareware model that really works. Right now the main group of programs are “buy and try” not “try then buy”. This means you don’t need 100,000 downloads to make 3,000 sales, you only need 3,000 downloads.
I probably didn’t make my point clear enough once more. I was trying to get some kind of measure of the relationship between a users interest and a purchase, and base it on something other than pure handwaving. In the world of traditional software sales (which native iPhone apps are closest akin to), for every 1000 people who come to your site, fewer than 100 will likely download your software. Of those, about 1% to 3% will purchase. So while Blucaso is right in saying every download is a sale, that misses the point. What percentage of folks who see your app will purchase? Is it going to be higher than the 3 in 1000 or so of traditional software sales. If so, why? Especially when you can’t try before you buy. A number of folks weighed in with opinions on this issue, which I’ll address in turn.
Blucaso continues
Another false comparison could be that most shareware is not $.99 or $1.99 or even $9.99. Some of it is, but good quality shareware is often $20 or more. For this, the price is a pretty big deterrent to any “buy and try” model. However, on the iPhone, most paid apps are $0.99, $9.99 or $4.99. These are the emerging price points (besides free) that are coalescing right now. And my theory is that at $.99, there is almost no barrier to entry. A lot of people will still download at $4.99 based on a description and screen shot. At $9.99, it better look really good in the App store, but still doesn’t seem like a huge investment. $59.99? That’s an investment.
This all sounds very reasonable, and it might be right — but it is handwaving. There’s no evidence for it. For example, in my experience, shared by others, putting prices up (within reason) does not impact software sales. With a lite and full featured version of an app, at two separate price points, the full featured version will on the whole outsell the less expensive one, typically significantly. But there is a matter of degree between $19.99 and $39.99. There’s a matter of substance between free and $.99
In fact, I have long thought that shareware (while I use it all the time, and enjoy its benefits) is in actuality a terrible model for running a business. If I were a software developer I would be horrified at the prospect of 97% of my customers wanting to use my software and never pay for it, still give me feedback, expect support, and use and abuse my servers. Ugh.
The thing is, how you or I as the developer feel about this is irrelevant — this is a business issue, and it is better business to give folks a demo, and indeed, a generous demo, despite how unfair or infuriating a developer might feel. This is a lesson learnt over and over again over 20 years.
The app store eliminates this, and charges 30% for transaction fees, servers, update support, and all the hassle of dealing with the user at the outset. Not a bad deal from my POV.
What remains to be seen is whether the appstore also eliminates purchasing as well. It certainly eliminates choice and flexibility for developers. Now, time might tell — as we see download numbers of free versus paid for apps, but here is my prediction — we won’t see those download numbers. Right now those counters are all set to zero. As soon as they report numbers, we’ll see how much apple, and every developer is making down to the cent. We’ll see by how many orders of magnitude free apps are outperforming paid for apps as well. But as I said, I suspect we won’t see those numbers.
In a similar vein, Hendrik wrote
To me the App Store definitely seems like an amazing opportunity for developers. Very few people pay for shareware apps (or commercial applications too in fact). Just as pretty much nobody used to pay for music online. Before the iTunes store came along. Making it super convenient made people actually pay for music online. When it first came out I thought there was no way in hell that people would stop downloading music for free and start paying. But they did.
But here’s the thing. When was the last time you bought a song, let alone an album, that you had never heard before — not on the radio, not even a 10 second snippet. No one even buys .99c songs like that, let alone albums. So why are folks going to buy legions of applications site unseen?
By the way, in essence pretty much all applications are shareware. Just about any app you can buy has a demo version.
And now buying applications at the App Store is so convenient that I am sure tons of users will buy. Of course if you are trying to sell a 1.99$ tip calculator and there is already a 0.99$ version plus a dozen free ones doing the same thing your sales might not be so hot. That being said, if for example the 0.99$ version looks nicer than the free versions and gets good reviews than I am sure it will still sell quite a few copies.
I’m not so sure at all — because price discrimination is one thing when comparing 1.99 and .99 — it’s another thing altogether when comparing 0.99 and free. This classic article by Clay Shirky addresses this in the context of micropayments.
By the way, right now, with the exception of games, the top selling apps are largely games and entertainment, and price points well and truly under $10 (and even under $5) for all but entertainment apps. I repeat my observaton that even individual developers will need to sell a great many apps to make even a decent living selling an iPhone app.
Try to get anyone to buy a subscription to your tip calculator web app.
That’s a fair point — but not an argument against looking to the business model of subscriptions and services, rather, an argument against trying to sell software . If I were looking to monetize a tip calculator, I wouldn’t look to do it as an app for sale. I’d look at the service you could build around tip calculating. That’s folks going out to dinner. So, a tip calculator makes sense in the broader context of dining out (restaurant guides, and so on). That’s where the business is.
Mitch writes
However, I don’t agree with a lot of second part. The ease and experience of buying something (a music album, a game, a program) from the iTunes store and App store is so easy and quick. That makes a big difference. It’s even simpler than buying software off a website
Now, this is a different angle — and the argument of convenience holds water — people do pay a premium for convenience. The drawback continues to be that you have to buy sight unseen, and there’s little evidence folks are willing to do that. Perhaps they will. But I’m yet to be convinced. I return to my analogy of music. It is extremely rare for folks to buy music without hearing it first — yes, for the odd artist who we follow very closely we might buy their new album — but it is likely we’ve heard a track or two at least first. But even still, when was the last time you purchased music like that?
Regarding pricing: I think it is not correct to compare the sale of a $4.99 app to a service you pay $5 a month for. $5 once is easy to spend while waiting for a train
It might not be correct to compare them, but the business model for one looks far more attractive to me as someone who has made a living from the business of software for 15 years, than the business model for the other (and that’s a business model I’ve been relying on for those 15 years). I guess I’m trying topoint out how viable, or otherwise, the App Store really is from a business model perspective.
Martin Pilkington writes (quoting my initial article)
“As developers, you need to rewrite your apps for other platforms, as well as, of course, for the platform that really matters — the web.”
This all really depends on whether the developer has any interest in releasing for other platforms. As you pointed out earlier, many of those coming to the iPhone are already Mac developers, many of whom develop solely for the Mac with no real interest in other platforms.
I’ve developed for the Mac, Windows, and the web for over a decade. One reason why folks don’t do it is that it is really hard. Not only do you have specific platform coding issues (and the lack of very many cross platform development tools), you also have specific platform user experience issues to address. From a business point of view, I can assure you, the more viable platforms you can target the better. But as a small development team, it is very resource intensive. Except of course, if you target the web. Suddenly, everything with a browser — from the iPhone to the Mac to the Wii, to your PC to your fridge can run your software. Now, if you are writing a word processor, this might not be particularly useful. But I see almost limitless possibilities enabled by the web. In my not so humble, any developer with no interest in developing web native applications really does have a limited shelf life. Indeed, my feeling is that there really won’t be a business in selling software in not too many years. There’ll be a business of software, it ust won’t be in selling it on a per license basis.
On the same issue, MP writes
You have managed to extremely simplify and incredibly complex issue. If you tell someone “This is only $5 a month” they may look interested before they realise it’s $60 a year for however long they wish to use it. Now this may work for web apps accessed via the desktop where you can access a decent amount of features, but on the mobile it’s different. You need to design for smaller screen which means simpler UIs and less functionality exposed (and some functionality just not really possible). Now try to get someone to pay $5 a month for that. It’s very unlikely.
I see the issue a little differently. What you tell someone is that it is free. Then they use it. And if they use it and realize they get value from using the application — it makes their life easier, more productive, more fun — well, they may well upgrade to a $5 a month, or $30 a year, or whatever plan.
In terms of simplified UI and smaller feature sets, that’s true. But I think it reinforces that increasingly applications aren’t islands, but part of eco-systems. Think of a Facebook client application (web app or iPhone native, it doesn’t really matter) — it is literally useless without it being part of the ecosystem that is Facebook. Increasingly I think all applications will similarly be part of broader eco-systems — either explicit like Facebook or Flickr, or more tenuous. But to my mind the days of the stand alone isolated app is coming to an end. On the desktop, as well as elsewhere.
As a counter to this, Alex writes
I believe ultimately your argument is founded on the assumption that the Web is always a better platform for both developers and users and that both these groups will eventually completely move to the web. The reality is that the web is an important platform, but will never be the sole platform, the basic physics behind computer networking makes sure of that. There is always a claim that the web will match desktop apps in X years. The problem is that by then desktop apps will have progressed X years.
Alex has hit the nail on the head. I essentially do think the “Web is always a better platform for both developers and users and that both these groups will eventually completely move to the web”. I think we often overstate the benefits of the desktop app. For example, I think it is just a matter of time before the ultimate desktop apps, those which more or less define the desktop era, namely, Office apps (word processors, spreadsheets, presentation apps, databases) become entirely web based. While Google Docs is far less full featured than Office, its connectedness will trump the millions of man years of development which went into adding to the number of features in Office over the last 20 years. A text document that can be simultaneously edited by several people is a fundamentally different thing from a beautifully polished document isolated on a single system.
There’s much more I could address tat emerged from these discussion, but I’ve indulged your time too much already, so I’ll close with this comment by Tim Swan.
If all of your assumptions are true then I suppose we’ll see over time whether people prefer native or web apps. After all, the iPhone’s strengths as a web client remain and some application developers will still prefer to develop web apps.
Tim’s right of course — the market place of ideas will win out, and my bet is that in time, it is web applications, not native apps, which will become predominant. Because the iPhone isn’t, and won’t be the only sophisticated mobile platform out there, because desktops and laptops will be with us for some time yet, because the web will be on our televisions, gaming devices, fridges, wrist watches, and countless other devices as yet undreamed of. And applications are what will bring all these devices into one extraordinary digital ecosystem. To do that, it won’t be possible to have a myriad different languages. We need a Koine, a lingua franca. But we don’t need to find or create this common language. We have it already — it is the set of open standards that make up the web. They work. They are supported on an enormous range of devices. Hundreds of thousands of people, if not millons, know how to develop with them. I wouldn’t bet against the web. And to me, iPhone native apps look exactly like that — betting against the web.
being a non US resident or company, I am not being accepted as a developer
Incorrect: Apple has accepted non-US companies in the developer progam. I know of several non-US companies/people who got accepted, as late as WWDC08 in June.
Hi Nicky,
I do recall reading somewhere very recently that you must be over 18, and a US Citizen. I can’t find anything to clarify this, and there do appear to be at least a number of Japanese language applications, which may of course be developed by US developers.
But the general point remains that Apple decide who may develop.
FWIW: I’m an iPhone webapp developer currently learning Cocoa, and let me tell you, it’s brutal. “Desktop” is a totally different mindset (and toolset) from web. And frankly, the “responsiveness” advantage seems to pale in comparison to the “deploy anywhere” aspect inherent in modern web apps. But then again, as a web developer, I naturally make apps that are multiuser, which leads me to my main point…
I am totally addicted to Moonlight Mahjong. If it was deployed as a web app, I wouldn’t play it at all. Why? Because it is my go to app when my iPhone is offline. The moral of the story is that some apps make more sense online, some make more sense offline.
Yes, I agree that eventually, there will be no such thing as “offline”. However, there are fortunes to be made and lost between now and then. The fact that Google *might* be broadcasting free wifi over radio someday, is no reason to sit on our hands today.
Overall, I agree that the “native iPhone app” is a step backwards in the scheme of things. So you might ask, why am I learning Cocoa? The answer is simple:
Because it’s worth it.
As different as Cocoa is from LAMP+CSS+JavaScript, it’s not really that hard. The development tools are awesome and free. There are a ton of free resources online to help you learn. There is an active and helpful Cocoa community.
I have seen the traffic spikes that come as result of a mention on Apple.com. When you combine the awesome marketing power of Apple, with the convenience of iTunes-style purchases, it’s a no-brainer. With the App Store, you are given the chance to piggyback on top of the trust that users have granted to iTunes, and the infrastructure provided by Apple, Inc to offer a single click (nee “Tap”) purchase of your software.
Spending a few weeks porting your app from web technologies over to Cocoa is worth the effort when you consider that doing so puts millions of potential users one click away from paying you a dollar.
Honestly, I don’t know why I am posting this. It would be more beneficial to just kept my mouth shut. Less competition ;-)
Jonathan,
many thanks for the frank and thoughtful comments.
Re the offline issue — that is going away soon, I’d expect, not because iPhones will be always on, but because we’ll have client side caching.
I’m keen to see how the App Store plays out — I’m very interested in the stats as to how many folks download free versus paid for apps. We might see in a month or so (not holding my breath — see comments above)
thanks again
john
It seems obvious to me that Apple are trying to focus the spotlight on the App Store and away from web applications. There are various reasons why they would want to do this, such as a show-case of a couple of dozen eye-catching applications with which to launch the new system rather than clutter it with old news. Apple also need to get the message across to users and developers alike that they have a secure distribution system in place that is as easy to use as putting an MP3 on your iPod.
With the release of 2.0, they certainly have not left webapps behind — they’ve just stopped blowing that particular trumpet as loudly now that they have the SDK to promote. There are still plenty of additions to webkit to keep a web developer busy, with hopefully more to come, but a distinct lack of activity in how to showcase these applications. Again, easy to understand when you realise that you don’t want to detract from the launch of the App Store.
The fact is, these SDKs are two different beasts who also happen to be pretty good friends and are able to play well together. The native SDK appears to be immature enough to the point that it will defer any complex text layout to a webkit component, whereas webapps know nothing of GPS, accelerometer, camera, etc and have no choice but to suggest you go native until a Javascript API is released.
I have found a hybrid approach interesting, but that is because I am coming it this from the angle of a web application that wants to appear native but really needs to be a web application but nevertheless wants the exposure that the App Store provides.
Initial reports suggest a ~2% conversion for iPhone apps offering both free and paid-for versions. This seems to be the app store way of offering a demo. Eight times the conversion rate of traditional software sales is quite impressive, although this might be attributed to ‘new iPhone giddiness’ ;-) Also these numbers are for $10 apps, whereas I guess the 0.3% conversion rate is for $60+ applications.
Oli,
that 2% is about exactly right for desktop apps as well — which is in the range of 1 – 3% download to purchase — interestingly it’s also roughly the conversion rate of free to paid accounts for web services like basecamp.
Looks like the App Store doesn’t change everything after all
john
Aah woops, conflation error. It’ll be interesting to see if this conversion percentage holds further down the track, especially given it’s ~90% crap atm :-S
Oli,
interesting that even folks like John Gruber are suggesting it is about 90% crap.
http://daringfireball.net/linked/2008/07/29/app-count
All I suggested was that using Cocoa was kinda extraneous, and I got slammed :-)
j
[…] iPhone native Apps redux […]