What programming skills I need to become an iPhone developer?

Question

I have almost 3 years of programming experience in windows world. I know C and C++ (part of my college education) and have been working on Delphi and C# professionally.

I am thinking about learning some iPhone development stuff. What programming/software skills I need to dive in?

Answer 1

You will need a mac with at least leopard installed (that's the OS). Then you will need to install the iphone sdk/development tools which you can get from the apple development site.

The language you will use is called objective-c which is superset of c++. The Ide is called xcode and another tool you will use is interface builder. All these tools are free and available from apple.

Answer 2

The skills in which you have appear to be right for the task.

The hard thing about iphone development is that gui is so important, the buttons need to be placed so that when you touch them they don't cover to much of the screen. Also the links need to be large enough that there not to difficult to touch. But other than that it just like programing for any other environment.

Answer 3

The iPhone uses Objective C. If you know other C-based languages (and I see that you do), it should be fairly easy to pick up the syntax.

Answer 4

• How to use Objective-C (memory management, function naming conventions and so on), and cocoa framework (NSDictionary, NSArray, NSString)

• How to use Xcode to develop all that cool software

• How to create GUI using Cocoa-touch - uikit

• And once you master that you need to learn how to use specific frameworks that you want to utilize e.g. how to access iphone functions/components like addressbook, play music/video, download images, maybe geolocation, graphics ... or whatever you plan to be developing (games, tableview styled applications, video/music players, web kit - access to web ...)

There is pretty good documentation online to get you started with any of the above. You'll probably be surprised that the development in mac is easier/better/faster then on windows, it is very powerfull, you'll have fully featured apps in no time.

Answer 5

I can highly recommend the Stanford lectures - if you can manage to sit through all the lectures (Even the stuff you think you know already) then you will be well prepared.

http://www.stanford.edu/class/cs193p/cgi-bin/index.php

I would also do the excercises from there - very worthwhile - get a couple of simples projects under your belt like this before tackling your own project.

Answer 6

Coming from a C# background myself I found that most of my skills transfered over pretty smoothly. What you need to focus initially is memory management. There is no garbage collection when doing iPhone dev, so there is a lot to keep track of when you first start.

The other area where I had to make some adjustments is the fact that you are developing for a mobile device with limited resources as compared to developing an application for a desktop. Though this is more of an issue of moving from developing for desktops to developing for mobile apps it still is a consideration. You're code will have to be light and tight.

You'll also need to get a good grasp on Interface Builder. With Visual Studio you can layout your UI, click on an object in your UI and your taken right into a function. In IB it's a lot different, you can't double click on say a button and have IB take you right to an ONCLICK function for that object. So in regards to UI design your have to get use to a different work flow when building out your GUI componants.

Lastly, having come from a C# background I had some struggles getting use to Apple's online documentation. If you do any kind of Microsoft development you're use to MSDN, Apple's offering, in my opinion, is lacking many of the features of MSDN.

Answer 7

One thing that may be unfamiliar for some folks coming from .NET/Java is the use of pointers and the critical role they play in using Cocoa and other iPhone frameworks. Get very comfortable with pointers before diving into Objective-C and Cocoa. Since you're up on C/C++, you should be all set.

Answer 8

DotNetRocks did an episode about what iPhone development is like for .NET devs:

http://www.dotnetrocks.com/default.aspx?showNum=454

::::EDIT::::

They've done another episode on it now from another perspective:

"Alert listener and iPhone developer Glenn Howes gives us the real story on iPhone development from a different perspective."

http://www.dotnetrocks.com/default.aspx?showNum=468

Answer 9

Here are some related questions and answers:

• http://stackoverflow.com/questions/7571/cocoa-and-objective-c-resources
• http://stackoverflow.com/questions/21464/recommended-iphone-development-resources
• http://stackoverflow.com/questions/405568/are-you-doing-iphone-development-how-do-you-learn
• http://stackoverflow.com/questions/885198/beginning-iphone-development
• http://stackoverflow.com/questions/927186/what-is-the-best-place-to-learn-iphone-development-with-xcode-and-objective-c-bas
• http://stackoverflow.com/questions/928516/best-way-to-start-learning-cococa-in-iphone-or-osx-espeicaly-getting-the-big-pic
• http://stackoverflow.com/questions/758748/best-book-or-article-to-learn-iphone-development
• http://stackoverflow.com/questions/370427/learn-obj-c-memory-management
• http://stackoverflow.com/questions/449101/iphone-development-books
• http://stackoverflow.com/questions/913352/iphone-game-development
• http://stackoverflow.com/questions/720901/learning-iphone-game-development
• http://stackoverflow.com/questions/783321/whats-the-best-way-of-learning-iphone-programming-when-coming-from-java

Answer 10

Knowing a c-like language is all you need.

People place too much emphasis on learning objective-c when it really
isn't a huge paradigm shift, it's just a c with square brackets and a
more dynamic type system. Even though it's compiled, it feels like a
scripting language.

Also, you only have to use it to interface with the iPhoneOS.
Yours nuts and bolts code can be in whatever language you like.

95% of my codebase is c++.

Answer 11

When I teach Cocoa to folks with a C++ background, here are the key issues I find they have:

• Naming. Correct naming is critical in Objective-C. The compiler will not save you. Learn the naming conventions and follow them.

• Dot notation. Dot notation is pleasant to type for experienced Cocoa developers, but extremely confusing to new developers. Dot notation does not mean "get or set the ivar of the object." Dot notation means "pass the message -foo or -setFoo: to the object." These two statements seem very similar, but are in fact radically different. Most importantly, foo and self.foo are not the same thing, though often they may appear to be the same thing. Assigning to the latter will generally retain the object, while the former will not.

• Following up on dot notation, accessors are not mandatory in ObjC, but should be. Always, always use them (except in the accessors themselves of course, and in -dealloc). Do not access your ivars directly. Not even if you see sample code doing it.

• The reason for all of the last three issues is memory management. If you will follow these last three rules, then your memory management will be easy and you will have very few problems. If you do not, and C++ folks often are very bad about this because C++ has such sloppy naming conventions, then you will have terrible memory management problems.

• Objective-C can use C++. I recommend strongly, however, that you keep your C++ and Objective-C separate, and have only a thin translation layer in Objective-C++. Learn to use NSArray rather than vector, etc.

• C++ developers often get confused about how Singletons are used in ObjC. If you understand the full, correct Singleton pattern, then you need to understand that ObjC generally doesn't use it. It's ok to have a static in ObjC that holds the "shared instance" and that you never free. OS X (phone and Mac) will recover the memory for you at program termination. It's ok to have a "singleton" that can actually have multiple instances (NSNotificationCenter and many other objects allow this). There is seldom reason to really ensure that you are the one and only instance of the object (if you're overloading -release, stop, even if you found the code to do it on Apple's site). "Singletons" are generally just an instance that happens to be stored in a static and is returned when you asked for the "sharedController" or "sharedFoo" or whatever.

• Threading is somewhat rare in Cocoa. Most things are done on the Run Loop, which is cooperative multi-tasking. You get asked something, you respond as quick as you can, all on one thread.

For C developers:

• I push C developers to stay away from Core Foundation (things that start CF). Core Foundation is very useful, but it's too easy to let it become a crutch to avoid actually learning Cocoa. It's better to first learn Cocoa in ObjC, and then come back and use Core Foundation when you need to.

• Do not be afraid of long descriptive names. Get used to them. Love them.

• Embrace objects. Even the C-based Core Foundation is basically object oriented in C syntax.

• Don't forget your C. A lot of Objective-C is done in straight-up C. It's just C, really. C++ isn't, but Objective-C really, really is just C.

• Objective-C is really C, but Cocoa isn't. Cocoa is Smalltalk. And so you really need to study the Model-View-Controller paradigm and live it every day.

Java/C#:

• Java developers seem to have the hardest time with dot notation. I often just flat-out ban dot notation for former Java developers. Don't use foo.bar, just use [foo bar] and [foo setBar:baz]. You will save yourself a lot of headaches. A Java background just seems to make it much harder to break the idea that dot notation is really a method call and nothing else.

• Even more than C++ developers, I have to teach Java developers that they aren't going to spawn threads for things. Use the run loop, and do thing asynchronously with callbacks. As a beginner, you may never need to spawn a thread. I write a lot of complex code, and still only spawn maybe a couple of ObjC threads in a major program.

• C# developers (and Windows developers in general) have trouble with Interface Builder. When you create a button in Visual Studio, it writes a bunch of code for you. IB does not write code. IB serializes an object. A NIB is just an object archive. At run time, the NIB is read, and the objects are deserialized.

• Objective-C does not subclass a lot. It uses helper objects (delegation, datasources). If you have a special window that can't be closed except in certain circumstances, you don't subclass NSWindow (you almost never subclass NSWindow for anything). You assign a delegate to the NSWindow instance, and when it wants to close, it asks its delegate -windowShouldClose:.

• .NET has lots of objects that do similar things in different ways, and each time a new rev comes along, they give you a new set of objects that do those same things in new ways. .NET objects tend to be really smart with lots of little fiddle knobs to configure them. Cocoa objects are dumb, and that's why I love them so much. A table view in Cocoa doesn't know anything about querying SQL servers. A table view knows how to draw a table. It asks its datasource for what that data should be, and it asks every time it gets ready to draw a cell. It asks its delegate how tall each rows should be and whether a given row may be selected, just at the moment it needs the information. This is backwards of how .NET generally does things.

And that leads to my biggest point for developers coming from anywhere that isn't Smalltalk:

• It isn't about you. It isn't about your code. And it isn't about your code doing this or that. It's first about the user and responding to the user. It's second about your code responding to the framework. You don't usually tell the framework what to do. It asks you for things when it needs something. You sit and wait for it to talk to you. You're not in charge. You don't control the runloop; it controls you. You register to be told when things happen, and you indicate that you're the object who knows something about something (data for a table for instance). And then you let go, and let Cocoa do the rest. It's a very different world. I like it very much.

Answer 12

And don't forget Unity 3D's iPhone development kit, if you want Open GL iPhone apps made easy.

www.unity3d.com