Marco.org

From Benjamin Stein’s great post about geek-tech pioneering that you should read right now, before continuing:

In those days, it was really easy to see where consumer technology was going. You could just look at the nerds and know that’s what you’d probably look like in 2-5 years.

[…]

But then something strange happened. Lots of people switched to Apple laptops. But the nerds didn’t move on. My nerdiest programmer friends use the same computer as my wife.

[…]

So my question is, why haven’t the nerds moved on? Where are all the alpha geeks and what are they doing? I look around and I don’t see them anywhere.

It’s a great question.

Part of my own transition was what I called grown-up computing five years ago, after a year of “adult” life:

Grown-up computing is, put simply, the way I use computers and my attitude toward them now that I’m out of college and settling into the 9-to-5 world. It differs greatly from “young computing”.

[…]

The last thing I want to do is figure out why some program isn’t working or reinstall my operating system. I see these as zero-gain activities: generally, I learn nothing new, I don’t enjoy myself, I’m not being entertained or enriched, and my effort only results in maintaining the status quo.

I’d rather get a computer that didn’t require any maintenance and simply allowed me to do productive work. I’d like to have something to show for all of my clicking and typing instead of simply making information balloons go away. I’d rather write an article for this site than type my serial number again. I’d rather search the internet for interesting or entertaining information to read instead of looking for the solution to an obscure problem for which I only have a useless generic error message. I just want things to work.

It’s likely that most geeks that Ben and I know are in or near our age group, and are probably “computing adults” in a similar sense: they’d rather use computers and related technology to accomplish a goal greater than just messing around with their computers.

But what if this effect, on a larger and less age-specific scale, is the bigger trend that Ben’s seeing?

What if most geeks today really are just buying Macs instead of building their own overclocked Windows PCs from Newegg parts?

What if PC gaming really is on a decline because only a very small slice of the population is willing to pay $500 for a giant, hot, loud video card and endure the Great PC Gaming Pain-in-the-Ass Trifecta of drivers, patches, and copy protection, leaving almost every gamer to just stick with game consoles for a fraction of the cost and hassle?

And what if a big slice of even the most hardcore geeks have abandoned their netbooks for iPads because they just work so much better most of the time?

Even geeks (like us) have their limits of reasonability. At some point, we often decide that what we’ve been doing or what we think we should enjoy just isn’t worthwhile.

Ever build a carputer? (Yeah, that’s a computer in your car.) I attempted it when I was 18: it was a bunch of old PC parts inside a Dremeled-out Rubbermaid tub with a gamepad next to my parking brake to control Winamp so I could play MP3s. It was ridiculous. I had to wait until my carputer booted Windows 98 before it could play music. Even I couldn’t take this thing seriously. It lasted about 3 days until I drove over a speed bump and the CPU fell out of the slot. I scrapped it and just bought an MP3-CD player (the second one ever released) instead.

More recently, I even stopped using my geeky pfSense router when I moved to this apartment because I wanted 802.11n support and WDS, and the AirPort Extreme Base Station was just easier than trying to wedge those things into my geeky alternative. And it happens that the AirPort Extreme is actually much nicer, because it Just Works™ with new crazy things like WDS and UPnP and Xbox Live and MobileMe, and I never need to think about it.

Aging technologies fall out of favor even among geeks. Even excellent programmers avoid writing assembly code because they know that it’s almost never worth doing. Nobody’s using those Linux phones (did they ever?). PC self-builders rarely mess with Creative’s dumb sound cards anymore because every motherboard’s onboard sound has been good enough since 2001. I don’t think anyone really uses water-cooling anymore, and I bet the [H]ard|OCP Forums peaked in popularity a while ago.

We may just be past the era in which many geeks were interested in messing around with their computer’s (or phone’s) hardware or software internals.

And as many major technologies and platforms become dominant, we stop tinkering at those levels. We’re all happily using Ethernet and TCP/IP instead of trying to invent new protocols at those layers. Nobody’s writing a PC OS from scratch in this decade. Nobody’s even writing their own web search engine anymore. It wouldn’t surprise me if we’ve seen the last new social-network giant for the next decade.

