Friday, March 7, 2008

Boy That iPhone SDK Sucks

I have been waiting for a multi-tasking mainstream phone OS for years because that is what is needed to create really cool mobile communications applications. I have been excited about OpenMoko, excited about Palm Access, excited about a handful of other linux based phone platform announcements. But so far none of these platforms has become relevant or have seemed like they will really gain traction.

About a year ago I became excited about the idea of developing for the iPhone. That excitement waned as Apple made it clear that they were not supporting 3rd party application development. Since then, Google Android has made its way onto the scene and offered a truly open, truly multi-tasking OS that will probably achieve fairly wide adoption.

But in the last few months, the idea of developing for the iPhone became exciting again. Apple announced they were going to offer an iPhone software development kit (SDK) that would allow third party developers to write iPhone apps.

Today, I am mightily disappointed. This morning I read in TechCrunch that iPhone apps will only be able to be run one at a time. No background functionality. No flipping between applications.

Now this may seem like a nit. But it is huge. Communications applications like instant messaging, VOIP, and really anything else where one wants to broadcast information about yourself (like presence) or monitor other events on the network and react to them, are impossible. Perhaps Apple will allow a few insiders to access multi-tasking functionality, but essentially, though the operating system obviously supports it, none of that will be accessible to developers.

The bottom line is I think we are going to see a lot of cool games for the iPhone, and perhaps other types of applications. But as a platform for building communications applications, the iPhone sucks. Damn.

19 comments:

  1. Personally, I wouldn't rely on Michael Arrington to tell me what is and isn't possible using an API, the guy is a lawyer not a developer.

    You might still be right, but it strikes me as odd that this restriction is described in the Human Interface Guidelines. I would not be surprised to discover that Apple's own application UIs work with this restriction too - it's just that background code (for example, for Mail, or the phone functionality) has to be split into a separate daemon.

    It just makes a lot of sense to unload UI code that isn't visible, especially when there is no/limited Virtual Memory to fall back on, and the UI can be reconstructed quickly enough that the user will not notice.

    Whether the SDK lets you write such a daemon, well, that's the question...

    ..Mark..

    ReplyDelete
  2. Boy, great point mark. I will look around some more. That would be excellent news.

    ReplyDelete
  3. Well I just looked. And what it says is "third party applications never run in the background"

    The reason its in the UI section is because in this section they are advising developers of the UI implications of the system's behavior.

    So, yeah, it still sucks.

    ReplyDelete
  4. PROCESSES run in the background, but UI calls don't.

    No reason to, other than use up a lot of memory needlessly.

    Doesn't matter on a desktop bit on a mobile device just not a good idea.

    The SDK handles this, flushes the UI calls and rebuilds on the fly.

    Why you you would be concerned with this is beyond me. Does not affect usability AT ALL and is just good efficient software design and compiler behavior. Have you noticed any usability problems on the current iPhone apps??? It's the same stuff, man. Your apps will behave the same way.... no worries, mate, xcode does the heavy lifting. It's all good. This isn't windows CE we're talking about here. These guys at Apple have actually thought about this stuff.

    ReplyDelete
  5. "Why you you would be concerned with this is beyond me."

    Because I want to periodically check and whether something has happened and be able to notify the user.

    "Does not affect usability AT ALL"

    Apparently it does, which is exactly why it is covered in the interface guidelines section.

    "and is just good efficient software design and compiler behavior. Have you noticed any usability problems on the current iPhone apps??? It's the same stuff, man."

    Again, right out of the documentation it is ***NOT*** the same stuff. 3rd party apps have restrictions that internal apps don't. Third party apps cant run in the background. No fancy footwork here about processes etc. You cant do it. They are flushed.

    ReplyDelete
  6. I couldn't help but notice the headline "boy that iPhone SDK sucks.

    If you spent 5 minutes in Interface Builder you would realize all the UI event calls are handled in the drag and drop object oriented framework.

    Drag the elements, connect the links, real time test it, compile the sucker.

    This isn't 1984. Apple is putting out a pretty nice set of tools and does a good job explaining what they do.

    Either you are a shrill hired to bad mouth Apple for the likes of the numerous Apple haters of the world (RIM, Ms, etc), or you haven't spent even the tiniest amount of time looking at Apple's tools.

    If you have any integrity maybe you should be just a little well informed before you make such an in informed boorish statement like that. Because it really makes you look like a moron.

    ReplyDelete
  7. Boy, nailing apple is like nailing ron paul. It really brings out the non-responsive retards.

    ReplyDelete
  8. There are no "hidden APIs" all of them are exposed to the frameworks.

    Apple uses the same tools to build their "native" apps as you can do on xcode.

    No difference. Nada.

    3rd party apps not built on xcode is a different story.

    ReplyDelete
  9. For someone quoting Michael Arrington on programming issues that's pretty funny :)

    ReplyDelete
  10. This headline is a pretty shameless troll.

    A lot of these points were covered the the townhall presentation. If you didn't go to that it is available online at apple.com.

    Instead of participating in this troll bait I encourage everyone to pop some pop corn and enjoy the show.

    You will see actual demos of seriously kick ass apps, and realize a lot of the troll bait (like this site offers) is just wasted bandwidth. Enjoy.

    ReplyDelete
  11. Hank, You know I'm not a developer - I'm a user.

    But reading the comments...I dont get it.

    You either can run a 3rd party application in the background (which is what the apple fanboys are saying) or you cant (which is what you are saying).

    What is it?

    I know with my cingular 8525 (htc tytn), apps run fine in the background for windows mobile.

    It may not be a pretty gui like apple but this seems pretty fundamental flaw in the iphone sdk.


    Cheers,
    Dean

    ReplyDelete
  12. Dean,

    Good question. Its not that the OS X or the iPhone *can't* multi-task. Clearly it is a unix OS that is more than capable. Apple has purposely restricted 3rd party app ability to run background apps. It is a strategic/political decision, not a technical limitation. They are fearful that 3rd party apps will leave proesses around and screw up people's phones. But it still sucks.

    ReplyDelete
  13. Just came here to bragMarch 7, 2008 at 11:34 PM

    Man, I feel your pain.

    Hum. On second thought, no I don't. I have a Blackberry.

    But you seem to be a very nice guy. I wish you the best of lucks. ;-)

    ReplyDelete
  14. Haven't you heard of Symbian? It's fully multi-tasking and many applications can all be running at once. It does everything you want, and has 10, 20x the installed base to boot.

    ReplyDelete
  15. Hank's just mad because he came out with clickradio which had the potential of being itunes before apple entered the game and which could have been successful like itunes had it not tanked, while apple's CEO knows something about not micro-managing and putting out products that work. There has to be quality controls Hank. That's how products come out that work. SDK's included. Apple needs to control the tech or developers could mess up the user experience. Allowing that would almost be as big a mistake as hiring someone that was the head of marketing for Prodigy to be your VP of marketing in your new venture.

    wink
    an old friend

    ReplyDelete
  16. "Anonymous",

    Thanks for the comment. You are the poster child for the fact that when you need to hire dozens of people, you will make some bad choices. Hiring is indeed key. Thankfully in your case, we saw the problem and had the foresight to fire you at a relatively early stage. But good luck to you in your future endeavors.

    ReplyDelete
  17. Thanks for the well wishes. "Anonymous" extends the same wish of good fortune upon you and your future endeavors. You're actually quite a smart guy. Great blog.

    cheers

    ReplyDelete
  18. I actually enjoyed reading through this posting.Many thanks.

    Symbian Application Development

    ReplyDelete
  19. I actually enjoyed reading through this posting.Many thanks.

    Symbian Application Development

    ReplyDelete