In John Gruber’s excellent analysis of the Gizmodo iPhone theft, he touches on something obvious in retrospect: that prototype iPhones have to leave Apple campus sometime before they are available to the public, because it’s impossible to thoroughly test a phone without moving it around in the real world. You have to know how it will react to changing signal strengths, to lost calls, perhaps even to changes in network carrier and how the roaming modes do or don’t work.

When the iPad was announced, Apple made it clear that plain iPads with WiFi connectivity would be available first, while the iPad 3G, offering connectivity through GSM mobile networks, would be available some weeks later.

There are many potential reasons for this. Perhaps the 3G hardware was developed on a slightly later schedule than the base model. But it seems more likely that the base model is more or less identical to the 3G’s hardware, with a few conspicuously missing chips (the GPS and the GSM), and perhaps a missing antenna.

The vast majority of functionality for both the 3G and base models could be verified within Apple’s walls. It’s just that question mark next to the 3G connectivity that would have to be verified once and for all out in the real world.

So, how do you do this final sanity testing without drawing attention to your “magical” 10×8 inch tablet, the likes of which nobody has ever seen before? By peppering the world with exactly lookalikes.

Once the iPad shipped, they began to show up in cafés, on subways, in public parks, everywhere! These few weeks have been Apple’s opportunity to send employees out with 3G iPads, completely undetected by curious onlookers. Nobody knows that the 3G iPad on the table at Starbucks is doing anything special. It’s connecting to the internet like all the other iPads in the room, no doubt delighting its user, but also performing valuable last-minute testing for Apple.

If everything goes well in those few weeks, the iPad 3G ships on schedule as promised. But if something really hairy becomes evident, it’s Apple’s chance to prevent the public embarrassment. They stop the factories in China, work out an engineering solution, and adjust the ship date accordingly.

For many years Apple has provided a valuable service to 3rd party developers, and to Mac users, by hosting a directory of software you can download and install for your Mac. You can browse the database on Apple’s web site: http://www.apple.com/downloads/.

This resource helps to bridge the gap between Apple’s customers, who are looking for solutions, and 3rd party developers who are looking to provide them. I, along with most other developers, am grateful for this service.

A few weeks ago, Apple ruffled feathers in the developer community by quietly removing the link to the Downloads section from its formerly high-profile location in the main navigation bar on its home page. This disappointed many of us, as it will likely lead to far fewer casual visitors to the Downloads section, and consequently, far fewer click-throughs to our product pages.

Recently, The Unofficial Apple Weblog observed that Apple has stopped updating the Mac downloads directory entirely. For those few apps that happened to be among the last admitted into the directory, this is a boon. They are permanently fixed as the “most recent” updates, since March 26. For the rest of us, this does not bode well.

Does Apple plan to introduce a new App Store for “authorized” Mac apps? Are they simply disinterested in the Mac since the iPod, iPhone, and iPad have taken one such an important role in their public relations? These are some of the questions that run through the minds of Mac developers as we try to interpret meaning from the unexplained actions.

Mac developers may be feeling a bit sensitive lately. As Apple rides the success of the iPod, iPhone and iPad, those of us who are still cranking out Mac software wonder whether Apple is as excited to boost us as we are to boost them.

But Apple is riding the success of the Mac, too. The Mac is still the heart of everything that Apple does. Imagine an expansive desert where no life seems possible. A settler discovers a spring, churning out water, in the middle of this wasteland. Soon others join in, and a town emerges. Eventually a government is formed, businesses are born, and a thriving economy springs to life. When the brilliant new Town Hall is erected, everybody agrees it is the crowning achievement for the town. It represents every forward-thinking inclination the citizens of this place have, and yet it would not be possible without that water. Without that gushing spring, the town is dead. The Town Hall is worthless.

The Mac is that spring of water that allows life to thrive in Apple’s ecosystem.

I think the failure to update entries on Apple’s Mac downloads site is a consequence of staff at Apple being stretched thin. I would not be surprised at all to learn that the very people who are responsible for reviewing submissions to the Mac downloads directory also serve as reviewers for the iPhone and iPad, either full time or on-demand as submissions for the touch platforms surge.

There have been times in Apple’s history when one of its technologies was clearly being ousted in favor of a successor. The Mac (eventually) obsoleted the Apple II. Mac OS X obsoleted Mac OS 9. In the absence of a clear successor, Mac OS X running on Apple’s sexy, modern hardware, is impossible to declare obsolete. We’ll be using Macs for a long time, and loving the way they empower us to make the most of our iPads, iPhones, and iPods.

