Today I was so supremely frustrated by this that I played around with all manner of double-clicking, alternate modifier keys, etc., until I stumbled on the simple solution. Googling for answers after-the-fact revealed that I’m by no means the first person to discover this, but it’s quite possible I’m the first person who has told you!

To zoom in on an arbitrary point with the iPhone simulator:

1. Hold down the option key to obtain the familiar “simulation fingertips”.
2. Move the mouse until the fingertips are the desired “starting width” for your gesture.
3. Keeping the option key pressed, hold down the shift key to enter “panning” mode.
4. Move the mouse until the fingertips are at the desired starting position.
5. Remove the shift key while continuing to hold the option key.
6. Click and drag to zoom in or out at the selection location.

It’s a little cumbersome, but it’s about 1000% more useful than not being able to do it at all.

It may go against the grain a little bit, but I’ll say it: I’m incredibly excited for the future of Mac software. I don’t expect we’ll make software that looks and feels like iOS apps (we shouldn’t), but I do expect we’ll learn from iOS apps how power is the real goal, and that flexibility is just a tool to use exceedingly sparingly, only when it substantially increases power.

I like, no … I LOVE the idea of learning from iOS apps, in order to build superb Mac apps.

As many of you know, I don’t believe the Mac is dead, and it should go without saying I don’t believe iPhone or iPad is dead.

We’re on the brink of an Apple-dominated consumer-electronics era, and we’re in charge of making the software good.

At the company’s I/O conference they announced Android 2.2, or “Froyo,” a significant update to their mobile phone OS. The open platform powers many of the iPhone’s most viable competitors, including the Verizon Droid, and Google’s own Nexus One.

Why is this good for the iPhone? Because it’s doomed without a proper competitor, and thus far, it’s been lacking one. What happens to fighters who nobody spars with? Regardless of size, skill, or strength of weapon, they end up flopping about the arena alone. Never defeated, but never victorious.

Apple came out swinging with the launch of iPhone in 2007, and has done an admirable job of shadowboxing: enhancing the device and expanding the platform with iPod touch and iPad. In the absence of serious competition Apple’s legendary paranoia has served some of the same function, but grit and independence of vision will only get you so far.

The details of Android 2.2 are not that interesting to me. What’s important and inspiring is that they are iterating on the product, and not throwing their arms up in defeat. Google lets us know they will not be sitting this round out, and their fighting posture sends a message to Apple, and to the world: the iPhone is assailable.

In order for Apple to benefit from this fight, they need to zero in on the qualities of Android that actually pose a threat. Sam Pullara attempted to give them a hand, by identifying Android 2.2′s lightning-fast Java VM as a potentially deadly blow. I think Sam is overstating the performance overhead in Objective-C. The language’s message-dispatch features have been so finely-tuned by Apple that any criticisms should come pre-loaded with proof of specific performance problems.

Even if we assume that Android’s fast VM does trump Objective-C for speed, is it meaningful to the competition? Duncan Davidson, an excellent photographer who happens to also be a legendary Java expert, says no:

“A faster VM will certainly help things out. But Android’s eventual fate will have little to do with how fast the VM is or how long method dispatches take on the iPhone. Instead, it’ll have to do with harder things like user experience, service plans, interoperability, and excellent applications.”

By most accounts, Android phones still fail to match iPhone when it comes to all those things that Apple does best: simplicity, attractiveness, and refinement of the user experience. But Google knows there is much about Android that pleases: more features, and fewer limitations. They’re using this allure to push the Nexus One on folks who would otherwise be naturally aligned with the iPhone.

The flow of free phones out of Google is measurable by the amount of surprising, casual-switcher chatter I’m seeing on Twitter and in blogs. I got one email from a colleague who announced, “I’m switching to a Nexus One for the week, so please use my Google Voice number to contact me.” If somebody is switching phone platforms, and they know in advance that it’s only a 1-week trial, there’s a good bet they didn’t pay for the phone.

