Editor's Note: From time to time, TUAW does cover commercial apps developed by our staffers, although it is relatively rare for individuals to write about their own projects (with some notable exceptions). In this case, Mike's experience of his app development process -- going from a code-naive start to a spot in the App Store -- is definitely worth sharing.

Last Tuesday, having covered the App Store for TUAW since before there was an App Store to cover (remember the "sweet solution"?), I finally did something I've been thinking about doing for a couple of years now: I released an iPhone app.

I write about lots of apps every day here on TUAW, but I'm a writer by trade, not a programmer. I used to code as a kid in BASIC, but before this app, hadn't ever written anything in an object-oriented language, or put together a piece of software with a graphical interface at all. I don't have a computer science degree or a background in coding -- I have what I call a "BS" degree, in media production. But last Tuesday, thanks to Apple's App Store platform, I became a published app developer.

From start to finish, I've learned a lot. My app, Antithesis, is a simple affair, a twisted take on an old arcade form with (hopefully) just enough depth to keep it interesting. But even that simple app has taught me lots and lots of lessons, about everything from game and art design to how to develop in Objective-C and Xcode, and just what kinds of challenges and questions independent game developers on iOS face every time they come up with a new title.

It would be impossible for me to convey everything I've learned in just one blog post, huge as this one is -- this whole process, of learning iPhone development to the bare minimum point that I now know it, has taken at least a couple of years, and just working on this app specifically took a period of about eight months. I originally started Antithesis back at the 360iDev Game Jam last year (while attending the conference for TUAW), and I wrote up my earliest thoughts about the game over on my personal blog. To convey everything I've learned in that time would probably take just as long.

But I did want to try and share a few different big lessons I've learned here, and hopefully give you a glance at some of the insights and experience I've picked up from my (admittedly still very limited) foray into app development. Here's a few things I've learned from publishing an app on Apple's App Store.

1. It's not easy. But it's doable.

There is a kind of a mystique to being an app developer, apparently. By far, the number one question people have asked me once I tell them about the app is, "How did you do it?" Unfortunately, looking back, I can't really recommend the path I took. I basically learned by trial and error, by jumping into the process of development at different points, seeing if I could do what I wanted to do, figuring out that I couldn't, and then stepping back in the process even further. So given all of that frustration, here's how I recommend you learn iPhone development, if you want to:

First, learn Objective-C. This is the language on which all Mac and iOS development is based, so it's very important to know the ins and outs as best you can. If you already know C or C++, this will be easier, though there are quite a few quirks to deal with (or so I'm told -- I never learned either of those languages independently of Objective-C). I will echo Aunt TUAW's great advice (to me, actually) and say that if you want to learn this language, Stephen Kochan's "Programming in Objective-C" book is the way to go. Read that book a few times, learn what code objects are and how to manipulate and deal with them, and that will give you a good foundation.

Then, learn how to use Xcode. Xcode is the IDE (integrated development environment) that Apple provides its developers to use to create apps, and even in my limited scope of knowledge, it seems to be to be the best way to go about core development (if you want to do cross-platform development, there are lots of other options, but that's not what we're talking about here). Aaron Hillegass' book "Cocoa Programming in Mac OS X" was helpful here for me, but it's not strictly about iPhone development. It does, however, teach you the structure of iOS and Mac apps, and it will let you in on all of the little hooks and levers Apple has built in to its operating system code for you to manipulate in your own apps.

Honestly, the biggest education I got in just how Xcode works with the iPhone was browsing through all of Apple's sample code, and seeing what worked and what didn't there. The documentation for Xcode and the iPhone is top-notch, so if you ever have a question, there's usually an answer on Apple's site. For non-programmers, some of even Apple's walkthroughs can be a little intimidating (it's a lot of code jargon all strung together), but all of the answers are there, even if you sometimes have to ask questions in the very helpful developer forums. You get full access to all the developer forums with a $ 99 annual membership in Apple's iOS developer program.

Finally, I used Cocos2D to make my game, and the great "Learning Cocos2D" book is primarily responsible for that one. Cocos2D is an open source framework that makes game development much simpler, allowing you to reuse code for standard objects like sprites and text labels, without having to build those things yourself. Ray Wenderlich is one of the authors on that book, and his site has an incredibly helpful and well-kept list of tutorials for working with Cocos2D.

There is a lot of math involved in programming, and I am not good at math. There's also a lot of object-based thinking, and I've learned that I'm not too good at that either. So I won't say that development was "easy" at all -- it was often very frustrating, and there were many times when I'd spend hours trying to fix something simple, or I'd work hard on a chunk of code only to never actually use it in the game.

But it is very doable. If you are interested in development, and passionate about making an app, and you keep at it even when the impulse to quit arrives (as it probably will many times), it is very possible to make and release your own iPhone app. Apple has lowered the barriers to entry on the App Store so much, so that even if you have a (more than) full time job, like blogging on a popular website, you can build and develop an app in your spare time on nights and weekends.

2. The iPhone succeeds because it's so frictionless.