And if Apple’s earnings announcement from earlier today is any indication, based on the huge Mac sales this past quarter, they are probably still just as excited to build Macs as we are to use them.

John Gruber analyzed the ramifications of an alleged 960×640 screen on the upcoming iPhone model:

Compare type on your iPhone or iPod Touch against the type in a glossy magazine. […] The next-gen iPhone is shooting for that caliber of resolution — not merely to exceed the resolution of competing devices, but to rival the optical quality of print.

I’m not sure what the software story will be for iPhone apps to take advantage of this increased resolution. If existing unmodified apps run pixel-doubled, they should look identical with the naked eye to how they look today on existing iPhone displays.

Marco Arment responds with skepticism about the value of such a move:

But I’m still puzzled about the 960 × 640 move, if it’s real. The iPhone is already the highest-DPI display that Apple sells, and to double its resolution is very expensive: the panel costs more, it’s likely to use more power, it places higher demand on the CPU for rendering, it needs much more memory for frame buffers and textures, and it incurs big costs on developers and Apple’s developer-tools and developer-support teams.

Let’s assume that Apple has a list of goals for the next phone, and a higher-resolution screen will help them to achieve them. Let’s not get carried away and start assuming that this means the high-resolution screen will be made available for general-purpose developer use.

Wouldn’t it be very Apple-like to use the higher-resolution screen as a mere implementation detail? Just because Apple’s putting a new screen in the phone, doesn’t mean they’ll let you have access to it. If they maintain a conceptual 480×320 screen for iPhones, there is very little of the increase in memory usage that Arment alludes to, there is zero change to complexity from a developer tools perspective, and there is no cost to developers in determining how or if their application should take advantage of a higher-resolution screen.

By applying the default pixel doubling as the baseline scenario for every app, they maintain 100% consistency in user experience across the current lineup of phones and the upcoming models. But on newer phones with high-resolution screens, Apple can take advantage of the screen at their discretion to pragmatically improve the user experience.

For example, if Apple applies this strategy, they can simply do the default bitmap doubling for all pixel-based drawing, but reap the benefits of the higher-resolution screen for all vector-based drawing. Vectors that are used e.g. to describe line art or the fine curves of a typeface, do not take up any more RAM when targeting a high-resolution screen than they do for a low-resolution screen, but when it comes time to draw them, they gobble up as much fidelity as you can throw at them.

A typical application running on a 960×640 screen will use the same amount of RAM as it does on a 480×320 screen, will have identical screen layout and user interaction behavior, but the fonts and vector art will be incredibly, dare I say magically, sharp and beautiful.

Update – A Catch!

John Siracusa explained to me through – a – series – of – tweets, how the story doesn’t play out so perfectly in reality.

Because the fidelity of any vector art is being compromised when it’s mapped to pixels, there will be subtle differences in the precise alignment of how these pixels end up falling on the higher-resolution screen vs. the lower-resolution one. In other words, the layout may change somewhat dramatically when, e.g., rendering a long line of text, or a complex, small vector illustration. If the application is designed with assumptions about the portion of the screen that content will take up, then the higher-resolution screen cannot dramatically alter that or it defies the developer’s design.

He’s got me worried that it’s a deal-breaker, but I leave it to Apple to demonstrate for us whether it is or not. I wonder if at some point the increased resolution becomes so high that it affords some compromise in the layout so that metrics continue to add up as expected without causing noticeable awkwardness in the rendering.

I complained on Twitter about PayPal’s unfortunate transaction search utility, which doesn’t recognize the transaction ID itself as a search term.

Georg C. Brückmann chimed in with a semi-solution, which is a URL template you can use to jump directly to a PayPal transaction by ID. Take the root PayPal URL for your country, and add “vst/id=” followed by the PayPal transaction ID. In the United States, this leads to a URL like: https://www.paypal.com/vst/id=1234.

It’s sad to say that remembering a static PayPal URL and pasting in the transaction ID in the magic location is indeed easier than navigating PayPal’s slow and awkward transaction history UI. But it could be even easier with a little automation.

Jump To PayPal Transaction ID is a simple AppleScript that prompts you for a transaction ID, constructs the desired URL, and opens it in your default browser. If you don’t live in the United States, open the script in AppleScript Editor and alter the template URL contained within it.

I put this in my Safari-specific scripts folder:

[Home] | Library | Scripts | Applications | Safari

So it’s available from FastScripts whenever I’m in Safari. Problem solved.