Little Go 1.7.0 has been published on September 18 2022 on the App Store. Another 1½ years have passed since the last release, which again is longer than I would have wished, but such is life… The new version continues the work started in 1.6.0, which has as its final goal the support of as many features of the SGF file format as possible. The release notes are available in the App Store update notes or on the GitHub release page.

A bit hof history… I had started to work on a 1.6.1 bugfix release quite early, already about two weeks after 1.6.0 hit the store. Unfortunately, at that time I also got hooked on a certain freemium space wargame¹, which proved to be fatal for Little Go’s release schedule. 10 months later, in early 2022, I finally managed to wean myself from the addiction and get back to do some useful work. As already one year had passed since the release of 1.6.0, I figured I could just as well turn the bugfix into a feature release. Alas, it took me another 7 months to complete the 2 features I had planned (support for SGF node and move annotation properties, and support for SGF markup properties).

If you’re interested in some rambling thoughts, then here are the major factors that delayed the release:

1. When I started work on the annotation stuff I soon realized that I would have to make some of the necessary changes in three different places: Once in every UI layout that the app supports. As the saying goes, this was the straw that broke the camel’s back. As much as I like to tailor the app to the screen size of certain classes of devices, and thus provide a nice user experience for the users of these devices, I came to the conclusion that supporting the current tailoring required too much work given the limited amount of time I intend to invest on the project. I therefore decided to ditch a lot of the stuff that made the three UI layouts different and create a unified UI layout that looks mostly the same on all devices (see GitHub issue 371 for some details). The main part of this “non-feature” took roughly a month to implement, with some follow-up work needed here and there. The most painful part of this layout unification is that the Landscape layout on iPhone devices now has less vertical space available for the board, thus making it very difficult to play on a 19x19 board.
2. Layout design and implementation of the annotation view took much longer than anticipated. For quite some time I couldn’t figure out how the layout should look like so that it would still work when squeezed tightly on small screens (old/small iPhones), but still look acceptable on large screens (iPad). Then, when I had finally decided on the current two-page approach, it turned out that I couldn’t use UIKit’s UIPageViewController and instead had to implement a custom PageViewController. While it was fun to design a generic version of such a controller, it still took time that I would have preferred not to spend.
3. When I started to implement the drag & drop mechanism in markup editing mode, the low-level drawing of labels very soon became a nightmare. For a long time I tried to make it work by doing all the drawing in a single CALayer, specifically the layer that also draws the other symbols (e.g. move numbers, last move marker, etc.). Domain-wise this made a lot of sense, because labels are just one more type of markup, and markup is just one class of symbols to be drawn on top of intersections. At some point I realized, however, that it is less important to group drawing artifacts by domain, than by the way how they are drawn. Specifically, label texts potentially can span multiple intersections on the board, whereas all the other symbols can be drawn within the boundaries of a single intersection. With this realization in mind, I created a new CALayer that is dedicated to drawing label texts, and after that the drawing issue quickly resolved by itself. The important innovation was that the existing symbol-drawing layer no longer had to care about re-drawing entire rows of intersection when there was a label change, but simply could rely on UIKit compositing the pixels drawn by the layers. The cost of a new layer is, of course, more memory, but I decided not to take the time to measure this cost because I could not imagine that it would be greater than my need for maintainable drawing code.

So what’s next on the table? The great advances I have made in this release with supporting new SGF properties have motivated me to finally tackle variation support (issue 380) for the next release. Along with support for time-based play (issue 29) this is now the last major gap that Little Go has to most other Go applications, and I think now is the time to close that gap.

---

¹ I’m not going to name the game as I now consider it to be a waste of time.