I could probably write books on what I've already learned about game design, and I'm sure there are still whole libraries left to learn. But the biggest lesson I took away from actually making a game (even after writing about them for so many years) is that iPhone users want and even expect direct, immediate access to whatever they're doing on that touchscreen. When I first put the game together, I did it using Apple's iOS simulator, which is a little app that comes with Xcode that lets you run iPhone software for testing on your Mac. So for most of development, I ran the game using a mouse or my MacBook's trackpad, not the actual touchscreen.

Once I actually paid the $ 99 to join the developer program and gained the ability to run my software on my iPhone, however, the experience was completely different. I was surprised by just how intimate and direct the touchscreen is. And my "beta testers" (friends and family who I gave my iPhone and told to play my game while I silently watched) had the same experience. When I first made the game, I designed it so that the onscreen "paddle" (that the player controls) had to be touched directly. But from the first person that played it, I realized that didn't work: Users sometimes couldn't hit the relatively small paddle with their fingers, and having to connect with it was just a chore.

So I changed the game, allowing the player to touch the screen anywhere to control the paddle, and that little fix removed that friction and made it much more accessible. Later, I added the ability for your paddle to fire a projectile, and a button to fire with, but players didn't get that you had to first lift your finger up and then touch the button -- they just expected multitouch, so I had to implement that as well (a little difference, but one that caused some headaches for me in code).

In short, users expect direct, clear interaction on the iPhone. I'm sure that's a software rule in general, but on that touchscreen especially, I was surprised by how simple, clear, and direct everything really had to be, and how when I made changes in that direction, how quickly and clearly users responded. In the end, I strived for an experience without any instruction at all -- something that anyone could pick up, and eventually figure out without help. Even developers can learn a lot there, I think: Apps like Angry Birds, Jetpack Joyride and Temple Run succeed in large part because they are so exceptionally clear and straightforward. Everything you put in your game or app that impedes that connection between what users want to do and what they're doing will cause problems.

When my beta testers played with the app for thirty seconds and then put the iPhone down and told me, "Well that's fun, good luck with that!" I knew I had things to work on. And when I got the game going so that people were playing for three minutes or more without taking their eyes off the screen, I knew I was doing it right.

3. Play to your strengths and weaknesses.