What if we’re also settled on the current handful dominant OSes, mobile platforms, and hardware manufacturers?

I’d argue that, if that’s the case, we’re better off. That was an interesting time, but it’s time to move up the stack and mess around at higher levels.

xkcd: Online Communities 2

I’m so proud that, after having the prior edition hanging on the wall at Tumblr for three years, Tumblr itself has become big enough to have its own island in the map (near the northwest corner of the Sea of Opinions).

I hope that Instapaper is on the map by 2013, possibly as a ferry route across the mouth of the Bay of Flame (in the Blogosphere core region).

My great photo from Deluxe Tilt-Shift Generator ProMatic Filter Plus for iPhone.

(previously)

I’m usually Tiff’s second shooter when she photographs weddings. She was shooting lineups with both big cameras when I saw this opportunity, but my iPhone filled in nicely.

My iOS app, Instapaper, relies on the installation of a Javascript bookmarklet to be effective, because it needs a way for users to easily send URLs from Mobile Safari to Instapaper.

Many other iOS apps have similar needs:

• Blogging and publishing apps can accept URLs that users want to include in a post.
• Social networking, instant messaging, and Twitter apps can accept URLs that users want to share or send to friends.
• Task-management apps can accept URLs to be used for new tasks.
• Note-taking apps can accept URLs to include in notes or save as references.
• News readers can accept URLs for new feed subscriptions.
• Bookmarking apps can accept URLs to save for archival or search.
• File-management apps can accept URLs to download.

There are only three ways to send URLs from Mobile Safari to apps today:

• Copy the URL to the pasteboard, then launch the app and either have it auto-detect or have the user Paste it in. But this is complex, especially since there’s no Copy button anywhere in Mobile Safari except the standard handling while editing the URL field, so most users won’t do this.
• Mail the link to a special email address. This works, but is tedious for users, and requires both a special email address to be installed in the user’s Contacts and a corresponding web service to receive the email and synchronize with the app on next launch.
• Use a Javascript bookmarklet to launch the app with a local URL scheme or send it to a corresponding web service.

Instapaper supports all three, but very few people use the first two. Customers prefer the workflow that the bookmarklet offers.

Most Instapaper customers install the bookmarklet directly in Mobile Safari. The process of doing this is extremely complex and user-hostile, and a large percentage of them abandon the process and are extremely dissatisfied with Safari, my app, and me as a result. I get emails like this almost every day:

(And this was one of the nicer ones.)

The current procedure:

1. Send the user to a placeholder web page, with the Javascript code in a textarea. The user must Select All of the text in it and Copy it.
2. The user must Add Bookmark for that page, then tap Done.
3. The user must then open their Bookmarks, locate the newly created placeholder bookmark, tap Edit, and tap the bookmark (but not in the “delete” or “move” accessory areas) to select it for editing.
4. The user must tap the Address line (which is not labeled as such when it is populated), tap the X “clear-contents” accessory, tap again in the Address line to invoke the pasteboard menu, then tap Paste.
5. The user must tap Done to dismiss the editing sheet, then tap Done again to leave the Bookmarks editing mode, and then tap Done a third time to dismiss the Bookmarks sheet.

Needless to say, this is extremely error-prone and tedious, and even skilled users often miss a step.

Proposed solutions that make bookmarklets unnecessary

The best way to solve this problem is to eliminate the need for hacky bookmarklets entirely:

• Add a proper registry of apps that can accept URLs from Safari, recognized by an Info.plist key, and add a “Share” or “Send To” panel to Safari that allows users to easily send the current page’s URL to any capable apps.

But I recognize that such a system would require major changes and is unlikely to ever be high-profile enough to be implemented in iOS. Other potential solutions would still be incredibly helpful:

• Add a public iOS API method for apps to prompt users to add a bookmark to Mobile Safari, e.g. in UIApplication:
  - (void)addSafariBookmarkWithURL:(NSURL *)url title:(NSString *)title
• Alternately, add a Safari-handled URL scheme that apps can invoke to prompt users to add a bookmark, e.g.:
  safari:///addBookmark?url=___&title=___

