I am, by no means, an expert developer. The code that I write is of the same quality seen from any novice in any trade or hobby: it’ll do but it certainly isn’t professional. The code that I write is passable, functional but lacking an elegance that you’d see with someone who has extensive formal training. Despite this, I can put together an application in a variety of languages that work, are relatively bug-free and efficient enough to preempt end-user cursing. Given that this is the reality of my skills, I find that I’m confident enough to put applications up in relevant markets for download by end-users, individuals that I’ve never met but I can reasonably assume will bear with the app if they ever had the desire to use them. In this way, I’ve experienced what it’s like on the “other side” of the App Store; I’ve gone through and fought with the App Store approval process, having both experiences defined by success and frustration. Today, I want to focus on the latter and highlight why the App Store model, despite the merits that come with close scrutiny of the content submitted for approval, is fundamentally broken.

The Good

In many ways, the App Store has a variety of advantages over something like the Play Store (the only other app distribution channel that I have familiar with so I limit my comparison here). Whereas the Play Store lacks individualized scrutiny of each application submitted, Apple inspects applications submitted for approval. I figure that this must involve humans – the App Store emails from iTunes Connect (the service responsible for preparing and uploading application content for approval) all but disappear on weekends and holidays. End-users reading should take solace in this fact for you have a level of guaranteed scrutiny that you won’t see with something like the Play Store (this is double edged however – honest developers can push out bug fixes and updates many, many times faster on Android than they can on iOS). Although this doesn’t secure the platform with any sense of perfection, it does insulate the platform from sloppy and rather easily detectable flaws and malware.

The App Store approval process also acts as an extra layer of quality control. Rejection notices can include justifications rooted in concerns over quality. After all, it’s Apple that benefits primarily (let’s face it, the App Store is for Apple’s benefit first, developer benefit second) and to let anything enter the marketplace is to potentially tarnish reputations that Apple crafts in its marketing practices. By being selective in that which can piggy back off of the platform, Apple retains a tight leash over who and what gets privileged. Why is this a good thing? Simply put, it ensures a particular standard of quality, one that is relatively high with Apple.

Third, a longer approval process might encourage developers to think about their own quality standards to a greater degree than with something like the Play Store. By making the process drawn out (relatively speaking), Apple has incidentally create a culture in which developers can expect releases to take longer to propagate across devices. If it takes five days to get approval (not all that uncommon), developers might be more likely to make sure that everything works because if it doesn’t, bugs linger in the user base for days at a time. With the Play Store, a marketplace in which app updates are available within hours, developers can be confident that any mistakes can be fixed quickly and thus, apps can be pushed out with a smaller concern or regard for quality. In other words, if it’s easier to push out bug fixes, you can worry less about the consequences of bugs because fixes can be pushed out with relative expediency. While this does ensure quicker releases of bug fixes, it does encourage a culture of “let the users be the beta testers.”

The Bad

Let me tell you about a recent experience that I had with the App Store. As part of her teaching, I created an app that contains the readings for a course that my partner is leading. It gives students the chance to have the readings with them at all times and it lets students save excerpts for assignments in which they might want to reference content. I submitted the app to the App Store, realizing after the fact that a minor bug was present (purely cosmetic but a nuisance nonetheless). I let that one slide and intended to upload a bugfix release once the initial version was up. A few days after uploading the binary, I got a message from Apple asking me for some clarification on a few questions regarding its purpose and whether or not it was linked to an already existing service. While I had never seen this before, I went along with it and answered the questions as honestly as I could. A day later, I found out that the app had been rejected because the “market” for the app was too small. In other words, the potential userbase was too small and consequently, it was argued that this would detract from the overall experience of the App Store which is meant to provide a set of applications useful to large portions of the user base.