This is one of the most surprising things I have heard about my app: People really like the graphics. My biggest drawback as an app developer (aside from the fact that I'm still a beginner, of course) is that I have no real sense of design or style at all. I've never been good at putting visuals together, and that's been a source of frustration over the years, given that I've worked on the web so much. So it's very interesting to hear that people like the graphical look of Antithesis.

The night before I started putting the app together, I went to a bar in Denver full of old arcade machines, and I kind of marveled at those, at the experiences that old-school game developers were able to create with just a few pixels and one or two colors. That's what fueled my design more than anything else: How could I, as a guy with no artistic skill, still create something that was visually interesting. In the end, Antithesis only uses about four graphics (and -- spoiler -- three colors), but I tried to put them together in a way that got people interested.

That visual choice turned out to be one of the most striking things about my app. So this is good advice for any endeavor, I think: Know yourself, know your weaknesses and strengths, and work in harmony with them.

4. Apple runs the show (but does it well).

I haven't ever developed software for other platforms, but I can tell you that on iOS, at least, it's Apple's game. I've heard many stories over the years about the app submission process, and how closed-box it all is, and as far as I can tell, the stories are all true. When you're finally done with coding and designing your app in Xcode, you enter the world of iTunes Connect, a separate site which serves as the backstage, so to speak, for the App Store. This is the clearinghouse where you sign all the documents you need to set your app's price and make sure you can get paid when the app sells, and then create all of the screenshots and the metadata required to go on the App Store itself.

The whole process is actually surprisingly rote at this point -- you realize just how much of an equalizer the App Store is when you find yourself writing up an app description, entering up to only five screenshots (it doesn't matter if you're EA, a one-man shop, or Rovio; five screenshots per listing is all you get), and setting up localization data for all of the various App Stores you might sell your app in around the world.

Once you have entered all of the required metadata for your app, you upload what's called a "bundle" (created by fixing exactly the right settings in Xcode and then uploading what's basically a zip file of your app through Apple's software), and then the waiting game begins: Your app is boiled down to an icon that's yellow, green or red. If it's yellow, the app is waiting for approval -- either you the developer or Apple's submission team needs to check and approve it somehow. If it's red, the app's been declined, and you the developer need to go fix a problem somewhere, and possibly resubmit. And if it's (finally) green, then app is finally good to go.

My whole experience here was relatively painless -- I submitted my app on Sunday, March 18, and it finally went under Apple's reviewing eye last Monday, the 26th of March. Then, about eight hours later, Apple approved the app, and about 12 hours after that it appeared on the App Store. That's a pretty typical cycle, as I understand it. It can vary quite a bit (some developers say that if you've had multiple apps approved before, the process goes faster, and if it's a particularly busy time of year at Apple HQ, the process can be even longer), but it all ran smoothly enough for me.

So there's two lessons here: First, it's Apple's show for sure. I could have asked Apple to hold my app, post-approval, for me to release when I want, but if I wanted to get it out early or somehow speed up approval, there was no chance of that. Once you submit an app, it's in their hands entirely, and though my app didn't get rejected, from what I've heard, all you get is an email asking for a fix. The App Store is Apple's game, no matter who you are, and every developer with an app out there is just playing along as best they can.

But the second lesson is that Apple also has this whole thing down pat -- from start to finish, I never wondered what was wrong or got confused about what was happening with my app. I did grow impatient waiting for it to be approved, but Apple never passed off any mixed messages or let me feel lost in the system, somehow despite the fact that the App Store team is now overseeing millions of apps around the world. I was incredibly impressed with how smooth the entire process was. Yes, it was complex and complicated (there are an astounding number of settings in Xcode for export, and even the metadata setup in iTunes Connect has to cover every possibility for security), but the system is there, and it works.

5. It's a jungle out there.

So: Sales. Originally, I was going to release my app for free, just because the only goal was to see what the development process was like. But the more time I put into development, and the more I thought about that $ 100 development fee, the more I decided I should really get something back for my time. Not to mention that I wanted to see how sales worked on the App Store, and see how well I, after covering all of these apps and their sales for so long, could convince users to spend a buck on me and my work.

As it turns out, not very well.

(I agree, sharing sales after only a few days of release is probably a little early. However, I'm about to head out on vacation for a few weeks, and as you can see above, there's already a trend. I will update this post if anything changes.)

As you can see above, I had a nice big start in sales, but since then, as the app has slowly moved out of everyone's consciousness, sales have steadily dropped. You can count up the numbers on the side there, if you like, but so far, I have sold 511 copies of the app. At 99 cents a piece, that's about $ 506. Not bad, right? I might even be able to pick up that new iPad!

Not so fast. 30 of those copies were from promo codes - I gave out quite a few to reviewers and press, as well as a few on my Twitter and Facebook accounts for promotion. And not all of those sales were in the US -- quite a few of them were overseas, which means that they actually sold for less than $ 1, especially after Apple takes out conversion rates and various charges there. Of course, Apple takes its 30% cut, so by the time I actually get my check (which I probably won't for a week or two at least), total gross profits to me probably won't be too much more than $ 300 or so.

Which is great -- again, the goal for me was release, not to make a bunch of money. But after taking out the $ 99 developer fee, and remembering that I put in about eight months of work on this thing, that's not very much at all. I am lucky enough to have a job blogging here, but if I was an independent developer who'd quit his job to try and support a family by making iPhone apps? I'd probably start browsing the help wanted section, or at least start work on a Tiny Tower clone of my own.

And here's the most interesting part of my sales: These are sales from a very successful launch. Because of my story as a "blogger who made an iPhone app," Touch Arcade kindly posted about Antithesis, as did 148Apps and a few other great app and iPhone sites. The buzz on my app has been great -- almost all of the reviews are positive, and I built up a nice chunk of Twitter talk as well. My app's even been featured by Apple -- after showing up in the charts in the Arcade and Puzzle sections of the App Store (I even cracked the top 200 chart in Germany for a few hours after some favorable press appeared over there), I was featured at the top of the App Store's Arcade page alongside much bigger releases.

In short, as app releases go, this one's been about perfect. I've been very lucky, and everyone, from the press to my users to even Apple, has been very generous with their support. But that hasn't translated into sales at all. Certainly, the quality of the app could be better, but my best conclusion here is that even buzz isn't enough on the App Store any more. There are so many apps out there, and so many ways for users to split their attention, that you really need to hit it out of the park on everything from presentation to release timing to advertising in order to get those sales numbers moving. In that sense, then, as I understand it, the App Store is growing more and more similar to game development in general.

(One aside about sales as well: As journalists, those of us who cover apps will sometimes use listings in Game Center or even iTunes ratings or reviews as ways to determine actual app sales. But as I said above, I've sold 511 copies, I've currently got only 19 ratings in iTunes, and Game Center lists 278 players on my leaderboards. So the next time you see a blog extrapolating sales from either of those stats, know that they don't have access to the whole picture.)

I'm not quite done yet. I wasn't necessarily planning to update the app at all, but my biggest bug is that I accidentally put the wrong sorting setting on the Game Center leaderboards, so it turns out the lowest scores are appearing at the top, instead of the other way around. People have also asked for universal support, so I'm going to combine both of those things (and some other updates) into a version 1.1, which will be out as soon as I can get it done (probably in a month or so -- again, I'm about to head off to vacation right now). And I'll continue to watch sales; I think I'm done with promotion for now (and I haven't spent any money on advertising, obviously), but it'll be interesting to see if there's an audience wandering around the App Store itself, and if just having an app listed will bring users in.

So there's lots more to learn for sure. But this has been quite an experience already. It's been invaluable for me as a writer to work on this project, and stay tuned -- I will do my best to share lots more of what I've learned in posts here going forward as well.

Developing my first iPhone game: the inside story originally appeared on TUAW - The Unofficial Apple Weblog on Mon, 02 Apr 2012 15:40:00 EST. Please see our terms for use of feeds.