This was my reason for only support a the canonical stock system ruby installation. But over the years, I received too many support requests from novice users with custom ruby installations, that messed up their installation causing lots of frustration and difficult to diagnose problems. Installing an additional Ruby in a different location may solve the problem for experienced users. I like my system Ruby installation to be untouched, because messing with system Ruby will cause problems in the long run. While wkpdf reportedly works in OS X 10.10 after Rub圜ocoa is installed with the binary installer, this is not the way I would like wkpdf to be installed. Thus it didn't come as a surprise when OS X 10.10 shipped without Ruby 1.8 and without Rub圜ocoa. While Apple still shipped Rub圜ocao for Ruby version 1.8, which was installed in parallel on OS X 10.9 for compatibility reasons, the writing was on the wall that Rub圜ocoa will be going away in the not too distant future. Apple stopped shipping Rub圜ocoa with its default Ruby, which was upgraded at the same time from 1.8 to 2.x. The official adoption of Rub圜ocoa by Apple, motivated me to port wkpdf from its initial incarnation in Objective-C to Ruby. I was excited when Apple started shipping Rub圜ocoa in OS X 10.5 because this meant that wkpdf could be installed easily using the rubygems package manager, without requiring the user to modify the system ruby installation with a Rub圜ocoa instalation. My objective for wkpdf was providing the user with a simple installation experience on a stock OS X installation.