sealed abstract class drew {}

So. It’s fashionable lately to whine about app review. I’ve done it. I’ve blogged about how evil it is.

Being at WWDC though, and hanging around Apple reps 24/7, I’ve started to drink the kool-aid. Now, I still think app review is often terribly unfair (I’ve had some absolutely awful rejections). But. I’m kinda starting to see Apple’s point. If you were looking for another article to enforce the mob mentality and get your juices flowing, you can stop reading now.

The User Experience

The reason app review exists is because it enhances the user experience. Jobs has said this. Apple PR has said this. Apple engineers have said this. Apple legal has said this. But I don’t think, in a very serious way, many developers have actually considered this statement on its face.

You see, from any other company, it would be a joke, or worse. On the level of “We’ve raised our prices to serve you better.” The sort of parroting that happens out of fear that it will be quoted in a class action lawsuit somewhere.

However, I’ve come to the conclusion after speaking with high levels of Apple insiders that Apple is indeed being deadly serious about user experience.

Part of the huge disconnect comes because I think most developers look down on mere users. In today’s world, the number of people who really want to use computers is pretty small. Real people want to browse web sites. They want to get e-mails. They don’t want to use a computer. They don’t want to have to learn the file metaphor. They don’t want to have to learn to use a mouse.

When developers talk about usability, we’re talking about GUI vs. commandline, or mac vs. linux. Nobody cares. The difference in usability is so minuscule for a normal person that it can hardly be measured: that is, everything sucks. It might be just a hair easier to use Apple Mail than Outlook. It’s certainly prettier to look at. But that’s the extent of the difference.

We’ve forgotten what it’s like to be frustrated by a mouse. We’ve forgotten what it’s like to not know what “IMAP” means. We’ve forgotten what it’s like to forget what we named that file or where we placed it. At this level of computer-uneducation, the sort of “prosumer” usability gains from Mac OS just don’t exist.

When developers see these people, we tell them to RTFM or to learn how to subscribe to the mailing list, or even things that (to us) are really trivial like drag this app to your Applications folder or control-click with that icon selected or “type it in spotlight.” All these require the parallel mental understanding of at least:

1. A conceptual idea of what it is the user is doing (at least if he ever wants to do it again)
2. Dexterity to perform some potentially challenging keyboard-and-mouse combos
3. At least one jargon term they’ve never heard before, making them feel stupid
4. The chance that, due to some weird hardware/software configuration issue, the right thing won’t happen, something bad will happen, or viruses from space will infect their computer.

Contrast this with iPhone OS, where the steps to do just about anything are:

1. Touch stuff
2. Nothing bad ever happens

As developers, we underestimate the order of magnitude of this distinction. We learn a new programming language once a week. Pro users learn a new version of Final Cut once a year. Your mom might learn how to send e-mail once, if you’re lucky.

And so, while we’ve laughed at Apple’s claim that Google Voice was rejected for a user experience issue, rather than an anticompetitive issue, consider the assertion on its face: mom installs the GV app. Maybe she even makes calls with it, some of the time. But she wonders why it only works occasionally, having never even entertained the idea of a dialing “program” before, and using GV over the phone’s native dialer is far from her mind. She gets confused–she has these notifications for voicemail, but they’re not in the usual voicemail place? She sends SMSes, but some of them aren’t recorded in GV? Maybe that will get fixed when iOS4 introduces support for “multitasking.”

The real place to have GV support is in the OS itself–perhaps refusing to do so is anticompetitive. But Apple’s statement is certainly true: a GV app is a serious usability issue for normal people.

Developers start with the assumption that the user is wrong. The user needs to be re-educated. Don’t delete your mail, archive it. Don’t power off your computer by pulling the plug. Use “documents” for documents, don’t put your downloads in there. Stop clicking “allow” on all those prompts. Don’t use IE, use <insert-browser>.

Apple is starting with the assumption that the developer is wrong. Developers write software that is way too hard for users to use. Developers need to throw away old metaphors like “save” and “load” and make things Just Work (TM). And if it can’t Just Work then don’t even do it in the first place.

App Review = $$$

