gsavit

My team and I built this! We're mostly former mobile engineers and we’ve felt the pain of app disaster scenarios in prod firsthand. No matter how extensive our test coverage, no matter how thorough our QA, no matter how much we put behind feature flags… our teams have shipped irreversibly-bad updates that break things and upset users.

And mobile hotfixes are slow. Your team has to triage the issue and assign it to the right team members, implement fixes (or carefully revert the offending changes), compile one or more RCs, upload to the stores, submit for review, then cross your fingers and pray to the store review gods for a speedy review. All of this takes time — hours in the best of cases, but potentially as long as days. And the negative impacts of even just a few hours with a critically broken app can be eye-watering: tens or hundreds of thousands of dollars in lost revenue, a flood of negative user reviews, and overwhelmed CX or ops folks.

So we decided to build a safety net.

Critical issue in prod? Roll back instantly. In the background of every normal release cycle, Runway automatically re-signs your last live production build and preps it for a possible rollback release — including preemptive submission for review (iOS only) — to remove all possible sources of delay. Should something go wrong in prod, there’s always a corresponding rollback build ready and waiting for single-click release in Runway.

Here’s how the rollback flow works in a bit more detail:

1). Your team is busy getting your next regularly-scheduled release out the door. Let’s call it version 1.2.0. 2). In the background, Runway takes your latest live build in production — say, 1.1.0 — and re-signs it, bumping the version to 1.2.1 and incrementing the build number as necessary. 3). Your team releases 1.2.0 as scheduled. Nice! 4). The 1.2.1 rollback release is surfaced in Runway, just in case. For iOS, we also preemptively create a new version for the possible rollback in App Store Connect and submit the rollback build for review. 5). Your team is monitoring the rollout of 1.2.0 and identifies a critical issue You halt the rollout. 6). Right next to the button you used to halt the rollout, there’s another button to release the rollback build that’s ready and waiting. Click that, and you’re all set.

With rollback builds primed and ready to go, your team can address critical bugs in prod with a single click — cutting out all the lead time needed to investigate and implement a fix, get builds compiled and uploaded, and make it through the store review process.

Would love to hear people's thoughts!

Or Runway will take care of the piping! Integrations with PagerDuty et al are certainly on the roadmap :)

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 :)

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!

I think it's a good point. Down the road it could be smart to explore an expanded idea of release defaults and the ability to assume away new questions about edge cases that show up in the flow. For now, we're committed to having Runway perform reliably and safely - which to start with means being explicit about options/changes that occur on a third party provider's side.

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.

Runway doesn't actually rely on fastlane, we're interacting directly with the App Store Connect API. So, to the extent Apple avoids breaking things on their own API, Runway should remain operational!

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.

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.

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? :)

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.

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.

Based on what we've heard from agencies, it seems it could be driven from either side: sometimes the agency handles the tooling and that's actually some of their value-add (having everything in place already), sometimes it's all BYO tools on the part of the company/client. Anecdotally, the former seems more common, like you say.

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!

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!