Little Go

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 ... [More] 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. Software Projects: Little GoArticle Styles: Release note [Less]

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 ... [More] 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. Software Projects: Little GoArticle Styles: Release note [Less]

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 ... [More] 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. Software Projects: Little GoArticle Styles: Release note [Less]

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 ... [More] 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. Software Projects: Little GoArticle Styles: Release note [Less]

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 ... [More] 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. Software Projects: Little GoArticle Styles: Release note [Less]

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 ... [More] 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. Software Projects: Little GoArticle Styles: Release note [Less]

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 ... [More] 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. Software Projects: Little GoArticle Styles: Release note [Less]

Little Go 1.0.0 has been released to the App Store a couple of days ago. The GitHub issue tracker has a list of all issues that I worked on for 1.0.0, and here is an excerpt of the changelog for the visible features changes: Superko is back (it was ... [More] disabled in 0.12.0), but simple Ko remains the default. You can select the Ko rule when you start a new game (#169). Little Go now supports area scoring (#30). I implemented this mostly out of necessity because I realized that Fuego does not properly support territory scoring. That's also the reason why area scoring is now the default scoring rule. Accurate scoring is now possible because stones can be marked to be "in seki" during scoring (#190). A little goodie that I wanted to implement for a long time is the display of player influence, aka territory statistics (#18). These features, however, were not why it took me so long (over 3 months) to finish the 1.0.0 release. Rather it were the things that changed under the hood: Upgrading to Xcode 5 cost me quite a bit of time (and a lot of nerves!) until I realized how I could get back unit tests to run. Initially I also tried to upgrade from OCUnit to XCTest, but had to abandon the effort because I am still using the 6.1 SDK. This Stack Overflow question summarizes my troubles. I completely rewrote the 3rd party software build process to use Git submodules. For this I had to learn about Git submodules in general, and in particular about svn2git so that I could mirror the Fuego Subversion repository with Git. The end result is the fuego-on-ios repository on GitHub, which is intended to provide other people with a base for creating their own Fuego builds for iOS. Last but not least, I decided to upgrade from Fuego 1.1 to the trunk version of the Fuego source code. This gave me a nasty surprise because the trunk version of Fuego uses much more memory in its default configuration than Fuego 1.1 did. So much memory, in fact, that Little Go becomes unusable for iOS devices with 256 MB of memory, and unstable for iOS devices with 512 MB memory. Although I soon found out how to reduce memory usage, a lot of effort went into making sure that Fuego works correctly with this low-memory configuration. The results are published on the Fuego wiki. Implementing most of these technical changes were not fun, and thus releasing version 1.0.0 has not been an occasion of joy, but rather one of relief. In the end, I must admit, that my motivation was so drained, and I was so weary of the whole thing, that I pushed the release to the App Store without a lot of testing. I hope my users will forgive me for this. Software Projects: Little GoArticle Styles: Release note [Less]

Little Go 1.0.0 has been released to the App Store a couple of days ago. The GitHub issue tracker has a list of all issues that I worked on for 1.0.0, and here is an excerpt of the changelog for the visible features changes: Superko is back (it was ... [More] disabled in 0.12.0), but simple Ko remains the default. You can select the Ko rule when you start a new game (#169). Little Go now supports area scoring (#30). I implemented this mostly out of necessity because I realized that Fuego does not properly support territory scoring. That's also the reason why area scoring is now the default scoring rule. Accurate scoring is now possible because stones can be marked to be "in seki" during scoring (#190). A little goodie that I wanted to implement for a long time is the display of player influence, aka territory statistics (#18). These features, however, were not why it took me so long (over 3 months) to finish the 1.0.0 release. Rather it were the things that changed under the hood: Upgrading to Xcode 5 cost me quite a bit of time (and a lot of nerves!) until I realized how I could get back unit tests to run. Initially I also tried to upgrade from OCUnit to XCTest, but had to abandon the effort because I am still using the 6.1 SDK. This Stack Overflow question summarizes my troubles. I completely rewrote the 3rd party software build process to use Git submodules. For this I had to learn about Git submodules in general, and in particular about svn2git so that I could mirror the Fuego Subversion repository with Git. The end result is the fuego-on-ios repository on GitHub, which is intended to provide other people with a base for creating their own Fuego builds for iOS. Last but not least, I decided to upgrade from Fuego 1.1 to the trunk version of the Fuego source code. This gave me a nasty surprise because the trunk version of Fuego uses much more memory in its default configuration than Fuego 1.1 did. So much memory, in fact, that Little Go becomes unusable for iOS devices with 256 MB of memory, and unstable for iOS devices with 512 MB memory. Although I soon found out how to reduce memory usage, a lot of effort went into making sure that Fuego works correctly with this low-memory configuration. The results are published on the Fuego wiki. Implementing most of these technical changes were not fun, and thus releasing version 1.0.0 has not been an occasion of joy, but rather one of relief. In the end, I must admit, that my motivation was so drained, and I was so weary of the whole thing, that I pushed the release to the App Store without a lot of testing. I hope my users will forgive me for this. Software Projects: Little GoArticle Styles: Release note [Less]

Little Go 0.12.0 has now been in the App Store since September 11, i.e. 4 days. I thought this would be a good opportunity to publish a few numbers from the iTunes Connect sales statistics: Number of updates on the first 4 days: 976, 5537, 1785 and ... [More] 1211. This shows that the majority of people are updating on the second day. The total number of updates is 9509. I wouldn't go so far as saying that these people are all actively playing Little Go, but at least they haven't deleted the app yet, so it's probably reasonable to assume that this is the user base that thinks the app is not a total crap ☺. I expect quite a few updates more in the next couple of days and weeks - for comparison, when I published 0.11.1 in May 2013, the total number of updates in the first 4 weeks was 12724. Since July, between 50 and 100 new devices have downloaded Little Go per day. I don't know how many new users that is, but it's certainly not too bad ☺. Apparently the app is still gaining some interest. Looking at the monthly rates of new downloads, the picture is this: Between August 2012 and January 2013 the rate was steadily climbing from 1315 to a peak of 3415 new downloads per month. Over the last 7 months, the rate then slightly dropped to a monthly average of ca. 2800 new downloads. In 2012 the top 6 markets were USA (3744 downloads), Germany (2678), France (1630), Thailand (1362), the Republic of Korea (1276) and Russia (969). Runner up on 7th place is Turkey (368). In 2013 the picture so far is pretty much the same: France (4517), Germany (3884), USA (3242), Thailand (2234), Russia (1900) and the Republic of Korea (1348). As in 2012 the runner up is Turkey (559). Software Projects: Little Go [Less]