If you don’t already know what this is going to be about, just skip it. If you haven’t already become aware of what’s happening, be thankful, and move on. If you really want to know, Google around for iphone sdk 3.3.1 and you can read up on the details.
I’m writing this article as:
- A software engineer (EIT)
- An iPhone user
- Someone who originally wanted to develop for the iPhone, but now (even before these changes) lost interest
Basics
Before
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.
After
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
The engineer
When it comes down to it, it’s Apple’s platform, and they can do whatever they want with it. Making a change like this wasn’t just the legal department making a few random tweaks; they really thought about this. It affects the number and quality of applications that get submitted, the number of developers working on iPhone applications, all the other companies producing middleman software to write iPhone applications, and as Emperor Palpatine says, “a great many things.”
On the other hand, I hate being told what technology I have to use to accomplish a goal. If I want to write a program to do something for myself, I can write it in whatever I’m feeling like that day, and it makes me happy. Now I’m being told that if I want to write an iPhone application for other people to use, I must use Objective-C? Lame. Have you looked at Objective-C lately? It’s disgusting.
And I’ve written Motorola 68K assembly.
From the new wording, I gather that you could write it in C, which I probably would. It’s not like you get the benefits of garbage collection on the iPhone anyway, though by using C you could probably use a garbage collection library.
It comes down to being an annoyance and time consuming more than anything. If you want to develop on the iPhone, you’re using an approved language. If you want to go multi-platform, you’re writing two completely separate applications. This should result in better applications, which I’ll talk about later.
If you’ve already invested a lot of time in your MonoTouch application (which doesn’t suffer from the multi-platform problem, since MonoTouch is exclusively for iPhone development) or any other platform that gets kaboshed by this change, then I guess it’s time to learn Objective-C.
Overall, I’m not a fan of the change. When it’s all said an done, Evelyn Beatrice Hall said it best:
I disapprove of what you say, but I will defend to the death your right to say it.
The iPhone user
Unless you’ve been waiting on an application that will now not come to fruition because it’s being written in MonoTouch, you probably don’t have any reason to worry, or even care. If anything, applications might end up being of better quality.
The developer who doesn’t care anymore
At first, I thought I’d get a phone I could love to use and develop for. Then I got it, got all the stuff, started to look at tutorials, and started to read about Objective-C. Fuck that noise. I disliked Objective-C the moment I looked at it.
Then I found these other things like Titanium from appcelerator, MonoTouch and a few others that would allow me to develop for the iPhone without touching Objective-C. Yay! I started to play with that, but lost interest. It’s another huge platform to learn regardless of which language you are developing in, and I’ve got shit to do thank you very much.
At first I had a purpose. I had a specific app I want to write, but after a little searching, I found one in the App Store that did what I needed. And all for the low low price of free. Why waste my time if somebody has already built something to do what I want?
The multi-platform-apps-result-in-lower-quality argument
This argument is completely valid. If you write an application using a multi-platform framework (like Qt, Java, or whatever), it just won’t work as well or look as good as if you wrote separate application for each platform. Simple as that. You can frequently tell as soon as you use the application (much more prominent with desktop applications).
Your appcelerator application might work pretty good, but it’s not going to wow anybody on either platform (Android or iPhone). The native applications are traditionally always better than the multi-platform.
Adobe/MonoTouch/appcelerator/etc
The lock-in advantage
John Gruber covers this, so read his post.
The omg-we-hav-2-lern-C-and-memory-management argument
We’ll talk about that later.