iOS Public Betas a Great Start, but only Part of the Solution

In January, I was pleased to see some excellent opinion pieces by, among others, two people named Marco.

Marco Arment, creator of Instapaper and developer of the superb Overcast podcast client for iOS, finally confronted the iElephant in the iRoom. Apple’s quality control, particularly when it comes to software, has slipped to the point that the problem is impeding productivity. Marco Arment called on Apple to spend time smoothing the increasingly rough edges.

I thought his initial post was thoughtful, timely, and needed to be written. It almost inspired me to break my hard and fast rule regarding not working or blogging during my summer break.

Thankfully, another Marco wrote most of what I would have anyway. On Marco’ Zehe’s Accessibility Blog, Marco wrote an excellent post on how Apple’s quality control issues are having a negative impact on accessibility.

I take my virtual hat off to him for writing it. It almost appears in the minds of some that if you offer constructive criticism of Apple, you’ve committed some sort of heresy. It’s good to see someone offering some robust analysis that points out the praiseworthy and the concerning.

Apple has chosen to become a screen reader company, and on that basis deserves the same kind of scrutiny, and constructive criticism, as any other. We endanger our ability to function effectively with technology if we hold screen reader companies to different standards based on whether they are “mainstream” or not.

Let’s applaud and celebrate Apple’s outstanding accessibility efforts which have changed the game in many areas, but we are purchasers too. We need not be the grateful recipients of charity who should simply accept what comes our way, even when it is increasingly flaky.

I use whatever platform, from whatever manufacturer, that will let me accomplish tasks most efficiently. Measuring efficiency is sometimes objective, so what is optimal for me may not be optimal for you. But I’m certainly not going to use a solution just because it has the Apple logo on it, if using another one would give me a better result. If I felt Android or Windows Phone would give me a better overall mobile experience, I’d switch when I had the money to do so.

We as blind people have so much to contend with, we can’t afford to treat technology like a sports team or a religion, praising everything one company does and being derisive of every other.

I also agree with the emphasis of Marco’s post in that it doesn’t suggest a lessening of Apple’s commitment to accessibility. In my view, that commitment is as strong as ever. There’s no greater evidence of that than the fact that if we choose, we’ll be able to buy an Apple Watch on launch day, triple-click the crown, and it will be accessible with VoiceOver. You can’t say that about any other smart watch. The consistency about the implementation of VoiceOver on a range of products is fantastic.

We’re dealing right now with a quality assurance issue across the board. While it might be argued that we’re more vulnerable to its effects than others, it’s not accessibility-specific. Fear not. Apple’s not suddenly going to take VoiceOver out of iOS. Accessibility is more in the DNA of Apple than any other mainstream company.

We, like every other Apple customer, are suffering from an Apple software QA issue. When Apple released an update to iOS 8 that disabled cellular service for many people, the update was pulled very quickly and a new build released. Yet we’re such a low incidence population that when iOS 8 was released with a bug that rendered a device speechless if Braille was configured a certain way, we had to wait a lot longer for a fix.

Perhaps that’s just the way it is, but it makes the testing process all the more important when it comes to accessibility.

The issue with Braille display status cells, and a number of other pretty nasty bugs, were known about. Many of us knew that iOS 8 was going to hit iDevices with them intact, despite us having reported them to Apple early in the beta cycle.

Many will remember that from an accessibility perspective, iOS 7 was also a little shaky in certain areas, and I was troubled by that. I had a think about what I might do to help minimise the chances of such problems occurring again. In 2014, I formed a private group of experienced testers, who I verified as being authorised to access the developer builds. We exchanged a lot of emails about bugs, and in many cases, worked together to fine-tune steps to reproduce the bugs.

I’m certain that this little effort made at least a bit of difference, and it’s nice to try to be a part of the solution whenever possible.

There were two problems though. The first is in itself accessibility-related. Submitting bugs to Apple isn’t the most user-friendly experience in the world from a blindness perspective. You can’t just send an email to the usual Apple Accessibility address, or you’ll get chastised for not using proper channels to report beta bugs. That’s all well and good, but the reporting process needs to be fully accessible.

The second issue is that collecting data about what’s wrong is only part of the process. The data then needs to be acted upon. Many others outside the testing community I founded were reporting bugs to Apple, and even now, some five months after the first public iOS 8 build, some remain unresolved.

No software is bug free of course, so I’m not suggesting for a moment that perfection is possible. But just to choose one long-standing bug, things like not being able to toggle QuickNav in iOS from a Braille display should be easy to address.

What has prompted me to write this now is a report from 9 to 5 Mac, saying that Apple intends offering public beta builds of iOS, starting with a public beta of iOS 8.3 next month. This is an excellent decision on Apple’s part and I applaud them for it. In the past, you either needed to have, or know someone who has, an Apple developer account, so your device can be added to the database of devices entitled to run Apple developer builds. For people who know who to ask, it hasn’t been too difficult for a blind person to piggyback on someone’s account. But for those who aren’t in the loop, paying the annual Apple developer subscription is quite a bit of money that many blind people simply don’t have.

Apple may also be acknowledging by moving to a public beta model for iOS that testers are doing Apple a favour. Developers enjoy the benefits of testing new technologies such as newly added APIs that might enhance their apps, but Apple also benefits from people who take the time to hunt down and report bugs. One doesn’t have to be a developer to be adept at doing this. Some of the best beta testers I’ve worked with in my own career as a hardware and software product manager have no developer background at all. Nevertheless, they’re meticulous, articulate end-users who have an ability to think logically about what just happened and what they did that might have caused it to happen.

So opening the iOS beta process to a much wider group is a brilliant step. But it’s not the entire solution. As I’ve illustrated above, many of us reported critical bugs in Apple’s code at a time when Apple could have fixed them, before they had a negative impact on the productivity of their blind users. Yet the bugs weren’t fixed.

Last year, OS X Yosemite was opened up to public beta, and a number of issues, arguably perhaps not as significant as those found in iOS, remained unresolved at release.

By opening the floodgates to a much larger number of bug reports, Apple will get a lot more data, but now we need an assurance that Apple is actually going to act on that data in a timely manner.

Rumours about a greater emphasis on bug resolution in upcoming iOS releases cause me to be optimistic that this important part of the equation, the timely resolution of the bugs that are reported, may be in hand as well.

In conclusion, well done Apple for taking the issue of quality control seriously. I’m left with an impression that Apple is more open to hearing, and acting upon feedback than might once have been the case. Let more people report bugs, make the bug reporting process universally accessible, then act on the data in a timely manner, and iOS will be restored to its former glory in short order.