iPhone 4.0: Why can't we all just get along?

There’s been a storm brewing between rivals Google, Adobe and Apple. Each day seems to bring news of some minor sparring between the software giants, but instead of looking on in mild amusement, I’ve started to realise how their actions are affecting the future of smartphone development.

The news that made me sit up and take note came only a day after Apple previewed their new v4.0 OS for the iPhone and iPad. At first glance the change was subtle; an addition to their developer SDK agreement:

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).

In a way, it’s a pretty reasonable request: that all iPhone applications should be developed and written in a C-based language, and link directly to the iPhone APIs. If I were to develop an iPhone application, that’s what I’d expect to do. However, I’m not an Objective-C or C++ developer – I’ve been a long-time .NET developer for the Microsoft platform, and my immediate thought was not about Adobe and Flash, but about a project called MonoTouch. MonoTouch allows .NET C# developers to work within the environment they’re used to, with all the benefits of the .NET framework, but write fully functional iPhone applications. In effect, it provides a bridge between .NET and the iPhone so that seasoned .NET developers can build multi-platform applications with ease (in fact, MonoDroid is in the works to provide the same bridge to Google’s Android platform). This makes sense from a developer point of view: One dev team can push out an app for the iPhone, Android and Windows smartphones relatively easily, and cheaply. Surely that’s a good thing for both developers and users?

Adobe’s Flash to iPhone tools are different from MonoTouch, in that they offer a higher level of abstraction and that their tools are, in effect, mediating between the application’s code and the iPhone’s APIs. In effect Adobe have created an abstraction layer for Flash developers to work within that hides the native iPhone APIs. It’s this specific point that Apple seems to be targeting in their revised SDK agreement, and from a development point of view I dont blame them. I’ve been using the iPod Touch and iPhone since they were first launched, and one thing I’ve noticed is that as the apps (and OS) becomes more ambitious, the more care developers need to take to make sure their app is as efficient and lean as it can be. There are some great looking apps out there that would be so much better if they didn’t take 10-15s to open; where the UI didn’t freeze when it performed some action, and in the worst cases crash when it runs out of memory. In a way these smartphones are a step back down the evolutionary ladder of tech, in that they are lower powered, lower spec’d that our desktop counterparts – but as users we expect and demand the same kind of performance. It’s up to the developers to make that happen, and in some cases even fool us into thinking it is happening, but there are too many examples of bad programming in the App Store. I don’t think Apple has revised it’s SDK just because they don’t like the idea of Adobe getting in on the iPhone action – in many ways Apple has nothing to loose and everything to gain, given that Apple’s development tools come free with every single Mac. The problem is in the way that Adobe have implemented their Flash to iPhone tools, and Apple’s apparent concern about inefficient apps is probably true.

As a developer, I hate Flash. Not just because it seems to offer a route for illustrators, animators and designers a route into software development, but more because in my opinion it’s well past it’s sell by date. This opinion was reinforced when Adobe released the AiR platform, to allow Flash-type applications to run ‘out of the browser’. As with all things Flash, AiR proves to be resource intensive and sluggish compared to developing either native applications, or using any of the other more matured cross-platform options, such as Java or C++. In a way, Flash’s focus is on creating ‘Flashy’ applications – so it comes with some great UI design and animation tools, but the IDE from a code point of view leaves a lot to be desired. There are other emerging technologies that offer the same level of creativity, but within mature development environments. In my development world there’s Microsoft’s Blend, and WPF technology – along with Silverlight for cross-platform, out of browser delivery that’s streets ahead of AiR.

However, back to the iPhone: Mike Chambers, project manager for the Adobe Flash Platform has posted a lengthy article on his blog making his feelings felt on  the matter, stating that:

“ultimately open platforms will win out over the type of closed, locked down platform that Apple is trying to create”

to which Trudy Miller, Apple Spokesperson responded:

“Someone has it backwards–it is HTML5, CSS, JavaScript, and H.264 (all supported by the iPhone and iPad) that are open and standard, while Adobe’s Flash is closed and proprietary,”

Apart from the amusement of watching these software behemoths spar like this, these two quotes pretty much sum up my feelings. I hear the arguments against the iPhone, and agree with some of them – but to me, Adobe’s Flash is as closed and locked down as the iPhone. Flash is a commercial product – part of a suite of monster apps from a monster company – and I’m amazed it’s grown to the size it has, given it’s origins and development. Apple may have sidestepped the criticism here, but they make a valid point.

While I feel the pain of native iPhone developers, with the restrictions on how their software can behave and how it accesses the hardware, not to mention the app review process; I respect Apple for having the gaul to operate that way in the interests of maintaining the iPhone experience. After all, the iPhone isn’t just a platform – it’s an experience, and all the more successful for Apple’s treating it that way. Yes, by contrast Google’s Android platform is nice and open, but as a result there’s less emphasis on and policing of that ‘experience’. Android users may be able to boast they can run more than one app at once – but at what cost? Apple simplify the issue of multitasking, for example, by saying they’re not implementing because of ‘battery life’, but the reality is that more than one 3rd party iPhone app running at once threatens to damage that precious experience. It remains to be seen how successful their ‘psudo’ multitasking in OS 4.0.

As a stark contrast to Adobe’s iPhone tools, MonoTouch’s future seems more hopeful. The team, while positive, are not certain of the effect the SDK agreement will have on them. They seem to be pinning their optimising on the fact that MonoTouch does not create a layer of abstraction in the way Adobe does – quite the contrary, MonoTouch’s software allows .NET developers direct access to Apple’s APIs on the iPhone. There’s no magic glue or shims to make this all work – it’s a true bridge between the two platforms. As a result, they do not fall foul of the latter part of the agreement. How strict Apple will be with regards the first part remains to be seen.

So, in summary … I’ve confused myself by writing this article! Lets see if I can reach some conclusion here:

While I wish, as a developer that Apple weren’t so damned precious about their phone, I feel that their actions have clearly lead to the most successful mobile phone ever created**, and as an iPhone user – I have to say it’s been the best phone I’ve ever owned. I just think that the concept is getting a little long in the tooth now, the edges are starting to fray, and competitors are starting to wheel out the clones. This is a good thing, because it will either lead Apple to creating something better, or if they don’t someone else will. In the end, it’s the consumers that win.

** I have no idea whether this is true – I’m just making stuff up now!

I think the Holy Grail dreams of developers wanting to develop for just one uber-platform are just that … dreams. Enforcing such a thing would only serve to stifle innovation, and in doing so make us all content with the tech we have … never needing to upgrade or throw away … the economy would recover; we’d wipe out 3rd-world debt in a year or two … everyone would be happy and we’d all just get along.

Now, who the heck would want that?!