Well, how to write good ones, anyways. This article describes how programmers can make good iOS apps. It kind of assumes they can design them, too. However, I recently realized two things:
Why should you listen to me? Well, I’m no expert in writing iOS apps. No, wait. Yes I am. I taught a course at my university on the topic. Let’s carry on, then.
You need to learn Objective-C. Go mess with MonoTouch or whatever if you want. Then go grab a fruit roll-up, think about what you did, and realize you should have just learned Objective-C. You can watch free lessons on iTunes U from Stanford. If you’re new to iOS apps and Objective-C and are serious, drop $100 to get a dev license and download Xcode 4.2 and never look back. Seriously, it’ll be worth it not to learn about manual memory management.
By the way, you better love Model-View-Controller. I mean love it like you want to marry it and raise a whole family of models, views, and controllers with it. If you don’t like to use it, go back to C. We’re civilized here..
The next step is to try to write an app. Anything you want - but remember this is only an attempt. You don’t want your first attempt to become something you have to maintain years later.
You think because you know Objective-C you know how to write a real app? Sit your ass back down because you’ve got to master UIKit first. I mean master it. It’s not a terribly hard or overly complex framework, but it’s something you have to know inside and out. If you don’t completely understand the lifecycle of a UIView instance, learn.
Seriously.
This will bite you in the ass every time. I’ve seen smart developers invent their own frameworks because they never bothered to learn UIKit and my god they were awful at it. You should be able to stand at a whiteboard and trace out the hierarchy of a keywindow for navigation-based, tab bar-based, and view-based apps, as well as describe the view lifecycle. You should know why adding a subview doesn’t mean its controller’s viewDidAppear: method ever gets called. You should know what awakeFromNib is and when it’s appropriate to use. And so on.
You can use UIKit to make your apps look nice. But it takes some domain-specific frameworks like MapKit, CoreLocation, and CoreData to make your apps useful.
The frameworks you decide to learn depend on the kind of app you want to make. I wrote a app for the last New Brunswick provincial election that displayed stuff on a map so I learned MapKit. There are programming guides, tutorials, and code samples available from Apple for about every framework they have. That’s a good place to start.
API calls can be done dozens of different ways. I can’t tell you which way is best for your app. You just have to try to write data-retrieval methods from your CoreData store or Web API with (somewhat paradoxically) too few and too many layers of abstraction and learn how not to do it in order to learn how to do it the right way for you.
If you’re not #importing <QuartzCore/QuartzCore.h> in your precompiled header file yet, your apps probably look fine. But they probably look like every other app, too. Also, if you don’t know what a pch file is, google it. It’s important.
If you want to make your shiny app intuitive and easy to use, you need CoreGraphics and CoreAnimation. If you don’t want to make your apps intuitive and easy to use, I hear OpenOffice is looking for some Java developers.
CG/CA isn’t that hard to learn. Basically, your UIKit stuff is rendered by this layer, which is in turn rendered by OpenGL, which we don’t care about because we don’t hate ourselves. Basically all you need to know need to know about the CALayer, CAGradientLayer, and CAAnimation classes and CG types, like CGRect/Point, where to use them, and where not to use them. Oh, and some CoreOS memory management stuff.
Gosh.
OK, fine, CG/CA is kind of hard. But it is so worth it.
You need to be aware of a few things. Foremost is that, while you’re developing on your shiny new iPhone 4 or iPad 2, your poor users might still be stuck on an iPhone 3G. And that sucks. But you can make a really good app that works well for them, too.
Doing things like turning off a CALayer’s opaque or masksToBounds properties makes your app slower. Like, way slower, brah. Only do it if you have a really good reason to. There are some awesome effects that you can achieve really easily with CG/CA, but you need to be aware of when it hurts performance.
Testing sucks. You could take the easy path and let your (paying) users test your app for you in the wild, but your ratings are going to suck. More importantly, you’ll be an awful person.
At least try to test your app. Give it to someone and see how they use it. Not someone who’s used it before, someone new to it. Observe when/where they get frustrated or confused and fix those parts of your app.
That’s it! If anyone has any suggestions, please leave them in the comments!