I scoured through the Cocoanetics blog for all the individual ZIP files of sample apps that I had made to accompany some of my Apple bug reports.
I like to create a fresh project for each bug to demonstrate, so these sample apps don’t contain anything that I would not want to be public.
The samples can be categorized into: Open, Fixed and Not a Bug. For the ones that got fixed I also mention as of which iOS version.
These samples serve as a nice reminder how much more likely Apple engineers are fixing reported bugs if you can provide them a quick to grasp example demonstrating the issue.
Sometimes I get lazy, especially when I am betting that I am probably not the first to report the issue and when I can be reasonably certain that the issue is not in my own code. Then I don’t do a sample right away. When the response then is that my bug report is a Duplicate then my bet was correct.
If not, then you get an email stating:
This is a courtesy email regarding Bug ID# 13836932.
Engineering has requested the following information in order to further investigate this issue:
Please attach a sample app that demonstrates this issue to your bug report.
At this point I kick into high gear and whip up a sample like the ones you can find in my Radar Samples Collection on GitHub.
The point of these apps is to demonstrate to yourself that the bug still occurs in a fresh app that came nowhere near your other apps. That it is not a Heisenbug. And to demonstrate to an Apple engineer straight and to the point what the issue is about.
At WWDC 2012 a senior Apple engineer told me that bug reports that he cannot quickly reproduce (with the help of a sample) will go to the bottom of the stack. The have little chance of being acted upon until many others report the same issue and provide better reproducibility.
Long story short: File good bugs and for the ones that are not Duplicates make exceptionally simple and self-explanatory samples.
Categories: Apple