It’s important to have a Top 10 list. I know this as every other site has one. I don’t want to miss out. So here are the top ten most read posts here this year, with the year they were originally published in parenthesis:

1. QA Mindf**k
2. Do Apple take 40% in the EU? (2011)
3. Learning Swift
4. iOS Developer Program: from individual to company (2011)
5. How do I do “X” in Swift?
6. AQGridView to UICollectionView (2013)
7. iPhone Dev: Saving State (2010)
8. NSFetchedResultsController and iCloud
9. Why you need a crash reporter (2011)
10. Sophia Smith (2006)

If there’s a lesson here in increasing readership it’s simple: get retweeted by people with lots of followers.

Preamble: In pre-Swift and pre-ARC days of development on Apple’s platforms, it was necessary to “manually” retain and release objects as you used and discarded them. One common, but incorrect, pattern that kept reappearing was the idea that you could use the retainCount method to ascertain whether an object was still being used.

## When to use -retainCount? Never!

There’s pretty much never a good reason to use -retainCount. Here’s a short and mildly abusive explanation why.

When I read Rand’s recent post on QA I was pretty much entirely in agreement. A good QA team is a real asset to any project, especially large ones. However, a bad QA team can be a huge liability and cause problems for everyone.

Bad testers don’t understand the product they’re working on. They follow test scripts they don’t understand, write short, inaccurate bug reports and make no attempt to appreciate the context of any error.

Ever since upgrading from OS X 10.9 to Yosemite (10.10) I’ve been getting a dialog popping up with the message “To view this web content, you need to install the Java Runtime Environment” periodically. As far as I know I have no software that needs Java to run.

When I asked on Twitter¹, the most common suggestion was that it was the Adobe updater. But I don’t have PhotoShop or anything else likely installed.

For some reason, when I saw the poster for the new movie “Fury,” I misread it as “Furry” and saw a beard on Brad Pitt that wasn’t really there. I’ve tried to correct these errors.

I was so busy when it came out that I never quite got around to blogging about it here: I have a new app out! It’s called ShareEverywhere. It is built exclusively for iOS 8 and uses the new, built-in “share” functionality, allowing you to share to a good number of services from any app that uses the standard share button.

When I first wrote it, I wasn’t sure how many, if any, developers would build share widgets into their apps. Now that we know the answer is “a lot of them,” I still use ShareEverywhere because it beats having a dozen widgets hiding in your action menu. And there are still services, like Pinboard.in, that don’t have their own native apps.

Maybe I have some duff feeds in my RSS reader. Maybe I have a few poor choices of people that I follow on Twitter. But I see links along these lines all the time:

How do you do something in Swift?

The answer is, almost always, exactly the same way you’d do it in Objective-C!

You want to do pull-to-refresh? Same.

You want to play with location services? Same.

You want to display one of the new UIAlertControllers? That’s the same, too.

Graham Lee’s “Why is programming so hard?” made me think about how I started programming and whether I’d be coding now if I was twelve.

When I began, I had a Sinclair Spectrum. Back then, home computers booted into a programming language (BASIC typically) and to do anything you needed to know at least one command. To be fair, even then many people didn’t get beyond J, Symbol Shift-P, Symbol Shift-P (‘LOAD “”‘, the command used to load a program from tape).

Over the years I’ve been asked to do a lot of programming aptitude tests. I’ve had to do some in the last couple of months and I’m deliberately writing this now before I get the results back of the most recent one so you won’t think that this post is just sour grapes…

I’m not going to get into the details of the tests because it doesn’t really matter what they are or who administered them for the purposes of this post.

If you look at the Swift Language guide, you get the distinct impression that the type system is sleek and modern. However the more you dig into it the more eccentricities you find.

The one I’m going to look at today makes sense only if you look at the problem domain from a slightly skewed perspective. I’ve been trying to think whether this is a sensible, pragmatic way of designing a language or a mistake. Judge for yourself.