Five months after declaring that iOS apps
developed with a cross-compiler would not be accepted into the App Store, Apple has eased up on its policies and
reversed course.
Beyond just being less stringent about what sorts of tools can be used to build apps, Apple has also published an App Store Review Guidelines that lay out, in black and white, some of the things that will prevent an app from getting into the App Store.
Both of these changes have big implications for iOS developers, and by extension, end users. We've spent some time talking to developers and companies who create iOS development tools to get their perspective on what this means for the future of iOS development.
A (Brief) Summary of Flash Fight '10
When Apple released the first SDK for the iPhone back in March of 2008, developers were quick to complain about the rigid set of standards and the stringent app review process.
When Apple released its SDK, it also made it clear that iPhone development was meant to take place on a Mac and inside Xcode. By encouraging programs to utilize Objective-C and the Cocoa Touch framework, Apple was able to build a strong level of consistency in its mobile applications.
Early on, many iPhone developers were also Mac developers, and the idea of using cross-platform tools wasn't as much of a concern. Fast forward a few years and the software development world is in a mobile gold rush, with much of that early activity fueled by the explosive growth of the App Store.
Thus, it wasn't surprising that third-party frameworks, toolkits and IDEs like Unity would come out to ease the development process. The Mono project, an open source implementation of C# and .NET released MonoTouch, an extension of its MonoDevelop IDE that was touted as a way for C# and .NET programmers to create apps for the iPhone.
In October, Adobe announced that it would be building iPhone support into Flash CS5, meaning that although native Flash content couldn't be played on the iPhone, the Flash program could be used to create an *.ipa that could then be uploaded to the App Store. Further more, this ability was built into the Windows and Mac versions of Flash CS5. In other words, Flash developers could use Windows to create an iPhone app and then just use a Mac to submit the file to the App Store.
Presumably, it was this development that spooked Apple. Just ahead of CS5's release, Apple updated the terms of its developer agreement to include the following:
"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)."
In essence, this stipulation would preclude applications that were created with the use of a cross-compiler or compatibility layer to be admitted to the App Store. Steve Job defended this decision in his infamous "Thoughts on Flash" memo, noting that apps created using non-native toolkits are slower and can be buggier and less responsive than their native counterparts. In other words, this was a quality assurance move.
The outcry from this decision was loud, although very few actual iOS developers really seemed bothered. Hand-wringing and "big brother" remarks aside, it appeared that a very narrow group of potential developers would even be hurt by the provision (assuming it was limited solely to Flash and not to products like Unity or Appcelerator's Titanium): magazine publishers.
Adobe worked with Conde Nast to create the excellent Wired Magazine app for iPad, but had to spend time rewriting the app natively after the no-Flash IDE rule was put into effect.
Adobe soldiered on and worked on creating some iPad-friendly publishing tools within InDesign, but larger publishers had to seek alternatives for how to deliver interactive print content without using Flash-based development tools.
Five months later, Apple has reversed course. Presumably, this means that if Adobe wants to go back to working on the iPhone Creator for Flash CS5, it can. The company has since said it would target its efforts on other mobile platforms, but if customers demand the feature, we feel pretty confident Adobe will listen.
So, what does this all mean?
Developer Reactions: Excited
From a cross-compiler perspective, very few toolsets appear to have been actively blocked by Apple, even before this reversal.
Initially, there were fears that the provision would extend beyond just Flash CS5 and into products like Unity and Titanium. It's important to note that with respect to those two companies, the official position was that the new stipulations had no impact on what those development tools do or how they work.
As we noted yesterday, Appcelerator has seen explosive growth since the first SDK agreement announcement and saw no direct or indirect signs that Apple would be banning Titanium-based apps. Likewise, Unity remained confident of its status as an approved tool. Still, both companies are very happy that Apple has rescinded its prior changes.
In a statement, Nicholas Francis, Unity Technologies co-founder and chief creative officer told us, "At Unity we applaud this move by Apple – we are all about enabling people to work with the best tools for any given job. Apple have always been focused on providing superior products to end users, and Unity games have been continuously released throughout this period. However, we are very happy for all those devs who can now join the party!"
We also spoke to Scott Schwarzhoff, Appcelerator's VP of marketing. Schwarzhoff told us, "All of these [changes] fundamentally provide transparency for developers and ultimately that leads to developer innovation, reinforces Apple's strategic advantage and benefits consumers."
Beyond just cross-compilers, Apple also decided to nix a recent provision that could have potentially disallowed third-party ad providers like Google's AdMob from working with the App Store. Here at Mashable, we were always skeptical that Apple would ever directly or even indirectly ban AdMob from the App Store.
Fortunately for everyone, we no longer have to theorize, as Apple has made it clear that it will not ban other ad servers from the App Store, provided the developers and the ad protocol follow Apple's privacy and customer data guidelines.
On the Google Mobile Ads blog, Google notes, "These new terms ensure that Apple's developers have the choice of a variety of advertising solutions (including Google's and AdMob's) to earn money and fund their apps."
Houston, We Have Guidelines
Moving on from the developer agreement-related changes, Apple has also made clear moves to be more transparent and to better communicate with its developers. Beyond the new "living document" of App Review Guidelines, Apple has also instituted a new Apple Review Board that developers can use to appeal an app's rejection from the App Store.
We've spoken with literally dozens of developers that have had their apps rejected from the App Store for one reason or another. In many cases, the rejection was understood by both parties (use of a private API, a bug that needed to be fixed, improper branding), but in others, the reason cited seemed to be at odds with the developer's actual intent or interpretation. In these cases, figuring out how to get an app re-reviewed or even an opportunity to better explain what was actually going on was like pulling teeth.
Thus, the mere fact that a documented process now exists is a great move. When speaking with some veteran App Store developers about today's changes, the general feeling was that this is a great move in the right direction.
One developer told us that the ambiguity surrounding the app review process has been the most frustrating aspect of dealing with App Store. Not having any clear insight into Apple's thinking process made it hard for developers to know what to do. After all, it's hard to conform to a set of requirements if those requirements are locked up in a black box.
Still, despite these ambiguities, none of the developers we talked to were ever bothered enough to look seriously at other platforms. That isn't to say that hasn't been a concern for others — and there are a few famous examples of high-profile developers leaving the platform because of the black box approach to guidelines.
At this point, developers may not agree with every guideline, but at least they know what the guidelines are.
Is This Enough
Android continues to gain momentum, with more and more devices selling all over the world and a flurry of new devices coming out nearly every single day.
It's not unreasonable to view some of Apple's changes as a response to Android's growing strength. Android is sold as an "open" platform, and while the actual level of openness can be debated, at the very least, its garden is surrounded by a low-level fence if not a full wall.
Having said that, in our research and discussions with developers, we just haven't seen any proof of a migration from iOS to Android or any other platform. Yes, Android development is growing in importance and is now often at a higher priority or consideration before, but by and large, the iPhone is still the primary target for most developers and brands.
Regardless of the headaches, most developers we talk to wouldn't give up the ability to develop for iOS. That doesn't mean that every developer will develop for iOS exclusively, but the restrictions haven't pushed a large number of developers away.
Still, Apple clearly sees Android as a competitor. We think that by making the decision to relax some of the IDE restrictions, to be more clear about supporting third-party ad services, and to make review guidelines accessible, Apple is showing that it does listen to its users and developers.
As a company, Apple has a very strong vision and a very concentrated focus. Because of this, Apple is often viewed as a company that doesn't listen to others. Historically however, it's clear that when push comes to shove, Apple does listen to its customers.
As an example, two years ago, the very first aluminum unibody 13-inch MacBook (that shared the same stylings as the 15-inch unibody MacBook Pro) was released without FireWire support. This was a big deal because FireWire was a technology Apple helped standardize and really pushed in its accessories. The customer outcry was immediate and despite Steve Jobs's e-mailed responses that most people won't ever use FireWire and that new video cameras all use USB 2.0, when Apple brought out its new MacBooks six months later, the now re-christened 13-inch MacBook Pro sported the addition of FireWire 800.
For years, developers have been crying out to Apple for more transparency and openness in its app process. Today's announcements are a good way towards fulfilling those goals.
What do you think of Apple's latest changes? Do they make you more likely to continue to develop for iOS? If you have held off from developing for iOS, do these changes make a difference? Let us know.
Reviews:
Android,
App Store,
Google,
Mashable,
WindowsMore About: adobe, appcelerator, apple, Flash, iOS, iphone, iphone sdk, mobile development, unity
For more Apple coverage:
Ted Patrick (
