Apple Offers App Developers Some Certainty

As someone involved in mobile application development, Apple's policies and practices regarding app development have always made me uncomfortable, as it has many, many others. One of the most unacceptable from a purely business perspective has been their app approval process. Not only has been little certainty whether, after you've put in your investment, they will permit your app onto their market (the only legitimate way to distribute to iPod and iPhone owners), you can never be sure it's due to some unwritten policy, the reviewer being in a particularly bad mood that day, or because your app may competitive with a current or future strategic initiative of their own.

Despite this dreadful uncertainty, Apple has been enormously successful in attracting a large stable of app developers, both small shops (including individual hobbyists) and some of the world's largest companies, many of whom are making a decent business of it. In other words, despite the criticism Apple had lots of reason not to make changes since their policy to this point has worked very well indeed.

Yet Apple is now officially loosening some of their more restrictive policies and coming clean on their app approval criteria. Uncertainty is one of those terrible things that can scare off any investor or businessman, so the change can only be a good thing. Less uncertainty means more predictability and less arbitrariness in those that might choose to develop apps for iOS products. As John Gruber says in his Daring Fireball blog:

**The existence of this document is a very welcome change, and it goes a long way to answering much of the criticism regarding prior controversial App Store rejections, by putting in writing the rules that are actually used by the reviewers.**

Regrettably the new policy is not public, only becoming available after you've paid your money and signed up to their developer agreement, which is not really as transparent as they ought to be. Of course this does not mean that it will not end up becoming widely available (there are far too many potential points of leakage), and in fact it already has. Apple's non-legalistic summary language is a fun read:

• We have over 250,000 apps in the App Store. We don’t need any more Fart apps.
• If your app doesn’t do something useful or provide some form of lasting entertainment, it may not be accepted.
• If your App looks like it was cobbled together in a few days, or you’re trying to get your first practice App into the store to impress your friends, please brace yourself for rejection. We have lots of serious developers who don’t want their quality Apps to be surrounded by amateur hour.
• We will reject Apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, “I’ll know it when I see it”. And we think that you will also know it when you cross it.
• If your app is rejected, we have a Review Board that you can appeal to. If you run to the press and trash us, it never helps.

Of course the actual agreement text (including the above summary) goes into lengthy specifics, which you can find on the Wired site (hopefully this link remains valid for a while). Despite the disclosure of these criteria, Apple retains a great deal of latitude in rejecting apps, so there is no reason to believe that the situation will now be much different for many developers.

Still, it’s an important step. By publishing the guidelines, Apple mobile customers will be able to know what they can and can’t get on an iOS device versus, say, an Android phone. Also, third-party programmers will have a clearer sense of whether or not to invest in developing an app, whereas before they were subject to rejection without knowing what they weren’t allowed to do. However, some developers think parts of the guidelines could be more clear.

“By no means is what they put out today perfect,” said Justin Williams, developer of Second Gear software, who quit iPhone development last year. “There are some vague areas. But compared to where we were yesterday, it’s a big improvement.”

As some of the commenters on this Techcrunch article correctly note, the terms of service regarding use of user data continue to be a bone of contention. Privacy sounds good, and in general it is, there does have to be a balance between user privacy and reasonable commercial practices. This is an area where Google and other mobile ad companies had concerns with Apple since much of the sellable value of ad space is lost if the advertisers can't know as much about users as they can on other mobile platforms or on traditional web browsers.

I've gone and lost the link now, but Google did issue a statement that they can work with Apple's new policy on user data privacy. Presumably they believe that they have enough access to non-identifying user data to meet advertisers' needs.

Apart from my concerns about the practice as a user, I have also had concerns as a developer because of the personal data that mobile ad companies demand that Android app developers such as myself get from their users. For example, disclosing location and unique device identifiers to enable user tracking. I don't particularly care for this as either a user or as a developer, though I also know that most smart phone users are simply not concerned about it. The qualms come from not knowing how the advertisers or mobile ad distributers are using this data, while having to take responsibility for asking users to give their permission to disclose this data.

It is interesting to watch the different approaches taken on iOS and Android on user privacy and app approvals. I can't say that Apple is really out to protect users with their stronger stance on app and ad content. They have their own commercial interests in exploiting their control over the entire eco-system they control, but they also know that they must treat their customers better than they treat developers and advertisers if they are to retain their still dominant position in smart phones.

I have to wonder how much of their policy changes on app approvals, mobile ad services and 3rd-party app development tools has to do with their increasing comfort with the reins of control they enjoy or with the increasing thunder of the advancing Android army. The battle continues.

Common Mobile App Platform

This is the week of the Mobile World Conference in Barcelona. With mobile technology having become so dominant, this event has become a major venue for carriers and vendors to trot out the latest gadgets and to announce new deals. The press releases have been coming fast and thick since the weekend.

One curiosity is the Wholesale App Community, an alliance of phone vendors and carriers around the world, to jointly build a vendor-independent platform for software app development. This would allow an app developer to write an app once and it will successfully run on any smart phone OS platform, on any mobile device and on any network. This is no mean feat, which any app developer knows, since they're the ones that have to write and rewrite app software if they are to run on iPhone, Blackberry, Android, and other platforms, and also deal with the diverse form and features of mobile devices using each of those platform. Here it is in the words of this new alliance:

