(remember, dont actually use that code for your own website, I'm sure apple wouldn't like that), the only reason I put it up on github is because I found it interesting to learn from and thought others might too.
Some interesting notes:
2. I took all of the minified css files and js files and made an uncompressed version next to it with the name <filename>.uncompressed.js for the css files I converted it to SASS because I like that and I can see better visually what they are doing with it. (ps, if nothing else, look at the css they are using, there is some awseome webkit-proprietary stuff you can do with your styles if you are targeting only the iPhone)
Some cool things:
1. check out the stuff they are doing with the html5 databases in classes/datacontroller-database-uncompressed.js that is pretty cool.
2. the loading image they do with pure css ( @-webkit-keyframes loadingImageAnimation ) in stylesheet.css is pretty cool.
>I'm sure apple wouldn't like that.
What I don't understand is WHY we can't use it since they have this statement.
"Copyright (C) 2006, 2007, 2008 Apple Inc. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: etc. etc.
As much as I'd like to think Apple will officially announce PastryKit at some preview event Q1 2010, it just doesn't seem very Apple-like to do anything at this point that could dilute the ongoing popular attention to the App Store.
Actually, maybe that's it: Perhaps PastryKit was developed originally as a "plan B" in case the App Store didn't take off. Its development probably tracks back to before 2007, when third-party native development was still in question, and was kept in the back pocket as the App Store was launched.
My guess is it will stay a stealth project unless the voice of devs burned by App Store policies becomes too loud and Apple needs to bring out an alternative.
Perhaps PastryKit was developed originally as a "plan B" in case the
App Store didn't take off. Its development probably tracks back
to before 2007, when third-party native development was still in
question, and was kept in the back pocket as the App Store
Actually, given the history of 3rd party development on the device, I think this was "Plan A" and the App Store was "Plan B." When you watch the first couple of Stevenotes that came during and after the iPhone's public announcement, you'll note that Apple was originally expecting developers to only make web apps. But there was a big push-back from developers complaining that they couldn't make apps good enough to stand side-by-side with the built-in ones. (And people also pointed out the pointlessness of advertising to devs that the iPhone was using the same technologies as OS X if they couldn't be directly accessed.)
Apple employs a big pile of talented individuals, but I highly doubt they went from developer pushback in Summer 07 to the SDK in Spring 08 (when the SDK started hitting Apple's partners). Particularly considering the huge changes to the API calls between iPhone's OS 1 and 2.
It looks to me much more like the SDK was dependent on an OS build that just wasn't ready for primetime in 2007 and Steve was just trying to spin what they had as something you want.
PastryKit is a red herring. If Apple decides that it wants to fully support webapps as rivals to native apps then PastryKit is just a nicety. What real commitment from Apple would give you is bug-fixes and improvements to Webkit.
We used iUI for the PAX scheduling app a friend and I hacked together in a few days (best seen on iPhone, mostly works on Android): http://pax.expojunkie.com/
iUI is a pretty decent way to get going quickly - it's a fairly simple framework once you start digging into it, and you can make some decent looking stuff. The AJAX loading of sub-pages is a nice touch and is handled well. We had to do a lot of the fancier map scrolling/etc. ourselves, though, and there are still a ton of shortcomings that we can't get around due to lack of native events (fixed toolbars, proper scrolling, a few other fiddly things that you might notice but are too esoteric to mention here.)
jQTouch is getting a lot of buzz right now, and we might look at rewriting ExpoJunkie using it early next year: http://www.jqtouch.com/
It works well enough on Android and Palm Pre, although without the fancy OpenGL-accelerated CSS transforms (it gracefully degrades to more traditional CSS animations if WebKit transitions are not available).
You may wind up needing to to browser sniffing on the server and serving up different HTML if you see various browsers; we didn't get that far in the project we worked on.
Not sure about iUI, but jQTouch uses webkit-enhanced markup so any webkit engine will read it correctly. jQTouch apps look great in desktop Safari, iPhones, and Android devices. It's even marginally passable in firefox.
Though, Android is very late getting some features (HTML5 manifests, local storage, and navigator.geolocation) and I'm still not sure if it supports support CSS animations.
EDIT: Momentum scrolling is delicious. I'm really enjoying this :D
The linked iPhone user guide (in fact the very default one from my iPhone) does not now load on my iPhone. On Firefox Windows I get redirected to http://support.apple.com/manuals/iphone/. Don't know if that's in reaction to the article or what.
This page is easy to break, at least using Safari on a Mac. Just pull the top list item, Getting Started, down the screen a little. Now when you try to scroll the gray scroll bar on the right moves but the content doesn't scroll.
I've just tried this out and it is indeed deeply cool, although the scrolling even on my 3GS is not quite native-like. I would love to know how they're managing fixed-position toolbars; has anyone reverse-engineered that bit yet?
Of, of course. He even mentions this in the article.
The "sticking" problem when you drag your finger off the bottom of the screen doesn't happen when you add the app to your home screen and launch it that way (because there's no safari menu at the bottom of the screen, presumably).
Looks like you're spot on, good call. I'd misunderstood the other comment, as you only have to tap the top of the screen once to scroll to the top. I wonder if they could just capture and prevent onscroll?
> But on the whole this User Guide app and the PastryKit framework are rather amazing. The $64,000 question, though, is whether PastryKit is something Apple intends (or that a team within Apple hopes) to ship publicly. It seems like a lot of effort to build a framework this rich just for this iPhone User Guide, so I’m hopeful the answer is yes.
Is he talking about a different Apple than the one that I know of?