Software Development is Obviously Hard

Look at Apple's recent iOS 8.0.1 release that broke cellular.
Look at (any company's I have used) Wi-Fi or Bluetooth stack and how flaky it is every other release.

The technology we use, rely on, love, and spend a lot of money on each day is a big let down when it fails. For non-techies I hear them blaming themselves. They must not be using it right.

Here's a secret though, most times when it is not working, but it worked yesterday or 5 minutes ago, it isn't you, it's the gadget. How many times have you cycled your WiFi or Bluetooth off/on to try to fix connectivity? Too many.

I feel for the people that don't know this much (you sometimes have to reset things).

It used to be a big joke, and I made it plenty of times, that you had to restart your Windows PC daily or whenever it started to act strange.

The bigger joke today is that we have to do that to the device in our pocket more often than we care to admit.

I always think, maybe it's me and the stuff I am interfacing with each day. Bluetooth headsets, in-car bluetooth, switching multiple networks, installing/uninstalling apps. My day to day usage of mobile devices is a little more extreme than the average user I figure and so I run into "edge cases" all the time.

Or maybe, we just need to spend some more time polishing our software before pushing it out the door.

DerivedData and xcodebuild

If you use Xcode you know about DerivedData. If you don't know DerivedData, you don't know Xcode.

If you are setting up xcodebuilds from the command line, say for continuous build and integration (CI), then you want to make sure you are using that command line the best way possible. Some things I keep running into as I see people's build systems are:

• Running out of space due to a backup of old DerivedData.
• Build performance hanging, due to a backup of old DerivedData.
• Unexplainable build failure, solved by deleting, you guessed it, DerivedData.

If you use the command line for builds then save yourself a lot of trouble in the future. Start using the xcodebuild option -derivedDataPath.

Here are the docs on it:

-derivedDataPath PATH                     specifies the directory where build products and other derived data will go

That one option huge significance. Here are some reasons why I use it and convert build systems over to this option:

• I can store the DerivedData in the temporary source workspace of automated builds (like CI builds, automated test runs, etc.) When the workspace is cleaned up the DerivedData goes away and net disk space should be 0 at the end of the build.
• With no shared DerivedData between builds the build performance does not drop due to large DerivedData folders.
• Without a shared DerivedData folder I see much lower instances of unexplainable build errors. This means less cleanup, less build host reboots, etc.

Personally, I am very interested in how remote builds with Mac OS X Server and Xcode have improve the build process for automated builds. Until I get the chance to put such a system together, for now and for legacy build systems, I will use xcodebuild -derivedData to improve build systems I have to work with.

Make a Swift Based iOS App Crash

I am writing an app for a contract where one of the deliverables is that the app must demonstrate various crashes.  Of these various crashes, one must be an application crash.

On top of that I am writing the app in Swift (about 80% Swift, 20% Objective-C libraries not ported to Swift).

It shouldn't be too hard to crash a Swift app hey? Well, if you follow Swift guidelines your app should be pretty stable since the language has been designed to force devs to be safer in their use of the language. That's not to say that misunderstanding the language or forced unwrapping of optionals that could be nil will make your app any less crash prone.

So let's break the rules, get unsafe in our use of Swift and crash this app.

I decided to go with this piece of code:

var crashWithMissingValueInDicitonary = Dictionary<Int,Int>()

let crashInt = crashWithMissingValueInDicitonary[1]!

This produces a crash with the following error:

fatal error: unexpectedly found nil while unwrapping an Optional value

The reason is this:

• Line 1 is creating an empty dictionary with Int keys and Int values.
• Line 2 is Force Unwrapping the optional dictionary value with a key of 1. Nothing has been added to our dictionary yet though so this means we will get a nil. Assigning this nil to a constant value (let) and we get a runtime exception, crashing the app.

So, there is one way to write a bug intentionally to crash your app.

See the Swift docs for further information on Forced Unwrapping and how they are used with Optional values.