Always two there are, no more no less. A master release and a bugfix release.
Alas, it seems to have become almost a rule that, shortly after I publish a master release of Little Go on the App Store, some issue is found and I have to follow up with a bugfix release. So here I present to you version 1.5.1 of Little Go which was published on the App Store last Sunday night and which contains the fix for a bug that affected users on older devices with iOS 9.x and below.
The annoying thing is that this time the problem was a piece of code that I had added in 1.5.0 to make UI testing work. In other words, my effort to increase the software quality had exactly the reverse effect. At least the bug was easy to find and fix, just a property (accessibilityFrameInContainerSpace) that was introduced in iOS 10 and which I had forgotten to protect with an appropriate @available guard.
Here's the usual link to the GitHub release page.
Little Go 1.5.0 has been published earlier today on the App Store. Version 1.5.0 is the first feature release since 1.2.0, almost 4 years ago.
The new version contains only a single feature: A new board setup mode in which you can place black or white stones in any order and combination to set up the initial board before you begin to play moves. This feature is a continuation of the work begun in version 1.4.0, where I added support for loading and saving .sgf files that contain stone and/or player setup nodes.
Also important in this version: I started to write automated UI tests. The main work was finding out how the UI testing API works and laying the groundwork for future tests (e.g. how to test the three different layouts, how to interact with the board to place a stone, etc.). Originally I had intended to automate all tests described in the manual testing script (file
TESTING), but then I realized how much work this meant and I became completely paralyzed. Several weeks of stasis finally convinced me that the task of fully automating all UI tests would have to be broken down and completed with "baby steps" if the project ever was to see another release. So that's why in this version of Little Go there is less-than-might-be-expected UI testing.
That's all, folks. If you want you can finish by reading the App Store update notes or the GitHub release page.
Little Go 1.4.0 has been published on January 15 2019 on the App Store, followed-up two days later by the 1.4.1 update that contained a high-prio bugfix. Version 1.4.0 is a maintenance and bugfix release that mainly focuses on updating the project to the newest development environment, Xcode 10.1 and iOS 12.1 SDK.
Although the bugfixes are quite substantial, the amount of time and work that went into them was dwarfed by what I had to invest into just getting the project to run again under Xcode 10.1! This is why I am dreading each new Xcode release: Apple's relentless push for technical renewal is sometimes disheartening for me because I do not code for the platform for profit, and my willingness to spend large amounts of free time on this project has certainly diminished over the years. Ah well...
There are a few things related to the Xcode upgrade that I want to highlight, and a short outlook on a future version 1.5.0. Read on after the break. Or check out the App Store update notes and the GitHub release page.
Little Go 1.3.0 has just been published on the App Store. This is a technical and bugfix release whose focus is on updating the project to the iOS 9.3 SDK, and on fixing an evil ko detection bug that might have been responsible for many bug reports that I have received due to the infamous "The computer played an illegal move." alert. Many thanks to Denis Martynov for helping me with identifying this bug. I promised to release the bugfix
[...] as soon as possible, probably next weekend.This was in June 2015 - over a year ago :-(
To find out about the changes that are in the release, either read the App Store update notes or hop over to the GitHub release page to see the changelog.
Yesterday Little Go 1.2.0 has been published on the App Store. This is a major new feature release that took fully 9 months to complete - in the end the release was dragging out for much longer than intended due to stability issues with the new iPhone 6+ user interface design. Hopefully I nailed all those pesky bugs.
This time I won't bore anyone with a repetition of the changes that are in the release. You can either read the App Store update notes or hop over to the GitHub release page to see the changelog.
Little Go 1.1.2 has just been released to the App Store. This is another bugfix release that contains a couple of fixes for potential crashes (#243, #247), one drawing bug (#245) and one regression (#246).
The harmless seeming drawing bug #245 probably was the root cause for the crashes that so many people experienced in version 1.1.0. The quick&dirty bugfix that I shipped in 1.1.1 (#242) merely turned a crashing bug into a drawing bug, but with the release of 1.1.2 the root cause should now be fixed as well. Since I am not 100% sure, I didn't have the stomach to remove the quick&dirty fix yet.
Little Go 1.1.1 has been released to the App Store yesterday. This version contains an urgent fix for a crash that sometimes occurs while a stone is dragged around the board (#242). The crash was clearly affecting a lot of people because after merely 3 days I had already received over 400 crash reports - almost double the amount of reports that were sent over the last 6 months.
Fortunately, the crash reports clearly showed me where the crash was happening, and why (initializing an
NSArray with a nil object). Unfortunately, the actual root cause that leads to the error condition did not became clear, even after several hours of detailed analysis. Due to the urgency of the problem, in the end I had to implement and ship a quick&dirty fix. I am not proud of this, but at least it seems to be effective: Now that the bugfix release is live on the App Store the crash reports have stopped pouring in.
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
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
UISplitViewControllerto 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.