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.
Hardware
- 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.
Development Environment
- 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.
Programming language
- 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
super. - The equivalent to Java’s
thisis pretty muchself. - You can access the selector (method name) for the current method with
_cmd. - 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.
Application Frameworks
- 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).
Memory management
- 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.
GUI programming
- 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.
Debugging
- Xcode has a GUI for gdb, the well-known C (etc) debugger.
- For cowboy debugging, use the
NSLog()function; it’s a bit likeSystem.out.printlnin Java. It takes an NSString, so it would look like this:NSLog(@"Hello World!"); - 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.
Final Note
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.
Good article. A few ideas (and feel free to delete this comment after, regardless of whether you take them):
“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)”: There are differences that *will* bite you, and you should probably mention this here so developers are planning for a device right away.
“(literally; it’s C with a fancy preprocessor and runtime)”: This is not actually true anymore, is it?
“”xib” is used for iPhone stuff; it’s a newer format than nib”: This makes it sound like xibs are iPhone exclusive. This could lead to people inspecting Mac xibs, expecting them to be iPhone files.
Nice post dude.
Something that’s sorely missing in tutorials and books. Everyone seems to want to hand-hold and lead you through _how_ to program as well as the syntax and intricacies of the language in question.
We need a range of books detailing the realisation of a design into a piece of software rather than a ream of C/Java -> [target language] tutorials.
Matt:
Great work, sir. *doffs hat*
Stephen:
Objective-C is still just C with a new runtime. The compiler still generates pure C. All the fancy new stuff in ObjC 2 is still usable from pure C as well— the collector is usable anywhere, Blocks are plain C (with some extra ObjC magic *if* the runtime happens to be loaded), and properties are syntactic sugar with a little bit of runtime metadata storage.
Or was there something else you were thinking of?
Objective-C is not technically a preprocessor, but to a first approximation that’s not a bad way to think of it.
I’d describe a selector as a “method name” not a “method pointer”.
[...] Matt Legend Gemmell – iPhone Development Emergency Guide (tags: iphone_tip iphone_dev) [...]
[...] Matt Legend Gemmell – iPhone Development Emergency Guidemattgemmell.com [...]
Great post!
May I add that _cmd is probably better described as the current method’s name instead of a pointer to the current method? In fact, it is more of a name hash, but it’s definitely not a method pointer. That would be an IMP.
Hi all,
Thanks for the notes and comments – some tweaks duly made.
Generally, my aim when writing this was to describe things in the simplest way that was still a useful mental model in order to just get started quickly. For a ultra-quick-start guide like this, my gut instinct says that making a new thing familiar in at least a functionally useful way is more important than the absolute letter of technical correctness – particularly when it’s unlikely to have a practical negative effect.
In the specific example of the nature of the language, my aim was to both demystify this strange-looking language, and also to convey that it’s a superset of C in terms of availability of language features, keywords etc; I think that’s the most useful way to think of it in order to quickly get a grip on the language – the technical minutiae can readily come later for those interested enough to pursue them.
Thanks for commenting; keep them coming.
Awesome! A lot of my developer pals have been asking me about this stuff recently. Now I can just refer them to your blog post! Thank you!
Maybe a bit more about how what people usually call named parameters in Objective-C are not really named parameters would be useful. Also, how method calls are messages and what that means.
Oh, another thing. Number one most important Xcode tip: you can switch between .h and .m file using ⌥⌘↑. Maybe link to Cocoa Samurai’s Keyboard Shortcut List, or One Infinite Monkey’s Xcode Made Easy?
Glossed over the iPhone stuff; i’m not making apps any time soon. However I very much enjoyed the generic parts/objective-c areas – being a programmer you get curious about such things. Nicely done :)
Really excellent article, Matt. I especially liked the part at the very end. It’s amazing how many “idiotic,” “horribly designed” things end up second nature with a bit of experience.
[...] Matt Gemmell recently published the iPhone Development Emergency Guide – quite handy if you’re just getting into iPhone development. var addthis_pub = [...]
[...] http://mattgemmell.com/2009/07/14/iphone-development-emergency-guide [...]
Thanks for this write up, Matt. It gives me a framework and a starting point.
One online resource for Q&A is http://stackoverflow.com/ – it seems to have gained a large population of iPhone developers and is a great resource to figure out some of those nagging issues and questions regarding development.
I’ve heard that tools like analysistool and clangalyst are good for good for checking that newbie iPhone code adheres to standard conventions etc (but i’ve yet to try these tools myself).
Thank you for this information; very helpful.
[...] credit: mattgemmell.com [...]
[...] iPhone Development Emergency Guide A great guide for a developer new to the iPhone. [...]
Kudos! Exactly what I was looking for.
[...] iPhone Development Emergency Guide A great guide for a developer new to the iPhone. [...]
Love these comments… cant agree more!
* It’s probably not badly designed, it’s just temporarily unfamiliar.
* You’re probably not stupid, you’re just temporarily inexperienced.
Makes me feel better… Thanks Matt ;-)
[...] says that the iPhone Development Emergency Guide is aimed at “competent developers who haven’t written code for the iPhone platform before, [...]
Very modest and legendary. You need cloning. Nice work ;-)
[...] Matt Gemmell: iPhone Development Emergency Guide [...]
How about “Thou shalt hire an experienced iPhone developer and UI designer for at least a short while at the start of the project rather than for a long while at the end when 5K lines of code have been written but aren’t quite having the effect expected.”?
Nice. One quibble:
“Apple will take 30% of your profits, and will meet all distribution costs.” Actually, Apple will take 30% of your App Store *revenues*. They have no idea what your profits are, since they don’t know what your costs are beyond the 30% they take. So you can’t claim to be making no profits and thus have Apple take zero dollars for their cut.
And Apple doesn’t meet *all* distribution costs — if you have a web service that your app depends on, that’s up to you to have hosted and you will have to pay for the bandwidth, etc. Apple handles distributing the app from the App Store to your customers’ devices. They also take care of all of the costs associated with collecting payment from these customers for the app, and for any purchases made in-app using StoreKit.
But: overall a great, tight synopsis. Thanks!
Suggest to add: Before you submit an iPhone app to Apple, and preferably before you invest a lot of time in writing an iPhone app, take time to read and fully understand the terms and conditions of the iPhone developer agreement.
Many apps are rejected simply because they don’t meet those terms.
Also, learn about the requirements for artwork used in apps. A lot of rejections happen because of the artwork not meeting the requirements.
And remember, every resubmission almost certainly WILL take as long or longer to go through the approval process. Be as sure as you can that everything is perfect BEFORE you submit.
xibs are just nibs in xml format to play nice with SCM systems.
Great! I am just jumping in and this was just what I needed right now! A quick guide for grownups where to look.
[...] iPhone development overview for the seasoned programmer, and by the tone of it, one who’s in a goddamned hurry. [...]
Nice article, I came from Actionscript so everything was back to front for a start but now it’s great!
For those using Garabge Collector enabled platforms ObjC’s memory management can be quite tricky. I strongly recommend using the Clang or AnalyisTool to spot and help you understand what’s going on with it.
[...] ★ "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." [...]
[...] Matt Legend Gemmell – iPhone Development Emergency Guide (tags: development tutorial iphone programming) Share and Enjoy: [...]
[...] Matt Legend Gemmell – iPhone Development Emergency Guide Moves too fast to be useful to me now; mostly linking to it because the blog template is perfect for this article. (tags: iphone programming reference howto) [...]
[...] Thema Advanced Programming Interfaces wissen muss | Gründerszene The Digital Divide Network Matt Legend Gemmell – iPhone Development Emergency Guide Firebug Lite ARtisan Flash banner ad examples | BannerSnack Kuler The Codeless Website: Four [...]
Exactly what I needed – efficient and to the point. I started taking notes but soon realized I was just copying the entire article — it’s that meaty. Thanks very much for taking the time to share this.
[...] Matt Legend Gemmell – iPhone Development Emergency Guide (tags: xcode objective-c iphonedev iphone apps) Tweet This Digg This Add to Delicious Stumble This This entry was posted in Boostmarks. Bookmark the permalink. Comments are closed, but you can leave a trackback: Trackback URL. « links for 2009-07-21 [...]
[...] http://mattgemmell.com/2009/07/14/iphone-development-emergency-guide [...]
[...] http://mattgemmell.com/2009/07/14/iphone-development-emergency-guide http://www.stanford.edu/class/cs193p/cgi-bin/index.php [...]
[...] Matt Legend Gemmell – iPhone Development Emergency Guide Really quite a good quickstart – cleared up a few things for me, at any rate. (tags: iphone development objective-c) [...]
[...] Matt Legend Gemmell – iPhone Development Emergency Guide (tags: viapssteam iphone objective-c) [...]
[...] iPhone Development Emergency Guide by Matt Legend Gemmell – This is the best guide so far, for “[...] competent developers who haven’t written code for the iPhone platform before, and just want to get started right now.” [...]
[...] iPhone Development Emergency Guide [...]
[...] praktischen Ratgeber für angehende iPhone-Entwickler stellt Matt Gemmell unter dem Titel “iPhone Development Emergency Guide” zur Verfügung. Die ausführliche, in zwölf Themengebiete aufgeteilte Liste hilf [...]
Awesome! Will come absoluteley handy when I some day start. *bookmarkset*
Great primer, thanks!
I would add a couple of things to this: some introductory stuff about how events work in UIKit (stuff like FirstResponder, event chains, UIEvent/UITouch), and a quick primer on the Application Delegate concept, as this guy seems to be fairly central to how an iPhone app runs and takes event callbacks from the system.
(I’m still just barely getting started myself in iPhone development, so there are probably parts of this picture I’m missing, but as a n00b these seem like they might be important to at least be aware of)
[...] http://mattgemmell.com/2009/07/14/iphone-development-emergency-guide Author: Joerg Categories: Objective-C, iPhone Tags: iPhone, Objective-C Kommentare (0) Trackbacks (0) Einen Kommentar schreiben Trackback [...]
[...] Original source : http://mattgemmell.com/2009/07/14/iphone-developme…; [...]