Verbose Logging

software development with some really amazing hair

T + S G I F R

Obligatory iPhone SDK EULA Change Post

· · Posted in Editorial
Tagged with

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



3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.


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.



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.

Sharing is Caring