In both cases, the user would be prompted by the OS and given an opportunity to decline.

These require changes to the public iOS APIs, so I recognize that they’re still less likely to be implemented than simpler fixes. So here are some alternatives that I assume are even simpler and therefore more likely to be implemented:

Proposed solutions, still using bookmarklets

Installing bookmarklets could be dramatically improved with any of these simple changes:

• Implement a Javascript method or URL scheme to prompt the user to add a bookmark with an arbitrary URL, specified in the code, like the old IE window.external.AddFavorite(url, title) method. If a web page could call such a method to bookmark an arbitrary javascript: URL, this entire process can be avoided.
• Alternately, allowing window.location.href to be set to a javascript: URL, and then having that be the logical URL added when someone taps Add Bookmark, could eliminate almost the entire complex procedure. (Today, doing this just executes the Javascript but doesn’t change the current page’s URL for bookmarking.)
• A less-desirable (but still helpful) alternative would be to make the Address field editable in the Add Bookmark sheet for new, unsaved bookmarks. Currently, it’s only editable on edits of existing bookmarks, necessitating many extra steps in this process.

Again, any of these would be a huge help.

Developers: We need your help

Apple prioritizes API changes and new features in part by how many developers have filed bug reports requesting them. It’s an unofficial voting channel for SDK changes.

If any of these changes could benefit your apps, please file your own bugs asking for them. You can do that here. Copy sections of my text if you want to, or write your own.

Thank you for casting your vote for Apple to make this a priority for a future release.

Apple: Thank you

Thank you to anyone at Apple who has read this, regardless of whether you’re on the team that can implement any of these proposals.

Relevant reports so far:

• rdar://8534665 (my most recent filing with this post)
• rdar://7636942
• rdar://6589436
• rdar://5935641
• A related bug that limits bookmarklet usability: the user’s text selection is lost when selecting bookmarks (thanks, Agile Tortoise)
  • rdar://8562369
  • rdar://7013257

Whenever I’ve brought this up in the labs at WWDC, every Apple employee recognizes how terrible the status quo is, but I still haven’t managed to campaign enough or to the right people to get it done.

I’ve been told repeatedly by Apple employees to keep filing bugs, even if they duplicate bugs that I’ve filed in the past. So I’m going to keep bringing this up and campaigning in the WWDC labs every year until it’s improved.

Thank you for your time and consideration.

It’s pretty hard to teach a kid who has been raised by the television, when he hasn’t eaten breakfast, when the family has been kicked out of their home, when he has to work a job to help feed the siblings, when the parents have just gotten divorced or lost both of their jobs, when no-one at home speaks English, or when their most alluring role models are dope dealers, pimps, or gangsta rappers. Imagine, then, trying to teach a room full of such trauma cases. […] If you want better schools, work for more stable incomes, families and neighborhoods.

— Robert Freeman (via AZspot), addressing the biggest problem our modern educational system faces: not bad teachers or bad schools, but the downward spiral of poverty and the decimation of the middle class.

It’s okay to be driven a little crazy by someone who is so consistently right.

— John Sculley on the frustrations of working with Steve Jobs’ perfectionism.

The new MacBook Air was released today, and it’s a hell of an upgrade. It got much better and it’s at an extremely compelling price.

It’s a great computer, but it’s not for everyone. It’s like a two-seater car. Read on if you think it might be for you.

The Air’s limitations

I previously owned an Air as my only laptop (but not my only computer). Its size and weight made carrying and traveling with it a pleasure, but after a while, its hardware was too limiting and I had to upgrade to a 15” MacBook Pro.

What got in my way the most that’s now alleviated:

• The screen resolution was cramped for doing development work or nontrivial multitasking.
• The hard drive was so slow that overall system performance was abysmal, especially with only 2 GB of RAM.
• There was only one USB port. You’d be amazed how often this limitation gets in your way.
• The 1.6 GHz CPU was so slow that basic operations we take for granted these days — especially stutter-free video playback, and especially when it’s Flash — wouldn’t be practical or reliable. (This has been improved in the new ones, but I don’t yet know by how much.)

