Changes to the terms of Apple’s iPhone SDK annoys developers, serves to perpetuate mobile application fragmentation, but may advance the argument for mobile web apps?

Posted by Jamie Moss Monday, April 19th, 2010

Add a comment

Clause 3.3.1 of the Terms of Service (ToS) that developers are required to sign in order to create Apple-approved applications for the App Store has been changed, to effectively ban the use of third party compilers that create cross-platform applications.

The changes and why were they made

To quote verbatim, the amended clause states that, “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).”

This means that developers must create their iPhone and iPod Touch applications using either a variant of the C programming language, or by using javascript. The applications must then be compiled directly from this code, thereby forcing any developers that wish to publish software on the App Store to write natively for the iPhone. They cannot use any third party development environments or toolkits that generate code for them, which could then be compiled into software for multiple potential mobile platforms.

The reason given by Apple is that allowing such ‘intermediate’ software layers to sit between the code and the finished application risks the creation of lower-quality or less-efficiently written apps. Presumably, Apple does not wish to have such potentially inferior applications diluting the quality of the content in the App Store. Furthermore (although it is pure speculation to suggest), maybe Apple feel that write-once publish-many tools risk the proliferation of ‘lowest common denominator’ applications, the functionality of which would be (at least) partially defined by the limitations of other operating systems. This could reduce the exclusivity of the applications written for the App Store and, thereby, the attractiveness of buying an iPhone versus handsets that use other operating systems.

Implications for mobile apps developers

Either way, the practical consequence of Apple’s decision is that development tools such as Adobe’s new CS5 and other popular utilities can no longer be used by App Store developers. While most end users and even most wireless industry participants will be unfamiliar with such software, numerous different third party utilities and tools have been used to create applications that are already hosted on the App Store today. Some of those apps have even become very popular and have been created by large, reputable software houses.

The implications of Apple’s decision for the mobile application developer community are that, having created their App Store apps, they then need to take their ideas and re-write them as needs be for other platforms, rather than being able to write once and publish to multiple platforms. So developers need to put in extra effort just to target the App Store user base. It also means that the advantages conferred on developers by labour-saving specialist development tools will be lost in the App Store applications they create.

One of the most crucial requirements for successful software development is the maximisation of creativity and inventiveness, often through the minimisation of the level of technical competency required. For example, visual development environments take a lot of the manual coding requirements out of the development process and mean that software can be written by people who are essentially designers rather than programmers. Natively coding the functionality that the aforementioned utilities enable would take far greater technical programming competency, time and expense - and could risk disenfranchising some developers from the App Store eco-system.

A hidden agenda?

The full reason why Apple took this decision has not been stated, considering that there had been no objection to the use of such non-apple-sanctioned software before. As well as due to the very obvious facts that there is no evidence that code compiled through ‘intermediate software layers’ invariably results in inferior apps; and that it is equally possible for developers to create inefficient, badly performing applications when writing natively for the App Store. Natively compiled code is no guarantee of application quality, as stated, the bulk of the ‘quality’ of a successful app resides in its concept and design, not in its programming.

A strong possibility for the real reason behind Apple’s decision is that the company intends to finally implement multitasking in the next version of the iPhone OS - and can only reliably do so with natively compiled applications. However, while multitasking on the iPhone mk4 seems certain to happen, this theory is again supposition. If it were true, however, then one could say that the ToS change was a move intended to protect consumers from having a bad end user experience with apps on their iPhone (or more importantly a bad end user experiene with the iPhone itself). Or it could be perceived as a move to stop applications compiled in other ways from showing up any embarrassing deficiencies in Apple’s new multitasking OS…

Of course, whatever the reason, it is Apple’s prerogative to change the ToS for their SDK and they have every right to make this decision. But maybe they should also remember that the interests of the software developers that create applications ‘for them’, i.e. for their product, extend beyond just the iPhone/iPod Touch. After all, the global installed base of mobile phones that the various versions of Apple’s iPhone accounts for is small – while the commercial market potential for the long-tail remainder is expected to be far greater; and it is this long tail that will be the ultimate target for mobile software developers.

Apple’s role in the industry

By creating an increasingly ‘walled’ developer community Apple are knowingly making the job of mobile application developers more difficult. The result of their ToS changes will take time to be seen. They could serve to promote the quality of App Store applications to the active detriment of the rest of the mobile applications market. Or they could backfire on Apple and only serve to weaken their attractiveness to developers. It has already been reported online that some developers have apparently decided to cease working on applications for the App Store because of the changes. But what is certain is that while the rest of the wireless communications industry is trying to foster interoperability and promote cross platform applications, Apple is seeking to ensure the separation of iPhone/iPod Touch application development.

Consequently, Apple’s attitude towards the developer community could be considered a disappointing one - and potentially says a lot about their interest and long-term commitment to the wireless communications industry. Namely that their involvement is solely for their benefit and that they are not interested in being an active and contributing member of the wider wireless communications eco-system. As they have no interest in enabling the promotion of the mobile application developer community beyond the development of the App Store-specific community. The App Store itself being a walled community that benefits no other party in the wireless telecommunication industry, besides Apple.

With all the telecommunications media attention that they receive it can be easy to forget that Apple is just a consumer electronics manufacturer, who happen to have one particular product, that happens to be a mobile phone. Their long-term commitment to the telecoms industry is not assured as their involvement in it is only one small portion of their overall business. Despite the fact that it is an industry that has provided a significant boost to Apple’s share price (not that I’m suggesting that any commercial company has an obligation to display ‘loyalty’ or ‘gratitude’ to any particular industry). Therefore is it really any wonder, for example, that they do not choose to have a presence at events like Mobile World Congress?

Web apps now more attractive than ever?

So, current developments do not seem to indicate that Apple for one is likely to contribute to any of the mobile applications interoperability initiatives and instead seem keen to reinforce the argument for the protectionism of proprietary implementations. But perhaps this in turn only goes to strengthen the argument that the solution to cross-platform mobile application interoperability lays outside of the realm of the OS anyway and in the (relatively) common ground of the browser?

The browser is already a native app for the respective OS of the phone it is installed upon. While all code executed through the browser uses web-based programming languages and is in essence just content being rendered through a generic application environment. Support for different types of content and for application functionality will be determined by the capability of each individual browser, which will require some logic on the server side on the part of the developers, in order to optimise application performance for different handsets. But there is a rich source of third party web development tools for developers to enjoy, in addition to which Apple’s SDK ToS does no apply to iPhone web apps…

The web is a guaranteed software development ground for the future - it is not something that is going to go away – unlike SDKs that are based on proprietary operating systems (even if those operating systems themselves are based on web technologies). At this early stage the business models for monetising web apps remain uncertain. But with carriers and handsets manufacturers needing to address device fragmentation there could be much to gain for mobile applications developers who, in the long term, choose to target more than just ’siloed’ communities of users. Communities wherein the agenda is being privately driven by a third party and where the terms of participation might only become yet more restrictive.