Today I’d like to share some insight in what I consider a mistake I made in investing our engineering time. Running a business is hard, and there aren’t always perfect solutions or ideal situations. One might even say that success is defined by making the right compromises at the right time.
Attempting to improve the user experience
The problem described in this article is that our command-line helper ksdiff must be updated separately from Kaleidoscope. This has understandably led to customer annoyances. Improving the situation for our direct version would have been a matter of a few days.
The Mac App Store sandbox restrictions are to blame, apps may not contain a command line tool that does not implement the app sandbox. This means ksdiff has to be distributed outside the Mac App Store via a separate download from our website, and the installer requires an admin password. For Every. Single. Update.
We knew that some exceptions had been permitted in the 2018 Mac App Store refresh. However our conversation with Developer Relations and DTS went nowhere.
The existence of an exception was acknowledged, but at the same time not granted to us.
So we came up with a Plan B: sandboxing ksdiff and granting it file access to the file system via back channel to our app. This isn’t a perfect solution. It solves the issue of non-sandboxed tools calling ksdiff, which is the major user case. But sandboxed apps like the Mac App Store version of GitFox would then not be able to use ksdiff.
We went ahead and worked on that, without asking ourselves if this really makes sense. Yes, improving user experience for our customers does make sense. But I failed to ask if it also makes sense from a business perspective.
I should have known better. I knew the stats: fewer than 10% of our users actually run the Mac App Store version. Yet I committed the team to work for what turned out almost a month on tackling all the sandbox issues, creating the entire flow for a command line utility to request file access, and testing it by throwing every workflow at it that we could think of.
The option of simply improving the direct version of Kaleidoscope while leaving the Mac App Store version as-is never occurred to me. I wouldn’t consider an option that did not benefit all our users.
The Mac App Store risk factor
From the time we took over the development of Kaleidoscope, we have published a huge number of updates on the Mac App Store, and never had any major problems. But as we have tried to add better integration with other developer tools, our updates required more access to the system and App Review took notice.
At this time, Kaleidoscope 3.6 has been in review for a full month without communication or progress, after an initial quick rejection. Not only is there frustration with the current update, our trepidation grows with regard to the updates we have been planning down the road.
This teaches me that the Mac App Store is no place for developer tools with more complex technical requirements than your average app. Which seems wrong, as Develop is one of the main categories in the App Store app.
What does that mean for the future? In the short term, I will definitely accept a hybrid solution. When faced with the choice, we need to focus our engineering time on the 90% of our users using the direct version. That reality is a bitter pill to swallow for a team that believes in customer satisfaction. But we can’t continue to spend such a disproportionate amount of our energy on first satisfying App Store rules, then fighting App Review, and still be profitable.
We can’t continue to spend a disproportionate amount of our energy on first satisfying App Store rules, then fighting App Review, and still be profitable.
App Store customers: use the direct version
In case you weren’t aware, if you have the Mac App Store version of Kaleidoscope, you can also use the direct version. Just install and run the Mac App Store version at least once. After that the direct version will recognize the Mac App Store purchase. Quite a few of our Mac App Store customers are doing that.