Archgrove

As anyone who trawls the technology sites knows by now, Apple have as of OS 4.0 banned the use of anything other than C/++ or Objective C/++ for iPhone or iPad development. Effectively, this bans Adobe’s Flash to iPhone targeting technology, MonoTouch and several other techniques. I can think of only two (tenuously) justifiable reasons for this.

1. Perhaps, during the beta, they want code written in C (and derivatives) to aid in debugging framework bugs. Rather than “My App doesn’t WORK!!!!! (Using MonoTouch Vxxyy)”, they can get a repro using a stack they know and control top to bottom. In this case, I can see it as justified.
2. If it’s specifically to target cross-compilers as a business decision, to ensure that iPhone only gets “exclusives”, then I suppose it’s their prerogative. It will probably backfire long-term, as their market share isn’t that dominant. “Browser, Palm, Android + all else” or “iPhone” makes the iPhone a secondary port target versus a first class platform.

Gruber gives a third, pretty sensible conclusion – that they just don’t want to hand control of their platform to another vendor, and become a commodity target – just another checkbox inside Flash alongside “Web” and “Android”. If developers started using these meta development tools, all of the iPhones advantages vanish – it’s just another smartphone that runs Flash based applications.

For Apple the platform holder, this makes sense. For developers, any of the reasons are overly restrictive. This is, at best, ethically dubious without inconveniencing real development (which is all going on in Objective C already). At worst, it’s indicative of an ongoing schizophrenic pathology within Apple management where, despite winning ongoing customers through applications, they are happy to slap developers around just to see how far they can go before everyone decamps to Android.

We already exist with the capricious Application Review policy whereby you’re playing Russian Roulette with your development time – there’s no way to know that tell which perfectly innocent development choice will lead to rejection. Add this new restriction, and one has to wonder what choice made today will be retrospectively banned tomorrow. It’s an odd strategy, as there are plenty of innovative developers who are now scared of targeting the platform, whilst coding sweat shops keep flooding the channel with $0.10 an hour developer dross; developers who will use whatever they’re paid to use, be it Objective C or Flash. Pump enough stuff in, and some of it leaks through.

I can take two solaces from this personally. First, it literally can’t ever sensibly apply to OS X – the historical baggage makes this kind of restrictive move possible only on the closed and dominant iPhone platform. Even if they ever decided to make a “Mac App Store”, there would always have to be a standard development path lest they lose the thousands of platform portable apps that they current have (and really, OS X is still missing large swathes of desktop software that Windows has). Second, it makes my Objective C skills more valuable.

I still think it’s a poor move technically and ethically, but the iPhone platform has always been rife with these land-mines. Whether it turns out to be a good move from a business perspective, the market and time will tell.

The big tech news today is that Apple’s iPhone OS is getting multitasking. I thought I’d briefly discuss what that means, and the implementation choices that Apple have made. This information will be based off the presentation, rather than the (current NDAed) SDK.

Multitasking is really an end user experience – that of doing multiple things on a device at the same time. There are many ways to implement this within an operating system, especially one where the UI is so constrained as to make displaying more than one application at a time virtually impossible. Based upon our definition, and despite what some people will claim, iPhone OS 1.0 through 3.2 have had multi-tasking built in, in 3 distinct ways.

• True pre-emptive, multi-process multitasking: This was reserved for Apple’s first party applications. Here, each application is a true process, and runs continuously no matter what you’re doing. Mail is one example, iPod another (You still hear new mail notifications, and music keeps playing, even when you’re not in Mail or iPod).
• Push notifications: For any long running task. This is really a cheat – you have to write a server side application, running on a machine away from the phone, that carried on doing “stuff”. When stuff was done, or something interesting happened, you send Apple a notice. Apple then tells the user iPhone, which can launch your application which picks up on the notice.
• Suspend and resume multi-tasking: All App Store applications currently follow this model, which you might call “system modal multi-tasking”. Applications are loaded, run until you press “Home”, then quit. To make it seem like multi-tasking, the rules of good development stated that, when quit, applications should save their state (the last page being viewed, half finished emails and so forth). The next time you load it, the application restores the data and UI so it looks like you never left.