I read an article the other day about a person who died because of a third-party dialer on Android.  Can you even imagine if an article like that was written about the iPhone?  I mean it’s obviously not Google’s fault.  But in the mind of your mom who just watched a scary Fox News piece on it… it kinda is.  Now she’s too scared to buy apps anymore.  Good thing she has an iPhone, were nothing bad can ever happen.

A free app market is kinda like terrorism.  Not many people really get hurt, but due to psychology it’s way scarier than the mundane things we really should be worried about.  Especially in the minds of people who don’t really understand technology.

So if there was, say, just a single app in the store that accidentally deleted all your data–how many newspaper articles would be written about it?  How many people would swear off buying apps?  By how much would the app market shrink?  How much would it cost you personally, competent app developer who doesn’t delete anybody’s data?

If one app deletes a customer’s contact list, that anger will be directed at Apple. If one app manages to hit 100% CPU for an hour and drain the user’s battery, that anger will be directed at Apple. If one app gets a kid busted for looking at porn, that anger will be directed at Apple. Developers in theory know better than to direct that anger at Apple–yet in the same breath we blame MS for creating a shoddy architecture that allows malware to thrive.

Already, newspapers don’t need any excuse to blame technology for today’s ills. Any day now, Australia or Jack Thompson or somebody’s ready to ban the Internet. Apple wants to pull itself entirely in the opposite direction–to be totally above reproach. They want those articles to be written about Android.

Fallacies

Due to psychology, consumers are irrationally afraid of bad apps.  But developers can be irrational too.  Here are a few amusing fallacies I’ve heard against the Apple market:

“There’s crap on the market already, so opening it up can’t make it any worse.” Why not?  Seriously, why not?  Just because it’s X bad now doesn’t mean that performing some action A won’t cause it to be 2X bad.

“Android has an open market and it’s doing fine.” If by “fine” you mean people aren’t buying anywhere near as many apps.  You have two things working against you on Android:  1) The people who buy Androids are more often than not developers, who either write their own software or are used to FOSS apps and are conditioned against paying money and 2) Any “real users” who pick up an Android device have the same barriers to buying apps that anyone not on an iPhone has:  (irrational) fear of bad things happening.  Paradoxically, an open market leads to reduced consumer trust and reduced consumer spending.

“Apple could use a community policing policy and that would work out fine.” It would work out fine until the first article about a third-party dialer causing somebody to die.  At that point, sales both of iPhones and of apps would drop off pretty sharply.

“Maybe with some consistent, clear rules, app review would be better.” No, it would be worse.  Right now, there’s (really) only one (secret) rule.  Don’t tell anyone I told you…

The One Rule

There’s only one rule on the app store.  Here it is:

Make your app a magical experience for ordinary people.

Things that are not a magical experience include:

• Crashing
• Not doing what the description says it does
• Using private APIs (a.k.a. crashing on iOS5)
• Being “slow”
• Being hard to use
• Having a sucky cross-platform GUI
• Running in a VM, a.k.a. killing the user’s battery life
• Being not roughly worth what you charge for it (“I Am Rich”)

Almost every rejection ever is a violation of The One Rule.

Conversely, if you follow the One Rule, you’ll find you can break a lot of the things in the SDK agreement.  Providing video recording on the iPhone 3G?  Turns out you can use private APIs.  Writing themes for your game?  Turns out you can use Lua.  The SDK agreement is just writing out a lot of things that are somewhat tangential to The One Rule, in a failed attempt to make app review seem objective.  Well, it’s not.  But that’s not necessarily bad.

Other Rejections

“My app got rejected for some other reason!”  Possibly.  The problem here is that Apple gets like 10,000 submissions a week or something ridiculous.  The best QA team in the world would have trouble with that number of submissions.  Mistakes are made.

Personally, I would love to be able to front, say, $99 or so per submission to get a serious app evaluation, maybe even with feedback from an Apple UI designer (currently I have to fly to WWDC to do this, and only once a year).  As a professional app developer, I would have zero problems with fronting some cash to get my app looked at if it meant an “express lane” better-quality review, with actual feedback.  At least I wouldn’t be in the same bin as the crap submissions.  I think Apple’s concern here is that it wouldn’t be “fair” to poor developers.  So keep the same “free” review lane, and add a premium lane.  Problem solved.

Conclusions

Apple might be a little misguided.  They might be treating developers poorly.  But they’re making a hell of a lot of money doing it.  Who are we to say that they’re doing it wrong?

This quote from a developer I think really sums up how a lot of developers feel:

If the end result has and continues to be shoddy then maybe there’s only one way to vote — with your feet.

My rebuttal is simply:

If everybody’s flocking to iPhone, doesn’t that mean the result is better than shoddy?

I’m doing freelancing full-time this summer.  Here’s a brief summary of what I’ve learned so far.

Lesson 0: Be good.

The key to being a successful freelancer is being good at what you do.  If you are bad, no amount of business wisdom will save you.  In the iPhone business, this means:

• Write a half a dozen or so apps and get them through App Review.  Kind of obvious, really
• Troll the official and unofficial developer community hangouts and follow what is going on, especially with regards to new “unwritten” app review guidelines and practices
• Stay up-to-date with the latest beta SDK documentation so you know what’s coming
• Spend a lot of time trying out iPhone apps
• Spend a lot of time learning new SDKs and APIs

Lesson 1: Say “no” a lot

Apple wins by saying “no” to features.  It makes sense that in Apple’s market, you win by saying “no” to clients.  Some examples:

• Client wants to add lots of really complicated features.  But you can solve 80% of the problem with a simple solution.  Simple solutions are easy to maintain and can always be extended later to recover that last 20%.  If the client can’t understand this, perhaps they shouldn’t be partnering with Apple, the king of simple.
• Avoid visual overload.  This is a design aesthetic, but it’s key on Apple platforms.  Again, if the client doesn’t get it, what other parts of the HIG is the client going to fight you about?
• Don’t negotiate on estimates.  I’ve had dozens of people who want me to come down 5%, 15%, or 50%.  If it was going to be less, I would have quoted less.  If the start of the relationship is a spat about $500, what does that say about the rest?

Lesson 2: Filter clients fast

If you are good (see Lesson 0), the amount of work available to you is effectively infinite.  Every person who has held an iPhone has an idea for an app and dreams of riches.  The number of people who can take that idea and convert it to a product, on-time and on-budget, however, is vanishingly small–perhaps 10,000 good developers at most.  So only take the best clients.

This concept is a lot more counterintuitive in real life than it is on paper.  You are looking somebody in the eye who is offering you $5k (for a $6k app), and turning them down, because you know that next week somebody will call you who is willing to pay full price.  It means turning down a stellar multi-app repeat client who pays on time but is extremely picky about the background color of unchangeable Apple UI controls because you know that right behind him is another stellar client who trusts your (and Apple’s) professional design judgment and will be a lot easier to work with.  Turning down a deal in-hand that’s “ok” but less than stellar simply goes against all intuition.

As soon as I have any idea at all what the project will be, I quote new clients a price with a margin of error of a couple of thousand dollars.  I do this before investing any work into writing an estimate or even hearing much about the project.  I need to weed out the “revenue sharing” people instantly, not after even one hour of my time.  There are simply too many of those guys out there.

Lesson 3: Don’t bid

There are a lot of bidding war sites out there like iPhoneAppQuotes.com and GetAppQuotes.com.  Leads from them aren’t worth the time it takes to write an estimate.  Here’s why:

• Competent developers already have plenty of work.  So the number of competent developers on those sites are pretty small.  So if you’re a developer, you’re bidding against incompetent people.
• Those incompetent people you’re bidding against?  They will quote a lot less than you.  It doesn’t take much money to not deliver a project.
• All those clients (speaking from experience here) are either clueless or penny-pinchers.  The reason they’re putting projects up for bid is because they want it done (or not done, as evidenced by the responding developers) as cheaply as possible, even if it sucks.

Fast food is cheap.  It’s the same everywhere.  Any fool can be taught to make it.

I am not in the fast food business.  I am a chef.  I juggle Apple, clients, changing HIG guidelines, changing SDKs, tools, documentation… I design good layouts.  I think through small-screen UI design.  I pay attention to battery life.  I look at what the client wants and I see past the requirements and into the real business problem.  I anticipate what they really want, and I find the right balance between features and complexity.  Those are specialized skills.  They’re not cheap.  They’re not replicable.  They’re not scalable.  And if you give that speech to somebody who’s trying to order a burger at McD, you’re never going to get anywhere.

