inconsequence

I’ve commented on the App Store approval process before from the position of a potential future App Store supplicant, but now that theory has become practice my feelings have changed. But this doesn’t mean I’m completely in the App Store is broken camp (paulgraham.com).

Apparently Apple’s attitude is that developers should be more careful when they submit a new version to the App Store. They would say that. But powerful as they are, they’re not powerful enough to turn back the evolution of technology. Programmers don’t use launch-fast-and-iterate out of laziness. They use it because it yields the best results. By obstructing that process, Apple is making them do bad work, and programmers hate that as much as Apple would.

Paul Graham (my emphasis)

From the point of view of a developer, the App Store approval process is just horrible. You basically submit your app and wait. And wait. And eventually you either get rejected with some kind of set of suggested changes (my wife’s experiences in Academia have led us to refer to this as “revise and resubmit”), rejected outright, or (you hope) accepted. In the best of all possible worlds, you produce a new or updated app and … some time later … it appears online.

The worst case scenarios are, in large part, well-known. Apps left in limbo. Bizarre and inconsistent rejections. Apps made with annoyingly conservative content or feature sets to avoid potential rejection or handle insufficiently specific rejections. Yuck.

Also annoying is the idea that, say, an App has a problem, the problem has been fixed, but there’s a bureaucratic snarl between me and the solution. The developer is ticked off because he/she looks bad. The customer is annoyed because he/she is living with a problem. And Apple looks bad because of both of the above.

So I reread Paul Graham’s (as usual) thoughtful take on the whole thing the other day when I was trawling his site for new essays (there were several, Paul is a super smart guy and a very good writer) and his issues with the App Store approval process seemed suddenly much more compelling. But as I was turning it all over in my head this morning, it struck me that (a) Apple knows all this, (b) Apple isn’t stupid, (c) the App Store approval process is obviously quite complex and expensive to administer; so why was Apple persisting with this obviously broken model?

Let’s take a step back for a moment and think about how the App Store submission process affects both developers and customers:

Developer

• If I fix a bug in my program, I can’t just recompile and stick it on my website where one of the various automatic update mechanisms can send it straight out to all my customers as their apps “phone home”. This sucks, because I like fixing stuff and my customers really appreciate getting quick fixes.
• If my app is in the submission queue and I discover a bug and fix it, I need to trade off waiting for the current version to get approved/rejected or reject my own submission and lose my spot in the queue. This sucks because it creates an incentive for me to leave buggy apps in the queue rather than send out my latest, greatest binary.
• It’s unfair for me to have to invest in developing an App not knowing if I’ll even be allowed to sell it.

Customer

• I want good software that Just Works and is easy to use.
• I don’t want apps that update themselves every time I launch them. On the other hand, I don’t like using out-of-date apps not knowing if I’m missing out on some really great new feature or risking running into some horrible bug that’s already been fixed.
• I don’t want to buy an app and then discover it doesn’t work any more or isn’t supported on the latest version of the OS.

It may seem like there’s an obvious win-win here that Apple is perversely ignoring. Let developers ship product when and where they want. Let customers buy the products they like. But actually that’s not true at all.

Here’s what the Wild West has delivered:

• Big Commercial Apps that treat OS updates as an opportunity to sell largely worthless version upgrades (I’m looking at you Adobe, Avid, Autodesk, Microsoft, et al.)
• Small Indie Apps that rev constantly so that every time you launch them it seems you need a new version. (“Install and Launch” is practically the equivalent of saying “good morning” to Acorn, GraphicConverter, etc.).
• Small Indie Apps that seem really great but never get to version 1.0, even after charging people for registration (The Hit List), or suddenly become unsupported with no word from the vendor (Silo 3d, Textmate).

Apple can’t do much about the last one except make it easier to track developers by reputation, but the App Store submission process is an attempt — a deeply flawed attempt, to be sure — to address the first two.

So here I am, Manta is in the queue, and I have a list of known bugs I am slowly working through. If I want to update my submission I will lose my place in the queue, so I am holding back my fixes until I get approved or rejected (since any issues leading to rejection will clearly be higher in priority than various things I think might need polishing). If I found a show-stopping issue, there’d be no point but to reject my own submission, but as things stand I think on balance I will stick it out.

Am I being “forced” to do “bad work”? No, I’m being forced into thinking of releases as being something I need to think about and not “whatever last compiled cleanly”. I’ve been selling software online since before it was terribly sensible to do so (e.g. when we sold Prince of Destruction online, we couldn’t handle credit card payments and most people had no idea what a website was) and the App Store submission process has certainly been useful and educational (and frustrating and scary) for me.

Arguably some developers don’t need to have this discipline enforced on them by Apple, but I don’t hear any of the likely candidates complaining (Omnigroup? Panic? Electronic Arts?). There are over 100,000 would-be App developers out there, and I’m guessing being forced to think in terms of concrete, well-defined, tested releases is going to be a big win for 99+% of them.

