“Preview” is damaged and can’t be opened.

“Preview” is damaged and can’t be opened. You should move it to the Trash.

"Preview" is damaged.

This was the rather surprising error message that I’ve been getting when I try to open a PDF from the Finder since I upgraded to OS X Yosemite. It’s bad enough when you get an error message, but one suggesting that you delete a frequently used app is inconvenient to say the least!

Since I found it, I’ve been using a workaround: start Preview.app and open the file manually.

But there’s a better answer. Apparently it just has a duff “quarantine” attribute set. To get rid of it and get things back to normal simply do the following in a Terminal window:

/Users/stephend $ cd /Applications 
/Applications $ xattr -l Preview.app
com.apple.quarantine: 0006;53563f06;Acorn;
/Applications $

If you see the same thing, proceed to the next step:

/Applications $ sudo xattr -d com.apple.quarantine Preview.app

And that’s all. Now opening a PDF from the Finder should work. It’s bizarre.

I raised Radar 19384558 with Apple. Please dupe if you see the same thing. Thanks to Gus Mueller (developer of Acorn) for the support.

Update: It seems that a couple of other apps also have the same, incorrect attributes:

/Applications $ xattr -l *.app Utilities/*.app | grep Acorn       
Mail.app: com.apple.quarantine: 0006;53563f06;Acorn;
iPhoto.app: com.apple.quarantine: 0006;53563f06;Acorn;

I have also removed those tags, though I’ve not seen any problems with them so far.


When I think of “Stillness,” this weeks PhotoFriday challenge, I tend to think of a lake; an apparently unmoving body of water. (A lot of the other entries, to my eyes at least, don’t represent “Stillness.” Of course, mine may well miss the mark for them…)

Whatever its merits, this one was taken near Spooner Lake, which is very near Lake Tahoe.

I didn’t have an entry in the last challenge, so there’s no need to vote for me(!).

Incidentally, there was another PhotoFriday challenge with the theme “Stillness.” You can see my previous entry here. Tragically, I nearly used the same image again!


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.

Honourable mentions go to the following as they were written this year but didn’t make it into the “most read” list:

14. Recruitment Tests
15. Two Years
16. Java and Yosemite
21. Starting Coding
23. Swift Hate
31. Lucky number two

I started with the intention of writing at least one blog a week. You’ll note that I utterly failed. I didn’t even get to the end of January with that!

The biggest surprises — since they were both written over a decade ago — were:

17. Italy, 2001
19. Oracle 8i for Linux Installation HOWTO (last edit was 2003)

I’m not going to make any promises or predictions about next year, other than I’ll be moving the site to a new web host (the old one closing down). But whatever happens, here’s to a great 2015.

QA Mindf**k

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.

This should all be obvious from Rand’s post. What’s maybe not so clear is what problems it causes.

What follows is not the tale of any one project but all of these things have happened at one time or another.

  • The QA team starts too early in development and doesn’t comprehend that it’s working on unfinished software. Many bug reports are raised for things that are known to be missing or incomplete.
  • The real bug reports contain so little data that they can’t be reproduced, or at least can’t be replicated without a lot of effort.
  • There are many bugs in the test scripts too, but since the QA team have no real understanding of what the software is supposed to do they refuse to take a second look at them.
  • Since QA don’t understand the desired functionality, important modules are not tested, leaving an unpleasant surprise at a later, critical stage of the project.
  • As the bugs pile up, the development team have to spend more and more time working on them instead of completing the project as originally planned.
  • Eventually, overwhelmed, the project is replanned.
  • This time the development team is under increased scrutiny. Metrics – bugs raised, time to fix, closure rate – are tracked.
  • Collecting all the metrics slows down development further.
  • Bugs pile up, the metrics start taking over the project.
  • The numbers mean everything. Few actually understand what is wrong, only how many defects there are.
  • Ironically, the pressure of developing the remaining features, working on the stream of defects and the new management overhead result in a decrease in quality as the same people are expected to do more work.
  • Management adds more people to the project to solve this problem. Unfortunately Fred Brookes wasn’t wrong.
  • The new project plan fails, further replanning…
  • Rinse. Repeat.

It’s a death spiral. Longer hours. Weekend work. Replanning. Delays. People, frustrated, leave. It’s toxic.

More often than not, projects like these get cancelled but sometimes, for political reasons, they have to be delivered. In order to do so the cycle has to be broken. This always requires someone brave to come in, slash the scope and come up with a truly realistic plan.

But it’s best just to have a constructive relationship between the development and QA teams. After all, the goal for everyone should be to deliver the best possible software.

Photography, opinions and other random ramblings by Stephen Darlington