What got in my way most that’s still true with the new Air:

• There’s no optical drive. You might say that you’d never need it, but in practice, I found myself needing it a few times: burning a disc for someone while I was on vacation, or reading a disc I was given (like the Snow Leopard beta at WWDC ‘09).
• There’s no wired Ethernet. (And the $29 USB Ethernet Adapter is only 10/100.) I’d often want to transfer a bunch of movies or other large files onto it before a trip, and it would take forever over Wi-Fi.
• The battery life, while not terrible, isn’t as good as a 13” or 15” MacBook Pro.
• There’s no FireWire, which means no fast external hard drives and no target disk mode. I didn’t need it often, but I really missed it when I did.

Noteworthy changes from the first Air

It has a few huge improvements:

• Much higher resolution: 1440x900, up from 1280x800. This brings it from the 13” class to the 15” class¹. I’ve always wanted a light 13” notebook with a 15”-class screen resolution, and Apple just released one.
• SSDs² only. The old Air base-model’s 1.8” hard drives were unbearably slow. SSDs have always been the only sensible option for the Air, and it’s nice that they’re now the only option.
• Two USB ports instead of one. This matters more than you’d think.
• An SD-card reader (13” only). Useful if you often needed that USB port for a card reader, although this isn’t a great photo-management computer.
• Ports that are perpendicular to the desk and aren’t behind a flip-down door. So you can probably use any square-ended MagSafe adapter you already own to charge it without hanging the corner off the desk like with the old MacBook Air.

And one minor downgrade:

• The keyboard is no longer backlit.

One thing that fortunately hasn’t changed: the screen still has the original-MacBook-style plastic-glossy finish with the metal bezel, not the far more reflective glass over a black bezel as seen on the MacBook Pro.

In addition to the annoyance of the extreme reflectivity, the Pro’s glass is very heavy and requires a thicker lid. The Air can’t afford the weight or thickness, so it gets the much more reasonable (and much less reflective) plastic-glossy.

It certainly raises the question of why any Apple laptops — which can’t afford excess weight, thickness, or versatility-limiting factors like reflectivity — have glass screens at all, when most of the benefits (color, contrast) are just as effective with the much more practical plastic-glossy screen.

Maybe there’s hope of losing the glass on the next MacBook Pro.³ But I wouldn’t hold my breath.

11” or 13” Air?

The 11” looks impressively tiny, but realistically, most people are unlikely to see significant benefits in portability or practicality from the 11” over the 13”. There are very few situations in which you’d be able to comfortably carry or use the 11” but not the 13”.

The 11” screen resolution of 1366x768 is great for its size, but it’s going to be very cramped, especially vertically. Screen size is very important and noticeable in everyday use, and it’s often the limiting factor for how much work advanced users can comfortably get done on a laptop.

The 11” is also significantly slower and with less battery life, and lacks the SD-card slot, although these are less important factors.

So, tentatively (I still haven’t seen these in real life), I wouldn’t recommend the 11” for most people.

John Gruber makes an excellent point in response:

I think what he’s missing about the smaller 11.6-inch model is that it might appeal to frequent air travelers (and anyone else who works in a cramped space).

Subjectively, I used the old 13” Air on some plane rides, and the 15” MacBook Pro on some others, and they both require you to adapt a fairly uncomfortable screen angle if the person in front of you leans their seat all the way back. (As my own quiet form of social environmentalism, I never do that.)

The 11” looks like its lid is shorter by enough to be a significant benefit for this particular use. So if your primary use for the laptop is to be used in coach on airplanes, the 11” is a better bet. But in nearly all other cases, I imagine the 13” will be much more useful.

13” Air or 13” MacBook Pro?

Before today, Apple effectively offered three sensible laptop choices:

• Low-cost: the 13” MacBook Pro
• Ultralight: the Air
• Workhorse: the 15” MacBook Pro

The new Air comes close to merging the low-cost and ultralight categories. But it doesn’t quite make it.

