Reading OSX Reviews

Over the course of the last week I've reread all of John Siracusa's OSX reviews for Ars Technica, starting with OSX Developer Preview 2 and finishing with OSX Mavericks. This page handily lists all of the reviews (earlier reviews linked back, but this pattern ended at 10.5).

My motivation was to learn a little more about the history of OSX, as I've only been using Macs since Snow Leopard. These reviews are a great place to get a sense of the history of the OS because they were written at the time of each version's release, rather than having been updated regularly with new information, like the Wikipedia articles.

The pattern of the early reviews (the first seven are all about 10.0 and its betas) was focussing on the differences between OSX, raw UNIX and Mac OS 9. Whilst 10.0 is very different there are striking similarities to the OSX I use everyday: it still had Aqua, HFS+, Cocoa, etc. A lot of the key differences, for Siracusa at least, were the user interface and experience, the Finder and the file system (there was also a font kerning issue in the Terminal for several versions that was his pet peeve).

As OSX progressed, the reviews did too. Up until 10.4 Tiger, the reviews often discussed the performance changes from the previous version (especially the fact that they got faster on the same hardware), whereas after this performance improvements were much smaller (Siracusa, whilst expressing admiration, did point out that the cynic's response is that 10.0 was so slow, which is why there was so much room for performance improvements).

Most early reviews also advised the reader on whether or not they should upgrade, especially given that each new release was a $129 upgrade. Later reviews do not even consider this (at one point Siracusa even considered it a compulsory 'Mac tax') but with Mavericks being free, price is given a final consideration in its review. Modern reviews seem to have this pattern:

  • Introduction and summary of expectations from the last review
  • The new features
  • Performance changes, if any
  • Kernel changes and enhancements
  • New technologies and APIs, if any
  • File system rant (which, having read the earlier reviews and got some context, now seems justified)
  • Grab bag (summary of minor apps and changes)
  • Conclusion and looking ahead to the future

The evolution of OSX is fascinating from a user and developer perspective. As new developer technologies, like Quartz 2D Extreme/QuartzGL, Core Image/Audio/Video, OpenCL, Objective-C 2.0, Blocks, GCD and ARC, emerged each was carefully explained. Whilst I am familiar with these technologies today it was awesome to see when, why and how they were released. Transitions in other areas (32-bit to 64-bit, PowerPC to Intel, 'lickable' Aqua UI to a more flat UI) was also interesting to read about, especially given a modern perspective.

Reading the reviews in 2014 has been fun, especially considering that some of them are almost 15 years old. Often Siracusa made predictions of varying accuracy:

  • Tags were predicted in the Tiger review
  • High DPI/retina displays were predicted when support was first added in OSX (although retina displays weren't considered until the Lion review)
  • HFS+ would be replaced
  • Macs with 96GB of RAM (this was in the Snow Leopard review, but the current Mac Pro can be configured to ship with up to 64GB and supposedly supports up to 128GB)

Another interesting series of articles was the 'Avoiding Copland 2010' series which were written  in 2005 and discussed the various enhancements that Apple would have to make to Objective-C in order for it to remain competitive with other high level languages. I also recommend listening to the associated 2011 episode of Hypercritcal, A Dark Age of Objective-C. With the recent debate over whether Objective-C/Cocoa should be replaced (they shouldn't), these articles are surprisingly relevant.

I highly recommend reading the OSX reviews if you're a developer and haven't read them before, or are just interested in the history of the OS. I ended up reading all of the reviews in Safari's reading mode because it was able to take the multi-page reviews and stick it in one page (albeit with some images missing) - in the past I had used Instapaper for this but it occasionally seems to miss multi-page articles.

Checking Apache licenses on Objective-C files

At the moment I'm putting together an open-source library based off of some classes that I've been sharing between some of my iOS apps for a while. I wanted to check that I had the Apache license at the top of each file, and that it followed this format:

// Filename.h/Filename.m
//
// Copyright 2013/2014 Programming Thomas
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

I could have checked through each file individually, however I decided that I probably ought to get round to trying Ruby at some point, so I ended up putting together this simple script:

Overall Ruby was pretty easy to pick up (although I imagine the above looks awful to a seasoned Rubyist) and so I was able to quickly check over the source files :).

Birthday

Prevent TextMate from resuming its state

TextMate is currently my favorite text editor, however the other day I tried opening a very large (~500MBish) text file and TextMate ground to a halt, so I force quit it. Unfortunately, the next time I opened it I found that it kept trying to open the same file. Eventually, even after deleting the file completely, I managed to find a solution.

As well as its main preferences pane, there are a few additional preferences that you can set via terminal, and one of these prevents TextMate from opening the set of files it previously had opened. Run the following command in order to do so:

defaults write com.macromates.textmate OakDisableSessionRestore 1

Voila! The next time I opened TextMate I was able to open up a blank document, which solved my problem :).

Keep Calm 3.1

Today I've just pushed a new minor release of Keep Calm for iOS:

  • If you've purchased the background pack there are now 50% more backgrounds available to you, at no extra cost
  • Pro users on iOS 7 can now create parallax wallpapers (I might write up another blog post at some point about how this works)
  • Free users (i.e. people that have never bought anything) will now see iAd and AdMob ads
  • Resolved a bug that caused the sharing dialog to crash on iPad
  • Ensured all users can now properly delete posters
  • Resolved a bug that caused a crash when you didn't enter any text

iOS 6 and 7 users can now update to Keep Calm 3.1 for free. Keep Calm 3.x is the last major version that will work on iOS 6.

Nine patch images on iOS

Android developers will be familiar with the concept of nine-patch images: images that have a resizable central area but fixed width and height images. This is incredibly useful if you have a resizable button that you want to use a custom texture as the background, for example. This has always been available on iOS (and is fairly easy to roll out with custom CALayers too) however Xcode 5 has helped to make the process a lot easier. 

To begin using 'image slicing' (Apple's name for it - probably because you can have three-patch and nine-patch) you'll firstly need to begin using asset catalogues - which provides a new easy way to manage images in your app and I highly recommend you migrate to using them. Once you've created a new image catalogue for your image file you can press the 'show slicing' button to begin dividing your image (you can have it resizable in one or two dimensions, with a choice of horizontal/vertical/both slicing).

Using the image is incredibly easy - if you've got a UIImageView you can simply set it using:

Unfortunately it seems a little illogical that you have to create a color from an image, but by drawing the image in a separate context it helps to ensure the image doesn't become tiled.