Making a webapp for the iPhone is a lot like making a normal web site, but with a few quirks to abide by. In this article, I'll give you a wide variety of tips, covering things such as: "must-haves", usability guidelines, testing/debugging, pitfalls, and performance issues. I hope you enjoy it!
WebApps vs. Native Apps
Keep in mind that a web application runs in the browser, while a native application is installed on the iPhone.
So, if you want to make something like a high-performance, fast-responsive, action-packed game with awesome graphics, then you're probably better
off just learning Objective-C and making a native app. However, if you don't own a Mac and/or if you are trying to do something a lot simpler, like
making a mobile version of your website or blog, then making a web app might be the faster and more reasonable road to take.
Still not convinced? Here are a list of popular sites that are iPhone web apps/websites:
iphone.facebook.com
m.digg.com
hotels.com/iphone
iphone.fmylife.com
iphone.coldwellbanker.com
The list goes on...
If you're REALLY smart, you'll make BOTH a native app(hopefully free) and web app, like most of the sites above did.
1: Viewport, Viewport, Viewport
I would say this may be the simplest and most important thing for an iPhone web app. It's just one line of code to include within your head tags:
1
2
<!-- add this in your <head> section with your other meta tags-->
<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />
This tells the browser to scale your page in such a way that will make it fit nicely on the iPhone. Here's what each field means:
width=device-width
This fits the page to the device's width. The iPhone's display is 320x480 pixels in portrait mode, and 480x320 pixels in landscape mode, which is why you sometimes see sites use width=320 instead of width=device-width.
initial-scale=1.0
This is the scaling when the page first loads up.
maximum-scale=1.0
This is the maximum scaling allowed.
user-scalable=0
This determines whether the user is allowed to zoom in and out by pinching/double-tapping. You can also use user-scalable=no and user-scalable=yes instead of 0 and 1.
Keep in mind that the viewport IS NOT A WINDOW. Think of it like a magnifying glass over a page. You can move the magnifying glass around and zoom in/out.
This is why certain features like fixed positioning don't work on the iPhone(at least at the time of this writing). In Professional iPhone and iPod touch Programming, Richard Wagner explains what a viewport is:
A viewport is a rectangular area of screen space within which an application is displayed. Traditional
Windows and Mac desktop applications are contained inside their own windows. Web apps are displayed
inside a browser window. A user can manipulate what is seen inside of the viewport by resizing the
window, scrolling its contents, and in many cases, changing the zoom level.
Specifying the viewport is a *must-have* and is the first step into making your web app iPhone-friendly.
2: "Hide" the Address Bar!
The address bar takes up a considerable portion of the already tiny screen we have to work with. You'll want to hide the address bar to display as much information on the screen as you can, so that the user doesn't have to flick down. Consider the picture below. Is that the whole screen, or is there more information below?
With the address bar
Now let us hide the address bar by adding this single line of javascript code:
1
2
//add this in your javascript code to 'hide' the address bar
window.scrollTo(0, 1);
This will "hide" the address bar by scrolling down just enough so that you won't see it when loading the page. In our picture below, we see that there was more information to be displayed after all!
Without the address bar
Notice that this only temporarily hides the address bar by just scrolling down a bit upon loading the page. Permanently hiding the address bar may not be the best idea, bu t it is possible. For safety's sake, we'll leave that outside of the scope of this article.
3: Test on iPhone AND Browsers
Although your ultimate goal is to put your web app on the iPhone, testing it on normal browsers can be beneficial!
Remember, since this is a web application, you can test it like one! That means useful tools like Firebug, Web Developer, and YSlow still work!
"A firebug error!? But that's impossible...my code is always perfect!"
NOTE: You may get errors for certain pieces of code that are legitimate -- iPhone-specific/webkit-specific code mostly. With that said, don't be too dependent on these tools...they are more of a guide, not an oracle.
Keep in mind also that Firefox may display things differenty than Safari does, and Safari is also different from Mobile Safari. You'll most certainly notice web apps that you develop in Dashcode won't display properly on Firefox.
This is why you still need to test on an iPhone. If you do however, develop in Dashcode, there are testing/debugging features that come with it.
4: Mimic a Native App if Possible
From a usability perspective, making your web app look like a native iPhone app is beneficial because users already know how to use an iPhone application, thus there is a positive transfer of knowledge.
Besides that, using the buttons, font, lists, etc is also beneficial. A lot of time and money was put into researching what would be a good design...Apple must have hired various usability and design experts.
If you mimic a native app, you won't have to go through the whole process of designing and creating something that may in the end prove infeasible.
Take a look at the picture below...this is the "Groups" menu from the "Contacts" feature. Can you guess whether this is the real deal(native app), or a fake(webapp mimic)?
Native app or web app?
If you guessed that the above pic is a web app, you are correct! See how closely you can mimic a native app?
If you do not wish to mimic a native iPhone web app, perhaps because your application doesn't fit well that way or because you want to maintain your style, then at least follow some basic guidelines:
Be consistent (i.e: navigation buttons on each page)
Make buttons large enough to tap (i.e: for fat fingers or the error-prone)
Make things intuitive (i.e: collapsible boxes should have hint...like a +/- next to it)
5: Use Frameworks, Libraries, and Tools to Save Time
If you do decide to mimic a native app, then I suggest not starting from scratch. There are many things out there that can save you a ton of time:
Dashcode
If you have a Mac, this may be the best route to go if you want to whip up something fast. Dashcode has a parts library(i.e: buttons/frames), a code snippets library, a workflow steps guide, and way more!
iUI
Created by Joe Hewitt, this nice little framework lets you create web apps with simple HTML! It has a nice slide-effect too. Performance is FAST and the framework itself is very tiny filesize-wise.
iWebkit
Just like iUI, you can create your app with simple HTML. However, this framework has many features that other frameworks might not have. It also comes with a user guide which clearly explains how to use the features.
What makes this my favorite framework is that it plays nice with other javascript code, so I can customize my web app and do things like make collapsible boxes
There are, of course, many other frameworks, libraries, and tools, but as to date, these are my favorite ones. Have one that you really like? Write it in the comments below!
iWebkit's pop-up feature
6: Use Lists When Possible
Lists are a nice quick n' dirty way of displaying information. "Contacts" and "Mail" display information in the form of lists. Lists allow for easy navigation, let you display a lot of items on the tiny screen, and are easy to touch compared to pictures.
They also load pretty fast since they're just text. Lists will almost always be your navigation method of choice, but then again it really depends on what your web app is.
If you do use a list, grouping items by alphabet, relevance, or usage is always a good way to go.
A list with items grouped by alphabet
7: Minimize Horizontal Navigation
If possible, minimize the number of screens your users have to navigate to in order to get the information they want.
Having less pages to jump to means less redirecting and unnecessary loading by going backwards and forewards.
Many navigation screens
In the example picture above, we can possibly eliminate the first two screens by automatically getting the date/time and start out with the third screen.
If a user wants to intentionally pick and different day/time, we can have that in the "Change View" menu.
8: Make Your App Small and Fast
Remember that performance is critical in the mobile world, as a user may be on the EDGE network or just have a slow connection. Give them as little to download as possible! Just like normal web sites, the same rules of enhancing performance apply. Instead of
giving you a checklist of everything, I would just recommend that you get both Page Speed and YSlow, as these
give more detailed checklists on beefing up performance than I could ever give.
Not bad for a framework that has a .js file, a .css file, and a bunch of images, huh?
9: Have a Homescreen Icon
Make sure to have a nice icon that people can see when they add your web app to their homescreen. Make a 57x57 PNG file and add the following code to your home page:
1
2
<!-- add this in your <head> section -->
<link href="path/to/your/icon.png" rel="apple-touch-icon" />
Having an icon is a good way to quickly recognize your web app, as well as look professional while having some nice eye-candy.
10: iPhone 'Simulators' aren't Perfect
You will notice that iPhone simulators, even the official "Aspen Simulator", can sometimes yield different results than on the iPhone. This is true even when making native apps. This should actually be somewhat expected since the iPhone OS is different from Mac OS and the iPhone architecture is different from a normal computer. I want people to know about this, because I've had quite a few friends
develop and test mainly on "simulators" only to find out near final production/deployment that their program on the iPhone was buggy, crashed, or simply just didn't work. Please be careful when using a simulator--they are here for convenience, NOT for iPhone replacement. Remember that since your ultimate goal is to put something on the iPhone, then test on the iPhone. Since you are making a web app and not a native app, you won't need to worry about paying the developer fee or becoming a registered developer with Apple.
Simulator FAIL
Conclusion
I hope you enjoyed this article! One of the joys of making a web app is you can develop on any platform! I tried to keep the tips as cross-platform as possible. However, although this is true, it still might be the best idea to develop on a Mac.
There are many other important tips that I did not mention here, simply because other people have beaten me to the punch! If you are really serious about iPhone web app development, go out there and learn more! There are plenty of resources that your best friend
can give you that I would not know about.
Have any tips of your own? Want to call me out on tips that are nonsense? Share your knowledge by writing in the comments below! I love learning new things and I definitely want to be corrected if I am wrong.
.
Are you looking for free YouTube Views?
ReplyDeleteDid you know that you can get these ON AUTOPILOT & ABSOLUTELY FREE by registering on Like 4 Like?