The free-phone strategy is working, prompting fair feedback from folks who nonetheless find plenty of negatives to criticize. Justin Williams demonstrates this with his guarded praise:

“Android is certainly a capable smartphone operating system. In fact, if the iPhone never existed, it’d be pretty great.”

The fact that its greatness hinges on the iPhone not existing is a problem, but it also underscores that iPhone is the primary challenge to Android’s success. Even though Justin stops short of declaring Android a winner over iPhone, he concedes that he’ll probably keep using it until the 4G iPhone is released.

Mike Ash offers similarly candid feedback:

“First full day with the Nexus One. Verdict: substantially uglier, harder to use, but VASTLY more powerful than an iPhone.”

This impression from Mike fits perfectly into the marketing message from Google and its mobile allies. I barely watch any television, and even I know that evidently “Droid Does.” The world is more thuggish than frilly, more impressed by strength than finesse, and this message will work. Android is the gigantic, Dunkin Donuts Coffee Coolatta to Apple’s dainty espresso cup. Still, if you’re only going to offer a couple advantages over the iPhone, power and freedom are not poor choices.

As John Gruber points out, even if Android or another platform takes a dominant position, it doesn’t necessarily spell disaster for the iPhone. Apple’s advantage, as demonstrated by the Mac, is they don’t need to serve the masses to succeed:

“Apple could positively thrive with a long-term mobile market share of, say, 20-25 percent” … “In the phone industry today — all mobile phones, not just smartphones — Nokia sells more than 10 times as many units as Apple, but Apple generates more profit.”

Playing the underdog suits Apple well. I have enjoyed, as a fan and stockholder, their success over the past several years, but it’s changed them. From a company that balanced its own ideals against the demands of developers and competitors, to one that holds a firehose to repel all naysayers.

The risk to Apple is not in losing the masses, but in losing the faithful core. In their unchallenged position, Apple made a lot of right decisions, but they also made mistakes, particularly in the form of political moves that limit what developers can distribute on the platform. These restrictions are done in the name of quality control, but anybody who has browsed the App Store knows that all this autonomy has done little to stem the flow of trashy, embarrassing apps.

What they have done is alienated developers, and ultimately deprived users of software they want to see on the platform. My fear is these botched decisions are hurting Apple, but they aren’t feeling it. Pain is a gift: the signal that prevents a burned finger tip from becoming a body engulfed in flames. Apple is numb from success, and I hope the emerging competition from Google and others will re-sensitize them to the threat of failure.

Google’s Android is the best challenge yet to the political and technical decisions made by Apple for its iPhone and related products. I welcome the challenge, and look forward to Apple’s scrappier, revitalized retaliation.

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 object to Apple’s sometimes farcical behavior when it comes to App Store policies, rejections, exceptions, etc. But my feelings are extremely mixed. I love the hell out of my iPhone, and I pre-ordered an iPad at 8:30 AM on Friday. I believe Apple has a morsel of magical quicksilver in its palm. As with the iPhone, I’m coming along for the ride, whether or not I like the way they are driving.

The iPhone and iPad are compelling enough, so why haven’t I released any significant apps yet?  I still have several apps under development, but none of them is ready for mass consumption. Mainly because my Mac software takes priority for my attention, but also because I want to make sure I understand how software on touch devices should work before I tackle the problem.

I attended Apple’s iPhone Developer Tech Talk in New York in December. During the reception, I had the privilege of speaking briefly with Apple’s UI design rock-star evangelist, John Geleynse. I got to talking with him about the iPhone and its significance in the world:

“I’ve lost 20 pounds in the last 4 months,” I blurted out. “I don’t think I could have done it without the iPhone.”

I had downloaded an app called Lose It, and thanks to the ubiquity of the iPhone, I was able to use this simple calorie-counting aid to change my eating habits for several months. I was eager to share how this little app had changed my life. I struggled to make my point:

“The iPhone has changed everything. Surfers love waves, right? And they want to surf everywhere. But if you’re a surfer and you want to surf in Antarctica, you’re screwed. But if you had the right wetsuit, you could surf anywhere. You could surf in Antarctica!”

Mr. Geleynse indulged the metaphor, but seemed to be waiting for the punch line.

“So, I lost all this weight, and it wouldn’t have happened without the iPhone. Before the iPhone and before this app, losing weight to me was like surfing in Antarctica: I had no equipment, and no chance of survival.  The iPhone gave me the equipment not only to survive, but to know that survival was possible.”

This is what Apple does well. While the rest of the world iterates on existing solutions to known problems, Apple discovers and solves problems we didn’t even know we had. I didn’t realize that the lack of a ubiquitous, hand-held computer was limiting my abilities. I didn’t know what had been impossible would become possible.

Skeptics of Apple’s innovation tend to be stuck in that mode of thinking which judges solutions only in terms of known problems. Imagine the poor inventor of the scuba suit, who upon first showing his contraption to peers, may have been met with flat rejection: “It doesn’t look very comfortable.” True, the scuba makes for terrible evening wear … unless you’re throwing a party at the bottom of the ocean!

If you’re not looking beyond the horizon, if you don’t care to expand the reach of civilization, or to solve impossible problems, then you don’t need a scuba suit.

If you are looking for adventure, suit up. Antarctica on a surfboard? April 3.

The future of software is on the web. That’s what they keep telling me. I just smile, and say “I don’t think so. There will always be compelling technologies on the desktop.” I believe this, but I admit it carries an odor of blind loyalty to my comfort zone.

People who argue the other side have latched on to a few admittedly stunning aspects of the web, and they seem to believe that these charming characteristics alone ensure a course for long-term victory over all others. These attributes include:

• Cross-platform. You can run a web app on any computer that has a capable browser.
• Ubiquity. You don’t need to be near your computer to run a web app. You just “log in.”
• Instant updates. No need to coerce customers to update, just change the code on the server and they’re quietly updated to the latest running code.
• Open, standard technologies. You have control over and  access to most of the source code at the heart of your application.

Attractive indeed. If you imagine a world where the sum of all things you can do with a computer is exactly matched, and locked down for all time with what you can inside a browser, then the arguments for the web are persuasive. Why write for a specific platform when you can write for all platforms at once and gain the other advantages as well?

The error is in disregarding the many unmatchable attractions of “the desktop.” When I say desktop, I mean any platform that provides applications with more features than the standard web. iPhones are “the desktop.” As are Android, Palm Pre, Macs, PCs, and Linux. All offer features and functionality above and beyond what you can do on the web itself.

But the web can do a lot!, you cry, and point me to examples of ingenuity such as 280 Slides, the flagship proof-of-concept from 280 North’s impressive library for implementing web apps in a way that is reminiscent of programming in Objective-C. What these people are doing is mind-blowingly impressive, and if I decided to write a web app for some reason, I would probably use technologies like these.

But if I want to write a truly great app, it has to be a desktop app. And this will be true forever, or until there is no difference between the web and the desktop. I grant you, if the web becomes the desktop, something I find very unlikely, then the web will have in fact won by default.

Anything You Can Do…

Companies like 280 North are investing years of engineering time into a necessary pre-requisite for web-app domination: bringing the web’s capabilities up to approximately what the desktop offers. I quipped on Core Intuition that “Web 2009 = Windows 95″. It’s a play on an old bumper-sticker from Apple, that poked fun at Windows for finally having “caught up” to Macintosh’s 1989 feature set, in 1995. The amount of work done over the past few years on web app technologies is staggering, but when you take a step back, they celebrate victories over things we have taken for granted for years on the desktop. Things like drag and drop and animation are at least possible on the web. Other niceties such as inter-application scriptability would require a total overhaul of how web browsers behave.

