Lorenzo Villani

(╯°□°)╯︵ ┻━┻

Unsolicited Advice

Apr 4, 2015

Earlier last year I went all-in to the Apple ecosystem after a 10 year-long relationship with Linux and a four-and-a-half one with Android.

One thing that struck me the most was how Apple is handling its developer community and how inefficient some processes appear on the outside.

Bug Reporting

Apple’s bug reporting tool suffers from one critical flaw: each ticket is private between me and Apple. Because of this, I don’t know if someone else encountered the problem I’m about to report.

Reports are confidential because they may contain sensitive data, like pieces of proprietary code.

All of this means that I often report bugs that will be closed as duplicates. Rumours say that Apple internally uses this “duplicates count” to prioritise issues that need to be fixed.

I usually spend about fifteen to thirty minutes on each issue I report to make sure it is reproducible with step by step instructions, screenshots or screen recordings. Then someone at Apple has to waste some more time closing the influx of duplicate bug reports.

The whole process is terribly inefficient.

Many bug reports don’t contain private information. I would welcome a checkbox that gives me the ability to make the bug report public and searchable.

Most of the time I’m not the first experiencing an issue. I would rather find the original bug report and participate to the conversation with Apple engineers. Also, a simple way to help with prioritisation would be a mechanism similar to “stars” on Google Code’s issue tracker.

Additionally, since I don’t get notifications when the original issue has changed state, each time a new product release comes out, I have to go through these steps:

  1. Check all bugs in “Open” and “Closed” categories and try to reproduce them in the latest release.
  2. If it is still present, then I add a comment like “Still present in iOS 8.2”. If it is fixed I add a comment like “Fixed in OS X 10.10.2” and then click the “Hide” button to move it to the “Hidden” category. Adding a comment is useful since it is shown in the bug list on the left.

Now multiply this process for each developer working with Apple products with enough time and patience to open bug reports. Think about all the wasted manpower at Apple to read incoming bug reports and mark them as duplicates.


  1. Add a checkbox to make bug reports public and searchable by other users.
  2. Add a vote system so that developers can help prioritise bug reports, in a manner similar to “stars” on Google Code.
  3. When I report an issue which is then closed as duplicate, send me notifications when the original bug report changes state.

Unified Developer Subscription

The Watch, along with Continuity and Handoff on iOS and OS X, contributes to create experiences spanning multiple devices.

We expect developers to create applications that work across multiple screen sizes and environments.

Developers, however, are still split between two camps: iOS/Watch and OS X, with separate subscriptions and developer portals.

Many iOS developers, myself included, would love to create products encompassing all of the Apple ecosystem but the thought of having to activate yet another yearly subscription is often off-putting.

Unifying both the iOS and OS X ecosystem under a single 99$/yr subscription would encourage the large pool of iOS developers to start developing applications for the Mac App Store, too, stopping the chronic lack of applications on that front.

Microsoft is doing it, with improved unification expected this year, and Google has always used a one-time $25 for Android and a one-time $5 fee on the Chrome Web Store.

There’s no excuse to still have a fragmented ecosystem.