Jordan Lev, an applications developer for Babcock and Jenkins, recently gave a talk at South by Southwest 2009 in Austin, Texas, called “iPhone Development for Experienced Web Developers.” This talk was an informative presentation on a web developer’s experience in diving into iPhone applications development and working with Objective-C, and included suggestions for those interested in getting involved in developing applications for the iPhone.

Jordan was kind enough to offer his time and experience here on TheBitsource.com, and talks about the most important things he learned in getting into iPhone development as a person with a web development background.

Slides from Jordan’s talk at SXSW 2009 are available at http://marketinglab.bnj.com/2009/03/bj-sxsw-sro/.
For a description of Jordan’s talk at SXSW, see http://sxsw.com/interactive/talks/panels?action=show&id=IAP0901123.

The Bitsource: In your presentation at South by Southwest 2009, you mentioned that Objective-C developers are rare, yet there are many iPhone developers. Do you believe the majority of iPhone developers come from an Objective-C programming background?
Jordan: I have no idea, but if I had to venture a guess, I’d say that a majority of the top-notch / more polished apps were developed by people with a background in Objective-C (or, more accurately, Cocoa apps for the Mac). But the platform has definitely attracted a lot more developers than the Mac ever did.

The Bitsource: How difficult is it to learn Objective-C, coming from a web development background? What are the most difficult concepts to get a hold of?
Jordan: Pretty difficult. The most difficult thing to get a hold of is memory management. The second-most-difficult thing is what I refer to as the “non-linear code execution” — meaning that with most dynamic web languages / platforms (PHP, ASP.NET, Ruby, etc.) you have a very clear “entry point” to the code, where you can conceptualize that a page is loading and that a certain method or file will be called or loaded, and code will be executed in order — but with Cocoa, you have all these “delegates,” which are called not at specific times and in a specific order, but when the system is ready to call them. So it can be tricky to figure out the order of operations. An example is displaying a progress indicator (like a spinning circle). On a web page, you might have some JavaScript that makes an XMLHttpRequest for data, and before that request is made you show a div containing an animated gif. Then, when the request has completed, a callback function is run, where you process the response and then hide the div containing the animated gif. In this case, the DOM is updating in “real time” — the animated gif gets shown and hidden at the exact point in code that you tell it to show and hide. But in Cocoa, you can’t actually force the screen to refresh at any given point in time. Instead, you’re putting a request to have the display updated into some kind of queue, and the system decides when it wants to update the screen, at which time your requested update will take effect. This may or may not be the specific time you actually need the display to update!
The Bitsource: What has been your experience in designing applications in Objective-C that run on the iPhone, and how does that compare with designing web applications for the iPhone browser?
Jordan: At first I thought that building full-blown Cocoa apps was preferable to designing web apps for the iPhone browser. But after struggling to learn Cocoa and Objective-C, I have a different opinion. For certain kinds of apps (mainly front-ends to web services), it would be much easier to simply design an iPhone-optimized web page, and you wouldn’t necessarily lose any functionality or “prettiness” (I was totally blown away by Google’s RSS Reader, for example). You can’t have web pages in the app store, but you can get around this limitation by building a really simple app that just contains an embedded Safari browser and connects to your web pages.

Of course, for other kinds of apps (most notably games), you will want to build a full-blown Cocoa/Objective-C app.

The Bitsource: What new features in the iPhone 3.0 operating system have you found to be of interest or radically different from the previous platform?
Jordan: From what I can gather, all of the features are providing new functionality, and not changing anything that was there before (so nothing is radically different — just “more”). As for the most interesting feature, I think the ability to interact with external devices connected to the iPhone is going to unleash a whole slew of new and innovative things — I think it will be as big a leap (in terms of new kinds of functionality for the end user) as the original app store launch was.

The Bitsource: Do you think the API for iPhone applications will need to become more web-centric in order to remain competitive?
Jordan: I don’t think it makes sense to change the API (Cocoa), but I definitely think that if they allowed you to program against it in a more dynamic (and memory-managed) language, the developer base would grow enormously.

The Bitsource: How can you evaluate whether or not someone is actually capable of developing iPhone applications? Would such a person be able to deem himself/herself an “iPhone developer”?
Jordan: I would evaluate this in the same way I’d evaluate anyone’s ability to learn a new programming language or platform — do they love to program, are they intellectually curious, and do they have the time/patience to work through the inevitable challenges?

The Bitsource: If your application has performance issues, will it be accepted by the iPhone application store?
Jordan: Depends on how bad [the issues] are — bad enough to be noticed by Apple during the review process? :)

The Bitsource: What general suggestions and experience can you offer to those who are interested in building their own iPhone applications?
Jordan: Start out really simple. At first, build an app that only has a single screen, and that utilizes all of the built-in controls (tables to list data, text fields and buttons for interaction). After that, start adding more complexity — multiple screens, non-standard controls, animations, etc.

As for memory management, keep in mind that if you are the one calling “alloc” and “init” on an object, then you are the one that needs to “release” or “autorelease” it when you’re done. If you’re not calling “alloc” or “init” (i.e., you’re getting an object that is returned by a function), then you do NOT call “release” or “autorelease.” This will make sense when you start coding.

Further Reading:

Objective-C programming language: http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html
Apple iPhone: http://www.apple.com/iphone/
Apple iPhone Dev Center: http://developer.apple.com/iphone/