A lot of people are worried about lowball foreign developers “stealing” all the work.  I’m not concerned, any more than the 5-star chef is concerned when McD opens next door.  It’s not within 100 miles of the same market.  I will solve the problem for you and bill you a price to match.  Fast-food developers will copy and paste something off a forum somewhere and you’ll be stuck in revision hell forever until you give up and hire someone new.

Lesson 4: Revenue sharing is only mostly evil

In the past, I’ve come down pretty hard on revenue sharing:

If you’re going to offer something stupid like “revenue sharing”, just walk away.  Developers are going to laugh at you.  I have a “revenue sharing” deal already–I do development work, and Apple sends me a monthly check.  The only way to compete with that is to pay actual money up front.

I still think this is mostly right.  I have all the revenue sharing agreements I want already: with Apple.  And there’s still no shortage of people offering me a 50/50 split for their “app idea”.

However, I have begun to offer a 5% discount for a 3c per copy royalty for certain projects where the clients are known to be reliable/honest and the product is sound.  This gives me a little bit of residual income and a little bit of risk.  The smart clients realize that it keeps me invested in their projects.

Conclusion

I’m learning more this summer than I’ve ever learned in a classroom.  Being forced to make actual money is perhaps the best teacher of all.  Why don’t we expose students to something like this before they enter the workforce?

A lot of developers (myself included) have expressed disappointment in the app store on ideological grounds. Can’t install your own software! Apple keeps competitors off the platform! Apple doesn’t let innovative apps through!

But there’s another angle to this that nobody’s covering. The app store keeps piracy off the platform. Not because it makes buying easier than pirating (which it does), but it also makes pirating hard. You can’t be running the latest firmware. You have to forego security updates. Apple’s own development tools often have unexpected behavior on jailbroken devices (not intentional, I think. Just Apple never bothered to test it).

And so developers are pacified because piracy is constrained to those people who wouldn’t have bought anyway (in a way that computer apps aren’t)[1]. This sort of stronghandedness hasn’t worked on other platforms because the users are up in arms. Extra DRM isn’t a feature.

But in this case, the app store acts like an insurance policy. None of the apps are going to wipe out your data. They’re not going to hook into your OS and break Dashboard. They’re not going to forward themselves to everyone on your address book. Users are willing to put up with buying more software if it actually works. And so this is an acceptable trade for them.

And meanwhile, Apple is sitting in the back, pocketing lots of cash[2]. They’ve pacified the developers with more money (less piracy), and they’ve pacified the users with software that works. They’ve solved the two biggest problems in the industry, and they’ve been incredibly successful as a result. The major personal computing platforms of today are no longer desktop and laptop PCs. They’re devices running the iPhone OS.

2012 may very well be the year of the Linux desktop. But only because people using Linux might be the only desktop users left.

There are some really, really great iPhone games.  And there are more coming.  The unsung hero of the iPhone 3GS (and upcoming iPod Touch) is the new graphics chip, which is going to rock the socks off what we’ve been seeing so far.

That said, I’m really worried.  Let me tell you why.

Phoenix Wright is a ridiculous game.  You play a crazy, how-did-he-pass-the-bar-exam defense attorney who ends up with hopeless cases where clients are consistently and inexplicably being framed by huge criminal organizations, the government, and/or the prosecution.  Which, by the way, is allowed to bring weapons in to the courtroom and assault and batter both you and officers of the court.  In a court system in which clients are guilty until proven innocent, and the prosecution has all of the evidence.  Also, you have psychic powers and summon people back from the dead to hear them testify.

Suppose you are a gaming exec and somebody pitches this idea to you.  WTF?  Dumbest idea I’ve ever heard.  What genre would this even be?  What’s the demographic for bizarro-world law and order?  How is this universe even remotely self-consistent, let alone sane enough for a rational player?

