iPhone native Apps: the great leap backwards?
As did many others, I greeted the arrival of version 2.0 of the iPhone operating system no little enthusiasm. To be fair, in the world of endless betas that is the web these days, as a version 1 the iPhone OS was pretty amazing. But what would Apple do with Safari? What aspects of CSS3 and experimental CSS support that we’ve been seeing in Webkit nightlies, and even Safari 3 for Mac and Windows would we see in mobile Safari 2.0? All these really interested me.
Seemingly putting me in a minority, one area I really wasn’t particularly enthused about was that of native apps for the iPhone, and iPod Touch. To me it seemed a pretty pointless step right from the get go — especially after a minor iPhone OS update last year allowed developers to make icons for their web based apps that could be added to the home screen of an iPhone. In essence, web apps became native, first class apps on the iPhone.
But the clamor for a software development kit (SDK) was loud, and the rejoicing great, when Apple announced that native app development support was forthcoming.
The first fruits of the labors of the developers who signed (and ponied) up, and were accepted into the iPhone developer program recently turned up in the new App Store (the only official way to get iPhone native apps — more on that below). And the results? Well, much excitement from the assembled blogosphere, but in my not so humble opinion, pretty much nothing to write home about. Well, except for Apple’s own remote app, which is frankly amazing [1]. In fairness, I’ve not tried any of the non-free applications (who doesn’t want to try before they buy), but I’m seriously underwhelmed by much of what I’ve tried.
This is not to say that the apps are pointless, many are very useful. But my overall take away from the apps I’ve seen is that, well, on the whole there’s little if any reason why most of these couldn’t be done with HTML/CSS/Javascript (I’ll get back to why building web apps instead of “native” apps would be of more than little benefit to developers in a moment). I can’t see at all why developers have waited a year to release applications that could have been developed and released in a matter of weeks, or even less, as web apps (and I’m talking from experience having done some work with webapps for the iPhone), a year ago.
In the meantime, Apple has invested enormous resources into delivering an SDK and App Store. Developers have learned new languages, development tools, and platforms. And yet, in all, it seems a great leap backwards, in several ways.
Perhaps my biggest disappointment is that so few of these applications take advantage of the connectedness and “always on” nature of the iPhone (and to a lesser extent the iPod Touch). They tend to use local storage of data, and do very little tapping into the shared resources and intelligence of the web. A perfect example is a $10 cocktail application, with a searchable database of cocktail recipes. This is just a client side, CocoaTouch version of the online database. Why all the resources poured into developing the iPhone app, when a little bit of CSS would probably have been enough to have a native version a year ago! [2]
In conception most native apps seem on the whole to be just scaled down desktop apps, living in their own isolated world. I wonder how much of this is because the developers of these apps are more likely to come from the desktop world, being Mac application developers, and how much this is a function of the toolsets being used — after all, CocaoTouch is a subset of Cocoa, itself a desktop application development platform.
Now, in fairness, only native apps get access to things like your location, the camera, your photos, and so on, which means certain types of application, for example a photoblogging application which uploads photos as you take them, or applications that rely on knowing your position, are restricted to being native apps at this stage. But most apps in the App Store don’t tap into these things.
And there’s little reason why this sort of functionality couldn’t be exposed by Apple using a Javascript API so that applications built using CSS, HTML and Javascript couldn’t take advantage of them as well (subject to addressing issues around privacy and security, you don’t want arbitrary web pages accessing your location data, photos and the like).
But, you might be thinking, “isn’t this some pointless little language war?” Does it really matter whether apps for the iPhone are developed using Cocoa or JavaScript/CSS/HTML? I’d argue that it does matter. The web apps approach to development brings with it significant practical advantages to developers, users, and Apple as well.
First up, there would be an order of magnitude more web application developers than Cocoa developers. By privileging CocoaTouch apps over web applications, Apple gains unique applications (all these native apps will need to be rewritten for Widows Mobile, Nokia devices, the upcoming Android platform, PSP, and other platforms). But everyone else, including developers lose out. As users, there’s less choice. As developers, you need to rewrite your apps for other platforms, as well as, of course, for the platform that really matters — the web.
But that’s not the end of the problems. As noted by many developers, debugging CocoaTouch applications is hard. Compare this with the debugging tools and resources available for web developers. Then, there’s the dearth of information, tips, gotchas, and so on that developers share with one another on forums, blogs and the like, and which are a lifesaver for many developers, whatever the platform or language or framework they use — these just aren’t out there for iPhone developers right now not simply because it’s such a new platform, but because the terms and conditions of being a developer restrict this. In fact, established publishers have had a difficult time even putting together books on developing native apps for this very reason.
These are big problems for developers, and ultimately users, as they will impact on the quality, and number, of applications available for no little time.
But it doesn’t get any better. There is but a single way to distribute native applications for the iPhone — Apple’s App Store. App Store is only open to registered developers, who both pay for the privilege of being a developer (an ongoing fee, presently $99 a year), and who are selected by Apple, according to whatever criteria Apple wishes to use. Apple are definitely gatekeepers here, and can arbitrarily exclude anyone from being a developer. Now, Apple are quite entitled to do this with their platform, but it should give anyone pause as a developer wishing to be involved — afterall, your professional and business future is entirely dependent on a third party’s arbitrary decisions, over which you have no right of appeal.
Again, this is not just a problem for developers — as a user, it’s your problem too. Why? Well, not only does it restrict the amount of innovation of the platform, but more directly, because software has bugs. That’s why you see so many x.x.1 releases of software. As a developer, this is very frustrating, but at least you can auto update your application, or post a fix and notify your users as soon as the fix is done. Not so with the App Store. You post a fix. Apple decides when this is pushed out to users. If you’ve paid for an app (and recall, you can’t demo an app, unless the developer has two separate versions, a free and a paid one), then you need to wait for the fix. If you are a developer, you wait anxiously, as your competitors get an hour, a day, or whatever, headstart while you wait for your fix to be available.
With a web based application, you have zero config updates — users need to do precisely nothing to update their version of the app, as it all resides on the server (or in libraries that the client application loads each time it runs). The App Store is a big leap backward over the always up to date nature of web applications, and even the desktop world, where apps can auto update, and developers can contact their user base to notify them of updates, and where developers can make sure the latest version is available online as soon as it is ready.
So, are there any arguments in favor of developing native apps for the iPhone? Well, arguably, there’s the whole issue of business models. People, we are often told, don’t buy web applications, but they do buy desktop apps, and so by extension will buy native iPhone apps. So there’s a ready made business model there. In fact, being able to charge for your apps is one of the key points of interest for many developers.
But let’s take a look at this issue in more detail. Disclaimer and aside — this is all back of the envelop stuff. But it is also based on 15 years of successfully developing and selling software online, and 15 years of pretty serious interest in this issue, and many frank discussions with other folks in a similar situation. Yes, the iPhone may just change everything about the software business. I just don’t think it will. If folks want to argue that iPhone native apps will turn all software business experience on its head, I’d be very interested to hear their arguments and see any evidence.
Firstly, people will and do buy web applications. Just ask folks like Flickr, Remember the Milk, and 37 Signals. In fact, they don’t just buy the app, they subscribe to the service, and pay recurring monthly or monthly fees. Now that’s a business model! Do you wonder why magazines offer subscriptions at a steep discount to the newstand price? Recurring, guaranteed income. One off sales with intermittent upgrades is not nearly so good a business model — just ask Microsoft, who’ve been trying to move users to a subscription model for years for Office and their OS products. Once more, native iPhone apps are a leap backwards, to the desktop world, and a time when freeware was on the whole not very good, and folks had the choice of either buying, or copying software. A lot of folks bought. But as any successful “shareware” developer will tell you, anything more than 1% of your downloads translating to sales (on the Mac typically these conversion rates were a little higher) was a pretty good outcome. In this regard, the App Store is a double whammy for developers — at a glance, many categories seem to have several free apps for each for fee app (just look at to do lists for a start). And, because there is no “try before you buy” system, what are folks going to download? The free app, or the $12.95, or even $1.95 app? So if the free version is “good enough”, you’ll struggle to compete regardless of how brilliant your app is. Good enough is a great strategy with software, and doubly so on the iPhone.
And even if you do start selling your app, let’s look at the kinds of numbers you’ll need to have a commercially successful app. Let’s suppose you are a small developer team. Hey, one person even. If you are a remotely good developer, an annual salary of $75K USD is probably on the low side. But let’s aim for just $50KUSD in income. Let’s say you sell your App for $1.95. You’ll need to sell 25,000 copies to make your income. Hang on, Apple take about 30% so you’ll need to sell 30% more. That’s 36,500 copies. If you look at a typical conversion rate of say 3% of downloads to sales (in my experience, good Mac apps can get that kind of conversion), if this were a desktop shareware app, you’d need to have 1.2 million downloads. That’s more than 10% of the entire projected iPhone user base for the end of 2008 interested in your app.
OK, let’s think about higher price points — at $5, you need to sell 14,000 copies, with a theoretical download of 476,000 demo copies. Up this to $10, and we are looking at 7,000 sales, and 233,000 demo downloads. And that’s for a single developer. Double this for 2 developers, triple it for a team of three, and so on.
In my experience, these are all very big numbers, and even with restricted competition (Apple is the gatekeeper remember, and there is only one way to develop and distribute your apps), I wonder how many folks are going to be making a decent profession or business out of developing native apps for the iPhone.
Now, let’s compare the “sell the app” business model with the increasingly common “subscribing to a service” model (like 37 Signals Basecamp and similar offerings). The model here is typically a free gateway version — with some kind of limit on how much you can do — for example the number of projects you can manage — then a graduated series of levels, starting at a small recurring fee ($5 per month for instance), up to a limit of typically $100 a month, which provides more or less unlimited functionality.
Let’s say we only have customers paying $5 a month. They are already paying $60 a year! So to make our $50KUSD, we’ll need around 1000 customers (about 14% of the number of sales of a $10 app). And I’ve factored in about 12% costs here (transaction and hosting costs, based on personal experience).
Interestingly, from what I’ve seen, the conversion rates from free to paying accounts for more than one such service based business is around the magical 1% number. So, you need 100,000 customers a year to try out your service, rather than anywhere between a quarter of a million and 1.2 million. Still a big number — but spread across all web users, not restricted to just iPhone users.
Now, there’s of course no reason not to have an iPhone native version of the client software for your service. It might even be an interesting marketing tool, and point of differentiation from your competitors. But it will require considerable effort and resources, which many small teams just don’t have. [3]
The launch of the iPhone was greeted with great excitement, but right from the outset, the lack of a way of writing “native” apps was considered widely to be detrimental to the platform. To my mind this shows still how little we really “get” the web. Instead of this being a defect, the iPhone marked the launch of one of the first, and certainly most hyped, web native devices. The way you wrote applications for it was using open, interoperable, non proprietary standards.
The arrival of native apps brings little or nothing to anyone other than Apple, and perhaps a few developers who launch successful businesses based on selling native apps. And it draws our focus away from the truly fantastic thing about the iPhone — its support for the web, which has driven data plan pricing down dramatically in many markets (sadly not yet in Australia), and as a consequence, ushered in an era of always on, web native devices, and seen a huge increase in mobile web usage. And, we are already beginning to see the impact on other mobile browser and device developers, as they ramp up innovation in the face of the success of the iPhone.
But imagine as newer Nokia, Windows Mobile, and other devices come online. Will developers have to develop for each individually? Yet another great leap backwards to the days of the platforms wars of Windows versus Mac, versus the rest.
That way madness lies.
The iPhone has amazing standards based support for developing applications — CSS/HTML/Javascript. Applications which will also run on the desktop browsers, on other mobile devices, on the Chumby, on your fridge, on your Wii, on Panasonic Viera televisions, and devices not yet even built. It’s time to put platform specific fragmentation behind us, and write applications for the one true platform. The web.
- [1] Others I’ve not tried that look pretty amazing, and which would probably prove far more difficult as web apps than native apps include the Moo music apps, and various games.
- [2] On the other hand, an application like Graffito, which lets you post notes that are then associated with where you posted them, and let you see other notes posted in the same area.
- [3] Notice I’ve made no mention of the advertising business model, for either iPhone or web apps? That is no business model at all in this space I’d argue. but that’s the subject of another post.
One Web to rule them all. One Web to bind them. One Web to bring them all and in the darkness bind them.
Apologies. I couldn’t resist.
Someone is paying attention :-)
Well, a couple of points you don’t seem to have addressed.
1) Sometimes the difference between a web app and native app is not WHAT it can do, but HOW FAST it can do it. I found a really nice web app to track time spent for projects / clients, and it was very slick and well-designed, I would have gladly paid $4.99 for it, even being a simple application. However it was DOG SLOW to run on the internet, not to mention that it sucks battery when I’m on 3G.
The point of this for me was that if the application doesn’t NEED access to the web, as in this case, the non-web version would be FAR superior to the user (me). No download time, no lag on screen changes, and no worries that I’m not connected to the net at any given time.
2) 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. Cloud computing has its limits, and this is one that people don’t seem to address often enough. I need my cloud, but I need at least basic functionality in many areas even without my cloud.
3) A couple things I think you’re missing in your back-of-envelope analysis of return on investment. You’re comparing desktop shareware models to iPhone software models, and it leads to a couple of false assumptions I think. One 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.
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.
So I think a lot of apps will sell easily, without the shareware model being necessary. 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 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.
Finally, I think you are ignoring (or at least understating) the nature of the closed system’s benefit — namely, that because 95% of users will not be using “jailbroken” phones, that means 95% of all users will only know one way to get more stuff on the phone. I’ll tell you straight that if you could even have a PRAYER of getting 60% of all Mac Desktop Computer users to go to a single website that paraded your shareware application in front of potential users, developers would be salivating. To deliver a store that shows your app to EVERY user? That’s beyond expectations, it’s awesome power. And it’s the only way to do it for most of them. And if they want to try it, they have to pony up the cash first.
For these reasons, I think your models are really off.
4) I should also mention that if you haven’t tried any paid apps, you really shouldn’t speak about the overall quality of what’s available, as you’re only sampling the lowest end of the market. Not that there aren’t some good free apps (and yes, Remote is the most amazing thing I’ve downloaded to my iPhone, to be honest) but the average paid app is probably better than the average freebie, and more likely to be updated and supported over time. So I think you’re doing a disservice to yourself and your readers.
That all being said, I think you’ve provided an interesting counterpoint to the general blog/news/media take on the App store. And I definitely agree that Apple being the gatekeepers has created quite a mess from the standpoint of getting updates done quickly, getting apps released in a timely fashion, etc. It’s not a bad thing that Apple wants to do some quality control, but the restrictions on programming information have got to be loosened, and clearly they need to re-think the app review process.
I don’t know if I agree with you or not — I didn’t bother reading your post because it’s nearly 6 screens long and not chunked with subheadings, but hey … that’s just me being fussy.
Anyhoo.
I did get a sense that your thoughts are based on the free apps available in the store, not the paid ones. Why is that? blucaso said the same thing. Why didn’t you hand over $25 tax-deductible dollars for, say, Crash Bandicoot Racing and the Things GTD app, just so that you could write a more balanced review? Nobody’s asking you to shell out $600 for Photoshop, after all.
@martinjy,
probably the same thing that stopped you being bothered reading 2500 words :-) No one’s asking you to read war and peace :-)
But I didn’t, did I? Which is kinda the point.
j
[…] Allsop wrote a long piece over at Web Directions South with some thoughts on writing native iPhone apps versus web-based iPhone […]
Why couldn’t Apple design a way to store webapps localy 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).
[…] pm on July 21, 2008 | # | iPhone Native Apps — The Great Leap Backwards? […]
Great Article. A good example of this is eBook readers. I was really excited to switch to native apps to get a native ebook reader. Turns out after apx $30 total spent (purchasing each one in the Appstore) dBelement’s eBook reader (http://reader.dbelement.com) is still the best. It’s not even a competition. Their reader app is a webapp and it is by far the best book reader I’ve ever used. It has all the features you expect and even includes a free public library.
I’m very disappointed (to say the least) with the native ebook reader apps (I’m looking at you ereader). For now I’ll stick with reader webapp by dBelement. It’s no doubt the best reader on the iPhone at the moment.
The Native Games are awesome though. I’m in love with Enigmo.
I agree with most of the first part of your story. A lot of apps are not doing anything special or anything that couldn’t be done in a simple web app.
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. And the App store is just always available.
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. If you want someone to subscribe for $5 a month, my feeling is their commitment to your product has to be far bigger. It’s like comparing flickr with an iPhone app written by one person. That $60 per year from a subscription is likely to go to many more than 12 people, if a service is to be worth $5 a month to a large number of consumers.
You do seem to be missing out on quite a few important things that the desktop gives you. Now if I could write a web app with the same level of usability and slickness, the same speed, with as little code and gain as many users as I like just running on one web server that I don’t have to pay a monthly fee on and have no need to care about any sort of scalability issues other than providing support, then I’d agree with you. Web apps have many flaws and are still only using what are effectively baby frameworks compared to what is available on the desktop.
Next, you have the issue of who would pay a subscription for web apps. Generally those who pay for web apps are businesses. There are some exceptions, but these are generally sites that are free but provide Pro features (see Flickr, last.fm etc). The iPhone is starting to be aimed more at businesses but it is still a mostly consumer oriented device and these are the people who are more inclined to pay once than to pay a fixed amount over and over.
Now to address some of your other points:
“after all, CocaoTouch is a subset of Cocoa, itself a desktop application development platform.”
CocoaTouch isn’t really a subset of Cocoa, as much as a different branch of Cocoa. It shares a lot of similarities but many parts are completely unique to the iPhone.
“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.
“But that’s not the end of the problems. As noted by many developers, debugging CocoaTouch applications is hard. Compare this with the debugging tools and resources available for web developers.”
Actually, debugging CocoaTouch applications is incredibly easy, getting debugging information from users when your app is out in the wild is what is hard. On the Mac you can just look at the crash logs, on the iPhone the tools aren’t yet available to decipher them. That is the point being made in that post
“App Store is only open to registered developers, who both pay for the privilege of being a developer (an ongoing fee, presently $99 a year),”
Can you point out where you’ve seen where it says this is a yearly fee? I’ve not seen anything that says or implies that to date.
“The App Store is a big leap backward over the always up to date nature of web applications, and even the desktop world, where apps can auto update,”
This is a valid point, but is very easily remedied. As with many things wrong with the App Store, it is a flaw but not one that would be impossible to fix.
“Recurring, guaranteed income. One off sales with intermittent upgrades is not nearly so good a business model”
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.
Next issue is getting someone to find your app. How many steps would it take for someone to find, pay for and start using a web app. The latter two options can be controlled, but the former is completely out of your control. On the App Store you can find, purchase and start using an application in around 8 taps of the screen, plus entering your password. You don’t really have to spend much on marketing your product as it’s so easy for someone to find it and then get it.
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.
The reality is that there future is in the desktop will be much more connected. People sat at their computer will use a desktop client for their apps, which can then sync data online (or the data is already stored online), which they can access through a web interface when they’re away from their computer. Funnily enough this has been around for a very long time in email. Most people using email seriously will use a desktop client most of the time and use a web interface when they don’t have access to it. And this is why native apps on the iPhone are useful.
An interesting take, but fundamentally flawed because the native apps are only one option available to a developer. 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.
Until my data is available on the “cloud” when I’m not internet connected, there are some apps that I’d prefer were native. Frankly, there are very few online apps that I’ve found as satisfying as native software, except for those that are by their nature either collaborative or web-based (such as Flickr.) BTW, when I tried to post my comment, I got an error: “Safari could not open the page “http://www.webdirections.org/blog/iphone-native-apps-the-great-leap-backwards/” because the server is not responding.”
Hopefully the native apps just add another choice.
I think that you are missing the importance of the user experience in all of this.
1) Purchasing. The iTunes store is brilliant because of the ease of impulse purchasing. I want that song, it’s mine. I simply have to type in my password. I don’t even have to type in my username/email address. No credit card number. No billing address. And for apps, no seriel number to enter or installer to use. I just hit “buy” it it’s mine. I honestly do not know how much money I’ve spent on the app store — $40? $50 — but it is money I was not going to spend of software otherwise. It was just really easy.
Moreover, the free apps accustom me to that impulse kind of thing. Then, if it’s a cheap app, why not grab it? It’s easy, and I can spare $4.99. I have never impluse subscribed to an online service. There’s the hassle of signing up. And there’s the issue of needing to remember to unsubscribe.
You want a real example? Well, I never bothered to download and install NetNewsWire or Twitterific on my mac. But I did for my iPhone, grabbing the free versions. They were easy, and I liked them, so I downloaded the paid version for iPhone and will pay for the desktop app, too.
Convenience. Convenience. Convenience.
2) The iPhone might be always on for some, but it is not for others. There are millions of New Yorkers — tens or hundreds of thousands of iPhone users — who ride the NYC subway. We don’t have phone/interenet access during our commutes. That might not sound like a big issue, but I don’t need iPhone web apps when I am at home or at work — times that I am at a full fledged computer. I need them when I am out and about, and usually when I am getting from point A to point B.
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.)
The iPhone is NOT connected 100% of the time, and the times when it is least likely to be connected are the times when it is most likely to be used.
3) EDGE.
I occassionally need to look up ingrediants on my iPhone from a cooking website, to which I DO subscribe. It takes too long. I’ve got to get to the page, sign in, look up the recipe and then read the ingrediant list. How long do I stand there looking like a fool? (It’s not looking like a fool that bothers me. It’s the time.) I would pay for an iPhone app, simply to be able to look things up faster.
Perhaps it is fast enough on 3G. Surely the website itself is partly to blame, because the slowest step is signing in — the site’s cookies only last like 24 or 36 hours. But that’s how they make sure only subscribers get in.
Right now, most iPhones are EDGE, not 3G. In many parts of the country, 3G is not available. In the future, many people will turn off 3G so that their batteries last longer.
So, the greater speed of a local app makes a difference in usability. A big difference.
********
The convenience that can leade to impulse buying. The common occassions when many people do not have internet access, even on their iPhones. Speed.
You make some good points, but you do not acknowledge these realities that make iPhone apps so useful.
John, how about replying to someone like blucaso who brings up several valid points that I agree with completely, rather than the guy who admits to not reading your post.
Great article. Someone finally gets it. It’s sad that some people reading this get all caught up in “CocoaTouch” isn’t really a subset of Cocoa.…which isn’t the point.
I have to agree with John. I was very interested in getting an Iphone 3G as my first iPhone experience but I’m seeing the marketing machine behind the phone more and more everyday.….….and not the phone I want to see. There will always be Apple apologists and I have to agree, it’s a great mobile platform. But being an owner of multiple Macs and an Avid Apple fan — as well as a Director of Marketing for my industry — I have to admit that Apple’s launch of all things iPhone will be studied for years in Marketing. But sadly, it won’t cause me to finally buy an iPhone.
Apple could have pioneered a business model and with their marketing brilliance, they could have easily converted the flock to subscribe. Easily.
But selling yet another proprietary platform was their goal. Nothing wrong with that but they could have launched another spectacular product with the App Store.
Great article John
Debugging Cocoa Touch applications is not hard. The link you used noted that it’s hard to tell what problems your users are having if the app crashes, but even there you have some help in the form of a crash log that can be sent to you (the specific complant was that it was not as easy to tie that log back to your code as it is when you have a crash in person).
But actual debugging, is not that hard and Apple has provided some great tools for you to see what is going on.
I agree to some extent that some apps seem like they could be done as web apps, and indeed a defining question that I think should be asked before developing any application is “what does this bring me vs. using the web or developing a web app”? But the answer is clear in a lot of cases — bundled graphics/media and therefore a MUCH lighter touch of the network for you app. That means better response time, better battery life, and a faster application all the way around. Even if something could be done as a web app if someone is going to be using the app often, or in areas of questionable network connectivity, a standalone app buys you much over a web app.
As time goes by we’ll see more apps start to get a handle on using some of the phone features in ways a web app cannot. One thing I would hate to see is too much customization of iPhone specific features in a web app, at some point you might as well have written a native application that at least did not need a server to launch and does not have all the navigation issues that browser based applications inherit from running in a browser.
@Dan
Spot on, the dbelement reader is just great. It really shows what the web can do. I can’t believe that they pulled off one touch scrolling. Major props to the db team.
Hi all,
apologies for not replying right away, as it has been overnight here in Australia. I’m now up with my two girls aged 2 and 3 months, then have an entire day on the road — so I’m not sure how much I’l be able to reply today, sadly. I’ll do my best,
thanks for the many thoughtful replies (even if on the whole folks seem to disagree with me ;-) )
john
[…] Allsop also just wrote a long and interesting piece comparing native apps to webapps over at web directions south. Though he didn’t really look […]
@martin pilkington
Re the $99 fee
http://www.macrumors.com/iphone/2008/03/06/99-year-developer-fee-to-publish-applications/
Yes, it is macrumors, but they quote a press release. I saw it somewhere on Apple’s site the last day or so.
Mmmh, I too agree that some apps could be done as web apps, however I agree with most posters above that speed matters, and native apps are faster, even with the improved speed of mobile safari in 2.0.
But more importantly, which I know was also already pointed out above, the important thing is that the iphone is not “always on”. Take for example that cocktail app you mentioned: You say it could be done as a web app, but as I see it, not having to connect to the net to get those recipes is invaluable. Especially because many great party locations I have been to have no cellphone reception at all. The same can be said for apps like epocrates or the Netter flashcards … imagine you had to get all that data over the air … a nightmare!
[…] The Great Leap Backwards takes a look at developing Web apps vs Native (Cocoa) apps for the iPhone. He starts naively talking about the better development platform, but does eventually get into the kicker behind AppStore — the business model. Web apps aren’t king for all, and they won’t be until there are some serious client side hardware interaction improvements. […]
You’ve got some good points but you’re some of the huge advantages of native iPhone Apps for the iPhone over web-based apps:
Lets suppose I am building an app for the iphone, and I build two versions of it, one that is a native iphone app, and one that is a web app. What will be different about the user experience between the two apps?
1) 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. Native apps only have to be downloaded once, so that when you use then 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.
This is already apparent to me in many of the new native apps — they feel far more responsive to me than their previous web-based counterparts and I guarantee you that this is because.
the other user experience benefit is that my apps are actually, well … apps. They get their own wrapper, not just their own icon. Rather than having to run under mobilesafari as tabs of the same app they are their own entity with their own data. If some runaway script on another mobilesafari crashes the browser, I don’t lose all my application states. I don’t accidentally open yet another instance of the same app in a different mobilesafari tab every time I click on the iphone icon.
While I can understand your gripes with the app store, there are many practical reasons that I much prefer native apps over web apps on the iPhone.
I just wanted to say that I am really impressed with the level of discourse here. Excellent points are being put forward both in the article and in the comments.
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. 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. Try to get anyone to buy a subscription to your tip calculator web app.
Let’s hope that Apple fixes the remaining unpleasant issues surrounding the App store and developer program soon.
Perhaps my biggest disappointment is that so few of these applications take advantage of the connectedness and “always on” nature of the iPhone (and to a lesser extent the iPod Touch). They tend to use local storage of data, and do very little tapping into the shared resources and intelligence of the web.
Well, yes… that was one of the major points of native apps.
I have to come down hard on the native app side as well. Apologies if I’m mischaracterizing things, but this article seems to be written from the position of someone who thinks of web apps as the be-all and end-all of software development. And that just ain’t so.
I’ve been fighting this particular idea in various guises (‘thin client’, ‘cloud computing’, ‘network appliance’, etc.) since working at a Sears Service Center in the mid-80’s. (Sears kept all its parts records on mainframes in Dallas and Chicago; the connection to the mainframe went down around once a week, leaving us stranded for however long it took for them to get things back up.) Network connectivity is not ubiquitous and is not reliable. I’ve spent five minutes on the iPhone waiting for a webpage to load, sitting in a restaurant in a fair-sized city, and that’s just a simple webpage — not a web app.
Even when the app is devoted to reading information from the network, it still is a big win much of the time to minimize the amount of data being sent… WeatherBug runs much faster when all the server has to send is the raw weather data, compared to the Weather Channel’s admittedly very nice web app that has to download all the page elements, graphics and scripts as well.
I’ll also agree that native apps are far more responsive than web apps on the interface side, even without having to worry about network connectivity.
fyi — check out http://www.torahweb.org/audio — using the iPhone UI style on a web app for an audio and video library, all standard js and css
I don’t get this. An app is supposed to take advantage of what its underlying platform provides. If AJAX cannot do it, what’s wrong letting native apps take over? Not Apple’s fault that AJAX is just not sexy enough.
Many have already stated this, but for me, your article hinges on a faulty premise; constant connectivity to the ‘webs. I’ve been out of the country since late March, which until the 2.0 release, basically meant I had a nice iPod.
That’s really it, isn’t it? It’s hard to build a logical argument on such a flawed foundation. Of course, if the idea was to generate page views, then I would say your article was a success…
Hi all,
I’ve posted a follow up article addressing many of the comments here. Sorry it took a little time.
http://www.webdirections.org/blog/iphone-native-apps-redux/
Who can list 10 things that can be done with an ‘iPhone app’… that’s *IMPOSSIBLE* to do with an “iPhone web app”?
Or… who can list other 10 things that can be done with an ‘iPhone web app’… that’s *IMPOSSIBLE* to do with an “iPhone app”?
It should be easy to find 10 tasks that can only be performed natively. Things that are currently out of reach for a web app: accessing address book, appts on the calendar, using the camera, GPS, accelerometer, accessing media in the iPod library, picking photos from the library, core animation, recording/playing audio, accessing voicemail, etc.
Seeing as you can embed a UIWebView control into a native app, it is fair to say that a native app can do pretty much anything a web app can do. However, a native app will have a hard time rendering custom content (even to the extent of text that uses multiple fonts) without resorting to this control.
As it stands now, it appears a hybrid solution covers most that the device has to offer, but each SDK falls short when used on its own.
[…] some while back I wrote quite scathingly about native iPhone apps. I still stand by what I wrote there — but that hasn’t stopped me downloading some apps, and […]
Just like in the non-mobile world both apps have there place, and it pains me that apple doesn’t just offer some simple xcode templates which expose uiwebkit, and would be acceptable in the app store. So the app would mainly be webbased but have a native look and feel. (much like air on the desktop) Yes you can do that with just an uiwebview, but apple considers that a webclipping app and WILL reject it.
Given that there is a lot functionality you need the native environment for. Not to mention if you have some functionality when the web is unavailable or your hitting multiple web sites, or want to keep open multiple sessions and push data from one session to another using server push. btw. I’m still trying to work that one through because there seems to be a bug in using multiple uiwebviews.
The point is, from an enterprise coporate standards apps that get and display data from webpages are probably more cost effective as web apps and more secure.
But if you need phone functionality or more polished look an feel you want to use a native wrapper.
We have a project using the server side icefaces here, you might be interested in.
http://www.mooncatventures.com/blogs
[…] Our interest is simple — the way you develop for the Pre and its new webOS is to use CSS, HTML and JavaScript. Now, this was the way Apple initially announced you should develop applications for the iPhone, but then ultimately realeased their own Cocoa based development framework for native iPhone apps, CocoaTouch, which we suggested was a “great leap backwards”. […]
[…] iPhone native Apps: the great leap backwards? […]
[…] iPhone native Apps: the great leap backwards? […]
[…] iPhone native Apps: the great leap backwards? […]