Faux Pas Blog

Version 1.4 of Faux Pas introduced a new rule: Unnecessary default case in exhaustive switch statement (DefaultInExhaustiveSwitch). The purpose of this rule is to find code that prevents a useful compiler warning from triggering. In order to explain...

As you might know, Faux Pas is sold outside of the Mac App Store (via FastSpring). This is by necessity: Apple requires sandboxing for all apps sold through their App Store, and due to its nature Faux Pas is extremely difficult (or impossible) to sandbox.

This post isn’t about releasing outside the Mac App Store in general, though — it’s about the process I use for handling releases. When you’re selling through Apple’s store, the release process is defined by how their system (iTunes Connect and Xcode) works, but the rest of us out here in the wilderness must learn how to fend for ourselves.

In iOS and Mac apps, resource files (e.g. images) are included into the app bundle and loaded in code by using strings referencing their filenames:

[NSData dataWithContentsOfFile:
 [[NSBundle mainBundle] pathForResource:@"Foo" ofType:@"bar"]];

In most cases, developers quickly notice when their filename references are incorrect. However, there are some conditions that might prevent this discovery even during initial development, as well as some situations where these references might become incorrect long after initial development.

Let’s look at some examples.

Faux Pas is now available via Homebrew Cask.

brew cask install fauxpas

That is all. Carry on.

Some people have been asking for ways to run Faux Pas on their continuous integration (CI) servers. Here are some instructions on how to set this up.

Today I have released the Faux Pas public beta.

Brent Simmons wrote about some issues he found in an unnamed open-source Cocoa project. He lists 12 things, and while reading them I realized that you can use the Clang compiler and Faux Pas to avoid most of them: