Filed under: Developer, Apple, iPhone, Beta
Dev Chair : iPhone SDK experience
Consider that I am learning three new things simultaneously: programming in Objective-C, learning how to use Xcode, and what is available in the iPhone SDK, I am going to describe the whole experience instead of just confined to the SDK.
Xcode
The main problem I have with using Xcode comes from the years of experience I have working with Visual Studio and ReSharper. Almost all the most frequently used keyboard shortcuts are different between Xcode and Visual Studio/ReSharper. Some are similar or logical (build is Cmd+B, for example), but others are just completely different (show method list is Option+Escape in Xcode vs. Ctrl+Space in ReSharper, or next placeholder is Ctrl+. in Xcode vs. Tab in ReSharper).
I've also yet to figure out (or taken time to figure out) some of the most frequently used document navigation keystrokes in Xcode. Switching between code files in Visual Studio (or any word processor in Windows for that matter) is Ctrl+Tab. And to switch between Visual Studio and MSDN Help is Alt-Tab because MSDN Help is just another application in Windows. In Xcode, the OS X standard keystroke of moving between windows within an application (Cmd+`) does not work. This also does not work on the Xcode help documentation viewer. Nor Cmd+Tab! While I have the screen real estate on my Mac Pro to arrange both Xcode and help viewer side by side, I do not have that luxury with my Macbook Pro. Thus, I have to take my hands off the keyboard and use the trackpad/mouse every time I have to read the documentation, likewise with navigating through code and code files.
The Language
There is nothing wrong with Objective-C as an object-oriented programming language. Unfortunately as it is built on C, a lot of what is considered unnecessary nowadays remains. Why in the year 2008 would I am still required to have a header file and have to declare everything twice? The 'synthesize' keyword helps but it feels like a hack than a solution. And call me lazy but after working with newer languages (C# and Ruby) over past 6 years, worrying about pointers makes me feel like I'm back in the 90's. Similarly, having to manage my own memory allocation/deallocation takes away from the job of solving problem, instead I have to worry about the mechanics of programming. However, I completely understand why the garbage collector that is new in Objective-C 2.0 is not in the iPhone since the garbage collector is an extra process that may be too power hungry in a phone.
What has really slowed me down is the un-uniformality of the syntax. In C#, I can access class methods or properties in very similar way. For example,
// Method
bool result = Foo.DoSomething();
// Property
string name = Foo.Name;
You can see I don't have to worry about whether I'm going to call a method or access a property when I start typing. I start with 'Foo.' Then I can decide whether to use method or property after the period.
On the other hand, Objective-C uses different syntax.
// Sending a message to object (i.e. Calling a method)
BOOL result = [Foo doSomething];
// Property
NSString *name = Foo.name;
So I can't type 'Foo.' then decide what to do. I have to decide beforehand whether I want to use a method or property. It would be fine if Xcode code completion is clever enough to insert the square brackets for me if I type 'Foo doSomething', but unfortunately it does not. Thus, as I explore the unfamiliar territory of the iPhone SDK, instead of using the SDK features and concentrate on building an iPhone app I wound up having to take my mind off the problem and constantly moving back and forth to add/remove square brackets. Any competent programmer will tell you this can get a bit annoying after a while.
This is just my unfamiliarity with the Xcode environment and I am sure someone will quickly tell me what a moron I have been and point me to all the keystrokes! Similarly with Objective-C, I am sure I will get used to its syntax after working with it more over time. But this does illustrate the obstacle that developers who are new to Mac development will encounter.
IPhone SDK beta
Despite the 'beta' label, the iPhone SDK is pretty polished. All the infrastructure classes and controls are there, along with all the relevant documentation, to allow developers to build a great looking iPhone application. Apple has also provided some great iPhone sample apps to show us the way. I was able to build a simple application using the table view within matter of hours, just by reading the documentation and looking at the sample apps.
But after digging a little deeper I have found that some standard iPhone controls have not been included in this beta. For example, the editable table cell in the Preferences app with the text label on the left and text field on the right? Sorry, you will have to build that yourself. The "+" button at the top right corner of the Calendar app? Sorry, you will also have to build that "+" image yourself. How about the up and down arrows in the Mail app? Same there. The large nice looking green button in the Clock application? You guessed right. You will need to create your own green bitmap and stretch it out for the button. Why is this not just a property of the UIButton class? All I want is a standard looking green (or red) button with some white text. The only things that I should need to do are: create the button, set the color(s), set the text and that's it.
On the other hand, integrating your application's preferences and settings into iPhone's Preferences app is very simple and straightforward. Similarly accessing contacts, photo library or location is very simple. And the Multi-Touch Cocoa makes it very simple to handle touch(es) events in the application.
Right now, the flexibility of the SDK is geared much more towards developers who want to create non-standard looking applications such as games. Hopefully, when June comes Apple would have added all of these standard controls to the final release of the SDK so I would not have to spend time creating bitmap images, and spend more time creating applications instead.
Another major omission in the original SDK is the Interface Builder for the iPhone. While it slowed down beginners such as myself initially as I cannot just drag and drop UI controls and connect up events, what I lost I gain in understanding how the framework works. Interface Build is now included in the latest iPhone SDK beta (build 9A2151).
Final thoughts
Reading my experience so far, you might get the impression that I do not like the iPhone SDK development environment. That could not be further from the truth. Despite all the issues I had, this last three weeks has been one of the most exciting development periods I have had in a long time.
I suspect that many Windows developers will find working with iPhone SDK, Xcode, and Objective-C a relatively painless experience. And many great applications will be in the iTunes App Store in June when it opens its 'door'. Unfortunately, I fear that the big difference in keyboard shortcuts and language constructs may prove to be too high a cost for the more casual developers to overcome and become a dedicated iPhone developer.
Reader Comments (Page 1 of 1)
Wes said 4:04PM on 3-28-2008
Thanks for the post. I'm a seasoned Microsoft developer as well and am anxious to get into the world of Mac and iPhone development. It's nice to hear from others who are in the same boat as me. I hope you'll write more articles like this as most authors on the subject don't have a Microsoft background.
Reply
AkitaOnRails said 7:27PM on 3-28-2008
You are misunderstanding somethings. First of all Objective C is not in the same league as C# or Java.
Almost everything on top of the Darwin low-level OS layer is written in Obj-C. This includes all the apps in iWork, iLife everything single thing you use in your routine is written in Obj-C on the Mac.
On Windows the equivalent is C++ with MFC. Office is written in C++ and so on. If everything in Windows was written in C# it would be simply unbearable to use. That's not an issue with Obj-C.
Obj-C doesn't run in managed-mode as C# or Java sandboxed Virtual Machines. This is one overhead that we don't need in desktop-class apps. In a Phone it's even more important to not have unnecessary overhead.
So, you don't have a proper garbage collector to rely on. Even the GC in Obj-C 2 is more like auto-pointers in C++, and still far away from a full fledged Generational Garbage Collector that a JVM has.
This is not a bad thing as in a desktop-class app and a iPhone app you do want to be near to the metal.
Method calls in C# is not the same thing as Message Dispatching in Obj-C. Those are 2 different beasts. Obj-C 'method calling' actually resembles Ruby and other dynamic languages more than C#, Java or C++ static vtables. An Obj-C object is much more dynamic than initially meets the eye. You even have equivalent to a method_missing in Ruby.
So Obj-C is a very nice balance between raw performance and dynamic feature that modern dynamic languages have.
Reply
Alex Hung said 8:50PM on 3-28-2008
I disagree. I have not misunderstood anything at all. In fact, I am aware of the things you mentioned before I started working with iPhone SDK. What I am trying to show in my post is the experience a developer would have working with Objective-C verses C#. Whether Obj-C is lower level or more dynamic than C# has no bearing on my experience using Obj-C so far. I still have to type differently and not able to work as fast as I would with C#.
Rick said 1:15AM on 3-29-2008
Interesting thoughts. If I may pick one nit - In the first paragraph, I think you mean overestimated, not underestimated.
Reply
Peter Kirn said 1:48AM on 3-29-2008
@AkitaOnRails:
I agree that comparing Objective-C to things like C# and Java is an apples-to-oranges comparison. They're different languages, with different features.
But I think you're implying some things about performance with C# and Java that aren't true.
As far as overhead and virtual machines -- misleading. There are Java VMs running on *far, far* less capable hardware than the iPhone. I would expect Java apps to perform quite nicely on iPhone. To go even further and imply that desktop apps shouldn't run in any kind of virtual machine or sandbox or managed code environment seems out of touch with the wide variety of applications -- many performance-intensive -- that do exactly that.
"If everything in Windows was written in C# it would be simply unbearable to use." -- perhaps true if you were talking about the whole operating system or something, but you're talking about apps. On the contrary, there's a wide range of C#-coded applications not only on Windows but Mac OS and Linux via Mono -- even including game engines, which have far more performance requirements than what you're likely to need on iPhone.
Objective-C is great -- as are the Apple frameworks and development tools. But there's no reason to dismiss these other widely-used tools.
Reply
AkitaOnRails said 12:46PM on 3-29-2008
Ok, I knew the 'overhead' stuff would be caught off first. Once the app is loaded and JIT'ted then it runs as fast as any native app, I know that as I am myself a Java and C# programmer. A Java or C# app can run as faster - and sometimes slightly faster - then a C coded app 'once the VM had the chance to optimize it'.
There are 2 problems on something like the JVM: start time is still an issue and memory consumption is another. Even if the iPhone has a total of 8 or 16gb of 'storage', it only has 116Mb of 'RAM' for concurrent apps to run.
If you could maintain the apps opened in memory once they were launched, then start time could be negligible in a phone that should never restart. But that is a poor design decision - Windows Mobile has this problem for years and that's why we have several 3rd party apps to just kill the damn apps, because memory is scarce and the device starts to feel sluggish over time. Eventually everybody restarts the damn WM devices. The iPhone, on the other hand, can go on virtually without any need to worry about memory consumption or restarting the device, which is one reason people like it: because it well behaves and don't expect any kind of software maintenance, like closing apps.
So both start time and memory consumption are big issues. That's why Google's Android doesn't use the full JVM as well, they had to develop their own custom made VM with all these constraints in mind.
I can understand completely why the iPhone has to be like that: the reinforced way being apps that close before the next is opened. Then, apps has to be snappy from the get go. If they feel 'sluggish' to start, the iPhone would never be a success. Having a micro-edition or compact-edition or whatever, as a jury rigged way of decreasing footprint, is not good as well as iPhone's app are good precisely because they have a comprehensive framework and library set at their disposal.
I expect something like Java to be very very sluggish on the iPhone. Let's be reasonable: it is a 400Mhz CPU - running in batery optimized mode - with 116Mb of RAM. Very very small footprint is a desirable thing without sacrificing features. With these constraints, it can only be done in a lower-level platform like C/C++ or slightly less low level as Obj-C. There is a reason no game console on the market builds games in Java, C# or equivalent: they want all the juice the machine can provide. This is true to smartphones. This ain't no Dual Core 2 Duo 3Ghz with 2Gb of RAM available to spare.
And sure, there are dozens of C# apps written for both Windows and Linux. Reminds me of the newer SQL Server tools: damn I miss those of SQL Server 2000 which were so much more snappy and responsive. There is a reason why something as iWork can be written and extended in Obj-C and Office's core has to be written in C++. Once I see a full fledged Office-like suite completely written in C# behaving as fast and responsive as the C++ version, then I will be convinced.
In the default Vista installation I can't remember of any relevant app written in C#, whereas in Mac OS X, from the get go you have most of the apps there written in Obj-C. This is what I call 'turtles all the way'.
Philips said 11:45AM on 3-29-2008
Xcode vs. documentation browser: after some struggling I have started using on-line documentation. Xcode documentation browser is on par by its ugliness with Windows Help.
Objective-C method invocation/message sending: I actually liked that. Unlike C++, ObjC didn't tried to be backward compatible to C - creators intentionally made syntax obvious. I liked very much that function prototype/invocation is self-documenting.
Reply
Ian said 12:04PM on 3-29-2008
Don't like the XCode key bindings? Then change them to what you are used to... Preferences > Key Bindings. Job done.
Reply
Mike Rundle said 7:48PM on 3-29-2008
Although hand-coding user interface elements is a bit daunting, the abundance of sample code that Apple has packaged within the SDK is simple to pick through so creating UI elements is a mere copy-and-paste job. I believe all the UI widgets you've described (plus buttons in navigation bar, the up/down arrows, etc.) are available either in sample apps UIShowcase or their navbar example, so that shouldn't be difficult to emulate. Also if you don't want to make the "plus" image (+) then you'll find it in one of those apps and can just drag it into yours.
As someone who wrote Java many years ago, then switched to focusing on web-based languages (PHP, Javascript), the learning of Obj-C is fantastic and overwhelming at the same time, mainly because I have little experience with memory allocation, header files, pointers, etc., all things inherited from C. However after reading code and working with the SDK for the past few weeks I'm very comfortable in the syntax of Obj-C and the Cocoa frameworks, and have been putting together some very interesting stuff.
For complete non-programmers looking to "just put an app together" with the SDK, they're in for a big shock and better break out an Introduction to Cocoa book :)
Reply
Glen Low said 8:02PM on 3-29-2008
Your experience with Xcode reminded me of 2003 when I did my first big Objective-C program, Graphviz.app :-). I used to curse and swear at the message invocation syntax [Foo doSomething] since you can't easily stack several invocations together without having to go back and type the extra [.
BTW, you can actually call a property by its name using the usual message syntax i.e. Foo.doSomething is equivalent to [Foo doSomething].
One of the best resources to get up to speed on Cocoa and Objective-C is the cocoa-dev mailing list in lists.apple.com. Got a head start on the idiom of the language by talking to the old-timers -- learning the idiom is more than mastering the syntax of the language.
Reply
Ixion said 8:42AM on 3-30-2008
I was just wondering how steep would be the learning Objective C. Can someone give a prioritize roadmap of what should I should read/learn to get started in developing for I-phone using Apple'SDK
I've no object oriented background, and as far as language as concernce I've got only experience in Visual Basic and Pascal ...
I don't have any experience in pure K&R C either ...
Reply
Ray said 11:49PM on 5-06-2008
Alex, you are far too kind to Obj C. This is a foul foul language. Having VB and C# background, its just seems foolish to have to worry about memory, pointers and the such as you stated. Because the apps on the iphone are small, as far as I am concerned we are comparing apples to apples. The only difference is how long it took you to pick those apples. It took me 2 days to figure out how to do a multiline text box where in C# its a simple property. Part of the problem was Interface Builder, but thats a different topic all together. Why in the world is IB not integrated with XCode??? Switching between XCode and IB constantly is a waste of time and makes no sense. I actually like how you use connectors in IB to hook up your events and controls, but thats where it stops. You still have to code your header file before you get into IB, hook up your connectors, then then come back and create the events in the module and hope the stars align to get it all right the first time. How bout this, in IB, you create a connector and it asks you for the outlet name, then it modifies your header file and even stubs out your module file with the event, now thats helpful! I am not an apple hater, my IPhone is a fantastic piece of technology, but common Apple, its the 21st century, use a language that helps developers code efficiently and effectively.
Reply
Andy said 7:53AM on 5-29-2008
The beauty of the Objective C method syntax takes a while to appreciate, but you will ! Say you see these two methods in code somewhere:
C style: deliverPizza(x,y,z);
Obj-C style : deliverPizzaFrom:x to:y size:z;
With the C style method call, you either have to remember what the parameters are, or go look it up. With the Obj-C style, the parameters are named as part of the method name. I know, just by looking at that method call, that I'm delivering a Z sized pizza from X to Y. Ok, this is a contrived example, the benefits really start to show themselves when you're calling some of the cocoa methods that have half a dozen different parameters.
Reply