Pull the iPhone out of your pocket and look at the home screen. Likely, you’re seeing some well known brands on the web: Facebook, Flickr, and Google to name just a few. You’ll also see companies like Amazon, Target, and Walmart which sell a lot of products via the web.
Like you, these sites and companies know how to build an effective website using the latest and greatest web technologies. The iPhone’s Safari browser also supports HTML5 markup with CSS3 styling and is powered by a fast JavaScript engine. So why is there a proliferation of apps instead of web pages that can do the same thing?
Longtime A List Apart readers may remember the Put Your Content in My Pocket articles I wrote soon after the iPhone launched. Recently, I published a book that explains how to create products for the iPhone App Store. With this article, I’d like to share my experiences with both mobile web and software development to guide your future developments on the iPhone platform.
Apple <3 standards#section2
From Apple’s point of view, iPhone OS and web technologies share equal footing. When you visit their developer site, the Safari Dev Center is prominently displayed. The iPhone gets all the press, but when you click on Safari Dev Center, there’s a ton of great information that explains how to use HTML, CSS, and JavaScript on an iPhone.
When you look back on your first experiences with the iPhone, one app stands above the others: The Safari web browser. Suddenly you were free from a mobile internet full of crappy CSS support or dumbed down presentation-like WAP. The iPhone’s real browser and the fact that it was in your pocket changed how you used the web.
Apple continues to invest heavily in the development of the WebKit browser engine used in Safari on the iPhone, Mac, and Windows. The result is a browser that excels in HTML5 and CSS3 support.
Apple also views HTML5 support as an important part of its marketing message for both consumers and developers.
Because it’s open source, the WebKit rendering engine also powers browsers for many other mobile platforms. If you’re surfing the web with a Blackberry, Android, or Symbian phone, you’ll find that your content looks just as good as it does on the iPhone. The only holdout is Microsoft’s Windows mobile platform which uses a browser based on the IE rendering engine.
With great HTML, CSS, and JavaScript support, developers are doing amazing things with the iPhone. Here are a few notable examples:
Pie Guy by Neven Mrgan#section3
Pie Guy uses HTML5’s offline application cache so that it works correctly when you’re not connected to the internet, as well as CSS animations and transforms for the game’s effects. Neven also keeps track of developments in this area via the HTML5 Watch website.
Showtime by Nial Giacomelli and Benjamin Gordon#section4
Showtime is a simple app that allows you to keep track of when your favorite TV shows are on. It uses a jQuery plugin by David Kaneda that provides many of the controls and effects that you see in standard iPhone applications.
Every Time Zone by Amy Hoy and Thomas Fuchs#section5
Every Time Zone is a very simple, but effective, view of times throughout the world. The slider that lets you pick the time works very well on a touch screen. This web application looks particularly good on an iPad display.
With such great tools available and talented developers that know how to exploit them, the iPhone should be overflowing with web applications, right? Actually, the opposite is true: there are over 100,000 titles on iTunes and only a handful of popular applications have been created with web standards.
Apple has promoted both the App Store and web browser as ways for developers to get their creations into the hands of customers. They even gave the web a year-long head start before beginning to sell apps in the store. Clearly there’s more at play here: what attracts developers to iTunes instead of the web?
Going native#section6
Before looking at the motivations of the move toward iTunes, we need some definitions. Developers have come to categorize the two iPhone development technologies as “native” and “web.” Web apps use HTML, CSS, and JavaScript that loads in Safari. All the examples above are “web apps.”
“Native apps” are created using the Xcode development environment in a language called Objective-C. These are the same tools used to create Apple’s own built-in apps like Mail, iPod, and even Safari itself.
Creating native apps is much different than the process you use to build web apps. Luckily, many of the underlying concepts are the same. Many web developers find that making the switch isn’t that hard:
- Like JavaScript, the Objective-C language is a descendent of C. In addition to sharing similar syntax, both languages are object oriented. If you’re comfortable with JavaScript, you’ll feel equally at ease with Objective-C.
- Native and web apps share some familiar design elements. On the web, you’re used to breaking an application’s functionality into pages, creating a series of
<div>elements to organize the content on that page, and using XMLHttpRequest to update that content. With Cocoa Touch, “view controllers” are used like pages, “views” provide the building blocks for your content, and NSURLConnection objects act as your link to the internet. - Frameworks handle much of the hard work. Just as you rely on jQuery or Prototype when working in JavaScript, you’ll find yourself doing the same thing with Cocoa Touch when you work in Objective-C. Both languages also benefit from a vibrant developer community that is happy to share development tricks and source code.
- If you’re a Flash developer who’s frustrated because there’s no way to play your creations on the iPhone, you’ll be happy to learn that ActionScript, like its predecessor JavaScript, shares the same lineage with C. The mechanisms for creating animation and other visual effects are different on the iPhone, but the concepts are the same. The recently announced Sparrow framework can help ease this transition, especially if you’re using Flash to develop games. It’s also a great example of the kinds of contributions made by your fellow iPhone developers.
To give you an idea of how similar things are, take a look at this snippet of Javascript code:
var beAwesome = true;
var myString = "chocklock";
if (beAwesome) {
myString = myString.toUpperCase();
}
Now, compare it to the same thing in Objective-C:
BOOL beAwesome = YES;
NSString *myString = @"chocklock";
if (beAwesome) {
myString = [myString uppercaseString];
}
In Objective-C, the variable definitions are different and function calls are replaced with stuff in square brackets. In a larger context, these are minor details. You can still see the logic that to be awesome, you just convert your string to uppercase letters.
One of the goals for my book about iPhone app development was to make this new environment accessible to people coming from other backgrounds. I dedicated an entire chapter of the book to explaining those square brackets in familiar terms.
The motivation#section7
Learning how to use new development tools will take some effort. So why should developers go through this hassle when they could just bank on the web skills they already have?
Some of the motivation is purely selfish: Native applications give the developer more control over the mobile environment. The other incentive is altruistic: a native app is generally easier for the rest of us to use.
- Speed: JavaScript performance has increased dramatically in the past few years, but as an interpreted language, it will never be as fast as compiled code that runs directly on the processor. In a mobile environment where processors run slower to conserve power, every clock cycle counts.
- Data Management: Cocoa Touch has several mechanisms that make it easy to store your application’s data. This is important because caching information retrieved from a network can greatly improve a mobile application’s ease of use. The persistent data storage in HTML5 provides simple key/value access or raw database access using SQL. Core Data on the iPhone provides a much more sophisticated system where relationships between your data objects are managed automatically.
- Animation: One of the hallmarks of both web and native iPhone applications is animation that reinforces a user’s actions. CSS3 provides ways to animate page elements, but much more sophisticated effects are possible when you access the underlying Core Animation framework with native code.
- Resources: Mobile developers never have enough memory, network speed, or CPU power. These limited resources are much harder to control when they’re being managed by JavaScript or the browser. It’s easier for native applications to detect these situations and adapt the user experience accordingly.
- Usability: iPhone users feel most comfortable when they’re using the standard controls they’ve become accustomed to in Apple’s built-in apps. HTML abstracts controls like
<input>and<textarea>so they can work in many different environments. JavaScript frameworks, like jQTouch mentioned above, do a fantastic job extending these basic control mechanisms, but an iPhone user will still notice that they feel a bit different than platform-native controls. - Productivity: From the developer’s point of view, it’s typically easier to build complex user interfaces using Cocoa Touch: The frameworks do much of the heavy lifting and allow you to focus on the problem rather than its implementation. With the limited amount of screen real estate on a mobile device, a simple form on the desktop often turns into multiple views whose state needs to be managed by your application. Apple developed Cocoa Touch specifically to deal with this situation.
- Integration: An iPhone has many capabilities that are beyond the reach of the web browser. Some simple examples are the user’s contacts, the photo library, voice recording, and device movement. Cocoa Touch frameworks are the only way to access this information.
As the web has matured, its applications have naturally split into two parts: The front end and the back end. Back end services manage the user’s data and are typically powered by racks of powerful servers. The front end of a web app takes this information and presents it in the browser: HTML, CSS, and JavaScript are all about user experience. In most cases, this front end is a fairly thin layer on top of the much larger back end.
With iPhone apps, this thin presentation layer is replaced. The access to REST-based APIs implemented by the back end is exactly the same. Yes, you’re duplicating the efforts of any front end development you’ve already done for the browser, but this extra effort comes with the benefits mentioned above.
In practice#section8
There are as many approaches to development as there are apps in iTunes. Every product and the people who created it are different. That being said, the evolution of a product from the web to the iPhone typically goes something like this:
- Design the product. No matter what platform you’re targeting: Be it the web or a smartphone, your first step is always to think about the problem you’re trying to solve. Figure out what your users want before you get anywhere near implementation specifics.
-
Implement the product using web standards. Use the tools that you’re most familiar with. This way, you also end up with a solution that has the widest reach and can be viewed on any platform with a standards-compliant browser. Think about using CSS and Javascript that optimizes the experience for users on mobile devices (including the iPhone, Android, and BlackBerry).
As a starting point, check out Put Your Content in my Pocket and Put Your Content in my Pocket, Part II.
As you implement this product, pay close attention to how the front end user interface communicates with the back end services. Try to use a REST API that third parties and eventually your own more platform-specific solutions can use.
- Launch the product. Get your work into the hands of users as soon as possible. As people begin to use your creation, they’ll start giving you feedback. This starts the virtuous cycle of iteration and refinement.
-
Run into problems. Eventually, you’ll encounter situations that can’t be solved with web standards. Maybe it’s something like feature requests from users who want to upload photos or access their list of contacts. Some users will explicitly ask for an iPhone app because so many of their other favorite sites have customized solutions.
There can also be internal pressures from your own designers and developers. They’ll find that navigation and data management are more difficult as the scope of the application increases. When you start to feel like you’re reinventing the wheel, sometimes it’s best just to use the wheel that Apple’s already built.
- Translate product design into an iPhone app. You’ll find that many of the decisions you made while implementing web pages were done in the name of platform neutrality. As you enter the iPhone’s platform-specific world, you’ll want to re-evaluate some decisions. Layouts and user interaction should be tailored to make them feel at home in a native app.
- Launch product on iTunes. After developing the app for the iPhone, you’ll now have an important new way for users to find your content or service. Which leads to the next section…
Takin’ care of business#section9
The other attraction for developers looking at native apps is simple: There are over 100 million customers in iTunes who can buy your app with a single button tap. They can also pay for your content with the same ease. If you’re running a business, there are some distinct advantages to building apps in addition to your website.
Brand marketing#section10
For brand marketers, the App Store is another important channel to get a product or service in front of millions of eyeballs. The big brands mentioned at the beginning of this article continue to have a strong web presence: their iPhone app supplements their position.
Many of these companies look at a native iPhone app as a cheap form of advertising: 30 seconds during primetime can cost upwards of half a million dollars. An iPhone app will cost much less and when a marketer sees their icon appear in iTunes, it’s better than Christmas morning.
Smaller developers can also use the App Store to find new audiences and fine tune the experience for current users. You’ve already done the hard work with your back end, so the effort and expenses to build a new front end are usually minimal.
Media matters#section11
Many websites have found it difficult to charge for access to content. The root of this problem is a lack of a convenient payment mechanism for the end user. There’s also a history of free access to information on the web. As a result, many sites rely on advertising to pay the bills.
iTunes offers you a simple way to charge users for content. It can be a one-time payment via app purchase, or a recurring payment (such as a subscription) with in-app purchases. In either case, a customer only has to tap on a buy button and enter their password. Apple handles all the payment processing and accounting. You just wait for bank deposits from around the world at the end of each month.
With the recent release and popularity of the iPad, publishers both large and small are finding it profitable to repurpose content for the iPhone OS. Wired magazine’s recent debut on the App Store generated 24,000 sales in the first 24 hours. At five dollars a copy, it doesn’t take a financial genius to realize that there is some serious consumer demand for innovative content delivered via iTunes.
If you think about it a little further, it makes complete sense from a customer’s point of view. You’re used to buying music and video from iTunes. Now with iBookstore, you can get mainstream titles delivered electronically. Adding your own content to this mix makes sense for you and your customers.
Proceed with caution#section12
Getting your content into the App Store also includes a step that you’re probably not used to in the wilds of the web: Third-party review. Anything you submit to iTunes will be checked and can be rejected at Apple’s discretion. Every app you see in iTunes has gone through this process.
The iTunes review tends to err on the side of caution: At one point political cartoons were not allowed because they ridiculed a public figure. Apple has since eased that restriction, but there are still limits that you need to be aware of. These conditions, and other nuances of iTunes, are explored further in my book.
If your content contains nudity or any of the other areas that are disallowed, you’ve just wasted your time reading this article. Things aren’t all bad though, because you can still use Safari to circumvent the entire curatorial process.
Wrap up#section13
So there you have it: A quick summary of what iPhone apps mean to today’s web content producers. Hopefully the information in this article is enough to determine if a dedicated mobile application is right for your site. If you decide to head down this development path, I hope you’ll find that my book is a helpful guide that explains the process from start
to finish.
One small and picky detail — Objective-C isn’t really a descendent of C, it’s a ‘strict superset’ of C. In other words, ObjC *is* C with objects added on. The object syntax is actually based on a language called Smalltalk.
Excellent article, it helped a lot with my decision. I just had to find’n’replace every apple and iphone with something more relevant, that is… desktop. I have no idea why the article is so Apple centric, and there’s no explanation for that in the text.
Just to make numbers clear: there is more Android phone out there than iPhones, and far more desktops/net/notebooks. So why the focus on web vs. iPhone?
I do follow ALA for years and it gave me so much, but this is first time I see such a consumer oriented (iPhone) focus.
I know JS well, but I can do nothing with Objective-C. I can’t even understand the ObjC syntax.
They have different typing, and a lot of different concepts. There is no prototypes in ObjC (but there is something called “categories”), and no messages and protocols in JS. There is also different name binding rules and many other stuff.
Example in “Going native” section involves two different concepts: dynamic/static typing and dot-accessors/messages. It’s introduced like similar, but it’s not.
Thank you for the article. Still I’m not sure wether I should develop my “muscle learning app” strictly on the web or as an iPhone/Pad App.
@scriptin You’re absolutely right. There are major differences in the implementations of JavaScript and Objective-C.
My point was the languages are conceptually similar: You’re using an “uppercase” operation on a string object. From my experience, many developers get lost in the syntactic differences (e.g. square brackets) and make the transition to the new language more difficult than necessary.
Without any doubt, device and context specific web and native apps are powerful. However, in my opinion, you still need to optimize the interface as much as possible independent from the device and capabilities of the user as well.
Interesting article. Not sure I quite agree with the notion that JS is similar to Objective-C. You have to deal with memory management for a start.
Also, correct me if I’m wrong but you have a syntax error in your Objective-C example. It should read…
BOOL beAwesome = YES;
NSString *myString = @”chocklock”;
if (beAwesome) {
myString = [myString uppercaseString];
}
(Note the @ when assigning an NSString value)
Cheers
Chris
@chrismwaite Yep, there should be an @ in the front of that string literal. The ALA production crew has been notified and will get that fixed up. Thanks!
I want my 10 minutes back.
This article fails because it omits the obvious one single reason for iPhone App versus Web – everything has to do with the phone *usability*. The only paragraph that mentions usability even has the nerve to give code examples. Excuse me – users do not *touch* or *care* about tags. They might see the result, but the usability issue of iphone App versus web has to do with this: “App”s are presented in singular, graphical, isolated, low-friction one-click actions, where-as web pages require more intensive interaction. This is the one, first and foremost reason why the two dimensions battle on the iPhone and why the iPhone and App concept is succesful in the first place.
A List Apart – you can do better. I thought this blog was meant for user experience professionals.
@thomasg It’s going to take more than 10 minutes to cover mobile usability issues: this article is just an overview that touches on many subjects. I summarized it as:
“Some of the motivation is purely selfish: Native applications give the developer more control over the mobile environment. The other incentive is altruistic: a native app is generally easier for the rest of us to use.”
If you’re looking for information regarding this topic, I’d suggest the following books:
“Programming the iPhone User Experience” by Toby Joe Boudreux
“Tapworthy: Designing Great iPhone Apps” by Josh Clark
“iPhone User Interface Design Projects” (various authors.)
(Taken from user interface resources in the Appendix of my own book.)
I’m getting flashbacks of the old internet all over again while reading this.
I don’t think it’s about Iphone apps VS Mobile websites. There’s much more players than that, we have iphone, android, nokia, microsoft, each with its own platform.
So, if you prefer to develop an application, you have to make one for each (large) platform.
When developing a decent web application, you only need one implementation.
So, i think you should only develop applications when the phones integration adds real value to the app, otherwise, go with the website;
Hi Craig,
It took me about 10 minutes to read your article. That’s a pretty long read to omit the obvious and important fact: The main factor to distingiush iPhone App popularity versus iPhone web sites is mainly a usability issue. It doesn’t take 10 minutes to explain.
Maybe I missed the point in your article, buried between the lines of code examples.
Thanks for the book references – I could direct you to great books on usability too. It’s really important on an iPhone.
An Apple guy in Norway said during a meeting that he felt too few knew about web-apps. As a content producer I can say for sure its much better to be able to produce with html/css/script than C++ because its easy and some of the work may be ready from other webprojects.
@thomasg I guess its more a question on how you use C or HTML than which of them you choose. Isent html/css/jscript capable of doing usable apps on iPhone/iPad.?
I published last Sunday a designed-for-iOS web app that I had built over the weekend. I’m a web designer by trade, and not at all versed in ObjC, so using the web as a platform was the obvious choice.
Though it’s only been out for three days, I’ve already pushed out 2 proper updates including minor feature requests and some (one major) bug fixes. I’ve also made minor tweaks over the last couple of days. There’s no user interaction required for the updates – they are applied on next launch, and using HTML5 Offline Storage, are only actually applied when they exist. I think that’s a big advantage web apps have over their counterparts in the App Store – I know a lot of iPhone users who never, ever update their apps, because they don’t really understand what that means.
A question for native app developers: I’m currently tracking a whole lot of the javascript (mainly ajax) events that occur during the use of my app. The data is immensely useful for the purposes of design of both UI and functionality (in the last three days I can see data on how people are actually using my app, without having to ask anyone). Is such tracking possible in native apps?
I listed my app on Apple’s Web Apps site, and though that doesn’t have anywhere near the penetration of the app store (I’d guess 90% of iPhone users don’t know it exists) it is certainly driving a lot of traffic to my app. I wish Apple would promote it a bit more, and I wish there was an equivalent to the App Store for web apps (whether quality controlled upon submission or not).
As an interesting counterpoint to this article; I submit the truly exciting and possibly revolutionary “Cappuccino”:http://cappuccino.org open source web framework. Rather then employ your Javascript skills to hack around in Obj-C; you could take the intermediate step of learning to write Objective-Javascript (which employs the conventions of Obj-C rendered as Javascript). You’ll learn the nuances of Objective-C while you build a “Desktop class” web application.
_Ready to be impressed?_
“280 Slides”:http://280slides.com – full fledged presentation software run in the browser window.
Looking for a great IDE to build “Cappuccino”:http://cappuccino.org web apps? Join the beta program at “280Atlas”:http://280atlas.com to drag, drop and code your way to web application bliss. Better still, it uses Native Host to run the application on the desktop, as well.
Still need something to push to the App Store? Why not do like “Google”:http://www.google.com/mobile/google-mobile-app/ and use your app to bounce users into an waiting internet browser window – with your internet app ready to go?
The illustration by Kevin is soooo hilarious…
Just have a look at those birds!
Thomasvand makes a great point: “When developing a decent web application, you only need one implementation.”
This will also require less time, resources and money to develop.
Furthermore, frameworks such as jQTouch (http://www.jqtouch.com/) can also use native functions within phones.
The biggest problem with native apps is that people have to go looking for your app, because nobody’s going to find it wading through the wasteland that is the app store.
With a web app, a simple Google search will (hopefully) give you instant customers. Try looking for anything on the app store and you’re presented with 19 “iFart” or “Sexy Sex Positions” apps for every 1 useful product.
That, and the lack of “try before you buy,” means most iPhone users I know (including myself) have never paid for more than one or two apps, and generally only use big name apps like Facebook or Twitter.
And as @thomasvand pointed out above, the fact that there is more than one mobile platform means that a web app makes much more sense for a developer.
Why not build a web app using HTML, CSS, and JavaScript?
Then integrate that into something like PhoneGap which will then allow your web app to become a native app taking advantage of the device features. This would work for iPhone, Android, Blackberry, Palm, Windows Mobile, and Symbian. Seems like a good solution to me.
yes, web app in mobile platform knows a lot of limitation. but just like creating cocoa touch to adapt desktop apps to mobile devices, many developers are creating frameworks just like phonegap to bridge the gap between the sandbox of browser and the device itself.
If built on a good framework, a web app can access the camera, contact list, all the sensors of the phone.
no difference with a “native app”
and the these “web apps” have some talents:
1. rapid prototyping using html5+css3
2.cross platform support, e.g. phonegap can be run on all popular smart phones!
3. employing open standards, not controlled by apple
I’m really glad you wrote this. Now, as an iPhone developer, I can send people over here when they want to learn about the benefits of a native solution.
Two points I would add. I think these are important because I work at a software development firm see a lot of proposals for iPhone apps that simply don’t make sense. Frankly, they would be a complete waste of money for the brand.
1. Commitment. When deciding on going for an optimized web app or a native solution, you have to think about whether the kind of app you are building is something people are willing to commit to. Web apps generally don’t require much commitment. You can find the site on Google and use it right away. Apps require more commitment: knowing it exists, going through the process of finding and downloading it, being okay that you just added another icon to your already clogged up home screen. If you don’t have enough customers who are passionate enough about your information or service that they would commit to your app, you may be wasting money building that app.
2. If the above case is true, you are not out of luck. It is actually an opportunity. How about instead of building a self-centered app for your brand (essentially, a mirror of your website), do what IMPACK studios did with Voice Tutor and build a remarkable app that does something a lot of users want to do. Its not about the brand, its about the function, but the app does indeed boost the brand and does, as you say, expand the brand’s market on the app store. This way you don’t need existing committed users and it will be a lot easier to get press and be featured by Apple – which, I think, is essential to a successful app.
I’ve fleshed these ideas out a bit more on my company’s blog if you’re interested: “Your company should NOT build an app”:http://skookum.com/blog/your-company-should-not-build-app – pardon the hyperbolic title.
I have been down this road before.
Having tried to make my App with an apple I found it really quite difficult. It ended in such frustration that I eventually returned the apple to the green grocer. He suggested I use a computer and he was right.
I now use a computer to make all my Apps. I am very pleased with it.
I think that Apple is the new Microsoft, and they’re secretly trying to turn people from web-users into app users, so that their competition fails.
What they are doing with the apps doesn’t really make much sense from any other line of thinking, be it usability or what have you.
Think about it; people have struggled and labored for years to come up with an abstraction that will run across all different kinds of computers, the ultimate “write-once-run-anywhere” as first termed by Java.
The closest any abstraction has ever gotten to this is the web, and its web applications; and it’s pretty darned close to that, excluding really old browsers and most past browsers made by Microsoft.
While I can’t speak for the rest of the developer community or the end-users that use what they produce, my personal opinion is that a better result will come from multiple web-app providers (i.e. Apples and their completion) than a single monolithic source such as Apple all by itself.
In short I hope HTML5 wins the battle with the platform specific apps (if there is one), as the apps feel like a step backward considering how far we’ve come.
There are many advanced techniques used to develop iphones. The latest development is the ebook reading application. Also I saw one amazing fact, “sixth sense technology”, I like to spread a word about this.
The news media has an appetite for iPhone apps. An interesting iPhone app is far more likely to get tons of PR than an interesting web app, right? Whether or not that matters, it helps color perceptions and guide conversations.
Plus, the idea of the _website_ has been an ongoing story slow to evolve. The media doesn’t cover complex, macrocosmic events or ideas very well — just look at pandemics compared to natural disasters; pandemics are far more severe but get so much less media attention. So when did a _web app_ become a web app? [Hard to answer.] But when did the _iPhone app_ become the iPhone app? As soon as the App Store opened. Easy.
Web apps are great. iPhone apps are great. Perception vs. reality and the excitement (frenzy?) stoked by the media has got to enter the discussion.
Great article.
The web shifted from being a web of pages to a web of data, web of things, web of apps.
You should really be developing on android.
Better API
Friendlier Company
And
Your app can port to the IPhone / Symbian / Windows Mobile (see xmlvm)
Yeah, yeah, IPhone shiney. Now get off my lawn.
Rethinking the Mobile Web by Yiibu:
http://www.slideshare.net/bryanrieger/rethinking-the-mobile-web-by-yiibu?from=ss_embed?from=fblanding
and also:
Mobile First
http://www.lukew.com/ff/entry.asp?933
**waah** me want iphone app.
http://www.quirksmode.org/blog/archives/2010/03/html5_apps.html
Seriously, you’ll reach 80% of the users, you won’t do that with an iPhone App.
It’s a nice article about the topic itself, but ALA! “For People Who Make Websites”?! Really? Is this the horse you’re betting on, device-specific apps?
While the article is great in its analysis of apps vs web, I don’t think that going from javascripting to objective c is a quick progression. If you already have a background in C, C++ or Java, you’ll be fine with objective C. However if your career to date has been coding HTML, CSS and JS you’ve got a world of ramping up. Dealing with memory management, compilers, debuggers, project configuration and deployment requires time and even additonal CS theory. If you don’t learn it properly you’re going to wind up writing buggy apps or not getting approved through the app store. While I’m not trying to dissuade anyone, I also dont’ think that the leap from js to objective C is a simiple one.