Compared to the new 13” Air, the 13” MacBook Pro is 50% heavier (more if you include the two laptops’ respective power bricks), a lot thicker on the wrist edge, a lot more expensive when equipped with an SSD of the same size, and with a much lower screen resolution behind a highly reflective, glass-only screen.

But the MacBook Pro has better battery life, a CD/DVD drive, much faster CPUs, a higher RAM ceiling, Firewire 800, Gigabit Ethernet, and options for much larger (but much slower) hard drives — and if a RAM stick or hard drive dies or needs to be upgraded, you can replace it cheaply and easily, even if it’s out of warranty.

And, critically for many, the Pro is versatile, fast, and expandable enough to be your only computer. The Air probably isn’t.

If the application you use most frequently begins with “Adobe” or costs more than $100, you probably won’t be well-served by an Air. (And you should probably skip the 13” class entirely and look at the 15” MacBook Pro with the high-resolution screen upgrade.)

So if you already have another Mac as your primary computer, especially if it’s an iMac or Mac Pro, and you want an ultralight laptop for travel, the new Air is probably a great secondary computer, as long as what you’d need it to do won’t be hindered too much by the hardware limitations.

Air or iPad?

If forced to choose between bringing an Air and an iPad on a trip, to a meeting, on a train, on a plane, or pretty much anywhere, I’d choose the Air. (Even the 11”.)

Most of what I do on computing devices either can’t be done or would take much longer on an iPad, and I’m impatient and demanding with my hardware.

If you can say the same about yourself, an iPad probably won’t replace a laptop for you.

OK, I want a 13” Air. Which configuration?

The base 13” model at $1299 is compelling.

For all configurations, I highly suggest the 4 GB built-to-order RAM option for the extra $100. You can’t upgrade the RAM later. It’s permanently mounted, like the first Air. The original Air’s 2 GB RAM limit significantly impeded its performance, and even with SSDs, you’ll notice performance issues when you hit that wall.

The highest-priced configuration, the 13” at $1599 with a 256 GB SSD, is a big jump: it’s an extra $300 for only 128 GB more storage. Notably, though, it’s the only configuration that has a 2.13 GHz CPU option (up from 1.86 GHz) for an extra $100. It seems nice to get the extra CPU power, but realistically, anyone who would notice the speed difference probably wouldn’t be well-served even by a 2.13 GHz CPU and should probably get a MacBook Pro instead.

Storage is obviously the biggest difference between the $1299 and $1599 models (if you ignore the CPU option, it’s the only difference). $300 is a lot for an extra 128 GB of space, and if you really need the space, 256 GB probably isn’t enough, either. But you probably can’t upgrade this later, either.

If the money’s less important to you, a maxed-out Air is only $1799. And if you don’t need the extra space or speed, the 13” base model with the 4 GB upgrade for $1399 is a great deal.

Like the Ministry of Truth, it appears that Apple is deliberately attempting to usurp the meaning of the word Flash in the computing industry and redefine it.

— Jeff Rock makes a great point

The Nook Color is ingenius.

Not because a backlit LCD screen is better for reading than e-ink — it isn’t.

And not because the Kindle’s grayscale screen is often a problem for what most people read — it isn’t.

But because anyone comparison-shopping between the Nook and the Kindle, who has never owned either, will assume that color is better and choose the Nook, putting Amazon in the unenviable position of trying to explain why their screen is better to people who probably haven’t seen one in real life.

Fortunately for Amazon, there aren’t likely to be many people who actually see both devices and comparison-shop, since there probably isn’t a lot of overlap between the two retailers’ respective customers. And those who do see both aren’t likely to appreciate the Nook Color’s $249 price over the Kindle’s $139.

To give B&N credit, though, they did solve a significant usability issue from the original Nook: on the Color, the two screen types won’t be confusingly competing for your attention and touches. (The case-strap issue persists.)

One of the surprisingly useful sessions from WWDC 2010 was #138: API Design for Cocoa and Cocoa Touch.

The title wasn’t a very good expression of its content. It’s more fairly (albeit verbosely) titled, “Conventions, naming styles, and structural guidelines that Apple has used for the Cocoa APIs, and how and why you should adopt them.”