The thing about the Phoenix Wright franchise, though, is that it’s quite possibly the best mobile gaming franchise ever made.  For one, its episodic format fits perfectly into the mobile space; its gripping plot and stunning characterization stand out like an extremely good book.  I feel like I know Detective Gumshoe, something so hard to pull off in this format I don’t even know where to begin.  Somehow, the writing is so good that this insane world actually feels believable.  The plot is so complex that the detail you missed back in game one should have tipped you off that so-and-so was the criminal mastermind in game four, and people endlessly speculate online about things like this like they did back when maybe Dumbledore wasn’t dead.  The localization team has quite possibly performed a miracle: the text effortlessly weaves together nerd humor, insightful aphorisms (thanks Godot!), witty puns, and the whole thing feels so polished you’ll swear it was originally a DS title (it wasn’t) and it was originally in English (nope).

You won’t find Phoenix Wright on an iPhone.  Sure, you’ll find innovative indie houses that find new and clever things to do with accelerometers and location, that make beautiful, well-designed titles.  This is new and exciting, and is bringing a lot of new players into the game space that weren’t there before.

But look at Nintendo’s stable.  No, really, look at it.  You’ve got The World Ends With You, and its sibling, Devil Survivor.  Here are two breathtakingly-gorgeous games that are innovative and refreshing and all that cool “indie” stuff.  And they have epic story arcs that make you feel something.  FF: Echoes of Time.  Solid franchise (arguably the solid franchise), solid gameplay, very competitive graphics (when you ponder this is done without real 3D acceleration, it really becomes a WTF moment), and an excellent story.  Covenant of the Plume, a dark, serious story-driven title.  Suikoden Tierkreis (possibly best-looking mobile game ever).    DQIV.  Fire Emblem.  FFIV.  Tactics A2, arguably the greatest strategy game ever.  I dunno, just work your way down the Editor’s Choice list: these are 100+ hour titles that look great, play great, and tell a great story.

Now go down the iPhone game list.  You’ve got some good titles.  Alternate Endings is cool.  CSI: Miami worked a lot better than it sounded on paper.  You’ve got your prettied-up Nethacks, which are playable, I guess, but no feeling.  You’ve got Monkey Island, which is a great idea but too buggy to be playable.  You’ve got Myst, which I’m sure was a checkbox for the rights holders (seriously, what platform does Myst NOT run on).  You’ve got some good “casual gaming” or whatever titles where you tap some colored circles to music or play something that looks an awful lot like Tetris except has some “innovative” feature like blocks moving sideways or something.  And then you’ve got the artsy titles which are really decent–I mean somebody really loved this game–but it just doesn’t hook me without a killer plot.

Now here’s what I can’t figure out:  we’re told that gatekeepers (like Nintendo) keep innovation out of the marketplace, because they’re motivated to not take risks and such.  But the fact of the matter is, Nintendo is consistently turning out excellent, high-quality titles, while, conversely, the king of the app store is mass market fluff.  I mean if you asked me “Which will be backed by a video game conglomerate: crazy innovative lawyer game or Tetris clone,” my money is on Nintendo passing on an innovative game and settling for something with wide appeal, the developer instead sets up shop with Apple and makes a million bucks.  And yet.

So I draw two conclusions from all of this.  First of all, I’m not throwing away my DS.  Nintendo’s hardware may be woefully behind, but they’ve nailed mobile gaming, at least for me.  You can pry their titles from my cold, dead hands.

And the other is, in spite of my aversion to taking on new work, I’m dying to put a decent story arc on an iPhone.  I’m dying to take old-school adventure RPGs, bring them into the 21st century with some GPS or multiplayer or something, and get them on the App Store.  I’m dying to feel something again.  So if that’s your cup of tea, feel free to hit me up and we can work on it.

Hi Steve,

I’m an iPhone developer. I’ve got four apps live in the store, one in review, and several more I’m working on. Plus the 3-4 apps that I’ve written for clients that they have listed under their own accounts.

TUAW says you pulled GV Mobile. Not only do I use this app every day, but I’m developing something similar (different service; similar functionality). This sort of thing strikes fear into the heart of app developers. Quite frankly I’m not sure about finishing my app anymore. There’s no place I can go to get Apple guidance on whether it will be approved.

TechCrunch thinks it has something to do with the official Google Voice app getting rejected, but I don’t want to speculate.