"For the developer, particularly small developers, the alliance will create an environment in which they can flourish and create applications in a straight-forward and effective manner. Today, the route to market for developers is challenging requiring them to approach multiple operators. The alliance will provide a single gateway for developers to access a vast potential customer base (over two billion with limited cost to the developer and this in turn will provide the maximum possible return on investment for them.

In addition, the alliance will utilise existing technical standards, rather than creating new ones to allow developers to access operators’ assets, for example network capabilities or API’s (Application Programming Interfaces) more easily. In practice this means that developers will only have to create one version of their application and this can be used on multiple types of devices and operating systems (such as Symbian, Android, Windows etc) which is not the case today."

Sounds great, although the details are at best sparse. The announcement itself is unsurprising since it's been telegraphed by many of the alliance members for quite some time. The thing is, is it feasible? Technically, sure it's feasible, but it is more important to ask how they will go about it and whether it will gain market traction. An example of a similar success is the world-wide web, courtesy of standard HTML and compliant browsers; it can be done.

As to how they'll do it, that will be interesting to see. One of the important reasons to have native apps -- those that are tuned to a device platform's OS and environment -- is to make use of all the services and technology that is local to the phone: GPS, accelerometer, orientation sensor, audio streams, camera, file system, and so on. A successful alliance initiative would need to achieve a common platform while providing local access to many device features. The challenge is increased by rapidly-evolving smart phone technology; a too-static common app layer will fail if it can't keep pace with the underlying mobile device feature set.

Can a common app development layer diminish the preeminence of the platform decision when developers produce an app? Certainly there will be a shake-out among mobile platforms since there are too many. This is going on even now with the announcement that Moblin and Maemo will be merging, reducing the number of Linux-based variants; this will not be a typical outcome: each of the rest will either survive or die. This, too, could happen to the alliance's initiative.

After a few moments of thought, I have an idea what a common app layer needs to achieve if it is to have the kind of success the web browser has achieved. In fact, it may be a variant of the web browser.

• HTML5-based app language that can run within a browser, providing a common user interface
• Cloud (server) APIs to access carrier-provided network services
• Javascript virtual machine to execute app code on the device
• Javascript APIs to access mobile device features

This is pure guesswork and probably wrong. I just want to give a flavour of what is needed. Others are guessing as well, and it does seem that games must stay native for now. The carriers will have full control of the network APIs, but need device and platform OS providers to cooperate on the device side software. The browser will become so heavyweight that it may take another generation of mobile phone technology to make it run well, but that will be no impediment if the initiative is planned as a long-term strategy.

I wish the alliance luck, even though I will not hold my breath. Then once it gets into the wild, my bet is that we'll see the first serious malware, designed specifically for the new app platform, appear within one week.

Silence of the App Users

Although I am involved in the Android app market, I haven't talked about Android apps in this blog for some time. I was recently compiling some statistics of one app that's been out in the market for over a year, and I suppose it is no surprise that what my stats show are not unlike what other app developers typically encounter: silent users.

You'll get an idea of what I mean if you look at the following numbers gleaned from this free app that has garnered downloads well into the six figures:

• Rated the app: 0.6%
• Emailed us: 0.01% (includes complaints, questions and compliments)
• Posted a review: 0.05% (or about 1 in 10 of those who rate the app)

To sustain my anonymity I have left the app unnamed and kept all the figures as percentages rather than actual numbers. I will only say that the app is useful but not terribly complex to use. Some use it only once or a few times, and whether they like it or not, for them it's enough and they then uninstall it. That's fine by me, and I even expect it. About 1 in 3 keep it for the long haul, which I consider quite good for this particular app. We only put it out there to gain experience with the mobile app market and its users, and especially to learn something about what works and what doesn't work in this slice of the market.

You also learn that people who use apps are a diverse lot who often judge apps in what I can only describe in a very subjective, egocentric manner. (This is meant as an observation, not an insult.) For example, if a user doesn't like what the app reports in response to info entered by the user, the user will often rate the app poorly. If they don't like the phone or network performance, they rate the app poorly as well: perhaps they do this in frustration since there is no way to rate the phone itself or the carrier.

Because the app does make what I can only describe as judgments about the user, they don't like this even if the information is correct. In retaliation some seem to see the app, phone or the developer (or perhaps all three) as things that are safe to lash out at, anonymously; I have seen user angst in both public and private feedback and, trust me, some of these comments are things I would rather not know! Perhaps app feedback works in the manner of ELIZA, the ancient software psychoanalyst that, despite its transparent primitiveness, still managed to get some people to empty their souls to the machine even when they fully understood that it was a mindless automaton.

Although I don't have complete analytical data, I will conclude by making the following general observations about many users:

• They do not read instructions or any of the help provided;
• They do not know they can use the Menu button to bring up additional features and options; and
• If it is at all possible to mess up the simplest operation, they will (and occasionally blame the app developer).

It's been a lot of fun and educational, and also useful to our future business plans.