The Feel of iOS Development

This semester I’m taking my advisor’s Mobile Computing course, which covers iPhone Programming. But the teaching approach here is different from back in China—they don’t teach technology for technology’s sake. TAs run tutorials, there are only three hands-on labs, and most of the time you’re expected to learn on your own. I’ve been thinking about whether China’s cramming-style teaching of J2EE and Windows programming is really the right approach.

I’ve completed two labs so far—first a Hello World, then a calculator. You could say I’ve gotten started. At my age, I’m no longer interested in learning more APIs or using more controls. Plus I have the heavy responsibility of advancing human knowledge through research, so I don’t have time to learn this stuff properly—I’ll never be an iOS programmer anyway. But I am curious about Objective-C as a language and Apple’s development platform. I wanted to understand what makes this platform tick. So I did some research and formed my own impressions. Since I’m reasonably familiar with Google’s and Microsoft’s platforms, I’ll compare them. Here’s my report—still just one opinion, not going into too much detail.

iOS development always seemed to have some barrier to entry—the language, framework, and IDE are all非主流 (non-mainstream), since there were virtually zero Mac developers in China before. So let’s talk about three aspects.

Section 1: Language

Google and Microsoft have similar strategies for mobile development languages—one uses C#, the other uses “Java”—both managed code running on a virtual machine. The benefit is lowering the barrier for developers: no memory management to worry about, so anyone can develop mobile apps. Google’s approach is interesting—they claim to use Java, but actually built their own VM that translates Java bytecode into another language. Another advantage is cross-platform compatibility—many x86 Android apps run directly, though x86 WP7 hasn’t appeared yet. The downside is the overhead. Saying Android is “laggy” because of the VM isn’t without merit, though the VM shouldn’t take all the blame.

Objective-C is also object-oriented C, but it takes a completely different path from C++. C++ tries to “compatible” with C at every level, inventing features like operator overloading. This introduces its own problems, and undeniably raises the bar for developers. To write efficient C++ programs, you not only need to know the syntax but also understand what the C++ compiler does for you behind the scenes—copy constructors, pass-by-value, etc. Beginners easily fall into these traps. I’ve seen too many examples in student assignments over the years.

At first glance, Objective-C’s syntax seems bizarre. Some code is pure C style—you can write xxx.xxx = 3—while other parts require square brackets for message passing. After using it for a while, I realized this design isn’t necessarily bad. Using two completely different syntax styles separates object-oriented from procedural programming. When you see square brackets, you know you’re doing OO. Without them, you’re still writing C. This is better than C++, where few people constantly think about whether they’re currently doing OO. The trendy MVC pattern—M in native code, V in XML, C in dynamic languages—has similar considerations. Unlike MFC, where MVC is all in one language and beginners can’t tell M from C and mix them up, forcefully “separating” MVC at the language level is one solution. Objective-C might have been designed with similar thoughts.

Another issue is memory management. Objective-C still needs reference counting—back to the COM era with AddRef and Release. For those used to virtual machines, this is undeniably a higher barrier. But it’s better than C++’s direct delete. For non-professional, non-perfectionist people, leaking some memory isn’t the end of the world. At worst, your program suddenly “disappears” and you restart it. Of course, for a game where someone’s been playing for hours, sudden crashes would provoke swearing. This approach is a compromise between managed code (completely hands-free) and native code (manual management).

Objective-C has another intimidating feature: dynamic language特性 (characteristics). The message inside square brackets can be absent from the implementation—it compiles without error and only crashes at runtime! Isn’t that scripting language behavior? Looking at the implementation, it’s not that mysterious. If C++ allowed modifying the vtable at runtime, it could do the same thing. Objective-C calls this “sending a message,” not “calling a function.” This feature is another compromise between managed code (powerful metadata and reflection support) and native code (compile-time determination or vtable).

Another unusual thing is that Objective-C doesn’t error on null pointer access. How to put this? It certainly brings convenience, and from a design perspective, it’s defensible—after all, you’re sending a message, not calling a function. If no one handles your message, there’s no error. But this design has hidden dangers. It reminds me of our Party’s维稳 (stability maintenance) policy—suppressing problems. To users, it looks harmonious, like nothing ever happened. This matches iOS’s behavior when a program crashes—it just “disappears” without telling the user what went wrong. In contrast, Linux bluntly reports “Segmentation Fault,” and Windows politely says “We apologize for the inconvenience.” It seems closed systems are keen on stability maintenance—whether computer systems or social systems.

Objective-C seems to be all about compromise. The doctrine of the mean is well implemented. I hear Jobs studied Eastern culture for a few years—maybe there’s a connection…

Finally, about the compiler. At WWDC 2011, Apple proudly announced the switch from GCC to LLVM. GCC needs to step up. I’ve felt for years that GCC for ARM was so slow…

[It’s late, going to sleep. The next two sections will be brief. I’ll write more based on response.]

Section 2: Framework / Library

It looks unconventional, but if you look closely, it’s quite similar to Android’s, WP7’s, or even the much-maligned MFC. UI frameworks—learn one, know them all.

Section 3: IDE

In a word—over-reliance on the IDE. But Xcode is free now, so no complaints—just use it. Some say Xcode is evolving into iCode, with more and more fancy features, possibly becoming a tool for poser coders.