Anyway, I think that was a really crappy thing to do. And it was especially crappy that you (according to him) wouldn’t give him written confirmation because (according to him), you were “scared he would post it“. I’ve independently been hearing rumours of a secret cabal of app reviewers who call us when your rejections are too “sensitive” for normal means. If that’s true, it’s not very nice, Steve.

App developers are your friends. Thanks for the increased transparency with the software betas, but my word, all anyone really cares about is transparency from the app store.

–Drew

Or: Why finding an iPhone developer is so hard
The answer is simple: all the good people are already busy.

Wow, you just got your shiny new iPhone! You can download all these great apps! Wouldn’t it be great if there was an app that did X? Hey, your company could really use an iPhone app! If Joe Developer on the Street can put out an app, then so can you! All you have to do is find a developer!

Stop right there.

Reality check:

• No matter who develops your app, if you want it to be sold under your company name, you (this means you) have to sign up as an Apple developer.  This is $99/year, and there’s a (last I checked) 3-week waiting list and a lot of paperwork to fill out.
• You need to pass Apple review.  Again, lots of paperwork to fill out.  And if you get rejected, you start again.  I’ve got an app that’s been in the queue 4 weeks now.

Okay, okay, so maybe you can’t impulse-commission an iPhone app.

But my app’s really simple!

No, your app is not “simple”.

Let’s take a “simple” app that does two things:

1. Displays “Hello, world!”
2. Plays a “Hello” sound effect

How much simpler could it get?  To an iPhone developer, your two-feature app looks like this:

1. Who is providing your application icon?  All apps need an icon, in very specific sizes and formats.  Do you know what they are?
2. Do you want to sell this app under your own name?  If so, you need to sign up as a developer.  Hope you don’t need this in the next month or so…
3. Do you want to actually test this app?  If so, it needs a seperate “testing” codesigning chain.  The Apple documentation on how to do this was (and to a large extent, still is) dead wrong.  And if you screw up, you’ll get a generic error (“Can’t install: 0xe0080018″).  I hope you know where to find help, because the good documentation isn’t indexed by Google.  Oh wait, the tester is running Windows and is trying to upgrade the test version in repsonse to a change?  That fails with a mysterious error, because upgrading test builds on Windows isn’t supported.  Again, not documented anywhere.  You didn’t know that?
4. Should the “Hello world” message be displayed using UIKit (like a UILabel, or UIAlertView), or with Quartz?  Or with OpenGL?  Is there any chance this app will later be extended to draw “Hello world” to an image, like to export to the photos app or to send in an e-mail message?  If so, you shouldn’t be using UIKit.  And is the “Hello world” text bigger than a certain size?  If so, you shouldn’t be using OpenGL.  But you’ve gone through the design process, and you know that, right?
5. Are the buttons and appearance consistent with the HIG (Human Interface Guidelines)?
6. Do you need to adjust/move text around when the app is opened when the available screen size is less than expected (for instance, when you’re on the phone, and the status bar is flashing green and huge)?
7. How are you allocating memory for this?  No matter how you display the text, there’s memory to allocate, and doing it wrong is grounds for rejection.
8. What background color should you use to be consistent with other apps?
9. Who’s providing the “Hello” sound effect?  I have some sound experience, but most developers don’t.
10. Should the sound effect be responsive to the phone’s volume controls?  (Hint: Apple reviewers have an opinion)
11. If the “Vibrate” switch is on, should you play the sound, play nothing, or vibrate the phone?  (Hint: Apple reviewers have an opinion)
12. If there’s already a sound playing (like music from the iPod), should you play the sound overtop?  Should you fade the music down, play the sound, and bring it back up?  Should you fade the music down, pause the iPod, and play the sound?  Should you then resume playback at app quit?  (Hint: Apple reviewers have an opinion)
13. If the sound is interrupted (like by a phone call or other alert), should it resume playback after?  Or should it die?
14. What fileformat is the sound in?  Who does the conversion?  Depending on your answers about fading music in and out, you may not be able to use formats like AAC that the phone should support.  Have you thought about the battery life, about performance (app launch times)?  Some formats are hardware accelerated, which may very based on the specific device, what else is going on (music, alerts playing), etc.
15. Were you aware that apps above a certain filesize can’t be downloaded over a cellular network, drastically decreasing your market?  Do you know what that size is, and which sound file format(s) will keep you in the limit?
16. How are you allocating memory for this?  No matter how you play the sound, there’s memory to allocate, and doing it wrong is grounds for rejection.
17. Are there any other apps similar to yours that have been rejected?  (Yes there are!)
18. Who’s responsible for acquiring the certificates, keys, provisioning profiles, etc. required to submit your app to the app store?  (Hint: if you’re selling under your name, you have to acquire these.  All a developer can do is help you fill out the forms, like a CPA does for your taxes).
19. Who’s responsible for support, diagnosing crash reports, fixing bugs, etc. after it’s out in the store?

