Making mobile apps for developers, with Anders Borum - creator of the most popular git client, Working Copy
Working Copy is the closest thing to a default Git client for iPhone and iPad, but Anders Borum built it for a mobile-computing future that arrived years later than he expected. His pricing model still reflects that: it's priced, and positioned, as a second Git client, not a first one.
Anders Borum is the creator of Working Copy, a Git client for iPhone and iPad that he started building in 2014 on a bet that iOS was about to become a full-scale computing platform for developers.
We get into why that bet was years early, why App Store optimization barely matters for a tool like his and word of mouth does almost all the work, the unusual pay-once-then-pay-again-for-new-features pricing model he settled on instead of a subscription, and the single change to how the app stores files that he calls the most impactful thing he's ever shipped.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What is Working Copy, and how is it different from something like the GitHub app?
Working Copy is a Git client for iPhone and iPad — it brings version control, the tool so many developers already use, to your mobile device. The GitHub app is mostly about the communication side of things, like reviewing and discussing changes, whereas Working Copy is for actually working with the files and the content of a repository itself. Very few people are doing full-scale development on their phone; it's more that people check things in the repository when they're away from their desktop, make small changes, or use it for non-development purposes like blogging off a repo. It's one piece in a toolchain where most of the other pieces still live on a regular computer, so it complements that setup rather than replacing it.
How did you get started building it back in 2014?
I think I started by misreading the market. I'd made regular consumer apps for a few years, and there were new capabilities appearing on iOS where it felt like the platform was maturing into a full-scale computing platform — apps could control each other, share files, and so on. I imagined it was a matter of a few years before people would be doing full-scale computing and developer tools would all be there, and a Git client was obviously needed for that world. Wanting to be early, it didn't pan out that early — there were policy limitations at the time, like not being allowed to build a compiler or run unapproved binary code, which blocked the rest of the developer toolchain even though it didn't hit me directly. That dampened the whole category for years.
Once you got it out, did people start using it right away?
It was a little slow at first. I had the hope that I was ahead of the curve and that as other developer tools appeared on iOS, the need for a good Git client would increase — and it did, but nowhere near as much as I'd hoped. Looking back, my strategy in 2014 was wrong in terms of timing. But things have compounded since then, and I do think I have sufficient users now and the app is a success.
What do you think were the biggest contributors to getting to where you are now?
Patience, or maybe stubbornness is the more honest word. Looking at the early numbers, a rational decision would have been to try something else instead of sort of keep going. But I could make a living from consulting, so I didn't need the app to bring in a lot of money in the first few years. Slowly I could see it growing, and that's what made it worthwhile to keep at it.
Most people listening won't know much about App Store marketing. How do you actually get users there?
This is one of my internal struggles. The App Store is great for mass-market products, and a good Git client for your computer is not a mass-market product. So it ends up being mostly word of mouth rather than the App Store itself — developers talking to each other, rather than me shouting on social media. Even if someone searches for 'git' in the App Store, many potential users would never think to search for it in the first place, because they don't realize they need it. It slowly spreads because the projects developers work on are dear to them, and just being able to carry your work around with you and glance at it, even if you don't do it often, has real value to them.
How does monetization actually work — is it a subscription?
Because Working Copy is a complimentary tool — for very few users is it their only Git client, it's their other Git client — I have to be careful about charging. Most professional iOS tools are subscription-based, but I can't force that pricing model on users; if I charge too much, or charge a recurring subscription they don't like, they'll just go back to their laptop. So users pay for the app once, and after a year, as new features appear, they can pay again to get them — or not pay again and just keep using what they already have without the new features. It sits between two chairs: it's not a subscription because they're not forced into it, but they do pay again if they want to keep up with new features.
How much does it actually cost?
It's around $30, and if people want the new features after that first year, the upgrade is about half that. I look at it feature by feature — when features were added determines when someone needs to pay again. It's the closest thing to how Sketch used to do it in its early days: you'd buy in and get a year's worth of updates, and after that year you could keep using the last version you had. That's what I'm aiming for. I think most professional iOS apps do charge a subscription now, and it would honestly be great for me if I could do that too, but it's too risky when I'm the second Git client for most of my users, not the primary one — meaning most people are running Git from their regular computer as their main tool, and Working Copy is the backup.
Do businesses buy it for their employees, or is it mostly a personal purchase?
It's a personal expense for most people. It's more difficult than it should be to get businesses to purchase apps for their employees, and that plays into the same dynamic — because it's such a voluntary, out-of-pocket purchase, the users themselves need to want to pay for it. To actually reach enterprise customers you'd need to sell through procurement, which would be great but requires a sales muscle I don't have at all.
You're in a mastermind group with other solo app developers, including Rauno. What's that like?
We're a bunch of people with different apps, at very different levels financially — some are doing extremely well, making millions as a one-person developer. But our apps do such different things that it's hard for us to help each other on the app-specific problems; every app is its own domain. Where we can help each other is on the shared App Store mechanics — Apple's policies, how to try to get noticed, that kind of thing. The big difference in the App Store is what kind of user you're targeting — targeting developers, like I do, is a very different situation from targeting someone building a game or a calculator or a weight-lifting app. We share maybe 90% of the same problems, but it's still different worlds even though we're all making apps for mobile devices.
How do you know if a new feature or change was actually good?
I get direct user feedback through email — there's a small community around the app. I also look at usage data that shows what users are actually doing; if nobody's using something, then maybe it's not very good, or it's too hidden. It seems to be important that there are meaningful improvements pretty often, or users start to lose confidence and think I've stopped caring about it — and that reflects directly in download numbers and sales. So the app needs to keep growing feature-wise, or trying new things and rolling them back if the analytics show nobody's using them.
What's the best change you ever made to the app?
It sounds strange, but it was allowing Git repositories to live outside the app's own sandboxed storage — outside of Working Copy's own little world inside the device. That meant, for example, someone using an app like Obsidian to manage their notes could have that same folder be a Git repository too, with Working Copy cooperating with other apps already on the device. On any other platform a Git client would have supported that from the first version, but that's just how iPhone and iPad apps are generally built — everything living inside its own document folder. Changing that made a huge difference.
And the worst change — something you wish you could take back?
I couldn't actually take it back, because people were already using it, but adding the ability to run SSH commands on a server — uploading a file, running it remotely, then fetching back whatever changed — ballooned beyond what it was meant to be. It came out of frustration with so much of the developer toolchain being missing from these devices, but it was never meant to be a core feature of what's supposed to be a Git app about committing and pushing. Suddenly it became about managing SSH servers and syncing files in different ways, and users kept wanting more of it. Eventually I split that functionality out into its own dedicated tool, so now when people ask for more flexibility there, I can point them to that instead.
Do you have a launch strategy for new apps?
It's very basic. I run newsletters for my apps and start teasing a new product a few months ahead, around when beta testing starts, so I build up a list of interested users. When I'm ready to launch, they get an email. It's old school, but I think it works, and if the app is useful, word slowly gets out from there. There's actually a nice side effect of that trust now — when I launch something new, there are a few days where I get more sales than people starting a trial, which is a strange thing to see since you'd expect people to want to try it first. I think people just want it because they trust the work already. Making something useful, keeping it updated over many years, and taking user feedback seriously is what slowly builds that trust, and it carries over to new products too.
What developer tools do you actually use day to day?
As an iOS developer, Xcode isn't really a choice — that's just the Apple pipeline. Beyond that I use VS Code, and BBEdit, a Mac editor I really like. For my own Git work on the Mac I use either Tower or just the command line.
You clearly avoid subscriptions in your own pricing model. Is that philosophy about your own tool choices too?
Yes. I remember years ago when JetBrains switched their developer tools from a model where you paid once and could keep updating for a while, to a full subscription — users got really angry. I think developers are more opposed to subscriptions specifically for tools that run on their own machine. If there's a service running somewhere, crunching numbers or storing data, that's a different situation and a subscription makes more sense. But for something you download that just runs locally, many developers push back hard on subscriptions. If a company as big as JetBrains, making deep tools used all day by professional developers, still faces resistance to that model, I can't expect to force it on users of a much smaller tool who have a free alternative already sitting on their laptop. That's really one of the reasons I avoid subscriptions myself.
If someone was thinking about building a developer tool as an app, what's your one piece of advice?
I do like making these tools, and I like the space I've carved out for myself on the App Store. But I think my life would honestly have been easier if I'd focused on a traditional software-as-a-service business instead. The App Store is a difficult market for something like this — if you do it, you should do it because you absolutely want to, because it will not be the easiest way to make a living.
Links & references
This episode is brought to you by WorkOS.