Launch HN: Runway (YC W21) – Easier iOS and Android app releases for teams
When I was an iOS engineer, my team rotated everyone through the release manager role for each release cycle. I remember dreading the weeks I was assigned this role - I’d get stuck spending a few hours with multiple Chrome tabs open checking on the status of different tools, killing time while waiting for builds to upload, Slacking the owners of various tasks, and referring back to a 40-line spreadsheet that was often out of date. . I also felt out of practice each time it was my turn - it was hard to remember the sequence of stuff that needed doing, and there weren’t any guardrails to guide me through the process again. New additions to the team felt even more lost when it was their first couple of turns in the role!
If anything, the problem has worsened over time as mobile apps became first-class platforms at lots of companies, and tech orgs naturally started to grow those development teams and implement more robust and complex toolchains to support them — but much of the process of coordinating those people and tools in order to release regularly has remained frustratingly ad hoc.
While some build-centric tasks can be automated (e.g. using fastlane or scripts), we see that a lot of the overhead of releases is actually very people-centric: keeping your PM up to date on progress, looping in marketing for release notes, or syncing with QA on the status of regression testing. We also noticed that, even with a solid CI/CD pipeline in place, there are often still lots of manual tasks along the way - build selection, branching and tagging, compiling changelogs, pinging the right people with status and updates, etc.
We built Runway to connect all those dots. It pulls in all Jira tickets and code relevant to the release, side-by-side, to surface and resolve any out-of-sync tickets or code. You can set up custom, interactive checklists with item-specific owners to replace the monster Google spreadsheet, and our Slack integration will ping the appropriate people or notify everyone when important milestones happen. Design/marketing can enter ‘What’s New’ release notes directly in Runway for all localizations (with a handy list of new features in the release to reference) without you having to hunt them down. Plus, Runway helps teams maintain good workflow hygiene by automatically tagging releases in GitHub and applying missing labels to Jira tickets.
Typically, tasks like these represent lost time that adds up quickly and silently for teams and release managers, between context-switching, monitoring jobs for completion and waiting to get someone’s attention on Slack (all of which only gets harder as teams become more distributed with remote work). In talking to lots of companies, we’ve also noticed that some larger orgs eventually try to build something like Runway in-house, but at a steep cost of dedicated engineers, time, and recurring maintenance.
Runway is made for any team building and shipping mobile apps – we currently support both iOS and Android, and have built-in support for OTA (over-the-air) deploys as well as SDK releases. And, we’re language and framework agnostic: whether you write in Swift, Objective-C, Kotlin, or Java, or use a framework like React Native, Expo, or Flutter, Runway has you covered. We envision Runway as a better way for most teams to manage the release process — one that can save an average-sized mobile team releasing bi-weekly about $50K a year.
We’re s...
31 comments
[ 3.1 ms ] story [ 76.2 ms ] threadHow’d the team land on savings of $50k/year?
My team doesn't releases a mobile client but we release desktop client / chrome extensions every week. It takes about a day of work for an engineer to go through the builds, QA, prepare notes, check the status of things in flight that are trying to land in there, fix some related bugs and so on. And that is with a lot of automation we have. It is also a big distraction from other work, so the opportunity cost is quite high too.
Related, I often find pricing doesn't scale down well for smaller teams (for understandable reasons!). What sort of ballpark are you thinking about?
Lastly, are you tackling the case of agency model development with external clients who may be involved in QA or other steps in the process? I see this as a common model in iOS.
At the moment our main tier is $400/mo, but we're exploring other options for those teams that are smaller and/or at earlier stages.
Re: external clients - This is a really interesting use case that we've chatted to some agencies about. The way we've been thinking about users and roles, it would make a lot of sense to give scoped access to clients and allow them to participate in specific areas as needed!
At the moment, $400/mo is more than the savings calculator suggests we can save, but we're currently 1 full time, 1 part time iOS engineer, 1 release a month, 2 apps (same codebase, whitelabelled). I think $400/mo for ~10 devs makes sense, at that scale it's similar in cost to our other collaboration and CI tools, but I suspect we'd have a hard time justifying it until we're at that sort of scale.
Are there costly features you can cut that could make it, say, $100 for < 5 people perhaps? Something that opens it up to small teams who can then "grow up" on the platform?
We hear you on the math! Our pricing is a work in progress and there's more we'll do on the lower end of the scale for sure. We're hesitant to cut/bundle the product too much but it's a likely option.
If you and your team are interested in trying us out, let's definitely chat though!
When we started, we had a 100% founder-led development/releases process, and the Runway team was pretty hands on in helping us level up. Spending less founder time/thought on releases has been extremely high leverage.
Two other top of mind benefits so far have been a) increased visibility with our ops team (we're very ops/field heavy), and b) improved QA consistency with the release checklist feature.
Curious how this can be folded into your business.
We more or less see it as a substitute for any of the other cloud CI/CD providers teams are already using and integrating with Runway - on the Apple side only, of course. So, a complementary product that Runway will certainly integrate with! We’re especially excited by the prospect of it helping less mature teams get an out-of-the-box build pipeline that better positions them to take advantage of Runway.
Apple breaks fastlane automation at least once a quarter. I would expect about 5-20 days when submissions will fail.
However, if you could get that to zero, emphasis on no manual intervention, like not asking me for configuration changes or to approve something or change or check some box, that is easily worth $400/mo from me.
In terms of config and checkboxes through the submission process, Runway allows you to set defaults so you should be able to set and forget. Of course, Apple does sometimes introduce new requirements and new checkboxes - we plan to help surface those changes to teams.
People who got this far in the thread probably thought, "Yeah, but things like the Encryption Export Compliance checkbox, that's such a nuisance, Apple breaks your automation over stuff that is basically never material." Which is sort of the opposite of what's going on in the flows I saw on Runway's site.
Nevermind what your customers think. If there's a difference between having 100/100 zero intervention upload days, and 80/100, a clear metric, an obvious thing that is valuable - which checkboxes, really, do you think are material? You personally. Because personally, I find the vast majority of checkboxes to be immaterial. CYA and IDC are two sides of the same coin.
In general, my opinion (or Runway's!) isn't as important as factors on the customer side - types of apps, industries/verticals, team makeup - which are likely to make a difference in which checkboxes and options are considered important or not. It probably makes sense to include those factors when thinking about how we can further streamline everyone's release process in the future.
When I researched my book Building Mobile Apps at Scale [1], the best advice I could give for large teams and release trains is… maybe build one yourself? Given I didn’t know of any products that would work from medium to large teams.
It’s great to see someone tackling this problem space. You should talk with Uber’s mobile platform for some hard-learned lessons when building Metro.
[1] https://www.mobileatscale.com/
PS - thanks for the kind words - we're big fans of the book! Maybe you can squeeze us into a second edition? :)
I'm wondering whether there is a specific reason to mobile apps?
Would be nice if all releases (web, mobile, etc) can be going through the same pipeline. After all, those "people-centric" tasks are generally applicable to other projects as well.
That being said, I think "more gated and complicated process" are the key here. Guess it's easy for web/backend developers to hold to the key and deploy as they see needed.
But for mobile, there are typically only a small set of gatekeeper at the entire company had the key to publish a new release to AppStore/PlayStore. Thus the more process is required.
There are similarities, but web has the massive advantage that you can deploy a fix anytime, for your whole user base. With mobile, you need to tread much more carefully.
There are tactics to try and get it to look more similar (such as using RN, or making heavy use of feature flags), but ultimately app store review makes it a different beast.
This is why we built Screenplay (https://screenplay.dev/): to make mobile reversible and try to get releases to look more like web.
How do people do all this for plain web-apps, deployed on a cloud? I don't do anything with mobile apps, and this all sounds great - especially the non-code stuff, like Jira integration and checklists.
Anyway good luck with this and I look forward to giving it a spin.
Do reach out so we can get you set up with access :)