This is the list of things to worry about for a dead simple app, with no user input.  Just imagine what this list would look like if your app actually did something useful.

But iPhone developers eat lists like this for breakfast!  All I have to do is find a good developer!

The good developers are always busy

I’m a good developer.  I have four apps in the app store.  I have two in review.  I lovingly care for these apps.  I push updates.  I add features.  I make money.

I have a waiting list of clients a mile long.  I’ve had to tell prospective clients “you have a great project here, looks like a good idea, but I have twenty great projects to work on for the next six months.  Good luck.”

All iPhone developers are like this.  Most of their time is spent on their own apps.  What little they have left goes only to the most lucrative or most reliable clients.

With other kinds of development, you can sort of snatch students out of college before they realize what they’re worth.  You can get some undergrad student to throw it together for you in his spare time for $20/hour.

But iPhone developers already have a well-paying job working for Apple.  To get their attention you have to pay them more than what Apple pays them.  And Apple pays them a lot more than you would expect.

If you’re budgeting anything less than $5k for your app, just walk away.  Developers are going to laugh at you.  Think about the “simple” two-feature app that exploded into the huge list.  Your app is more complicated than you think.

If you’re going to offer something stupid like “revenue sharing”, just walk away.  Developers are going to laugh at you.  I have a “revenue sharing” deal already–I do development work, and Apple sends me a monthly check.  The only way to compete with that is to pay actual money up front.

But this five-star company on eLance offered to make my app for $10!

We’ve been over this.  The good developers are busy.  In the hour or so I’ve worked on this blog post, I’ve gotten two e-mails and a phone call inquiring about iPhone work.  I sure as hell don’t have time to spend searching for work on eLance, and anybody who does is dangerous.

If you know anything about software development, you’ve heard the horror stories of outsourcing work and having it shoddily-done[1].  Without rehashing that argument, be aware that iPhone development is harder than most other kinds, and so there’s a great deal more that can go wrong.

How to find a developer

It’s simple:  cold-call the people who made apps you like in the app store.  Every project I’ve ever done started as a cold call.  Most will tell you they’re too busy to do new contract work.  But, if they’ve written an extremely similar app, they will know what’s involved and will be way faster than average.

Tell them what your budget is.  Cold-callers who are flakey about budgets go to the bottom of the bin.  Ask them for an estimate.  If they say they’re too busy:

• Ask them if your budget is in the right range.  Remember, it’s always more complicated than you think.
• Ask them if they know anyone who can help you.  Maybe they personally know another developer.  Maybe they use an app that’s similar to what you want that you’ve never heard of.
• Ask them if they have any advice.  Most developers are pretty friendly, even if they can’t help you.

tl;dr

If you don’t have $5k, walk away.  Anyone who does iPhone freelance work is either

• Being paid more than Apple pays him for releasing an app on the app store, or
• Incapable of writing his own app store apps (not the developer you want).

If you want someone good, try cold calling apps you like in the app store.

If you’re read all of this and are still serious about making an iPhone app, feel free to call or e-mail (phone widget on the right sidebar).  But I keep a pretty full schedule, so I may not be able to help you.

[1] When I say “outsourcing” here, I mean the kind in which you pay considerably less than states-based developers.  I’m not implying that similarly-priced developers in other countries are inferior.

If you’re trying to talk to an MFMailComposeViewController and are setting the delegate property (you know, like every other class in the iPhone SDK), you’re doing it wrong. You need to set mailComposeDelegate.

Oh, and just to confuse you, delegate is left in, so as not to cause any warnings or compile errors. It just silently fails.