Category Archives: Mac OS X

File A Bug

My friend Marco Arment laments that of the 15 bugs he’s filed since 2009, eight have been marked as duplicates, and seven have received no significant response.

Since 2009, I’ve reported 161 bugs. It’s much harder for me to do a stone-cold analysis of the results of my efforts. Yes, I’ve “wasted some time,” but often in the process of doing so I have also gained a deeper understanding of the problems I was reporting.

Having filed 161 bugs over six years, I can guarantee you that I’ve had far more bugs ignored or filed as duplicate than Marco has. I’ve had my share of bugs for which I’ve had to send back a sternly worded note to the bug screeners, implying in as polite a language as I could muster that they were not doing their jobs well.

I’ve also burdened Apple with a good number of false alarms: bug reports that I filed hastily only to discover were actually my own problem. Sometimes these were reported with confident, dismissive words that I later felt like eating. Sometimes I am not a great bug reporter.

And sometimes I am a great bug reporter. I’ve received notes of personal thanks on Twitter, via email, and in person at conferences such as WWDC. Engineers at Apple have said things such as “I wish all bug reports were as good as yours,” and “your bug report spelled out exactly how to fix the bug, so that’s exactly what we did.” I can’t remember a major OS X release when at least one of my reported bugs was not addressed during the beta release period, before the software ever saw the light of day. If we stretch the timeline back to 2008, I’ve even had the unexpected honor of being credited in a security update for what I thought was a simple networking bug.

I’ve had my share of frustrations with Apple’s bug reporting system, but I’m a developer. I can take it. I’m used to rejection. 9 times out of 10 when we developers press Cmd-R in Xcode to “Build and Run” our projects, they don’t even make it past the compile phase. But we keep trying. Why? Because we know how great it feels when we finally get something to work. We don’t need to be constantly reassured that we’re great, that our input matters, or that our concerns have been heard. Would it be nice? Sure. But so would Objective-C namespaces and a pony.

If we developers want Apple’s platforms to work as well as they can, the sad and short truth of the matter is we have to report bugs. If you’ve only reported 15 bugs over 6 years, as Marco has, I’m afraid to say that you haven’t done enough. To stand a statistical chance of either helping the cause or of being gratified by a personalized response, you’ll have to step it up, grin and bear the frustration and continue to press “Build and Run” on the Apple Bug Reporter and see what comes out the other end.

Out Of The Bag

AppleInsider reported on Friday that the number of visitors to their site purportedly running a pre-release version of Mac OS X 10.9 had risen dramatically in January. Federico Viticci of MacStories followed up on Twitter, confirming a similar trend.

I was curious about my own web statistics, so I started poking around at my Apache log files. They start with the IP address of the visitor and include various other information including the URL that was accessed, the referrer, and most importantly here, the user agent string for the browser.

Although the vast majority of visitors to my sites are running Mac OS X 10.8, or iOS, or even Windows, there were indeed a few examples of visitors who appeared to be running 10.9. This is what the user agent string looks like:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9) AppleWebKit/537.28.2 (KHTML, like Gecko) Version/6.1 Safari/537.28.2

See that 10_9? It’s a strong indicator, combined with the respectably “higher than 10.8” Safari and WebKit versions, that the visitor is indeed running 10.9. Could it be fake? Sure, but the odds of anybody faking this kind of thing seem relatively low: there is little imaginable reward for duping a site into believing that a solitary IP address is running 10.9, and it would be challenging to orchestrate some kind of distributed fraud without being found out.

If you have access to your own site’s HTTP access log, and the format is like mine, you can sift out the 10.9 accesses by simply grepping for the 10_9 substring:

grep 10_9 access_log

If you have any matches, odds are good that they will be from IP addresses that start with 17. Why? Because Apple is somewhat unique in that it owns outright an entire class A subnet of IP addresses: all addresses starting with “17.” are theirs.

So people at Apple are running 10.9. What’s the big deal? For one thing, anybody with access to a reasonably popular web site’s access logs now has an insight into Apple’s development schedule. Look at the graph from the AppleInsider link above and you can deduce not only that the number of users actively running 10.9 has gone up, but I would also guess that the troughs and peaks in the graph are correlated with the release cycle of internal test builds. What is this worth to a competitor? Probably not much, but who knows.

The other issue that comes to mind is that not all the IP addresses are liable to start with 17. Why? For one thing, Apple employees may be working from home, either in the Bay Area near Apple headquarters, or scattered around the world in their respective telecommuting locations. For another, Apple may have granted early access to close business partners who would naturally be running the operating system in their own office environments, on other subnets than 17. To see if you’ve been treated to any of these visitors, and to further refine the list to avoid duplicates from the same IP, try this:

grep -v ^17\\. access_log | sort -u -t- -k1,1

If you found any results, first of all I strongly encourage you not to share the IP addresses in public. I am writing this article at least in part to call out the reasons why Apple’s divulging this information is a risk to its employees and partners. You should protect the confidence of your site’s visitors.

That said, you may want to privately perform a rough geographic lookup based on the IP address. Googling will find many services for this and this is just one that I used. You will probably find that the IP address maps to a location in San Francisco, San Jose, or Santa Cruz. But some of my 10.9 visitors hailed from other parts of the US.

So Apple’s broadcasting of the Safari user agent string reveals information about their development schedule, and divulges the IP addresses of likely employees or business partners. While I can’t quite imagine somebody taking advantage of the employee IP addresses, it sets off my spidey-sense creepiness alarm. The potential for divulging business partners could be of more obvious pragmatic interest to investors or competitors. The discovery of an alliance between Apple and another company would seem likely to affect the perceived value of either company, and could ruffle the feathers of other business partners who feel threatened by the cooperation.

So what should Apple do? The answer was in their hands before Safari launched: spoof the user agent! Don Melton was on the Safari team and wrote recently about keeping the project a secret:

Nobody at Apple was stupid enough to blog about work, so what was I worried about?

Server logs. They scared the hell out of me.

To guard clues about their development schedule, they should probably spoof the user agent string until the release is in a large enough number of hands that the number of user agents is uninterestingly diverse. But to protect the IP addresses of their employees and business partners from prying eyes they should at least spoof the user agent on non-17 subnets.

Apple’s famous secrecy is not foolproof. We don’t know yet what exciting new features 10.9 will bring or which hardware it will support. We don’t know how much it will cost, or which of the diminishing number of code names it will have. But we know it’s coming, and we know collectively the IP addresses of those who are testing it. The cat is still a secret, but the paws are out of the bag.

Screenshot Lightning

Apple recently changed their policy regarding screenshots for iOS applications in the App Store: you must supply any changes to your screenshots by the time of approval, or the existing screenshots will be locked down until the next time you submit and are approved.

Long story short: you better have those screenshots ready at submission time or very shortly after. And the screenshots had better be something you are willing to live with for a good long while.

This is a dramatic change from the old policy, under which developers could update screenshots at their leisure. This afforded a workflow where a developer might put all of their effort into the actual development of the app, submit it, and then get to work fine-tuning their screenshots for the marketing aspect of selling in the App Store.

One reason for putting off the job of creating screenshots is that creating them is time-consuming and tedious, even with a relatively simple app. For a more complex app, or one that is localized into many languages, the challenge is that much greater.

Last night, at our local Boston CocoaHeads meeting, I learned about a well-timed solution for this problem. Kent Sutherland, the programmer for Flexibits, showed off how he uses an automated screenshot-capture procedure to tame the task of generating Fantastical’s many screenshots, in many languages.

His approach uses a novel technique in which the target app itself is built with customized screen-capturing code compiled right in. Then the app can be driven through the iOS Simulator with WaxSim, a command-line tool for launching the simulator with various options. He was kind enough to share a sample project in which he applies the same technique to Apple’s UICatalog sample app:

Click to download Kent’s UICatalog sample.

After downloading the sample, navigate to the “Screenshots” folder to find the real goodies. The Readme.txt in that folder has simple instructions for kicking off the process. In a nutshell: just open the Screenshots folder in the Terminal, and type “python make_screenshots.py output”. Then watch as the iOS simulator cranks through the process of generating 12 screenshots for UICatalog before you’ve had a chance to wipe that tear of joy from the corner of your eye.

I plan to build more iOS software in the future, and something like this will undoubtedly be a lifesaver when I have significant screenshots to generate. My only existing iOS app, Shush, only has 4 screenshots in one language, and I still found it tedious enough to re-generate screenshots that I hesitated to improve the UI because of the work of another round of, ahem, bitsplitting.

The same approach is also applicable to Mac apps. Currently I go through a similarly tedious procedure of manually navigating and cajoling the app into a specific state before taking a screenshot by hand. This could all be driven by automated capture code built into a custom version of the app, where I could also imagine other niceness such as adding annotations to illustrative screenshots, being added to the process.

If you’re selling apps on the iOS App Store, Apple’s policy change makes it imperative that you come up with a workflow for effortlessly and quickly generating screenshots. Thanks to Kent’s generous sharing of his approach, your work is mostly done for you.