Web Apps

Here’s a very important thing to know:

Web Apps Run On All Phones And You Can Build Them Faster And Cheaper.

That’s a mighty powerful statement. You should stop and ruminate on that for a minute. If it runs on all phones and you can build a web app faster and cheaper, then why think any further? We’ll get to that, but first let’s look at the two drawbacks to Web Apps:

  • Web Apps run on your browser and cannot be sold in iTunes or Marketplace.
  • Web Apps have very limited use of phone hardware and software and may have little offline functionality.

The first bullet may not be a showstopper for you, and actually is a bit of a plus, but let’s look at the particulars of this statement:

  • Web Apps have to be found to be used. This means you have to direct people to them. The easiest way is to have a link on your website that appears when people view your site on a mobile device. You’ve probably seen little popups when you visit a site on your phone, touting their web app.
  • If you are looking to monetize your app (make money off of selling the app) then you can go straight to Native and build stuff for iTunes and Marketplace. You can’t really sell a web app, only access to its content. Its just too easy to steal or hack because it’s little more than a webpage. But if you’re giving mobile access to content, then it’s actually EASIER than a native app. We’ll touch on this further.
  • Running on your browser isn’t necessarily a bad thing; processing speed for Javascript (which you’ll use to build a web app) is very fast and provides really good interface and capabilities. The javascript, etc. is cached after first use, so should run quite nicely. Not as good as native code, but you aren’t creating Angry Birds here, are you?
  • Web apps can be cached and written to disc on your phone. It’s a process using an XML Manifest. Basically, it says to download content and stash it on space on your phone. This makes that content fly! However, it isn’t all content… Videos, larger audio files, etc. won’t come down and be stashed.
  • Databases, however, can be stashed and run quite nicely. Most phones use SQLite, a database thats awesome for mobile work. You initially download and populate the database and now you’re good to go. Imagine that your web app is a catalog. You can download and stash data and review catalog quickly.
  • Cacheing is limited to 5mb at this writing, and there are particulars to how you pull down and reference files. Buyer beware.
  • The reason for cacheing is to use your web app offline. Like a native app. But its not, so why try? Personally, I make it a rule to require users to be online to use mobile apps. And its simply not a problem.
  • When you want to access phone features like geolocation, vibrate, camera, etc. you are pretty much out of luck without getting into some serious voodoo. There is an alternative that is close, called frameworks, that we’ll talk about later.

Let’s go back to Dr. Bob’s needs for a minute. He has a lot of videos and he wants to share. If that’s the extent of what Dr. Bob wants to do, then a web app is perfect for him. In fact, if his website is built correctly, it can automagically turn into a web app! (You should ask us about how to do that.)

But there would be a few caveats associated with doing this:

  • Dr. Bob’s web app can’t be downloaded from iTunes. He’ll have to promote it (or his website) to get people to see his web app.
  • It will only work online. Videos will not be downloaded for web apps. They’re just too big.
  • He will have to ensure he’s serving his videos in a mobile-friendly way. If you’re using YouTube to host your videos, you’re in good shape. They automatically convert to proper players. If you are self-hosting and using Flash then it won’t work. But we know how to fix that.

So all things considered, Dr. Bob’s in a good position to have a web app. But suppose he wants to do a little more… Dr. Bob may need a Native App.

Please proceed to the next primer.