• Print

Web developers can rule the iPad

A lot of tech commentators seem disappointed that the iPad feels more like an evolutionary step than a revolutionary step. For one group of technologists, though, the iPad is an opportunity for revolution, to take center stage in creating experiences users will want, and even want to buy.

The iPad is all about consuming content, but most of the conversation about that content has seen it in traditional silos:

  • Audio, through iTunes
  • Video, also through iTunes
  • iPhone apps (and now iPad apps), through the App Store
  • Books, through iBooks
  • The Web, the most open of these options.

The last of those options, however, can incorporate all of the rest – even the iPhone applications. Given the space on the iPad screen and the reported speed of its A4 processor, web design is actually the easiest way to create applications for the iPad.

Web design? On the iPad? Wasn’t that the bad idea Apple originally had for the iPhone, before they were overwhelmed with requests for a real SDK?

Well, yes. The early iPhone development environments felt maybe too sandboxed. A lot of features now available in Mobile Safari were only starting to develop, and key tools for connecting to features of the iPhone not typically found then in web browsers (vibration, accelerometer, geolocation) didn’t exist. Learning Objective C made sense at the time.

Today, things have changed. With support from tools like jQTouch, it’s shockingly easy to create apps that feel like they belong on the iPhone using HTML, CSS, and JavaScript. With PhoneGap, you can reach out to features like vibration, accelerometer, geolocation. What’s more, PhoneGap lets you target your application to multiple platforms, including Android and Blackberry, so you’re not even locked into Apple’s tightly-controlled universe.

For a quick tour of how this works, see Bill Peña’s tutorial. For a lot more detail, though still 160 pages, see our recently released Building iPhone Applications with HTML, CSS, and JavaScript. Despite massive rust on my web skills and no experience with iPhone development, I was able to create a functioning, if basic, iPhone application in three hours, and have it running on the iPhone Simulator in twenty more minutes.

Moving to the iPad shouldn’t be difficult. As the PhoneGap folks tweeted:

for those unsure, iPad is @phonegap compatible out of the box.

There are, of course, ways Apple could make this difficult. They could have locked web-based apps into the iPhone size, but fortunately that doesn’t seem to be a problem. They could also block PhoneGap based applications from the App Store, as they once did, though they seem to have
gotten over that a few months ago
. Even if they were to cause trouble, however, it would just block one possible revenue stream – the web browser itself would still be open for business. I don’t think even Apple can close that down.

Apart from the joy of being able to say “I don’t have to learn Objective C”, the web approach has tremendous advantages for probably 80% of the applications people the iPad seems built for. The layered approach of HTML, CSS, and JavaScript makes it easy to pour content into templates, decide how those templates will look, and what interactivity they will have. Done right, it’s a much more maintainable approach as well, making it easy to change the look or add interactivity without having to break into the underlying content again. Adding content or reaching out to content elsewhere on the web is easy. Toolkits already make the shift from traditional web browsers to device development easy. We’ve come a long long way since the first glimmerings of a slow and creaky Dynamic HTML appeared on the landscape.

I expect music and to some extent video to stay in iTunes or similar venues. Terrified book publishers who want their DRM will likely stay in the iBooks zone, though hopefully Apple will let braver publishers in there without DRM. Customers will expect to find “books” there. It’s also clear that there will always be applications, notably games, which demand native code – Objective C on the iPad – to achieve the fastest possible response time, draw intricate graphics, or bind tightly to iPad features. There’s a future for all of those things, in their particular venues.

But for “content”, especially content that combines text with audio, video, pictures, and interactivity, web-style development has a tremendous advantage.

Arise, web developers! Our time has come to dominate!

