Little Go 1.1.0 released

August 11, 2014

Little Go 1.1.0 has been released to the App Store today. The GitHub issue tracker has a list of all issues that I worked on for 1.1.0, and here is an excerpt of the changelog with the user-visible changes:

The app's user interface has been updated to the iOS 7 look & feel (#204).
Drawing for Retina displays has been fixed (#205). Many thanks to Eric O. Lebigot for reporting the issue and giving me the necessary KITB to investigate the problem.

In addition to these changes, another two items that are not user-visible turned out to be major time sinks:

I decided to adopt Auto Layout as a replacement for manually calculated view frames (#206). After the usual initial learning curve, the real problems that cropped up were always related to the new iOS 7 bar handling (e.g. when to use view controller properties like edgesForExtendedLayout and automaticallyAdjustsScrollViewInsets). In a desperate last minute effort I even wrote my own implementation of a split view controller because I simply could not get UIKit's UISplitViewController to work reliably (issue 236 has the details).
In a fit of complete insanity I decided to rewrite the app's board drawing code, with the goal to reduce memory usage when the board is zoomed in (issues 212, issue 214 and issue 215). This took me another month to complete, but the scheme succeeded beautifully - ignoring the memory gobbled up by Fuego, peak memory usage dropped from 170 MB to 67 MB (measuring "dirty size" with the "VM Tracker" instrument). For details check out the Research document, section "Memory usage after adding tiling").

Last but not least, I had a hard time analyzing crash reports. In the 6 months since the 1.0.0 release I received 230 crash reports. Roughly 70% of these seem to originate from the same root cause, which unfortunately I have been unable to pinpoint. A major part of my difficulties was that crash log symbolication provided me with an impossible stack trace, i.e. the last code line in the Little Go source code could not have invoked the UIKit method that was shown by the stack trace. I don't understand the details of the symbolication process, so I can't even guess how something like that is possible (except, of course, a wrong .dSYM file, but I can guarantee that this not the case!). Anyway, very frustrating, and I hope I will find the bug in the next version.