For a lot of applications, this is enough. Aside from the occasionally annoying reload times, any decent application implemented a state persistence that makes it look like you are just switching from app to app whilst they sit in the background, waiting. For those that must know right now that Bob has announced his Wedding on Facebook, you’ve got Push notifications. Unfortunately, these solutions have not been enough for a large class of applications – Those that must run on the iPhone, yet remain useful even without visual attention. Some common classes that have emerged are

• The “I’ll keep playing audio” applications (Pandora, Spotify etc.)
• The “I’ll wait for something to happen, then spring into action” applications (Skype, TomTom etc.).
• “I’ve things to do whilst you wait” applications (FTP apps, WordPress etc).

So why not allow “true” multitasking for all applications? Apple have always said, and I personally agree, that unrestricted, pre-emptive, process based is a bad idea on mobile devices – badly written applications drain battery life and degrade the end user experience. By taking memory they don’t need, failing to suspend unneeded computation when not frontmost, any application can drag down the end user experience of the entire phone. Note that I say phone – the majority of users will not link their lag when typing SMSs to the poor performance of StupidDev HyperFart HD, and will complain about their new iPhone being slow and useless.

Rather than open full multitasking, iPhone OS 4.0 gives targeted solutions for the classes of problems listed above.

• Fast application switching: This solution just makes the previous “Save state” solution more palettable, solving the “Long reload” times between switching applications. Rather than terminating an application, then reloading it from scratch, the operating system “freezes” it, and when you switch back, it can be “unfrozen” far more rapidly than it could be reloaded.
  Background listening: This solution allows applications to stay running in the background, performing simple audio streaming tasks – playing music or sound, and using the network to fetch it. I’d imagine much more than this is forbidden, but it’s enough to allow Pandora and Spotify to run without issues.
• Local notifications, VOIP Services and Location notifications: This will be a combination of solutions. Local notifications will no doubt be push style, but scheduled via a timer. Location services will be similar – a callback into a frozen application that fires when the location changes. VOIP, I’m not sure – some kind of limited network usage so you can poll the server seems likely.
• Background tasks: I expect that, upon being “frozen”, your application will be allowed to perform some computational tasks under strict supervision (time or resource limited). This mode will not be the “catch all” true multitasking, whereby you can sneakily do any computation you want in the background – it will be restricted to cleanup, or long running task completion. I expect this to interact with local notifications to allow, e.g. FTP uploads.

The interesting thing about this approach is that it’s extendable, as and when needed. The implementation of these “multi-tasking classes” is no doubt just true preemptive multitasking, with a more aggressive scheduler that will kill off applications that don’t conform. If another class of applications turns out to be both needed, and not too draining on the hardware.

What does this all mean for end users of iPhone apps? Well, practically, not a whole lot for most applications. They’ll load faster (because they never quit), and those that fail to be good, state saving, citizens will behave as people actually want. The real changes will be seen in music players and location aware services – Spotify will become more useful, and Tom Tom will co-exist happily with making phone calls. Realistically, much like copy and paste, I suspect this will be something people have ranted about for years, will find some nice usages for, but that will not be a huge deal for 99% of iPhone users.

I’ve exchanged a few e-mails with Shawn Burke, who’s writing the “iPhone SDK vs. Windows Phone 7 Series SDK Challenge” series on his blog (which I highly recommend you read). Those reading my previous posts will know I’ve taken him to task for a few of his comments concerning the “number of lines” comparison between the iPhone and WP7. I just want to clarify a couple of my comments – not at his request, just to set the record straight.

I mentioned that Expression Blend is not a free product, but he’s mentions that “A basic version of the tooling for WP7 (including Blend) will always be free”, which is good news – the XAML designer in Visual Studio frankly sucks, and having to pay for a UI designer would be unwelcome. The main point of our brief exchange has been the (lack of) quality of Apple’s documentation, which I entirely agree with. The Interface Builder techniques I used in my implementations are not widely known, being documented in an obscure corner of the IB Manual, and it’s understandable that someone just arriving on the platform would think they didn’t exist. It’s also undeniably true that the iPhone tutorials are more complex than they need be to achieve the target application.

To clarify my opinion on this, I believe the tutorials are not going for the “ideal” MoveMe application – they’re covering a gamut of techniques people will need whilst developing for iPhone. Is the pacing of the tutorials quite right? Would a more “drag and drop” IB approach in the first few be preferable? I don’t know. Given the number of applications in the App Store, it certainly seems most people are getting to grips with iPhone development. Though given the quality of most of them, it’s fair to say there’s scope for improvement.