February 13 (of 2020) marks the second birthday of GitFinder. I haven’t really marked its first birthday in any way, hence I thought the second one would be a nice opportunity to recapitulate what GitFinder has achieved during that time and what are its prospects for the future.
GitFinder was actually conceived much earlier than two years ago. First idea to create a git client integrated in macOS Finder came soon after the release of macOS 10.10 Yosemite, in November 2014. With Yosemite, Apple introduced a public API to (again) insert menu items into Finder’s contextual menus and (for the first time) provide custom badges for file icons in Finder, so that some special file status could be graphically shown. The API is known as Finder Sync extensions. Due to numerous bugs in the initial API implementation and due Apple taking more than a year to clear them up, the idea stayed just that for over a year. It surfaced again in October 2015, after the release of macOS 10.11 El Capitan, which fixed mentioned bugs. At that time, I created the first Finder Sync API test application. The first lines of code consisting future GitFinder application were written some time in February 2016. It took another two years to release it to the public.
There are many reasons it took GitFinder that long to go from first lines of code to publicly available product, some of which are explained here. The very similar process happened during GitFinder’s public life. Even though the first release could be regarded as a full-featured git client, many advanced features were missing. In these two years Git Finder got richer for many such features, such are (completely natively implemented) Git LFS support, support for git hooks, beautiful straight-lined commits graph, ability to stage, unstage and discard diff changes per hunk and per line, not only per file, highlighted diff changes, ability to perform various operations on multiple selected items, just to name a few. It also made strides to extend support for different text encoding beyond the realm of UTF-8 (this task is not finished yet). It also became notarised by Apple, although that brought some additional application sandbox entitlements, which I didn’t really like and adopted Internet Access Policy. Finally, while learning more about Finder Sync extensions, GitFinder has undergone some complete redesigns of the way the application and its extension work and communicate, and their specific and shared responsibilities, all in an attempt to make GitFinder experience more pleasant, performant and secure.
One may ask a question if in these two years GitFinder has fulfilled its initial goals. For start, there weren’t really some strictly defined goals at the time the development started. One goal has been fulfilled for sure, GitFinder became the only git client I use. I don’t even use standard git command line tool anymore, as GitFinder serves all my needs. I actually use others only to compare results they produce with certain operations with those produced by GitFinder, as an additional precaution GitFinder does all things right. It is actually rather tricky to use GitFinder while developing it at the same time, due to a very likely conflict between Finder Sync extensions of the version being developed and the one actually used for git operations on developed version repository. Solving the problem includes some trickery and explaining it can be a subject of another story, but it works.
One of the potential goals of GitFinder was to become financially sustainable product. That goal has not been fulfilled yet. It sells, but current quantities are far from being enough to make it sustainable. Therefore I don’t spend my full working time developing it. There may be many reasons for this “failure”. I don’t really see it as a failure yet, as not many things were done to make it succeed. It may be the market for git clients on Mac is already saturated with a lot of quality solutions, some of which are backed by very large companies and hence offered for free. It may also be my initial thought that many people would like having git client integrated in Finder, seeing file git status in Finder and executing all git commands from Finder contextual menu, was completely without merit. TortoiseGit is fairly popular on Windows and I thought GitFinder may experience the similar destiny on Mac, without putting any additional effort in its marketing.
Poor marketing certainly is the main reason GitFinder hasn’t made bigger impact. Nothing has been done regarding advertising and promoting the product and it seems “a word of mouth” is not enough anymore in the saturated market, which also experience devaluation of shareware applications and price race to the bottom (but that is yet again the subject of another story). However, regardless of poor sales, GitFinder is not going to be abandoned any time soon. My plan is to include some highly desired features in the following 1.x releases and then invest some effort in more serious marketing. Hopefully better sale results will follow.
Perhaps the best goal GitFinder has fulfilled so far is being a guinea pig for applying new macOS technologies Apple introduced. I adopted many of those introduced in the past few years, practically everything that could find its way into GitFinder. One thing, rather huge, remains still unused, at least in the official version: Swift. GitFinder is still a complete Objective-C beast, from head to toe. There are a few reasons Swift still hasn’t found its way through. Firstly, I’m much more proficient in Objective-C, than in Swift, I would rate my Swift knowledge as a bit above rudimentary. Secondly, although I like Swift for many reasons, I still prefer Objective-C in certain situations (where it seems less complex, although more verbose). But most importantly, macOS system libraries weren’t available in Swift due to ABI instability until Swift 5 and macOS 10.14.4, well after the development of GitFinder took full swing. I was never really enthusiastic about the idea of bundling necessary Swift system libraries in the application bundle, hence significantly increasing its size, only to be able to say the application was written in Swift, without any clear practical benefits.
But since Swift 5 and ABI stability, the playing field changed and GitFinder started living its double life. The official version is still Objective-C and will remain like that as long as macOS 10.14 Mojave is supported. But an alternative, future version has being shaped for almost a year now. It will be written completely in Swift and currently it serves as another guinea pig for shaping my Swift understanding, knowledge and skills. Introduction of SwiftUI gave another push to this version, as it will abandon AppKit completely and use SwiftUI, hence pushing for a full Swift design, not only in language, but also in underlying APIs used. The current vague plan is to keep adding new features and polishing the current Objective-C version in consequent 1.x releases, until it is complete as it possibly can be. Once that happens and Mojave becomes outdated enough so the support for it can be safely abandoned, the new Swift only version 2.0 of GitFinder will step on the stage and take over. Hopefully by that time will Apple (and the community) improve and fix all current Swift quirks and bugs. That especially concerns SwiftUI, as it is currently clearly in the beta stage and very far from being ready for any production software.
All said concluded, GitFinder still has some long and exciting times in front of it. These past two years were just warming-up, the real race has not started yet.