Some tips included, from my notes:

• Name all of the arguments to reduce readers’ trips to the documentation. Consider removeObjectAtIndex:: You know exactly what the parameter should be.
• Don’t abbreviate unless it’s a very common abbreviation.
  • Good: PDF, URL, Max, Min.
  • Bad: Str, Fmt, Dat.
• Don’t prefix method names with “do”, “compute”, etc.
• Getters shouldn’t be prefixed with “get”, with two exceptions:
  • Use “get” on accessors that return values by reference, e.g. NSData’s getBytes.
  • Prefix BOOL getters with “is”, e.g. isEditable. Shortcut: @property (getter=isEditable) BOOL editable;
• Avoid names with ambiguous meanings or parts of speech, e.g.: displayName, center.

• Exceptions in Cocoa are meant to indicate programming errors, not expected operating conditions. (Like assertions.)

  Exceptions are typically not meant to be caught. They’re not supposed to ever fire in a shipping app.

Apple’s developers have made their style and API design decisions with far more time, wisdom, and experience than any individual developer is likely to have. There will always be exceptions to conventions in real-world use, but when you can more fully appreciate why those conventions are in place, you can more responsibly choose when to break from them.

This was one of the sessions that has had the most lasting value for me,¹ but I attended it by chance: there was nothing else pertinent to me during that hour, so I ducked into this one, thinking it was about entirely different matter. I’m glad I did.

If you’re a registered iPhone developer, get it: go here (you’ll need to log in), follow one of those iTunes links, select the “Application Frameworks” category, and download Session 138.

AnandTech calls the new MacBook Air’s SSD “Not Half Bad”:

Overall I’m pleased with Apple’s SSD selection. It could’ve been a lot better but it could’ve been a lot worse. The MacBook Airs in their default configuration have better IO performance than any other standard config Mac sold on the market today, including the Mac Pro.

This is much better than I expected.

There’s a big difference in performance between various SSDs. The worst ones can actually be slower than hard drives in some important operations, so you need to be careful when selecting one. Apple’s SSD offerings, to date, have been average (the optional SSDs in the MacBook Pro, iMac, and Mac Pro) to poor (the original MacBook Air’s SSD).

I had low hopes for the new Air’s Apple-branded, Toshiba-controlled SSD, but it’s actually pretty decent — and compared to SSDs used by Apple in the past, it’s great. It’s nowhere near an Intel or SandForce SSD (hey), but it’s still much faster than hard drives and most “bad” SSDs.

A lot of customers and tech review sites put too much emphasis on the sequential read and write speeds, but the differences in these benchmarks between various SSDs have little impact for most people. The most important benchmark for real-world SSD performance in most usage is the 4KB Random Read test:

As you can see, standard hard drives perform so poorly in this benchmark — the most common operation that most people need their hard drives to do — that it’s no wonder that SSDs feel so much faster than hard drives. It’s not even close.

Most good reviews of the new Air have published only whole-system benchmarks and declared it faster than most shipping Apple laptops. I initially thought this was unfair because the other laptops weren’t tested with SSDs, and having an SSD is really what’s responsible for most of the new Air’s performance in these tests.

But the SSD options on the others are so expensive that most people won’t get them, so if the goal was to show real-world results, and the Air is the only laptop in the lineup likely to have an SSD in the real world, I guess such tests were accurate.

Apple’s recently announced App Store for the Mac is a Really Big Deal™, for reasons I’ll get to in a moment. But a lot of existing Mac developers have pointed out major issues or unknowns that need to be addressed:

• Will App Store apps be required to be sold exclusively in the App Store? (My guess: No.)
  • If so, how different would another “edition” of the app need to be for Apple to consider it a separate app and permissible to be sold elsewhere? (The vagary of this is why I guessed “No” to exclusivity.)
  • If not, will a publisher be allowed to charge a different prices in other places? Could they, for instance, charge 20% less on their websites so they’d attract savvy buyers to get it directly and still make more money since Apple’s taking 30%? (My guess: Yes.)