tags: ,
  • Alasdair Allan

    I think I’ve got to disagree. You only have to look at the newly re-written iWork applications optimised for multi-touch. That sort of interface simply couldn’t be done with a web application…

    A lot of applications on the iPhone are fairly simple, and that’s okay. The amount of screen real-estate available means that presenting information in small chunks, simply, is actually a really good design choice.

    That isn’t going to cut it on the iPad. Developers are going to have to totally rethink their interface design. In fact I actually think desktop developers will have a much easier time of things than people coming in directly from the iPhone, or the web…

    The killer apps on the iPhone will be applications that allow people to get things done, and those take advantage of the hardware.

    When the iPhone SDK was introduced, there were a number of people that argued that it was actually a step backwards for developers. They felt that a Web-based application was good enough, better in fact, for various reasons than native applications.

    By writing code specifically for the iPhone in Objective-C, you were making porting your application harder, and that porting a web application more-or-less consisted of simply restyling it using a new CSS template.

    However users of the applications disagreed, and it’s arguable why this is the case, many of the reasons why developers believed web-based applications would be successful were actually seen as disadvantages by the users.

    In the end it’s not going to be us, the developers, that decide. Like the iPhone, it’s going to be the users.

  • Brian LeRoux

    Open systems will always win in the long term! Of course, Apple has not limited their innovation to the native desktop. Webkit has been seeing steady (incredible) enhancement these past few years.

    As a PhoneGap contributor/developer certainly I am biased!

    Combining native access with HTML5 apis and the lines between desktop and web begins to blur. What we call hybrid today will be what we call the web at some point in the not-so-distant future.

  • Jonathan Stark

    Great post! (and thanks for the plug)

    As the author of the “Building iPhone Apps” book linked to above, I’m clearly a huge fan of the web-based approach to mobile app development.

    That said, I’m the first to admit – as Simon points out above – that the HTML, CSS, and JavaScript approach is not suitable for every app.

    At the end of the day, developers have to decide for themselves which strategy is going to work the best for their app, and the overall goals of their business.

    When I give presentations on this subject, I usually end with this quote:

    “If you can build your app with HTML, CSS, and JavaScript, then you probably should.”

    It’s still a pretty big generalization, but it seems to help folks who don’t know quite where to start.

    Thanks again, Simon!

    Cheers,
    j

  • Liza Daly

    Unfortunately, the new iPad emulator doesn’t include Safari at all, so until the device comes out it’s impossible for web developers to know what features are supported (I’m thinking specifically of bleeding-edge HTML5), or how they should best optimize their layouts.

  • Keith Fahlgren

    Shame the new 3.2 Beta SDK doesn’t ship with Safari as part of the iPad Simulator, so there’s no way to test web apps written in this style (without a lot of pain).

  • George Bray

    Create *native* iPhone, iPad apps using HTML, JS, CSS with Titanium

    http://www.appcelerator.com/

  • steve

    I agree with trying to make apps easier to build and openness, but from a practicality/business standpoint, there’s this:

    If I want to charge for an application via my web designed site, users will have to input CC info. I have the extra work of processing CC info.

    An iPhone app, a user just inputs his/her iTunes password and it’s done.

    Yes, Apple takes a percentage and it’s hard to discern user behavior in the buying process – the question is whether the you lose more from the Apple cut or users who don’t want the hassle of a buy cart process.

    The iPad is less of a problem with the screen size, but I have to think in most cases, you’d get more purchases if the buying process is less of a headache.

  • Simon St.Laurent

    Steve – with PhoneGap (or Titanium, noted above), you can sell your HTML/CSS/JavaScript applications through the App Store if you want. They compile into applications. There’s no need to handle your own credit card processing, unless you want to.

    You can sell native and web applications the same way.

  • An author

    Since web connections aren’t always there, I rather see developers focus on apps that wouldn’t make sense on an iPhone but do make sense on an iPad. My own preference would be a version of that marvelous writer’s application, Scrivener. It’s developer is already getting besieged with requests for that but has had to plead off, not being a iPhone developer.

    Keep in mind that if this follows the iPhone pattern, this could be a really big market.

  • Simon St.Laurent

    An author -

    Again, the web connection doesn’t have to be live for web-based apps to work on an iPhone or iPad. Once a web-based app is baked into an application for the App Store, you can use all those parts with the networking off. (Well, unless the app needs to call out to external resources, a problem that’s the same for native apps.)

    Even traditional web sites can make their pages cache on the iPhone and iPad, so they’ll stick around when the network isn’t available.

    “Web connections aren’t always there” is not a problem for web-based iPhone/iPad development.

  • Nick Bilton

    Great points here Simon. It’s going to be interesting to see what people make with a standard size browser screen that’s not variable. One of the iPhones success on the UI front has been consistency, the same will ring true for the iPad.

  • Billy

    @Allasdair,

    Multi-Touch via web applications is already available. Silverlight made it possible in this case, but that’s not to say another method wont be devised using other languages.

    http://www.techcrunch.com/2009/12/02/ciplex-multi-touch-website-silverlight/

  • Justin

    Haven’t developers been doing this for quite some time with flash? Of course, flash is specifically disabled on the iphone and ipad platform.

    If what your advocating is more of a focus on web development then the ipad is irrelevant. It’s not about any specific piece of hardware because if you are truly platform agnostic then hardware becomes a commodity which would make the ipad nothing more than an overpriced touchscreen, albeit a pretty one.

  • Simon St.Laurent

    Justin –

    My point is that web developers can take the tools they already have and build applications for the iPad much more easily than the folks who think they need to use Objective C.

    HTML, CSS, and JavaScript have become the de facto cross-platform development tools for these kinds of devices. They’re a very natural fit for devices that allow users to consume media, as they’ve been doing that for years. Add the local storage and media support of HTML5, and it’s not really a problem that Flash isn’t supported on the iPhone and iPad.

    And just to reiterate: it’s easy to build apps you can sell through the App Store using HTML, CSS, and JavaScript. Those technologies now have a client-side life that isn’t necessarily connected to a web server.

    I see the iPad as an opportunity for web developers in particular to make money, because they already have almost all of the skills they need to build sellable applications.

  • steve

    Oy vey, I missed the one of the gists of your article, didn’t I? I’ll take a closer look into the mentioned products.

  • Daniel Asare

    the product and price is cool but i think iped will be out soon before i even finish exploring ipads controversial features..

  • Tomas Sancio

    Thanks to this article, I just bought Jonathan’s book (the plug worked).

    What I’ve seen is that unless an app really requires the native features unavailable to web development, the best bet for a team of developers is to work with skills that can more easily be transferred from one platform to the other. In this case, Javascript should be the first option.

  • Brent

    Awesome. Looking forward to ruling content with iPhone mobile web design. I knew out time had to come as long as we were patient. JQTouch rules and I’m looking forward trying PhoneGap and Appcelerator next.

    The main problem that I see Apple did was not let enough people touch the iPad – forcing them to speculate and imagine. People thrash with that much freedom. Apple shoulda not announced with 2+ months left to go.

    Thanks.
    ~brent

    http://www.mobilewebkit.com

  • john

    “Arise, web developers! Our time has come to dominate!”

    Yeah right, if the entire world buys an ipad.

    I love mac fanboys and people who think the world runs only on a mac.

  • Steven Gulie

    Liza Daly wrote:
    Unfortunately, the new iPad emulator doesn’t include Safari at all, so until the device comes out it’s impossible for web developers to know what features are supported (I’m thinking specifically of bleeding-edge HTML5), or how they should best optimize their layouts.

    Not true. Download iPhone SDK, launch iPhone simulator, change to iPad in Hardware menu. Safari is there, and works with HTML5 audio and video tags as it should on the actual device.

  • mike

    hi!

    I agree with what you’ve said. I wish I am a web developer because I have lots of ideas now how to make use of the ipad with grea apps.

    like these websites:

    business insider
    ipad reviews

    It’s not about any specific piece of hardware because if you are truly platform agnostic then hardware becomes a commodity which would make the ipad nothing more than an overpriced touchscreen, albeit a pretty one. I see the iPad as an opportunity for web developers in particular to make money, because they already have almost all of the skills they need to build sellable applications.

  • Jack Lusel

    Great blog, this could be the best blog I ever visited this month. Never stop to write something useful dude!
    ipad

  • http://cellcept-buy.posterous.com/ cellcept

    As a Newbie, I am always searching online for articles that can help me. Thank you
    Wow! Thank you! I always wanted to write in my site something like that. Can I take part of your
    post to my blog?

  • tylerv

    umm, what are you going to do with htms js and css with out a database?

  • http://simonstl.com Simon St.Laurent

    Safari for iPad includes SQLite, and there are other local storage options as well. There’s plenty you can do.

  • http://ipadstyles.net/ Genevie Kingdom

    IPad’s other capabilities consist of internet browsing, film viewing and music listening. E-mails could be sent by way of Mail app on apple ipad, having a split-screen watch and expansive on-screen keyboard.

  • http://itunes.apple.com/us/app/id387240098?mt=8&affId=1744357&ign-mpt=uo%3D4 lzkim

    wow great Genevie is there more applications about it? But still this article is awesome.. Good Job..

  • http://www.dynamic-website-design-seo-marketing-professionals.com/internet-marketing/open-source-real-estate-solutions/letting-agent-software-cms.html Cordie Chatman

    Charming Thanks a bunch, I think you can use network storage with html5. This excellent post has been really clearly composed. As my mumar used to quote ; In the long run, it’s actually not likely to make a difference the number of breaths you actually had, but exactly how numerous experiences took your breath away:-)

  • http://pennystockclassroom.com Jason Johsnson

    “umm, what are you going to do with htms js and css with out a database?”

    I was wondering the exact same thing while reading the article. Never the less, well written and informative. Nice post.

  • http://www.10-minute-trainer.com Barry Tooker

    Having worked through Building iPhone Applications with HTML, CSS, and JavaScript already, I have to say that I think we’ll see a rise in HTML/JS based native apps for both Android and iOS in the next 12 months that will bring them to the forefront of development. For the majority of data driven apps (IE nothing graphically intensive), there’s no point to use Objective-C and get locked into just iOS or Java and locked into Android when you can pump out a single app that is cross platform, beautiful, and fast.

    Also, I’ve been eyeing jquerymobile to replace my jqtouch apps, definitely worth checking out if you’re serious about developing like this.

  • http://twitter.com/darth_schmoo Bryce

    Re: the database question. Somebody already mentioned Safari’s SQLite support. The other option is to pull all your data from remote services.

  • Jose A

    I’m more confused now tan ever before ….

    So, what are my choices again for RAD (Rapid Application Development) on the iPad ?
    There’s actually nothing out there, without having to learn 2-3 different scripting and/or programming languages and convoluted interface techniques. I cant believe that Apple expects developers to be thrown back 1K years and actually take learn Objective C++ language. What about making a simple to use, SDK and App generator that will spew out Objective C++ code and also HTML5 or CSS for the Android marketplace, without all the programming issues. What a waste of time !!!!
    We are actually going back in time instead of gaining on it with what has been so far achieved in development.

  • http://www.pornostreaming.org Streaming X

    Unfortunately, the new iPad emulator doesn’t include Safari at all, so until the device comes out it’s impossible for web developers to know what features are supported (I’m thinking specifically of bleeding-edge HTML5), or how they should best optimize their layouts.