The next release, 4.0.1 will probably be submitted in the next day or two. This is mostly a maintenance release with a few minor features (access to notes from pre- and post-event checklists).

Once that drops, we will turn our attention to iOS7.

It is looking like 4.0.1 will be the last build of RCLogbook that supports iOS4. We are thinking that the next release for iOS7 will require iOS5 or later. Honestly, given the scope of changes in iOS7, a pretty good case can be made for moving the next release to iOS7 or better. The changes are deep enough that maintaining support for pre-iOS7 versions is going to be a huge pain. We are going to give it a shot and see how it goes.

So others can learn from what has, so far, not been one of the smoothest RCLogbook release cycles, here is what happened…

Back when 3.5.0 was being laid down, the feature set was a little more extensive. As a result, I decided that RCLogbook would require iOS 4 at minimum. As a result, there were a few places where I moved from some existing code that worked to new APIs introduced in iOS 4 that were more compact, easier to use, and so on.

As development wore on, some choices were made to drop some of the originally planned features in favor of getting 3.5 out faster. With the pull-in, it was also decided that I would not leave iOS 3 behind quite yet. So, I began to back out some of the iOS 4 specific changes (or, rather, appropriately guard them – originally I had not guarded them since, hey, the app was going to require iOS 4 at minimum so why do a “if iOS 4” song-and-dance).

You can see where this is going. Turns out, I did not get them all in 3.5.0. Turns out I also did not get them all in 3.5.1. While no bugs are ever OK, the transgression in 3.5.0 is a slightly more forgivable – I did get most of guards in place. The transgression in 3.5.1 is a matter of rushing the release out to help out the user base on iOS 3 (of which there are at least a handful of folks who have emailed me with tales of crashes) and not taking the time to make sure I really had all of the guards in place this time. It also did not help that I assumed the bug report was for the crash I was seeing locally (in this case, “add a flight” could mean either with or without the event timer). It turns out that there were three escapes that needed to be fixed and I assumed that the one I fixed was the one the user was seeing, which was not the case.

What I learned:

• Guard always if there is even a sliver of a chance that you might want to run on an OS that does not support the API.
• Always ask for clarification on bug reports to make sure you are fixing what is being reported, not a different bug.
• Stop, take time, and double-check.