Why Apple’s opacity with developers is bad for users

As the 2014 edition of Apple’s Worldwide Developer Conference approaches, Mac and iOS developers who were lucky enough to win the ticket lottery are beginning to share their expectations and hopes for the coming conference through their blogs and over social media.

While interest in new products and technologies is undoubtedly running high, however, a common pervading theme is the hope of grabbing some one-on-one time with an Apple engineer and asking questions that, all too often, go unanswered through official channels.

Lies, damn lies, and bugs

As a company, Apple is not exactly known for its warm and fuzzy attitude towards disclosure—a stance that works well when it comes to delighting its customers with new products, but that often tends to irk third-party developers whose success depends on their ability to properly utilize the company’s software and services.

Unless those developers find themselves at one of WWDC’s labs or happen to have a direct contact within the appropriate engineering group, they typically have a limited set of avenues for reporting problems with one of the company’s software development kits—the tools that make it possible to build apps for iOS and OS X—and services like iCloud Sync. One such system is the venerable Bug Reporter, a public website through which any user can report issues with any of Apple’s products.

Unfortunately, using the Bug Reporter—known internally at Apple as Radar—is often a hit-and-miss affair, as issues that the folks in Cupertino don’t consider as priorities sometimes go unanswered for months or years (I have a bug that has been open since February of 2009, for example). Those reports are managed through a largely opaque process, making it hard for a developer to track the progress of the bugs they file.

“I’ve had countless Apple employees tell me over the years that filing bug reports is the most effective way to get actual bugs fixed and ‘vote’ for new API features,” wrote  Instapaper creator Marco Arment in a recent blog post. “Of the few that get any response at all, it’s almost always a useless response or the obvious result of a careless engineer trying to clear out the bug backlog with as little work as possible.”

The frustration is in the cloud

The frustration that developers feel towards Radar is not hard to understand when you consider that third-party apps are entirely dependent on Apple’s underlying software in order to work properly. A bug in the code that, say, makes touch interaction possible, or a limitation in iOS’s Twitter interface could mean dozens of hours spent working around an issue—hours that could instead be spent creating a better experience for the end user.

Moreover, Apple’s ecosystem has grown over the years to encompass all sorts of cloud services, which, like all Internet-based systems, are prone to the occasional bout of downtime. Thus, developers are increasingly faced with problems that arise after they’ve delivered a finished product into the hands of hundreds of thousands of customers, and often without any warning or notice from Cupertino.

Such was the case for Adam Grossman, one of the developers behind the popular Dark Sky app. In a follow-up post to Arment’s article, Grossman described how a temporary outage in Apple’s geolocation services—used to match the name of a location with a set of geographical coordinates—caused his software to stop working. “Apple’s server was broken,” he wrote. “You could still get a weather forecast for your current location, but location searches—which many users rely on—were out of commission.”

Faced with a deluge of angry customers, the Dark Sky folks attempted to contact Apple through Developer Technical Support, which offers ad-hoc assistance to users who pay to join the company’s developer program, and still got nowhere. “Five hours later, still with no response, I called up the Developer Telephone Support line to check on the status,” wrote Grossman. “They couldn’t even check on the status of our ticket!”

Trickle-down

While developers bear the brunt of dealing with Apple’s bug management system, all customers may ultimately suffer from its opacity, since third-party apps are often the most front-facing part of the iOS and OS X user experience. Reached via email by Macworld, Grossman explained that “bugs are bad for users. In my case, Dark Sky was broken for three days and there was absolutely no information we could give to any of our users as to how long it would stay broken or when, if ever, the problem would be fixed.”

Red Sweater Software developer Daniel Jalkut, who responded to Arment’s post by reinforcing the need to file bugs, takes a more sanguine approach, explaining that the company’s tight-lipped stance is about managing expectations. In an email to Macworld, he clarified his viewpoint: “On the one hand, Apple wants customers to think [it] cares deeply about them, while on the other … [its] priority is to remain silent about specifics of fixes so as not to make promises [it ends] up not delivering on. I can relate to this as a developer, and I treat my customers with a similar kind of ‘no promises, but I hear you’ approach. Ultimately I think it’s the best compromise.“

Of course, it helps that writing software for OS X and iOS means reaching a market of millions of customers who don’t mind paying for the apps they find useful—a detail that is not lost on developers, who don’t seem to be in any hurry to switch to competing platforms. Says Grossman, “Apple still has the best platform out there. Which is maybe part of the problem: it’s not like [it’s] going to suddenly lose a bunch of developers because [its] support sucks.”

Change is hard

Obviously, this doesn’t mean that Apple couldn’t (or shouldn’t) improve the situation. The sheer number of participants in the company’s developer program is likely to translate into a very large number of bug reports reaching its technical support systems on a regular basis, which probably makes managing those reports a challenge.

Still, Apple’s deep pockets should make it possible for its engineering team to hire enough manpower to at least provide developers with better feedback, if only to let them know that their bug reports are not falling on deaf ears. “If [Apple] can’t handle the load, [it needs] to hire more technical support people, pure and simple,” says Dark Sky’s Grossman. “If [the company has] to charge more for support emails, so be it.”

The problem, however, may be institutional in nature. “I see Apple as behaving in black and white in many instances, and this is one of them,” explains Red Sweater’s Jalkut. “Rather than figuring out the nuances about how [it] might be slightly less opaque, [it] ‘sticks to what has worked,’ which in [its] case is to draw a pretty stark line over which [it] will not cross when it comes to sharing details about unannounced products or, yes, even unannounced bug fixes.”

Ultimately, adopting a more transparent approach may well be in the company’s interest: Happy developers who can place their trust in a well-curated programming ecosystem are likely to continue cranking out better apps, which translate into loyal customers that continue to invest their hard-earned money in Apple hardware—and that’s something we can all agree on.