The problem with the game of catch-up, is you only ever win if your target is moving slower than you are, or better yet if they stop completely. All desktop platforms are innovating to offer developers greater and greater capabilities that peer into the future of what your high-powered CPUs, GPUs, and peripheral hardware makes possible. Meanwhile, most web platforms are just trying to catch up.

And catching up is hard for many reasons, not least of which that they have no idea where the desktop is going. None of us do, and Apple’s announcement yesterday of the iPad is a great example of this. The goal of a “vaguely Mac/PC-like application interaction environment on the web” is thrown a curveball when desktop vendors such as Apple are constantly picking up the goal, brushing it off, and setting down again on a completely different path you’ll have to now forge a trail to.

It’s an unfair fight. We know exactly what the web can do, and we have a good idea of what it plans to do, thanks to its (laudable) open standards. But none of us has any idea what the next iPad, iPhone, Wii, Xbox, TomTom, whatever, will do. Don’t get me wrong: the web is excellent at innovating, but it innovates primarily for publishing and social interaction. It doesn’t innovate on desktop UI or device integration, the very areas where brilliant desktop applications shine. And it does innovate, as I have already suggested, in the art of catching up.

Anything you can run in a web browser can also run inside a desktop app, thanks to the modular embedding capabilities of WebKit on the Mac and Internet Explorer on the PC. However, it should be obvious that the inverse is not true. When something truly innovating and mind-blowing happens on the web, I can drop it into a WebView on my Mac and make it a part of my desktop experience. When something mind-blowing happens on the desktop, you can bet you’ll have people scurrying to painstakingly imitate it on the web. It takes a lot of work, and a lot of time, and sometimes it’s not precisely even possible. But eventually they will come up with something reasonably close.

I imagine in 5 or 10 years the web will have caught up to something resembling how desktops behave today. But I can’t even begin to imagine what we’ll have at our fingertips on the desktop, by then. iPad? We ain’t seen nothing yet.

Inside view of the iPhone Tech Talks from Daniel Jalkut

Thanks to Mike Rose for approaching me about writing this up!

(Edit 8/6/2009: Since I wrote this article, John Gruber received a response from Apple’s Phil Schiller. He paints a slightly different picture of the alleged censoring, and defends Apple’s intentions as being noble. I still maintain my theory below helps explains the capriciousness of AppStore review policies.)

John Gruber excoriates Apple for censoring a reference book. Gruber also discovered through an interview with a Ninjawords developer that Apple must have gone out of its way to locate words they could find fault with. Apparently the developers had been careful to prevent casual users from stumbling upon an offensive word, by preventing auto-completion for common vulgarities:

“In other words, the App Store reviewer(s) explicitly searched for curse words they already knew, and found them.”

I’ve been thinking about the capriciousness of the App Store review process. It’s ridiculous the kinds of rejections and hoop-jumping we’ve observed in the past year, and one has to assume that the issues making their way into the public eye are only the tip of the iceberg.

Then I remembered something from my own experience that might shed light on the situation. I started as a Quality Assurance tester back in 1995, in a small engineering group. Our group was diligent in the pursuit of finding issues that would embarrass the company or hurt customers. But we worked with larger groups whose motives seemed more oriented to the systematic evaluation they were receiving from their bosses.

These testers didn’t care how good their bug reports were. It didn’t matter if the software gaffe they discovered would save the company a million dollars, or a metric shit-ton of public grief. All that mattered was that the bug was “valid” and that the reporter was “first.”

I learned about the subtleties of this system through the ways that those testers interacted with me. Sometimes a bug that I submitted was determined to be a duplicate of an earlier report one of these testers submitted. If mine had more detailed information, it might be marked as the “original” bug, while the less informative bug was designated a duplicate. This worked great for those of us trying to ship a great product, but not so good for people who were fighting for their reputations in the metric-oriented testing groups.

