Skip navigation

It’s been two whole years since I wrote my two-part article comparing C# to Objective-C: Part 1 and Part 2.

Ironically, in Part 1, I linked to an Ars article commending how great the Cocoa API was compared to the Windows API. Today, however, I’m going to link to an Ars article that says quite the opposite: this one, by John Siracusa, states how much Cocoa and Objective-C have lagged behind .NET and C# and other competitors’ platforms. I highly recommend reading this article. An excerpt:

The fate of individual competitors aside, the fact that the most dangerous players are all coming out of the gate with languages and APIs a generation ahead of what Apple offers should be a huge warning sign. And again, this is all happening in the memory-starved, CPU-constrained mobile world. On the desktop, Apple is even farther behind.

The most important way it’s lagged behind: memory management. As I said in my article and Siracusa says in his, I think it’s an absolute waste of time for a developer that is focusing on a UI-based app to have to worry about micro-managing pointers and memory. Obviously developers of games, operating systems, professional editing tools and other niche performance-driven software have to focus on such minuta. But a guy who wants to make a simple RSS reader in his spare time?

And even the classic performance-driven argument is basically disproven now. As Siracusa states, Google has proven you can have high-level abstraction and performance too. (He links to the video of a phone running the newest Android beating the iPad in JavaScript performance.)

The only reason Apple can pull this off, I believe, is because of how vibrant the App Store has so quickly become. That means that developers, especially newcomers, simply have to bite the bullet and accept Objective-C’s old ways in order to tap into the great App Store market. Otherwise, I’m sure newcomers (e.g., kids who start programming at an early age) would be averse to using Objective-C.

It’s interesting to note that it’s very clear that apps in the iOS App Store are leaps and bounds ahead of Android’s app in terms of UI design and aesthetics. I wonder if the steep learning curve does a good (albeit imperfect) job weeding out the amateurs and people who simply want to make a quick buck.

Despite having spent more time in Objective-C since my article two years ago, I still am annoyed by these things:

  • No garbage collection in iOS. And for Mac, it’s off by default and hidden away in a setting that you have to actively hunt for. Siracusa contrasts this with .NET in which garbage collection is fundamentally a part of the system, and you even have to use the keyword “unsafe” to start doing memory management yourself.
  • Lack of generics: When I know that my array will only hold strings, I want to not have to do casts when I retrieve objects from the array.
  • Xcode’s lack of controls for linking “.h” and “.m” files (headers and implementation files, respectively) smartly. How hard is it to make a button that says “Implement,” so that whenever you create a method signature in the header file, the name and arguments are automatically copy-and-pasted into the implementation file? Or how about automatically-generating “synthesize” statements for all properties?
  • As Siracusa mentions, you can’t access objects in collections with a simple [] as you can in other languages. So list[0] in C# becomes [list objectAtIndex:0] in Objective-C.
  • Why does every string literal have to have an @ symbol before it? Come on.
  • No overloaded operators for string manipulation. Again, C#:

String s = "Hello, " + username + ". How are you? Today is " + date + ".";

and Objective-C:

NSString *s = [NSString stringWithFormatting:@"Hello, %@. How are you? Today is %@.", username, date];

Of course, the great thing is that C# offers you the option of doing it the Cocoa way if you want to. (Instead of “%@” you put in “{0}”, etc.)

  • I mentioned this in my previous article, but it still bugs me so much: instead of having hierarchal name spaces delimited by periods as in .NET, you just have really long names of things. So, instead of System.Animation.FlipFromRight (made this one up), you have constants like UIViewAnimationTransitionFlipFromRight. Luckily, the code completion works just as in .NET, so the end-result is the same, but I can’t help but feeling period-delimited namespaces are more ordered and neat.

Obviously, these huge deficiencies and disappointments in Cocoa haven’t in any way impeded its success. But it’s hard to reconcile how forward-looking Apple is with regards to everything consumer-facing with how backward-looking their developer platform is. As Siracusa writes:

It is 2010, after all. “The future” or not, it’s getting a bit silly for GUI application developers to perpetually be one bad pointer dereference away from scribbling all over their application’s memory. The world has moved on; Apple should too.

About these ads


  1. why?
    with all due respect, if you are not an engineer, why do you even bother to talk about what other people (who ARE) said?

  2. Hey, you really need to read up on the origins of Objective-C… it’s a SUPERSET of C… there, I just answered some of your question by quoting from the FIRST paragraph of Apple’s documentation. Why do you need the leading @ character? Because it’s Obj-C NOT C.

  3. For lazzy people you can use C# or even other easy to use languages as Python. But when you want to do something right, then you use C or Objective C or C++. Each one have their diferences, but the three have good performance. The hard part of any good programer is memory manage, and Apple know this. There won’t be a garbage collector as good as a good programer. At least not until the turing test prove otherwise.

    • Performance should never be the only reason. If people are really concerned about performance then they should just use assembly. I’m bias towards C# and other languages like it, but when you have to start worrying about null pointer exceptions or start writing over your memory that is dangerous and can seriously slow down development

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: