This assumes you have an interest in developing websites/web apps for the iPhone, and that you’re comfortable doing so.

Did you know webpages can be made completely chromeless on the iPhone? By “chromeless” I mean that a page can specify it should be shown without the navigation bar at the top and toolbar at the bottom (the status bar is there to stay, and you can’t change its color. WebKitBits points out you can change it - and how!).

Add this meta tag:

<meta name="apple-mobile-web-app-capable" content="yes" />

Now load the page. No change, huh? Well, Apple decided not to let pages steal the browser from the user just like that - imagine, you go to my site, and suddenly Safari has no UI to jump back to another page. Instead, the user will have to add this page to their home screen - “make it an app” - to get the full-screen sweetness. So let’s do that - tap the generic + button and Add to Home Screen. Quit Safari and launch the page as an app.

NO CHROME. Neat, huh? Of course, now you need to build in any navigation the user might need in your app - back/forward buttons, reload, etc. You could theoretically build your own browser within a browser, but friends don’t let friends do that, ok.

Here’s a complication for you, one I knew would come up with my little Glyphboard project (a glyph keyboard for iPhone 3.0). I wanted to build a scroll-less page, one where all the elements would be aligned and neatly visible on launch. But I didn’t know what sort of window the user would view the page in. The possibilities are, in descending order of likelihood:

  1. Non-full-screen Safari view, with the chrome and all, in portrait mode,
  2. Chrome view in landscape mode,
  3. Full-screen, chromeless view in portrait mode, and
  4. Full-screen in landscape mode
  5. Full screen with translucent status bar, portrait (using  <meta name="apple-mobile-web-app-status-bar-style" content="black" />)
  6. Full screen with translucent status bar, landscape

Each of these results in a different window height. With apps where every pixel matters, this matters a lot. Here’s how much page you have to work with in each mode, as reported by window.innerHeight:

  1. 416px,
  2. 268px,
  3. 460px,
  4. 300px,
  5. 480px (yay!)
  6. 320px (yay!)

The bad news is, you have to build four six four different styles for your app (unless your UI is small or you make it flow and you’re cool with scrolling, which is cool). The good news is, you can sniff this out on page load, and on each orientation change thereafter. Here’s how I do it:

// Make sense of the page on load
addEventListener("load", function()
{		
	updateOrientation();
	window.onorientationchange = updateOrientation;
}, false);

// "Hide" the navbar
function hideAddressbar()
{
	window.scrollTo(0, 1);
}

function updateOrientation()
{
	// Orientation
	var orientation = window.orientation;
	switch (orientation)
	{	
		case 0:
				document.body.setAttribute("class","portrait");
				break;
		case 90:
				document.body.setAttribute("class","landscape");
				break;
		case -90:	
				document.body.setAttribute("class","landscape");
				break;
	}
	
	// Chrome mode
	if (orientation == 0 && window.innerHeight > 400 ||  orientation != 0 && window.innerHeight > 290) // we're in fullscreen mode, either orientation
	{
		document.body.setAttribute("class", document.body.className + " fullscreen");
	}
	else
	{
		document.body.setAttribute("class", document.body.className + " chromed");
	}
	
	hideAddressbar();
}

There’s a Safari/WebKit bug that will mess with your head here. If you launch the homescreened web app in portrait mode, all is well. But if you tap the web app icon to launch, immediately rotate the phone, and let the page load in landscape mode, orientation updating pretty much breaks. Maybe I’m too dense to figure out what’s happening and why - all I know is, it works fine in all other cases. Anyway, I hope this helps!