App Store Update Approval: A Proposal
As mentioned over at the Ballistic Pigeon blog, our latest update to Folio was rejected by Apple. The rejection was for a legitimate violation of the HIG, and is well in line with the precedent established by Apple so far. The issue of App Store approval has been done to death, and I have nothing of note to add to the debate about the process as a whole. I do have a constructive proposal for how this process could be improved for future updates: provisional approval for a single revision.
First, some background. The particular issue we were rejected for has been present since Folio 1.0. Neither Apple nor Ballistic Pigeon had noticed the issue prior to 1.0.2. We also hadn’t received any bug reports from users about it, although we’re well aware that this doesn’t mean users hadn’t noticed it. One could argue that we were lucky to make it into the store at all, and I would be inclined to agree. If we’d been rejected prior to 1.0, I’d have nothing to complain about. That wasn’t what happened, though.
Our product made it into the store and, as with all software, it had bugs that made it past QA. Some of these were minor UI glitches like the popover issue in question. Others were more severe bugs that could cause crashes. Folio 1.0.2 contained a number of fixes to the latter type of bug. It did not fix the multiple-popover issue because, at the time we submitted it, that issue had slipped by unnoticed.
The problem, then, is this: by rejecting our update Apple has left users with both the buggy popover behavior and the crashing bugs we set out to fix. I support that Apple cannot simply let updates like this slip by without action. The point of the HIG is to provide a baseline standard for how high-quality apps should behave. Such standards are important to maintaining the overall quality of the App Store, and simply approving apps which violate them defeats the entire purpose. There is a middle ground, though.
To both provide users with timely access to import bug fixes and to encourage developers to fix UI issues as they’re discovered, I suggest Apple approve exactly one version of an app with a newly discovered “minor” bug. That is, if you submit an update which contains an issue that would cause a reviewer to reject it and that same issue is present in the version currently live in the store (meaning it had been missed on a previous review cycle), the update can still be eligible for approval.
Under my hypothetical approval process Apple approves the update, notifies the developer that there’s a problem, and the developer has one release cycle to fix the issue. Future updates in which the issue is not addressed will be rejected just as they are today.
This middle ground encourages continuous improvement while still allowing users to gain early access to important bug fixes. It’s also more equitable for developers: bugs which make it past both developer and Apple QA once are given a free pass for one revision since by this point both the developer and Apple are at fault for the buggy software having appeared in the store.
Tweet