An Open Letter to Phil Schiller and Apple Developer Relations
January 21, 2017
Dear Phil Schiller,
My name is Brandon Medenwald and I co-founded a small company called Simply Made Apps in Fargo, North Dakota. Our product, Simple In/Out, has embraced your developer platform since 2011. We have 3 native apps for iOS, a tvOS app (making us one of the few business apps in the tvOS Store), and a native app in the Mac App Store. I mention this to bolster my credentials as exactly the kind of developer Apple hopes to foster.
I write you today to share my frustration with the sporadic nature of App Store reviews and to offer what I believe is a great solution. I hope by the end of this letter to convince you of the merits of my idea.
The Problem
The problem is the uneven application of the approval rules, the root cause being that individual App Store reviewers have broad discretion and finite time to check apps for every single one of the mounting guidelines that exist. This is understandable as reviewers are only human. The fact is that an “issue”, an item that has been approved countless times in the past, can stop our development cycle cold.
When we have a new feature to ship, many times we need to go live with all of our apps and related API services at the same time. Recently, one of our apps was rejected for violating Rule 2.3: Performance: Accurate Metadata. Specifically, we had mentioned in our app description that our 45 day free trial was available with “no credit card needed”. For any developer submitting to the App Store, these so-called “metadata” errors are perhaps the most frustrating. They are arbitrary in nature and often at the mercy of the reviewer’s interpretation. This language, for example, has been in our app description for years (plural) and has been approved every single time.
While this example stopped us in our tracks despite not being an issue in prior years, at least we were able to resolve it quickly. Other times we have not been so fortunate, like In-App Purchase demands placed on Software-as-a-Service companies like mine. In these instances, it’s weeks of work before anything else can ship even though we’ve made no changes around these “violations”.
I understand that Apple has policies that are subject to change. I also understand that Apple internally emphasizes/changes rule interpretations to clamp down on bad practices. This is all well and good, but the frustration from developers like myself is that these indiscriminate rejections appear out of nowhere and often happen at the worst possible moments. We’ve had multiple instances where bug fixes were thwarted by a seemingly-random cracking of the metadata whip.
You see Phil, I want to be a good App Store citizen and the changes your reviewers demand are not bad or unreasonable. What is unreasonable is that I cannot schedule our programming resources around rejections on existing functionality/metadata that have been approved countless times in the past. This has knock-on effects on our non-Apple developers, our customer commitments, and our marketing efforts.
The Solution
I write to you not just to complain but to offer a solution that I believe will solve this problem in a way that is both fair to developers as well as to Apple. The solution comes from the real world: law enforcement and the Fix It ticket.
Let’s say you are driving down the road and you are pulled over for a broken headlight. The police officer does not issue you a fine, you are not placed in jail, and your planned trip is not measurably disrupted. You are provided with a Fix It ticket which gives you 30 days to have your headlight repaired and you resume driving. Your travel plans remain intact while you have the flexibility to schedule the repair over a month’s time. If you do not repair your headlight within 30 days, then you suffer the consequences the next time you travel.
I believe a similar solution would work wonders within the App Store review process.
If you are found in violation of a non-critical rule and that same violation existed in the previously-approved version of the app, the reviewer would approve the app for sale and would issue a Fix It ticket. This ticket would specify the violation and start the 30 day clock. After the 30 day period, Apple would block all approvals if the violation hasn’t been resolved.
This policy would allow critical bug fixes to go through without the delay caused by rules being interpreted differently from review to review. The 30 day warning would be on the developer’s account, making it easy for your App Store reviewers to see what other reviewers are doing and reject those that haven’t complied. Fix It tickets would reduce animosity towards the review process by creating a system where the only ways to have updates rejected is by creating new violations entirely or ignoring Fix It tickets for longer than 30 days. Apple can change emphasis on the guidelines without placing the hammer to all updates big and small.
Most importantly, this would allow developers like myself to schedule these fixes without arresting our entire development process.
I hope this idea can be implemented in the future for the good of Apple and the developer community. I would welcome a dialog on this matter at any time and my email address is below. Thank you for your time.
Sincerely,
Brandon Medenwald
Co-Founder, Simply Made Apps, Inc.
brandon [at] simplymadeapps [dot] com