It seems to me that the 1.1.2 release of the iPhone firmware packaged a version of MobileSafari that is substantially faster at loading large pages, especially JavaScript-heavy pages. This is entirely speculative, but it looks like the iPhone surreptitiously got in on the new hotness that is WebKit 3.

Apple released both 10.5.1 and 10.4.11 recently, updating Tiger to ensure that even the previous OS had access to all the good new stuff in WebKit 3. As 1.1.2 was released just about the same time as these updates to OS X, it seems entirely logical that Apple pushed these changes into "mobile" OS X as well, especially considering all the talk about JavaScript's unfortunate performance on the iPhone to date.

Anyone done any digging? Let me know.

Update: Swannman suggested a simple-yet-effective method I'd completely missed for proof: user agent strings! Without further adieu, the proof is in the pudding:

-- Safari 3 on 10.5.1 reports:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us)
AppleWebKit/523.10.3 (KHTML, like Gecko)
Version/3.0.4 Safari/523.10
-- MobileSafari on iPhone 1.1.2 reports:
Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en-us)
AppleWebKit/420.1 (KHTML, like Gecko)
Version/3.0 Safari/419.3
So while it looks like MobileSafari on 1.1.2 may not be running the latest-and-greatest version of WebKit, it is definitely endowed with a version in the 3.0 family, and one I'd gather has the majority of the speed increases touted in the "10 new things" post.

Now the really interesting question: what user agent does MobileSafari prior to 1.1.2 purport to be? Anyone with an older iPhone OS version can quickly hit this link and fire an email my way with the results, so we can put this one to rest once and for all.

My sister called me tonight, frustrated and frantic. She's working in iMovie for the final project of her college career, and OS X keeps yelling at her that her startup disk is full (and it is; only 190 megabytes remain). "It won't even let me add the last frames of the movie" she exclaims: it's clear that something must be done, and quickly.

As we sat talking through all the possibilities for clearing up disk space temporarily - most of which she's a bit squeamish to attempt solo - I mentioned that she could just use her backup drive to offload a part of her massive collection of pre-NBC-bitchslap "Office" episodes to clear up a good chunk of space for a while, then move them back when done. After whining about the time investment even that would take, eventually she assented: what else was she to do?

This is always when my inner¹ geek tends to chime in: "If only she were using ZFS... a startup disk that was really just a pool could add space from the backup drive no és problema!" (Yeah, my inner geek has a bit of Mexican in him.)

Unfortunately so far, it's only been the nerds and fanboys that have cared, or even known about ZFS's (albeit read-only) inclusion in the release of Leopard. As such, the Mac-using public marches along with a file system that was originally introduced² the same year my nearly-college-graduate sister was born. So sayeth "The Architect" himself:

"We've rethought everything and rearchitected it," says Jeff Bonwick, Sun distinguished engineer and chief architect of ZFS. "We've thrown away 20 years of old technology that was based on assumptions no longer true today."

If Apple Geniuses could tell Paul Photoguy or Greg Garagebandman that they could take that LaCie 1TB drive home and immediately add it as extra capacity to their pre-existing storage setup, I imagine the public as a whole would start getting a lot more excited about things like next-generation file systems... because dammit, we nerds are!

[1] I don't think I qualify for having an "inner" geek: it's all outer geek baby, geek all over.
[2] Yes, I know it was regular HFS released in 1985, and not HFS+. Even still, HFS+ is nearly ten years old at this point, besting ZFS by seven years.

We make a product that, during the course of it's work, does a bit 'o disk partitioning. On Intel hardware (which uses the newer GUID Partition Table), Apple has defined a 128 megabyte "gap" partition that is created after any partition on large-enough disks. If you're a developer writing code that will be manipulating the partition table, you usually want to ensure that you stick exactly to the "letter of the law"; in this case, whatever Apple does is all the truth and justice you need. As diligent developers, our software respects this gap when creating the partition(s) it needs.

But when Leopard was released, we kept getting tech support calls exclaiming that any machines that had been partitioned using our software were failing to install the new OS successfully. Days went by and our QA couldn't reproduce it; then someone from Apple calls directly. Turns out it was our code: the gap partition we created was inexplicably one block too small. Since hardware block size is 512 bytes, and the gap partition is 128 megabytes, this accounted for a discrepancy of but 0.00038% of the total bytes in that gap partition. And it was hosing people's machines. Update: turns out the symptom was unwanted behavior in the installer (informing users they had to reformat their drives, something most didn't want to do) rather than actual data loss. Still, no good.

An effort was launched to track down the problem, and after pouring through code that no man should have ever put to disk in the first place, the offender was found.

As it all too often turns out, the problem was minor miscalculation in a small part of a larger calculation to determine the starting and ending addresses for the new gap partition. Considering that these "gap" partitions are just that, blank gaps left there to ease future software development, we were apparently getting by with the fact that no system app or installer actually checked to ensure these gaps were of the "required" size.

That is, of course, until the Leopard installer. In which Apple decided, for the first time, to check and enforce the size of these partitions, causing the installer failures we've been hearing about constantly lately. All because our code calculated 262,143 when it really meant 262,144.

If you've ever skimped on testing a bit of code where you thought an off-by-one bug might be lurking but weren't sure, hopefully now you see how much harm even 0.0004% can cause. (Especially when you're writing dangerous code to muck with partition tables directly!) Just imagine what would could have gone wrong if the offending code had been in a more sensitive or destructive algorithm than it was...