This is an emergency guide to iPhone software development, i.e. a guide for competent developers who haven’t written code for the iPhone platform before, and just want to get started right now.
If you’re inexperienced in application development, this isn’t for you; try a good book instead. If, however, you’re confident of your ability to read documentation, do your research, and apply your existing skills to a new language, IDE, SDK and platform without the need for a preface, introduction and lecture on guiding principles, you’ve come to the right place.
No filler, no philosophy, and no bullshit – because you’re a professional, and you don’t have time for it. The clock is ticking, so let’s go.
For easy and speedy assimilation, this guide consists of simple lists of facts and tips as bullet points, split into sensible sections. Have a quick read through them, and then start coding.
- You have to use a Mac to develop iPhone apps. Specifically, you need an Intel Mac - iPhone development isn’t supported on PowerPC Macs. There are hacks to make it work (at time of writing), but if you’re serious about it you should probably just get an Intel Mac. Doesn’t have to be brand new; all new Macs have been Intel-based for years now.
- You’ll need the iPhone SDK, which is free from Apple when you sign up as an iPhone Developer.
- It’s obviously handy if you have an iPhone or iPod touch too, though you can certainly get started without one (the SDK includes a Simulator you can run your code in).
- Xcode (your IDE) has an Eclipse-like all-in-one UI by default (though you can split it all out into separate windows if you like), but its documentation browser is a separate window. Both those primary windows work best when large. You’ll also need to at least occasionally be using Interface Builder for your GUIs, and you’ll be running the iPhone Simulator often. Given all these demands on your screen-space, you may find it helpful to have a big monitor, or even two side-by-side. Your Mac will automatically extend your desktop onto multiple monitors as soon as you connect another one.
- You have to use Xcode as your IDE. You can use an external text-editor of your choice alongside it if you like.
- Xcode has built-in help and API listings. Look in the Help menu, and choose Documentation.
- It also has a Research Assistant feature which shows info about whatever class-name or type your text insertion-point is in or near (including links to Apple sample code which uses that method/class/etc). That’s in the Help menu too.
- Option/Alt-doubleclick on a class or method to go to the relevant documentation.
- Apple/Command-doubleclick on a class or method to go to the place where it’s defined.
- Press the Esc key to autocomplete. You’ll get a popup list of options if necessary.
- There’s a graphical debugger (a UI on gdb), and a tool called Instruments which lets you inspect just about everything from file access to memory usage to performance.
- Xcode provides native GUI support for Subversion, CVS and Perforce. You’re also free to use any SCM system you like, via the command line. Xcode won’t cause any damage to your SCM system’s special/hidden files.
- You have to use the Objective-C language.
- It’s just C, with some extra stuff (literally; it’s C with a fancy preprocessor and runtime).
- Objective-C syntax looks weird, but it’s only visually different.
receiver.doThing(foo, bar, baz)in Java would be something like
[receiver doThingWithFoo:foo andBar:bar andBaz:baz]in ObjC.
- Objective-C just splits the method-name into pieces and intersperses those pieces with the actual arguments, so it reads like a sentence. It’s verbose, but it’s more explanatory. Accept it and move on; you have auto-complete to help with the typing.
- Because it’s based on C, object types aren’t automatic pointers like they are in Java; you have to explicitly create them as pointers. This is usually just as simple as putting an asterisk between the class name and the variable name when you declare an object.
- As you might expect, that breezy glossing-over hides some complexity, and causes me some pain because you really should learn how it actually works. There’s plenty of tutorial material online about pointer syntax in C. Try reading it sometime.
- Primitives like int etc behave as you’d expect, because it’s just C.
- If you want to use dot-notation to access instance variables, you can. You just need to declare a “property” for that instance variable first. Read the docs on properties.
- Accessing properties is actually just calling appropriate automatically-generated getter and setter methods on the object (literally). You can override those methods if you want to; it’ll work as you expect.
- A few specific things you’ll want to know about:
- You can call the superclass’s implementation via
- The equivalent to Java’s
thisis pretty much
- You can access the selector (method name) for the current method with
- Those last two are implicit parameters to every method; it’s not magic.
- You can call the superclass’s implementation via
- Strings. About 99.99999% of the time you’ll want NSString objects instead of raw C strings. Objective-C has a nice feature whereby you just put an
@symbol before a string to make it an NSString, like
@"this". Just do that by default, every time; it’s pretty much always what the APIs will expect.
- There are two main frameworks you’ll be using: UIKit and Foundation.
- These aren’t “Cocoa” (that’s the Mac desktop development equivalent, consisting of AppKit and Foundation), but they’re extremely closely related and in many cases are near-duplicates. If you’re looking up documentation online, be sure you’re looking at docs for the iPhone version of Foundation, and not the Cocoa (Mac) version.
- Classes to do with actual visual controls etc (including windows, views, buttons, tables, etc) begin with “UI”, and have names like “UIButton” or “UIWindow”.
- A lot of the non-visual stuff is in classes beginning with “NS”, including object types like NSString, NSNumber, NSArray, NSDictionary (a hashmap class) and so forth. There are also some other frameworks, including a fair few C-based ones.
- There’s a convention whereby data-structures are immutable (not editable) by default. In almost every case, if you want an editable version of that same type then it has a mutable subclass, whose name will be of the form “NSMutableArray”, “NSMutableDictionary” and so forth. You can often call
mutableCopyon the immutable version to get a mutable one with the same contents. Pay attention to memory-management rules (mentioned below) when you do that.
Saving and Loading
- For saving preferences or settings, look at NSUserDefaults.
- For saving files, look at NSDictionary’s ability to read and write XML property-lists (for saving basic data-structures containing standard object types), or at NSData (for more complex and/or custom objects).
- You have to manage your memory manually. There’s no garbage collector.
- There are simple rules and conventions; follow them at all times, and without exception.
- This is one area where you just have to read the docs. There’s also a good tutorial here.
- Don’t make it harder than it actually is. You can get the hang of this in an afternoon.
- There’s a really nice GUI builder called Interface Builder, included with Xcode. When people mention “IB”, it’s Interface Builder they mean.
- You can also make your GUI programmatically if you want, or mix both techniques. Neither method is “preferred”; IB is a tool that you can use if it helps you.
- The files which Interface Builder generates are called “nibs”. The actual file-extension for nibs is often “xib”, but can be “nib” too. “xib” is used for iPhone stuff; it’s a newer format than nib. Interface Builder will just do the right thing.
- Code can be connected to IB-created GUI via “outlets”: instance-variables with IBOutlet before their type, on classes which you connect in IB. Read the docs on it.
- IB-created GUI can be connected to code via “actions”: methods which take one parameter of type id, and return the type IBAction, on classes which you connect in IB. Read the docs on it.
- To make the connections you need to have an instance of the appropriate class in the nib document. If it doesn’t exist, drag a yellow Object cube from the Library, then use the Inspector to change its class to the correct one. That’s enough to create an actual instance of the class at runtime.
- You make connections by right-click-dragging in Interface Builder. You can also just right-click to see and modify a list of all connections for an object.
- UI in a nib file isn’t like a specification or template, and it isn’t code-generation either; it’s actual instances of objects, serialized into a file for later reloading. These are real, actual objects.
- There’s zero magic in Interface Builder. The first/main nib is loaded by the UIApplication class, and its name is read from a property-list file in your project; you can see it and take a look. That’s how the main nib gets loaded; it’s just a handy default behaviour. You can load as many other nibs as you like.
- Xcode has a GUI for gdb, the well-known C (etc) debugger.
- For cowboy debugging, use the
NSLog()function; it’s a bit like
System.out.printlnin Java. It takes an NSString, so it would look like this:
- You can put printf-style formatting characters into it, and add the relevant variables after the string just like you’d expect. The syntax is identical to printf:
NSLog(@"You are %d years old", age);
- You can also output arbitrary object types using the
%@formatting character. Many hierarchical datastructures like NSArray and NSDictionary will be pretty-printed automatically.
- The equivalent of Java’s
String toString()method is
-(NSString *)description. Many of UIKit and Foundation’s classes provide helpful default implementations of this. The root class’ implementation will simply print the object’s class-name and address in memory.
- The console output is within Xcode itself, either in a separate window or in a split pane (depending on how you’ve got Xcode set up).
Using the iPhone Simulator
- The Simulator is included with the iPhone SDK.
- It is NOT cycle-accurate. Not even remotely. Your animations will be much faster in the Simulator than on the device, so don’t ever judge performance from the Simulator.
- It doesn’t have all the apps/facilities of an actual iPhone. For example, it doesn’t simulate things like the accelerometer.
- Don’t try to submit apps to the App Store that you haven’t tested on actual devices.
- Your Mac’s keyboard works for text-entry in the simulator. Your mouse works for clicking and dragging. You can simulate two-finger input by holding down the Option/Alt key.
- The Simulator has menu-commands to rotate the device to landscape and back to portrait, and also to simulate a memory-warning so you can respond to that situation (no garbage collector, remember?)
Deploying to a device
- You have to have a certificate in order to sign your code to make it work on a device.
- This is true for development as well as for actually deploying on the App Store.
- You have to pay a yearly fee ($99) to get the ability to create such a certificate.
Getting onto the App Store
- If you haven’t yet signed up as a paid iPhone Developer to get a certificate, start now.
- You can’t just do it at the last minute, once your app is ready - it takes time.
- You’ll have to provide various pieces of information, and enter into a distribution contract with Apple. Apple will take 30% of your profits, and will meet all distribution costs.
- Give yourself at least several days to do all this.
- Apple has to approve your app before it goes onto the App Store. This can take any amount of time; right now it’s somewhere around 1-2 weeks. You can’t speed this process up; you just need to wait. This is an inherently and unavoidably flexible part of your deadline, so don’t over-promise.
- This approval process happens even when you submit an update to an existing app, every time.
- Your app will be run by an actual human.
- If your app is rejected, you’ll almost always be told why. You can make suitable changes and re-submit it.
Getting more help
When you need help, do what you’d do on your own platform:
- Read the official docs. There are Getting Started guides as well as raw API documentation; it’s all there when you log into the iPhone Developer site.
- Look at the sample code provided by Apple.
- Search the official forums, and post a question if necessary.
- Also try third-party forums.
- Use Google; someone might have blogged about this.
- Buy a book; there are a few out there now. Use Amazon reviews to see what’s worth buying.
And apply the usual common-sense principles when seeking help:
- Don’t ask your questions here; this is a blog, not a support forum. Likewise, don’t email me your questions.
- Do your research before asking anything. Be prepared to answer the question ”what have you tried?”
- Be precise. If you’re coming from another platform, say so and mention which one - you might be using terminology from your platform which is slightly different in the iPhone development world. If you tell us where you’re from, we’ll figure it out.
- Be concise (but not at the expense of precision).
- Be polite and respectful; it costs nothing, and you’ll get more and better answers.
When learning a new development platform, you’ll inevitably encounter some frustrations along the way. Try to remember that these two statements are almost always true:
- It’s probably not badly designed, it’s just temporarily unfamiliar.
- You’re probably not stupid, you’re just temporarily inexperienced.
Keep those in mind. Now go get started.