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.
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!
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.
+1000 to focus on mobile first. Totally understandable :)
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.
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.
> to submit 100 out of 100 with no manual intervention
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.
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.
> 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.
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.
I think that's a reasonable place to be. If you introduced a "Breaking build changes: New Checkbox Requirement" email most teams could just pipe that to pagerduty/opsgenie and have a reasonable way to ensure a working green deploy pipeline.
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.
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!
+1 to the external clients. Not sure if it makes sense for it to be agency driven with external client stakeholders, or company driven with external agency developers/PMs. I'd imagine the former would be more common but could be quite a different solution for the latter.
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?
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!
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.
Seems about right ballpark, if not undercounting it.
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.
Right now the focus is on public/prod deployment. Beta Testing is a step within Runway, but it's not so fleshed out and no integrations are pulled in there yet. It's definitely on our roadmap though - we want to help teams codify and streamline their internal distribution!
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!