How Apple's restrictive app store policies are driving Android platform adoption

Wouldn't it stink to create a great mobile application, only to have Apple reject it from being published in their app store? Sadly, that's exactly what's happening, and it's helping to drive software developers to the Android platform.

Thenative versus web app debate is ongoing in the mobile development community. There are plenty of pros and cons from a technical perspective for performance and usability, but behind the scenes, there are also many considerations from a business perspective that must be taken into account. One of the first things to think about is whether it will be possible to get the app published in an app store—or even whether the development platform for that store is designed for the enterprise.

We ran into unsurmountable hurdles with the Apple store getting the container published.

Steve Maryka, CTO at ICEsoft

Not all app stores make it easy

Barry Burd, author of Android Application Development All-in-One for Dummies, admitted he finds some policies difficult to navigate from a development viewpoint. "What I like about Android is the openness. I like it as an alternative to the competing platforms. I find many of Apple's policies to be unnecessarily restrictive. In contrast, the policies surrounding Android seem to be much more open. I'm sure in the fine print of the legal documents there are similar restrictions that would keep us from calling it an open platform. But at the level which I use it, there seems to be more openness. Plus, it's Java and I'm comfortable in Java."

In an age when every amateur coder seems to have an app for sale, it can be surprisingly difficult for a business to meet some of the more arcane app store requirements. Putting together a simple consumer-facing or gaming app could be relatively straightforward. But an application designed to help developers create other mobile apps is another matter entirely.  The licensing issues alone could pose a monumental challenge. Sometimes, an app store might simply choose to say no, rather than working with a company to figure out a solution that complies with their labyrinthine policies.

A quick cautionary tale

Ted Goddard and Steve Maryka at ICEsoft technologies got to experience the frustrations of app store delivery firsthand when an important aspect of the company's initial ICEmobile tool suite for mobile was cut off at the knees. ICEmobile had put together a nice suite of components and styles to build a web application that could automatically detect the device it was being displayed on and style a page to look like a native app. They were intent on introducing hybrid capabilities with containers much like those offered by PhoneGap with JS for direct access to native features.

The idea was to offer this suite as a development tool developers could download from the app store and then brand to deliver their own application. It was a great concept, but there was one big problem. According to Steve Maryka, "When we went to publish the containers, we ran into unsurmountable hurdles with the Apple store getting the container published."

How to take no for an answer—and run with it

That wasn't the end of the story for ICEsoft's tool suite. Steve said being forced to innovate ended up being a boon. "Ted and his team devised a new technique to deliver hybrid capabilities to the application using URL interception. Basically, the web application from the browser will issue a URL when you click on the camera button that has a custom scheme to it that would then be intercepted on the platform by our utility application. The utility app would perform the camera function, upload the artifact (image) to the server and pass control back to the web application again by issuing a URL that the browser would then intercept."

What I like about Android is the openness. I like it as an alternative to the competing platforms.

Barry Burd, PhD

The workaround actually turned out to be a faster and easier solution. "It started out as a way around app store publications problems at Apple. But we discovered that this approach was much simpler. You could use a pure web application that relied on a standard web browser and work across a wide variety of platforms."

With this web-based solution, they avoided the issues that could arise with a containerized method. "One of the problems you run into in the hybrid world with technology like PhoneGap is that the web container the hybrid solution uses is not always the best-in-class browser like Chrome or Safari for the mobile space. It is typically less performant with fewer HTML5 capabilities. That makes it difficult to write web applications that perform across platforms." From this angle, hybrid vs. web may appear even less attractive than native vs. web.

The correct approach for enterprise mobile development

As Ted pointed out, the right decision depends on what you're trying to do. In his experience, "The web application approach is by far the path of least resistance. Enterprises typically have a huge amount of web-based infrastructure and are developing a large number of apps with a wide variety of functionality." In addition, these apps need to be updated frequently. When this is the case, putting as much emphasis on the web side as possible may help larger organizations get the most out of their investment over the long run.

What struggles have you had getting apps into the Apple store? Let us know.


Dig Deeper on Ajax Web development and Java client programs

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.