Stop whining and do a little QA.

Post Script

Manta has been approved and is now on sale in the App Store. Also, I added an image to the post.

Seriously, this is the best icon Apple could come up with?

iTunes 10 is out with “Ping”. The one good thing I can immediately say about Ping is that it’s not “one more useless account” (sadly, uselessaccount.com seems to be defunct). But that’s only because it hangs off of your AppleID (if you have one). Why is Apple entering the social media game? Pumping up their stock price would seem to be a dumb reason. Then again, Apple also got into the search portal game at one point (and I believe that was after Jobs’s second coming). Bear in mind that this was when search portals all sucked in different ways. Seriously — people would actually recommend altavista to their friends back then…

The usual reason Apple does things is that it thinks it can do them better than anyone else. Certainly, the way “following” works in Ping is intelligent, and the basic idea (form a circle of friends and share recommendations, vs. randomly “friend” people for no good reason) seems sound. In the end, MySpace and Facebook both started out as being primarily about music and became privacy invading quagmires. We’ll see. Right now I can find two Paul Simons and two Bjorks, but not the Paul Simon and the Bjork I’m interested in. (And seriously, they couldn’t get Bjork to sign on? Maybe she’s just too 1998.)

Ars Technica rightly pointed out that what we don’t need from iTunes is new features. What we need is better reliability and performance. Oddly enough, while Jobs made no mention of under-the-hood improvements, iTunes seems significantly more spritely.

I think I’m even willing to forgive this:

OK it's annoying, but it is consistent with the minified window.

Shoe Icon (created in Art Studio on the iPad, from a pencil sketch photographed using my iPhone)

For a while now I’ve been using a simple PHP script to publish my working notes for the stuff I do at the University of Alabama. Essentially, I have a folder full of text files (using markdown syntax) and it simply lists what’s there, uses markdown.php to render it, and voila. I imagine it’s not dissimilar conceptually from the way Gruber manages daringfireball, but I’m sure his setup is much more sophisticated and does caching, etc. Since I have about five users, there’s no need to get more elaborate.

Anyway, I submitted Manta to the App Store in the wee hours of Monday morning and thought I’d better put some kind of website up for the game at the URLs I provided as part of the submission process. You know, the reviewer might actually check. I threw some stuff on the server and then quickly realized that making something that looked good on all the target platforms I cared about (i.e. Mac, Windows, iPhone, and iPad) might be pretty tricky in a short timeframe. After all, my main website has been kind of sucking on the iPhone for some time.

I figured I’d use a “simple toy” to get a site up real quick, and worry about proper content-management, etc., later. (In other words, probably never.) My first stop was WordPress. Surely there are some awesome themes out there that look good on everything. I love WordPress for managing simple sites and this was going to be pretty darn simple.

Well, if there’s such a theme, I couldn’t find it. The one theme I found that claimed to be iPad-friendly (a) wasn’t, and (b) was decidedly not free.

My next stop was Rapidweaver. I licensed Sandvox a long, long time ago back when I needed to get a different website up-and-running fast. I’ve followed Sandvox for a long time and it continues to suck in almost every way I care about but — at the time — I preferred it over Rapidweaver because it was kind of WYSIWYG and had some power-user features I thought might be useful (but really weren’t). Rapidweaver had themes that were claimed to be iPhone- and iPad-friendly (but weren’t — in fact even the demo sites were badly borked) and managed to produce pages with videos that couldn’t play and other embarrassing glitches (e.g. failing to correctly update the site after changing a page name, and pretty much broken SFTP support). Good grief.

OK, in desperation I tried Sandvox. Oddly enough, even though Sandvox seems very clunky beside Rapidweaver, and even though Karelia seems to go out of its way to ignore third-party theme developers (e.g. there are no links to them on its website), there are some very nice third-party themes for Sandvox (I didn’t buy them, but they looked pretty nice in my browser). Even so, Sandbox infuriates me and also produced broken pages.

I even tried iWeb ’09. Actually, of the three, iWeb seemed to produce the least dysfunctional site, but its pages are heavy, it didn’t do a good job with videos (they did play, at least), and it has a terrible collection of themes and very little third-party support (I think it’s safe to say iWeb is a total failure as a product). It certainly makes no effort to produce iOS-friendly pages, which says a good deal. And producing a simple gallery page is a chore unless you set up the gallery in iPhoto first. No thank you.

Back to Coda.

So, here’s the solution I came up with. I took the basic idea of my markdown-driven “work blog” site and combined it with some ideas I have been using for a very long time here and there, which essentially involve using file-naming and directory structures to connote relationships between content. A little bit of glue code in PHP, two PHP library files I use for all kinds of things, one CSS file, jQuery.js and markdown.php, and a simple .htaccess hack, and voila: instant website. Just shove files in the right format using a simple naming convention in a pretty pattern on a server and it all just works. It’s very much a work in progress, and there are some obvious refinements I can add, but it’s shaping up to be a simpler and more flexible way to quickly build an attractive (and highly customizable) website than Rapidweaver, Sandvox, or iWeb. And with some kind of Web App for online management it might even be simpler than WordPress or Tumblr.

