Launch HN: Runway (YC W21) – Easier iOS and Android app releases for teams

[gsavit]

Hi HN! I’m Gabriel, one of the co-founders of Runway (https://runway.team). We’re building a SaaS platform that makes it easier to coordinate your team’s mobile app releases. Runway is an integration layer that sits on top of mobile app teams’ existing project management and development tools, making it possible to understand at-a-glance the status and progress of release cycles and to communicate tasks and blockers — allowing teams to spend their time on improving their product instead of managing releases and tooling.

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 still experimenting with pricing strategy, but for now we’re charging a monthly subscription fee per app – there's a lower tier to access most features, and a higher tier with added features is in the works. Currently the product is in private beta, but we’re actively onboarding new teams of all sizes. If you and your team are interested in trying Runway out, head to https://runway.team/demo for a detailed demo video and we’ll get you onboarded right away!

There are lots of possibilities for further automation and intelligent monitoring on a platform that serves as the glue between the pieces of a release workflow, and we’re excited to hear from the HN community about their unique release process challenges (and general thoughts as well!)

[gregdoesit]

This is a really cool project. When I worked at Uber, the team built a custom release train called Metro, automating as much as possible, integrating with various internal tools and touchpoints. It worked really well: except if you want this, you need to build it yourself.

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/

[gsavit]

It's definitely a problem area that's currently tricky to tackle properly for all but the largest of teams/orgs. Building in-house is often a luxury, and one which requires a big investment not just up front but into the future with upkeep and support. Of course it's nice to have a custom solution, but we've been working hard to make Runway flexible and able to adapt to every team's specific workflows and processes.

PS - thanks for the kind words - we're big fans of the book! Maybe you can squeeze us into a second edition? :)

[sanjayio]

We’ve been using Runway at ClassPass for the last several months. The engineers love it, we can create a release in one click, not to mention improved coordination. The possibility of having an automated RC cut is exciting.

How’d the team land on savings of $50k/year?

[gsavit]

We started with some napkin math, graduated to a complicated spreadsheet, and then tried to distill that into this rough calculator: https://runway.team/release-cost-calculator. General idea was to capture the cost of wasted time spent coordinating and herding cats instead of doing real work! We think there are even more hidden costs not captured here though - e.g. upkeep for in-house tooling or effort spent onboarding new team members.

[bredren]

Any thoughts on the Xcode cloud service described in the WWDC keynote yesterday?

Curious how this can be folded into your business.

[gsavit]

We were super excited by the Xcode Cloud announcement! It’s a neat evolution of the Apple dev ecosystem and could be especially helpful for smaller teams wanting to more easily and quickly level-up their Apple DevOps.

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.

[goodcjw2]

Neat! Looks like a great release tool.

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.

[gregdoesit]

In my experience, mobile is a completely different beast compared to web thanks to things like: - You ship a binary that you cannot revert. Mistakes are very expensive: which is not the case for web. - The App Store review process. - Localization often being shipped with the binary (and you can’t fix it once shipped) - The business impact for mobile apps can be large: your highest value customers often use the native apps

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.

[gsavit]

Some aspects of mobile (e.g. deploying binary, dealing with app stores) make it a more gated and complicated process. That, coupled with our team's domain experience in mobile, led us to focus there to start with. But you're totally right - there's a lot of overlap with any kind of deployment and we have an eye towards a future where Runway is the single place where teams ship everything they need to ship. Plus, there's extra value to unlock in coordinating releases across platforms - e.g. coordinating backend changes with app releases, or sync'ing product launches across web and mobile.

[danpalmer]

This looks great for medium-large size teams, but I've often found these sorts of tools to not have the same impact in smaller teams where communication and processes are a bit leaner and requirements simpler. Is this a market you're aiming for, and how do you think Runway suits small teams?

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.

[trekirkman]

Fwiw we're on the smaller side (~17 people, 3 mobile eng) and have been loving Runway for months. I definitely expect the impact will scale with our team size, but it's already been a no-brainer win for us.

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.

[gsavit]

You're definitely right, in its current form Runway is aimed most squarely at mid to large sized teams. But, we do think there's still value for smaller teams - and in fact, a couple of our early customers are on the smaller side. Although some of the coordination and process overhead isn't there, there's still value in creating a source of truth and reducing context-switching between tools during releases. And, it's really valuable to get a framework like Runway in place earlier on, to better position a team for growth! We envision helping small teams out early on in a lighter-touch way and then helping them mature.

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!

[vosper]

> 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.

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.

[gsavit]

We're happy to hear this sounds appealing even in a non-mobile context! While some of the friction and pain points that Runway aims to solve are especially acute for mobile, it's true that releases are often a problem area for web as well, especially in team settings. We definitely have the idea of applying Runway beyond mobile in the back of our mind!

[an_opabinia]

Let's say I have an iOS app. Not a single thing changes in my repo. I would like to build and submit to the App Store every day. On how many days out of 100 does Runway successfully result in an app submission status of "Under review by Apple" or whatever, without any input from me?

[gsavit]

Interesting question :) Our "full autopilot" mode isn't yet launched but once it is, if you have a recurring cadence set up with scheduled kickoff and submit days, and if each release's interim steps/gates are green, you'd theoretically be able to submit 100 out of 100 with no manual intervention. The real-world limiting factor is that in App Store Connect only one submission can be in flight at a time, and they'd usually be in flight for longer than a day.

[ditn]

This is very very cool and I'm excited to eventually get access to it. I'd love to see a Crashlytics integration so that we can also use Runway to monitor post-release health in one place - looks like maybe you thought about this as I can see Firebase support is coming.

Anyway good luck with this and I look forward to giving it a spin.

[gsavit]

Post-release monitoring and metrics is definitely an area of big interest for us as well! We’re excited to flesh out that part of the platform. Also the idea of release-to-release intelligence, so your team can see how things track over time and make sure your release practice and performance trend in a good direction.

Do reach out so we can get you set up with access :)