In the early months, we spent a lot of time talking to mobile teams of all shapes and sizes — from award-winning indie developers, going all the way to large mobile platform teams generating millions of dollars of revenue every day.
A sign of a maturing platform is the differences between how teams operate, which is evident in the mobile app ecosystem. App teams work differently from each other, even when looking at similar team sizes, geographies, or industry verticals. Interestingly, backend and web frontend teams don't show this degree of disparity, even across organizations. Even at mobile-first businesses, backend and frontend teams display a high degree of operational maturity compared to their app teams.1
The tools and systems that support running an app-first business still have a long way to go. For e.g. PaaS systems (Render, Fly), IaC systems (Argonaut) or declarative CD systems (ArgoCD) cannot be directly translated to the world of apps, but it appears that there haven’t been enough attempts to figure out what apps need.
The struggles of delivery
The communities around Android and iOS have done a lot of work on architecture patterns and cross-platform frameworks, and it has paid off in many ways. At some level this was expected because high-quality software engineering practices look similar regardless of the type of software being built. Modern programming languages liberally borrow from each other, which in turn supports the ability to create similar higher-level paradigms as well — unidirectional data flow, functional core + imperative shell, etc.
However, patterns of release engineering have little in common with those of building software. Apps are not shipped like backend services, and backends are not shipped like web frontends. Backends and frontends are delivered through standard virtualized or containerized environments and consumed through standard client-side software (e.g. browsers), but apps reach consumers exclusively via centrally-controlled marketplaces. Evolution is slow because Apple and Google make so much money from their stores, and give the community little to no say in how these stores are governed and run.
Let’s take an example of what this causes: Unlike backends or web frontends, continuous delivery of apps to stores (and consumers) is not possible2, and neither is rollback of offending builds. As a result, app teams come up with some form of a release branching strategy — a way to stabilize a release candidate build, without blocking the team from continuing development work. Unfortunately, there are no community-accepted strategies to do this and in our conversations, we learnt of teams using needlessly complicated patterns. More than a few times, our discussion with engineers led them to understand during the call itself that they can simplify their process quite a bit!
Branching strategies is just one of the oddities of the app release engineering process. On-device UI testing, different distribution channels (internal groups, external groups), phased releases, manual and automated review processes, user reviews — all of these add complexity to an app’s release cycle.
On building a new product
This is the first time that we’re building a product business from scratch, and a lot of people asked us what that has been like. The widespread literature on startups is not wrong — it is an emotional rollercoaster and a mental drain. If you choose to go down this path, have a strong support system and don’t hesitate to ask for help!
Here are two things that stood out for us.
New market or No market?
We're building a product in a new space, and we had little meaningful data when we began. Much of our early work was based on instinct and experience — there was no way to distinguish the signals from the noise. As we had more conversations and received more realistic data, flaws in our thinking became apparent.
However, some of the ideas mutated so much that we started to question the original premise itself. Even now, we often ask ourselves, "Is this the wrong answer? Or is this not a problem?" which is both amusing and stressful.
Solutions vs Products
Throughout the year, people told us again and again that what we’re building is “not that hard to do” — which is true! That is one of the reasons why solutions created by internal platforms teams work so well, as long as the business can afford to invest in them.
However extracting a solution into a product that lots of people are willing to pay for, has very little to do with the solution itself. When one starts to build for the diversity of the real world, the same solution exponentially increases in complexity. The original solution may eventually be unrecognizable, but that's just the nature of product evolution. To deal with this dilemma, we continue to focus on the problem, not the shape of the original solution.
Opening up
All said and done, what we did for most of 2022 was discover, discuss, and develop the foundation of a release platform for mobile apps. At its core, Tramline enables teams to codify their app release policy. It gives them the ability to express their release workflow in a way that it can be run by anyone.
When a system like this is adopted by an organization, there is very little room for failure. We want to assure teams of the longevity of our software, and we hope to support a rich variety of processes. However, hope is not a strategy so we’re going to go a few steps further…
Tramline will be released and developed as open source software.
We’ve been thinking about this for some time now, and it is clear to us that this is the best way forward:
- Software that sits in the infrastructure layer should come with a high degree of reliability and longevity. Open source software guarantees that to everyone.
- Workflow software is difficult to build in a closed room. After all, how can a small team design something that’ll fit a wide variety of workflows?
- We cannot simply hope for convergence of ideas and best practices; we will have to create a welcoming space. Open source communities have done this successfully for decades.
📆 🚀
Over the next few weeks, we’ll lay the groundwork for community participation. We’ll pick a license that protects both, contributors and our SaaS business. We’ll document the system as it exists today, and we’ll create separate discussion spaces for the community and our customers.
On the SaaS side, we’re already in private beta! If you’re interested in joining the program, write to us at hello@tramline.app or use our Calendly to book a quick call with us.
Footnotes
1: Our data shows that the maturity gap is lower in US and EU markets in comparison to India and South East Asia, but it is still a significant gap.
2: This is not entirely true if one uses React Native and Code Push, but the data we collected on popular React Native apps shows that the frequency of store releases is not dramatically different in comparison to native apps.