• The prohibition on private API usage will keep a lot of popular Mac apps out of the Store. Are they serious about that? (My guess: Yes.)
• Will there be any good way for developers to get customer lists from App Store buyers? (My guess: No.)
• Will there be any good ways to “crossgrade” buyers from the retail edition of an app to the App Store edition without making them pay again in full? (My guess: No.)
• Will time-limited trials be permitted? (My guess: No.)
• Will upgrade pricing for new versions be implemented? (My guess: No.)
• Will refunds be any easier? (My guess: No.)

Since almost all of these are likely to be inconvenient at best (and often dealbreakers) for current Mac developers, it’s easy to miss the likely intention and likely effects of this.

The likely intention

I’m guessing this is what Apple has in mind. If not, this is at least what I think is likely to happen:

Actually, the scale’s off.

This is the much more likely outcome:

…for a few reasons.

Apps as entertainment

In high school, my friends and I went to the movie theater almost every weekend, usually not even knowing what was playing, and decided how to spend our $5-10 when we got there. We knew it would buy us a few hours of entertainment, and we knew that most of the movies would be mediocre, a few would be horrible, and a few would be great. The predictability and low cost of these outings gave us a reliable way to be entertained on a regular basis.

One of the reasons the iOS App Store is so successful is that app-buying has become a form of casual, routine entertainment for iPhone and iPad owners. We gladly go and browse the App Store even when we don’t “need” anything at the moment, with the intention of going and spending a few bucks on whatever’s new that looks good.

This requires a few conditions to be ideal, all of which are true on the iOS App Store:

• There must be a large number of new apps being regularly added, and they must be easy to find and browse.
• Apps must be low-risk. That means:
  • Inexpensive.
  • Trustworthy that they won’t do anything creepy or destructive.
  • Easy and quick to purchase and install.
  • Easy and quick to delete.
• Enough apps should be good that people will remember the good ones and forget the bad.

Today, on the Mac, almost none of these are true. And if the Mac App Store is only populated by a subset of today’s Mac software, a few key points (such as “Inexpensive”) still won’t be true. This is why I believe that the Mac App Store will be dominated by (and become known for) apps that don’t exist on the Mac today.

Appeal to iOS developers

Much of what made the App Store so compelling to developers will begin to apply to Mac software with the Mac App Store:

• Most Mac owners will be encouraged from prominent places on their Macs to buy apps. The potential audience is huge, and will be much easier to reach.
• Payment processing will be much simpler.
• Software websites won’t need nearly as much functionality.
• Two of the most common support issues for desktop software vendors — installation support and serial-number issues — will almost completely disappear.

So I expect a lot of iOS developers to start making Mac apps, especially individuals and very small teams.

And these are the average selling prices I expect for non-free software:

In other words, a lot like iPad-app pricing, but shifted slightly higher. And even considering the lower prices than current Mac software, and Apple’s 30% cut, the value in exposure will overcome those for most good apps, and developers will be able to make a lot of money.

What about today’s Mac developers?

They’ll be fine.

Today’s market for Mac software isn’t going anywhere. People will continue to find (or not find) traditional apps in the traditional ways, and will continue to buy (or not buy) them in retail stores and from the vendors’ websites at about the same rates. In fact, as the Mac’s marketshare grows, this market will continue to grow with it.

But a huge new market is about to open next door. And yes, it’ll probably be dominated by Angry Birds and other inexpensive, often trivial apps. When this happens, a lot of traditional Mac developers are going to look down on it. But those with a bit of free time to develop their own inexpensive, often trivial apps might have a different viewpoint entirely when they see their sales numbers.

As both a Mac user and an iOS developer, I’m incredibly excited for the potential of this market.

Explaining that your app has to be installed differently (and why) is going to be a rather thankless task. Anyone who plans on going this route should start working on their phrasing now. I recommend not blaming Apple, but boasting about the advantages of your approach. “Hand-crafted uniques”, not “Down with Walmart”. Make customers feel good about their purchase, not bad about the world.

— Part of Neven Mrgan’s response to this