While Apple admitted that what constitutes “niche” is arbitrary (their wording), they noted that I could fill out an appeal if I had reasonable justification. That said, they argued that I couldn’t use precedence – if an app in the App Store appeared to target a similarly sized niche market, I couldn’t reference that as justification for its inclusion. Quizically, I decided to forego doing that (despite the fact that precedence is important) and proceeded to make a claim for its inclusion in the App Store on pedagogical grounds. I argued that the application was being used in an educational context (a context Apple purports to support with unquestioned enthusiasm) and that the app was being piloted with users in a specific classroom with the possibility that it might be used in other classrooms at some point, an argument made to directly address the “niche” argument.

My response from Apple was rather disheartening. The appeal was rejected, with Apple making the claim that the original decision was valid and that letting an app with a small target market would detract from the overall experience that Apple was trying to cultivate. Thus, Apple rejected the application not on technical or legal grounds but instead, rejected it because my target audience didn’t meet Apple’s arbitrary (admittedly so) criteria for acceptable market size.

As a possible solution, Apple suggested two things. First, it suggested that I distribute the app through an ad-hoc distribution server. This requires me to get the UDIDs of every single student who uses an iOS device in the class and then generate a provisioning file that includes each and every one. A simple mistake in copying over this code means that the app won’t work at all for that user. I’d also have to track each device – if a new one is added (pretend that a student gets a replacement phone or a new iPad), I have to remove the old one from the list of authorized apps, add the new UDID, recompile the app and update the copy of the app for every single user. Let’s assume for a moment that this was feasible. Were this the case, I’d have to setup an ad-hoc app server and then manage this. None of this is pleasant, easy or worth the effort.

The second solution involved Apple’s recommendation that I make a web based version of the app. In other words, Apple told me to rewrite the application such that I don’t run up against their draconian restrictions. In effect, Apple has said “one possible solution is to obviate our rules all together by ignoring the only market place available for the platform.” How this is a helpful solution escapes me.

The outcome here is simple – iOS users in this classroom get nothing and can watch their Android using classmates use the app. Why can they watch them? Simple: Google couldn’t care less how big the target market is because, presumably, they want developers to decide for themselves how large the market is. Google also seems to realize that niche products do not destroy or tarnish the quality of the platform as a whole and instead, make it easier to use the platform for very specific purposes. Even if they didn’t, the ability to install apps from wherever you want means that even if Google had similarly restrictive rules, I could distribute the app myself without having to contrive some sort of ad-hoc solution that required validating and authorizing individual devices. From where I sit, this is reflective of everything Apple does wrong about development for their platform. All steps in the process are convoluted, time consuming and require different parts to work together (you register the app using iTunes Connect and then have to use an application on your Mac called “Application Loader” to upload it…for some reason). I’m not saying that Google’s process is perfect for those criticisms of their process in relation to the benefits for Apple users are still worth noting and highlighting. What’s important here though are the benefits as they exist for end-users, not developers (and consequently, perhaps contradictorily so, for end-users). It would appear that Apple is doing what they can to make development miserable for iOS devices so as to ensure some sort of quality or standard for end users. Does that have to be the case though?

Conclusion

I don’t want to make it sound as if application development for the iOS platform isn’t worth it. The platform as a whole has benefits for developers in particular locations (if you’re in North America, you can’t ignore it). Instead, I bring this up to generate discussion around the difficulties experienced by those behind the scenes. The excessive attention to detail on the part of Apple gets offloaded to developers such as myself whose intentions can be as admirable as “trying to help students learn by making access to content easier.” I’m not trying to make myself sound like a victim either (indeed, this process has convinced me that developing for the iOS platform isn’t worth it and, as a consequence, has clarified a few things for me). From this, I hope to illuminate the consequences of the walled garden approach and not just for developers, but for end-users. From my experience, I now know that a portion of a class loses out on a possibly beneficial mobile tool and that there’s very little that I can do. Who knows how many other “niche” iOS markets have lost access to something.

Do you have any experience developing for iOS or any other platform? Do you have similar or different experiences?