iPhone Developers and Language Snobbery
[Update: Jeff LaMarche (author of one of the best iPhone books on the market) wrote one of his trademark 'no tact' responses to this post. I'd be very interested to know what people think about his post.]
[Update 2: Guy English (aka kickingbear) chimes in on this debate with what is the best response I've seen from a hardcore Cocoa developer. Basically: Apple's tools are probably better at producing better iPhone apps, but let's see what MonoTouch and Flash can deliver before we definitively say that they are no good.]
Novell recently announced a product called MonoTouch, which allows developers to write iPhone applications using C#, a language invented by Microsoft (but since standardised). It’s a very clever piece of work that allows someone without experience of Objective-C – the only option that Apple gives you for iPhone development – to write an iPhone application with a reduced learning curve.
Yesterday, Adobe followed suit and announced that they are working on a way to make native iPhone applications with their Flash technology.
Naturally, this is a good thing. Talented C# and Flash developers will be able to write excellent iPhone apps and we can all go home happy. The fact that two heavyweights in the technical space have made these tools is a massive compliment to Apple’s achievement with the iPhone.
Not if you listen to many Objective-C programmers it isn’t.
Before I launch off into a rant here, I should probably get my retaliation in first. I made the effort to learn Objective-C before MonoTouch was even a twinkle in Miguel de Icaza‘s eye. I’ve made an effort to become engaged with the Mac developer community, and even have a shipping (if small) Mac application to my name. I like Objective-C, I like Cocoa and I love the iPhone and Mac platforms. I like learning new languages and platforms, and Objective-C is one of the most pleasant I’ve worked on.
Objective-C was the natural choice for Apple as the development language for the iPhone because that’s what modern Mac applications are written in, and the Mac developer community were always going to be the most likely to start writing iPhone apps. The iPhone was not guaranteed to be the massive success it is today, and developer adoption of the SDK has been key to selling it to the public (‘There’s an app for that‘). There is no rational way to criticise Apple for their choice of technology for the platform.
But, here’s the problem. Objective-C is very much an acquired taste. Roughly speaking, it takes the elegance of Smalltalk and mashes it up with the power of C. The result is something that is very elegant in many respects, but gives you the ability to get right into the guts of things if you need to.
The downside is that it has an odd syntax compared to most other languages, which arguably has not been helped by some changes introduced in Objective-C 2.0. On the iPhone, you also have to write your own memory management code, something that is not necessary in any other mainstream high-level language.
If I write a sloppy iPhone application, it will waste memory. Waste enough memory and the application will crash. And users hate applications that crash.
This is because Objective-C on the iPhone lacks Garbage Collection, an automatic memory management technique that is used in virtually all modern languages, and this makes developing code for the iPhone a little harder than for other platforms.
The thing is that memory management – once one of the hardest technical challenges a developer faced – has been removed as a consideration for most developers. Many developers have grown up in a world with, in effect, unlimited memory and no penalty for not thinking about how much memory is being allocated by their program.
This changes on the iPhone because it has a very limited amount of RAM – something like 24MB per application, compared to the 4GB that is the default configuration in a MacBook Pro. The difference between those two numbers is like that between a drop of water and a swimming pool. No one worries about wasting water in a swimming pool.
This is one of the things that makes developers new to the platform less productive on the iPhone. The strange Objective-C square bracket syntax is another. The fact that you are forced to use C-style header files is another. The amount of code you need to define properties is yet another. These are the issues that MonoTouch is designed to solve.
There are many talented developers working on the .NET platform. The .NET platform is a brilliant bit of software engineering, and perhaps the best product that has ever come out of Redmond. Don’t let your dislike of Microsoft products cloud your judgement on either of those points. Most .NET developers will already know several languages, especially if they work with web technologies. These are likely to include C#, Visual Basic, JavaScript, SQL, XSLT and more. It’s not a fear of learning a new language that makes developing iPhone apps in C# attractive. It’s productivity.
Here’s the thing. C# is designed to solve precisely the same set of problems as Objective-C. The language designers set themselves different parameters, and ended up with very different results, but if there’s a feature in one language, there is bound to be its equivalent in the other. Lambdas in C#? Try blocks in Objective-C. Interfaces in C#? Try protocols in Objective-C. Categories in Objective-C? Try extension methods in C#. Like many rules of thumb, this is not entirely accurate, but it’s close enough.
Yet Objective-C developers reacted with derision – including ones who work for Apple on the language tools – when MonoTouch was announced. I find this deeply frustrating.
Further to this, there are large C# and ActionScript codebases out there that, hitherto, would have had to have been rewritten in Objective-C if they were to have found their way onto the iPhone. Who would have gained from this effort? If I’m a Flash developer who has written a neat Flash game (say, DiceWars), I would have to learn a whole new technology and language in order to get my game on the iPhone, costing me probably weeks or months of additional effort, and I would end up with two independent sets of code that I would need to maintain separately. How does anyone benefit from this? Certainly users don’t.
For far too long, techies have been obsessed with the workings of what they do rather than the results of those workings. With only a statistically insignificant number of exceptions, most people using an iPhone would not know Objective-C if it smacked them in the face with a sackload of gold-plated unicorn shit. More than that: they simply don’t care. Not because they’re careless, but because it is genuinely irrelevant to their lives.
Users just want to get things done. Many have grown up feeling nothing but frustration with their computers, which they see as things imposed on them rather than things they actually want to use. The iPhone is a watershed device in the sense that it is the first mainstream general purpose device that people actually want to use. They find excuses to use it. That’s the kind of delight I’m talking about.
But, to at least one Objective-C developer, if you don’t learn Objective-C and use that to develop your iPhone apps then you are a less than worthy coder.
There are many reasons why this is wrong-headed, but none more than that the end-user doesn’t care. If the non-native tools are incapable of producing a polished iPhone experience, then users will notice and vote with their feet. If not, then what on earth is the problem with using them?
There are good reasons to prefer Objective-C, not least because it is officially supported by Apple, is theoretically documented in full, has a large community of expert, friendly developers willing to help others and is guaranteed to be supported for the foreseeable future. If I were developing an iPhone application today, I’d definitely be doing it in Objective-C and Cocoa Touch.
Like me, many developers will welcome the chance to learn a new language and a new platform. But many will just want to write an app and get it into the hands of their users as quickly as they can.
The Mac developer community is, on the whole, very welcoming, polite and probably more imbued with expertise than any other I’ve been involved in. In my experience, Mac software is vastly superior to anything found on Windows, and much of it comes from independent developers rather than large corporations. There’s much to like about it. But the flip side of this is that many Mac developers have a near religious attachment to Objective-C that has the potential to stand in the way of many a developer’s desire for productivity.
It boils down to this: if MonoTouch and Adobe’s Applications for iPhone platform are no good, they will die. Developers who use them will sell fewer apps in the App Store. Objective-C developers will carry on developing apps in their preferred style and creating apps that sell well. But if the rival techniques are sound, everyone gets to write great iPhone apps, and the result is happy users, and an even wider adoption of the iPhone platform.
Who on earth could have a problem with that?
15 comments
Nice post James.
Although I’m coming at this from a completely different angle to this from James. I’m an ActionScript developer, so I welcome the strides that Adobe have made in giving people like me the opportunity to make iPhone applications that I ordinarily wouldn’t be able to do.
There’s one thing I would like to add though. No matter who makes an application in whichever language they choose to create it in. Apple have the final say in if the application is good enough for the iPhone or not. So for me, if Apple are happy with it, then I’m happy with it.
The issue isn’t a case of using these other toolkits is in any way bad, it isn’t. Some people took my tweets the wrong way, but the gist of what I was trying to say is that you should use the native toolkit for a platform if at all possible.
If there are valid business reasons not to use that toolkit, for example if you have a huge existing code base or you’ve been given a short period of time to write an app and that doesn’t give you time to learn the new SDK and develop the app, then it makes sense to use toolkits that help you produce the software in a way that fits your business needs.
But one of the most important business needs of any developer should be to provide a great user experience, and the best way to do this is with native toolkits. The vast majority of great applications on any platform are written using native toolkits, and those written with other toolkits are often a distant second.
Objective-C does provide a different syntax and on the iPhone does require you to learn reference counting, but when faced with these problems there are two sorts of coders. Good coders, who persevere and learn these things, and bad coders, who will write the language/API/IDE off as rubbish because it is different to what they are used to and try their hardest to use something else.
So to sum up:
- I believe you should use native if at all possible
- Only reason not to use native should be business reasons
- Any programmer worth their salt should be able to learn a new API/language/IDE
Hello,
I for one, think that Flash on the iPhone is a great new choice for developers that want to target a hot platform with the tools that they are familiar with.
Martin might be missing the point of MonoTouch though: MonoTouch brings the core of .NET and the C# langauge to the iPhone while exposing every single bit of the underlying APIs that he wants to use.
In my opinion, you get the best of both worlds: the benefits of the awesome iPhone platform, with its fantastic libraries and the best of C# and .NET (garbage collection, xml serialization, web services, DI containers, and for that matter, libraries for pretty much anything that has been conceived under the sun).
Life is too short to debug memory leaks, double-frees, double-inits, memory and buffer overflows and the use of dead objects.
I believe that the combination is great to give more people to developers to innovate.
I agree with learning the native tools of the platform.
Objective-c developers should just come down from their pedestal and write iphone applications in ARM’s assembler: http://stackoverflow.com/questions/238010 and http://stackoverflow.com/questions/270078.
http://stackoverflow.com/questions/238010
http://stackoverflow.com/questions/270078
Yeah, I liked it uphill both ways in the snow. Just where did I leave my crutch?…
@Martin:
But one of the most important business needs of any developer should be to provide a great user experience
Absolutely. But I don’t think you’ve shown that native tools are the only way to do that. As Miguel points out, here is no way to tell whether an app has been written in MonoTouch or not since it’s using the exact same libraries. The only difference is that the compilation process to produce the binary is different. How does that suggest a poorer user experience?
I’d also be very interested in your (and other Objective-C devs’) feedback on Miguel’s point: objectively, MonoTouch is better than Cocoa Touch since it implements everything Cocoa Touch does, plus Garbage Collection and so on.
As an existing Cocoa developer, naturally Objective-C and Xcode feel right. What makes you think that someone looking at Miguel’s comment is a lazy developer who doesn’t want to learn a new language, and not just one who wants to write bug-free iPhone apps with a great user experience?
Thought experiment: if someone made a compiler so that you could target .NET with Objective-C (there probably is one, actually), how would using that language be ‘lazy’ if you already knew it compared to learning, say, C#. I think the point is that .NET developers are used to seeing the platform as one thing, and the language as another. You can target .NET in pretty much any language ever conceived, and all languages are (or at least can be) equal citizens.
If MonoTouch delivers what Miguel says it does, how is it in any way lazy or likely to lead to a poor user experience?
I concede that to some degree MonoTouch is a valid alternative, but (and correct me if I’m wrong) the only way to get MonoTouch working within the AppStore restrictions is to remove a lot of dynamism from it. And for the features you gain like Garbage Collection, you lose features such as dropping down to straight C with nothing special needed. From an objective point of view there is as much to lose as there is to gain.
Now maybe I’m jaded by the many appalling cross platform APIs and programs on desktop computers, none of which really fit in or work very well. Maybe MonoTouch will be different, being only for the iPhone. But from everything I’ve seen on any platform to date in terms of trying to work around native APIs has led to inferior quality applications.
@Martin – agreed on how cross-platform stuff normally sucks. I for example, loathe AIR apps for that very reason. But I think you’ll agree that the man in the street doesn’t give a crap about “dropping down to straight C”. I think my point about that stands.
I’d argue the man on the street doesn’t care about Garbage Collection either, but I agree these are implementation details. I mean I’d love to be proved wrong in all of this and for Mono Touch to be the first API that is a good native citizen while not being the native API, but we’ll have to wait and see.
No, the man in the street doesn’t care about Garbage Collection, but if you had to bet which technique would introduce more bugs out of Garbage Collection and native C calls, which would you pick? ;)
As someone who codes in .NET in my day job and then comes home to an “all-Mac all the time” household, I must say that I appreciate the options that MonoTouch has provided. As you can see in my UITabBarController screencast at CodeSnack, I have studied Cocoa and Objective-C. In fact, I picked it up before the iPhone even existed and even before Objective-C 2.0 came out. I, like James, can see this from both angles very clearly.
I have been trying to stay out of what I see as a religious war on this topic. Life is too short for that. After reading Martin’s tweets on this topic (see @pilky… you’re welcome ;) ), I thought I was going to come here only to find more of the same from him: all potential MonoTouch developers are lazy bastards because they don’t want to use native APIs. Well, all those native APIs are available. As MonoTouch developers we are using UIKit, Foundation, MapKit, etc. You name it, we can use it. If there’s an Objective-C library you want to use, you can bind it. And you mentioned C – we have P/Invoke for that too. The world, as they say, is your oyster.
Are there times when Apple’s tooling might make life easier at the moment? Certainly. Right now MonoDevelop (the IDE for MonoTouch development) is able to pick up changes made in Interface Builder (yes, we use Interface Builder), but Interface Builder does not pick up changes made in MonoDevelop. So the seamless to’ing and fro’ing that you get from XcodeIB is not quite there yet (I suspect it will be eventually). However, when you add an outlet in Interface Builder a property is automatically code-gen’d back in MonoDevelop and that’s a pretty nifty timesaver.
I suppose what I’m hoping is that we can all get along. I love Cocoa and Objective-C, but I also love .NET and C#. Given that MonoTouch has made it possible to use all of the iPhone’s native APIs so that user’s get a fantastic native experience, can’t we put aside our differences in preference? In the end, isn’t it all about providing high quality applications to the user?
I decided to put together some choice words on the subject at
http://blog.alexwinston.com/2009/10/lets-not-kid-ourselves.html
http://blog.alexwinston.com/2009/10/lets-not-kid-ourselves.html
My post here is my take on this and it is purely a UX issue. If your app is eye-candy or a game with limited UI and no requirements to integrate with the OS then why not use Flash to build it as long as it performs well. The problem is with half-baked attempts to mimic the UI components that Apple provide and wild deviations from the HIG that will dilute the high standards everyone expects from the device. You’re right though, people will vote with their feet … hopefully.
here
I agree with your point that we (those of us developing in or learning to develop in cocoa touch) should completely write off the possibility that Adobe might put out a half decent attempt at this yet. I can see a long line of reasons running through my head as to how they won’t, most of these stem from how bad flash sucks as it is, but I agree that it would be an act of snobbery to just dismiss it knowing as little as we do about it and given that it isn’t finished yet.
I do however agree with Jeff’s blog post that you reference much more wholly than yours. There are defiantly allot of good reasons to spend the time learning the tools apple has supplied, and there allot of lessons that are absolutely essential that everyone working on the platform learn that the process will short-cut. From what it seems so far, the UI tools are half baked, the resulting ipa is bloated and in efficient, and though there are many great flash developers out there, there is little to no great flash applications out there. When they bring it out and the app store gets flooded with every bit of nonsense someone has made in flash over the last 5 years being compiled for iPhone with no thought at all and good apps are hanging in a que for review for months I think it will reflect badly on Apple, the iPhone development community, and the platform itself, the user won’t even consider Adobe.
I’ll admit my attitude towards Flash has been bad for a long time despite the fact I think it is a powerful too with great potential for what it was originally designed to do. The problem I have with flash is that it give people who don’t have a clue the means to do something semi complex with great ease and not so great implementation, then because they don’t have a clue they run wild. There are enough people who have half a smattering of common sense and can actually write good code shoving absolute crap like fart apps etc onto the platform, I don’t feel like I would want to happily invite what has turned into a plague on the web into the platform as well even if it will bring with it a handful of extremely talented developers.
My question from all those guys supporting Monotouch is that
Have you developed any application which is approved by Apple and is available on App Store??
When you guys have made that then you can argue on merits of Monotouch.
Moreover, they charge a lot for their License.
I am a objective-c developer and c# developer.
I really found monotouch very frustrating experience.
I dont think developer who only knows Monotouch and c# can develop iphone Apps
I think this Language Snobbery is not unique to Objective-C programmers, it’s pretty much everywhere. JAVA programmers constantly put down PHP programmers. C# programmers scoff at Visual Basic programmers, this has been going on for a long time. It’s pretty clear that any language can create a remarkable program on pretty much any platform/device given enough time and effort and care by it’s developer. The language is never really the problem here, it’s the developers who use the language.