Because our group was committed to shipping a great product, we were always convinced that bug reports with more information were superior. But the testers who were under the gun to produce new, unique issues, wanted credit for having uncovered these issues first.

As you can imagine, the “thirst for first” led to a significant number of ridiculous bug reports. If a tester could reasonably defend a bug report as valid, then it counted in their statistics, and made them look like a useful member of their team. My impression was that promotions and raises were directly linked to these statistics.

Many of the mercenary testers I encountered were motivated to scrape the system for bugs, as ridiculous as they may be. They logged them into the bug system and then defended them at all costs, as if their lives depended on it. And it turned out, they did. At least, their paychecks did.

I would not be surprised to learn that App Store reviewers are working under a similar structure. A system that rewards “unique, valid rejections” would certainly explain the behavior we have seen coming to light in the past year.

Why would somebody waste time typing profane words into a dictionary, gathering screen captures, and sending them to developers, except to defend their prize “catch”? If perfecting the product was the goal, we’d see a lot more nuance and thoughtfulness. But excellence is one goal, and collecting proof of “doing one’s job” is quite another. I think I know what many App Store reviewers aspire to.

Afterhought: It occurred to me shortly after publishing the above that App Store reviewers can’t be working purely under a “catch all violations” directive, because if they were, there would be numerous rejections based on UI guideline violations, and we’re not seeing as many of those (or are we?). I’m sticking to my thesis, but I suspect that the number of rejections we’re seeing on contrived issues like “you can find ‘cock’ in the dictionary” is because these are the easiest for reviewers to defend with Apple’s published guidelines. Whether a text field is aligned properly is a lot harder to challenge than whether “cock” can be interpreted as profanity.

I have opinions about product pricing, and have not hesitated to share them in the past. I have mostly stayed quiet about iPhone application pricing, but for some reason I now feel compelled to add my voice to the choir:

iPhone applications are too cheap, and changes are needed to encourage the development of premium applications that sell for a fair price.

In particular, I agree with Craig Hockenberry, who suggests that the complexity and ultimately the greatness of applications is limited if Apple encourages bargain-basement prices across the board.

But what happens when we start talking about bigger projects: something that takes 6 or even 9 man months? That’s either $150K or $225K in development costs with a break even at 215K or 322K units. Unless you have a white hot title, selling 10-15K units a day for a few weeks isn’t going to happen. There’s too much risk.

I also agree with much of what Paul Kafasis, who has been writing regularly for the O’Reilly Inside iPhone blog, has to say on the subject. In today’s article, The App Store Effect, he compares the pricing environment of the App Store to Wal-Mart, where premium products are difficult to sell because low price is overwhelmingly the most important feature of any product.

Walmart sells customers disposable goods at the cheapest possible price. At the time, Wal-Mart had six different push mowers for less than $200, while the cheapest Snapper listed for $350. These low prices change expectations across the board, and leave customers wondering what they could possibly be getting with a Snapper to justify the much higher price.

The problem in a nutshell is that it’s difficult to develop a complex, premium application that earns enough to pay back its development costs and provide developers a decent living. The more 99-cent applications there are in the App Store, and the more Apple promotes and rewards 99-cent pricing, the harder it becomes to develop a product that will stand out and can be marketed at a sustainable price.

I’m Not Whining

I have watched as colleagues who scrutinize the situation have been dismissed by some commenters as “whiners.” So let me head that off right now: I’m not whining. I recognize the incredible opportunities the iPhone brings both to developers and to customers. The iPhone is great. Apple is great. Customers are great. Developers are great. We’re all great. Let’s make some great products, and let’s make some money.

I’m not looking for pity or for artificially inflated prices, and I don’t believe Paul Kafasis or Craig Hockenberry is, either. I’m just trying to call things as they are. Attempting to understand the App Store, and how customers relate to it, is the first step in speculating about what tweaks might be made to improve the situation for everybody.

Many Ideal Solutions

There is no simple solution to these pricing problems, but I think this is a good thing. Instead of focusing on a single solution, it’s both more practical and less daunting to focus on an ideal outcome. To me, that would be an economy where iPhone applications of all price levels can be freely and fairly evaluated by customers, ranked and reviewed for the benefit of others, and marketed collaboratively by Apple and developers so that the maximum number of interested customers is exposed to any particular app.

Any single solution that makes progress towards this is one of the ideal solutions. So this should be a piece of cake, right?

To Apple’s credit, some of the worst shortcomings of the App Store have been eliminated over the past several months. They have improved the reviews and ranking systems, making it harder for shoddy products to rise to the top, or for excellent ones to be pushed to the bottom. But many shortcomings still exist which are an unfair burden on premium applications.

There are steps that any of us can take to help to bring about the ideal outcome. I’m going to list some specific changes that I think Apple, developers, and customers should make in order to improve the health of the iPhone economy. These ideas are unoriginal, and you’ve probably heard them elsewhere, but I think they are important, and I agree with them.

Apple Should: Level the App Store playing field.

Three major changes would help a great deal:

1. Facilitate trial versions of all paid applications in the App Store. The higher the price of an application, the harder it becomes for customers to have faith that the purchase will truly be of value to them. Trial installations would give customers the opportunity to verify that a premium application is well worth its price.
2. Guarantee and promote a full refund policy. A reputable business of any size operates on the premise that customers will be satisfied with what they have paid for. It’s unseemly for Apple to operate the App Store division of their business as one in which customers have no recourse for having been sold a product that does not meet their expectations.
3. Establish a rating system that rewards premium applications. With the proliferation of 99-cent “ringtone apps” as Craig Hockenberry calls them, it’s becoming increasingly difficult for customers to learn about premium applications. Helping to connect customers with developers who have solved complex problems would benefit all parties.

Developers Should: Resist the temptation to price products dishonestly.

Artificially low prices are often a form of bait and switch, luring customers in who you will not be able to support for the long term. On the other hand, some developers might react to the uneven exposure that premium applications receive by charging a higher price to those customers who need and seek out their product. This alienates customers and leads to an overall perception that software is too expensive.

The best thing you can do for customers is to charge a fair price that sustains your business, and pays for the cost of ongoing development.

Customers Should: Make an effort to take a balanced view of the price to reward ratio for applications you discover in the App Store.

In the “Wal-Mart” environment, among the 99-cent masses, it can be tempting to jump to the popular conclusion that an application is “too expensive.” But you know darned well that $10, $20, or even $50 is a fair price for any product that dramatically improves your life.

When you discover amazing premium applications, don’t be afraid to spread the word. Shout it from the rooftops that you paid $10 and that it was worth every penny. Your activism in helping to promote one premium app is what will make the next premium app possible.

I Should: Put a lid on this blog entry and get back to writing software. Thanks for reading. Here’s to a thriving iPhone software economy in 2009!

Update 12/27/2008: Brent Simmons keyed into the “free market” arguments that are coming up in comments both here and in other venues. I think he sums up the counter-argument well:

It’s still not a free market. It’s a market that has a certain shape (with hot-lists but no demo versions), and that shape rewards very cheap apps over higher-quality, more expensive apps. It’s a guided market.

Exactly.

I definitely do not think that sheer numbers are the story of the iPhone’s future, but if it makes some suits feel better about the device, then I’ll join in the cheers. 10,000 individual products for sale or free download definitely indicates a high degree of interest.

The guys at Tap Tap Tap have taken the opportunity to put together a remarkable poster-sized graphic of the icons from these 10,000 apps, arranged so as to look like a photo of an iPhone:

I think this was a really cool idea, even with a dubious point of celebration. For many of these apps, their presence in this poster is the most attractive they’ll ever be.