Afterthought

The one “super simple” solution I didn’t try was mobileme. Of course the idea of paying Apple $99/year in perpetuity for a tiny amount of cloud storage on a server that won’t let me run my favorite scripting languages somehow doesn’t appeal to me. I also tried looking at some sites on mobileme.com and if there’s a way to quickly generate attractive, compatible sites using it, no-one seems to be using it.

Manta screenshot from Unity dev environment

I’m finally getting close to releasing Manta and one thing that has somewhat surprised me is what a fabulous gaming device the iPad is. For example, while I’ve never been happy with any “glass joystick” games on the iPhone, I’ve found several on the iPad work just fine — including Manta.

One of the things I was determined to do with Manta’s touch controls was make them “relative”, and this is something the games I’ve liked have in common. In other words, the point you start touching the screen becomes your origin. Most “glass joystick” games on the iPhone combine (a) absolute controls and (b) no central visual feedback. The first means (a) it’s critically important that you put down your thumb in exactly the right spot or you’ll do something weird and (b) you can’t immediately tell by looking at what’s going on in the game where you’ve actually put your finger down — this proves a fatal combination, even for otherwise very polished games such as Grand Theft Auto: Chinatown Wars.

With Manta, your “ship” quickly (not instantly) snaps to a heading based on your thumb position, and your initial point of contact is always the origin. It certainly works well for me (and no complaints from my testers) but we’ll see what the reviews are like when and if it appears in the App Store.

An iPhone can do things with its pictures no dedicated camera can hope to compete with

A really interesting article on the future of photography from a pro photographer with a very analytical mind (Thom Hogan). I’ve added his site to my permanent links, I like it so much.

Hogan raises many interesting issues, notably that tech-obsessed early adopters have ceased to dominate demand for digital cameras (because cameras are “good enough”), that cell phones are eating out the point-and-shoot market from below (certainly our iPhone 4s have made our Panasonic TZ5 redundant), that mirrorless interchangeable-lens cameras (i.e. Micro 4/3 et al) are eating out the DSLR market from below (I’d like to see some actual figures on that), and many of today’s camera buyers value convenience over absolute technical quality. Today’s DSLR is an image capture device without a lens which needs to dock to a computer to be really useful. To jump to the ultimate conclusion, Hogan argued earlier that serious cameras need to be computing platforms capable of running third party software.

While I very much appreciate his take, I’m not sure I agree with his conclusions. I think what a camera needs to be is an image capture device without a lens or a computer (or with a simple computer that can be ignored or bypassed or swapped out). In the short term this means becoming an iPhone (or similar device) accessory, while in the longer term this means being a cloud device.

Now, Nikon (et al) could essentially build a proper touch-based computer with a real operating system (Android, say) into their cameras and then allow third parties to provide extra software for their “platform”, but I think it’s pretty optimistic to expect that Nikon (or Canon or Sony) would able to produce as good an Android device as, say, a phone handset maker. Heck, most of the camera companies seem to have quite a bit of trouble creating decent menu systems for their cameras. Even if Nikon could manage this feat, how can they expect to attract third-party developers to such a niche market? The iPad, which has no built-in camera and no convenient mechanism for docking with cameras has a positive embarrassment of riches in terms of photo editing tools (e.g. Filterstorm is currently $2.99).

Imagine, on the other hand, that Nikon (or some other DSLR maker) were the first to offer a DLSR which could simply dock an iPhone 4 (say) and use it as its back-end (including live view, image editing, and so forth). They could include their own “back” for the camera (and in fact they could simply make different “docks” accessories). They could provide (free or otherwise) their own software to go with it. Such a camera would instantly gain caché just for being iPhone/Android friendly, gain immediate access to an existing, vibrant third-party software market, and immediately gain access to the “digital hub” and “the cloud”, social networking, and all the other buzzwords.

Let’s suppose two big camera companies decide to take differing approaches: one decides to turn its DSLRs into iPhone accessories (they probably would phrase it slightly differently) while the other decides to build some kind of proper OS into its high end cameras and try to build up a third-party developer community around them. Which one do you think has a non-zero chance of shipping something in less than a year? How is the other one going to look when its product comes out second? It seems clear to me that the “iPhone accessory approach” is not only more likely to get to market first, it would succeed even if it got to market second.

Back in 2001 there were quite a few companies making their money as hi-fi vendors. Most of these are now extinct, much smaller, or glorified iPod dock vendors. OK, it’s pretty ignominious to become a glorifed iPod dock vendor, but it’s worse to go out of business.