Runway Release Notes

2024 has now passed Runway by. It’s probably passed you by too, unless you live backwards through time like Merlin the Wizard or those people from Tenet. If you are one of those people from Tenet (they need streamlined mobile releases too, we’d think), don’t read this as we don’t want to spoil the past for you.

As Runway, we’re already hard at work on all our plans for 2025, but we’d still like to take a moment to stop and look back on everything we did in 2024. If you haven’t done so for your own 2024 yet, you should. It all goes by in such a blur, but all the work you do every day and every week and every month really adds up.

Also, thank you so much as always for being a Runway user, potential user, happy hour attendee, conference booth visitor, booster, investor, future shareholder or friend. In the spirit of the season, we even thank you if you consider us your arch nemeses. Whatever brings you to this post, we hope your year has been a good one!

What did we ship in 2024?

We built more big features, a lot more enhancements, and a longer list of new automations & integrations than any year before.

Here are some of the highlights.

Fixes offers a safer and more consistent way to get late-arriving changes into a release whenever needed. Fixes applies real guardrails that allow you to track, review, and approve any late additions, and automates away the busywork and context-switching required to actually get changes pulled in.

AI-powered user review analysis

Your app gets reviews. Most of them are good, but some of them are not so good and may indicate a bug or other problem with your app. Still others might be because someone had a late delivery, didn’t think their wings were cooked long enough, felt that your subscription plans were too expensive, or had a bad experience talking to support.

Simply evaluating these reviews based on sentiment isn’t enough, since that would include those reviews which have nothing to do with how well the app is performing. So Runway considers the context of your company and app in order to single out bugs and broken functionality, using AI to analyze all of your incoming app store reviews and identify common issues mentioned in them.

Release digest emails

You and your teammates can subscribe to recurring digest emails that pull together info on recent and upcoming releases. Stay in the know on what you’re shipping, when you’re shipping it, and key metrics about post-release app health. These emails include things like adoption stats across live versions, detailed stability and observability metrics as configured in Runway, info about release schedules and timing, an overview of pending and completed work and fixes, upcoming release pilots, and direct links into Runway for each release in question.

Ping all pending owners

Never again will you need to track someone (or someones) down in order to keep your release on schedule. We’ve added a “Ping all pending owners” action to the Feature Readiness step. When you click the button to ping, Runway will send a notification to Slack tagging the respective owners of any outstanding code and/or project management tickets associated with the pending work.

Build Distro v2

We added Build Distro endpoints to our public API that allow you to upload builds, as well as create, read, and update buckets. Plus, we now automatically post comments containing build information and install links for release candidates that contain code associated with a given ticket. Finally, we added full search functionality to Build Distro so that you can search by build number, commit message, PR title, and other fields to find the right build in seconds.

Release pilot scheduling

Runway’s existing release pilot rotation management can now connect to a scheduling tool like PagerDuty or OpsGenie. Runway will manage your release pilot rotation accordingly, automatically assigning pilots to releases based on a given on-call schedule, swapping folks when coverage changes, and re-assigning pilots if a release rolls over into another team member’s shift. Reminders and alerts can be sent along the way, so there are no surprises or gaps in coverage.

Update metadata and release notes, whenever

As soon as a release exists in Runway, you can update your metadata and release notes so that they’re there and ready to go whenever you submit to the app stores. This also means that translation work can begin immediately (via our new translation integrations noted below). No more rushing to copy and paste at the very end of your release process.

Checklist items and gating for Rollouts

We brought Runway’s checklist items functionality to the Rollout page so you can assign and track any post-release tasks the team needs to perform. With these here, you can also now pair checklist items with our rollout automations. So we’ll monitor your rollout and configured health metrics as usual, but even if health and adoption conditions are met, Runway won’t trigger the acceleration to 100% unless all required checklist items are also complete.

Timeline event search

Search the timeline to track down specific actions, or understand a sequence of events within a release. This search is available anywhere your release timeline is accessible within Runway.

Quick Actions menu

This surfaces shortcuts to many of the most important views within Runway. Enter Command + K / Ctrl + K from anywhere in Runway to start a search. You’ll never have to touch your mouse again, at least if your only goal is to find something in Runway.

Automatic user review translations

Runway will automatically translate any non-English reviews and surface those translations alongside the original reviews in Slack (if you have store review notifications enabled). No more asking ChatGPT what a French customer meant when they wrote “Cette application plante toujours à chaque fois que je l'ouvre. Mais j’aime et respecte toujours les ingénieurs qui l’ont construit.”

Sync app store metadata automatically

If you check your app’s metadata into version control in your repo, you can now have Runway automatically read all the store metadata and sync it with the app stores. Leveraging your existing version control integration in Runway, you simply enable the new automation, specify the file path, and Runway will automatically grab metadata and populate it in the stores as each release is kicked off.

More integrations for everyone

We also shipped nine new integrations:

• New Relic (Monitoring)
• Huawei App Gallery (Distribution)
• Pager Duty (On call)
• Opsgenie (On call)
• Crowdin (Translations)
• Localise (Translations)
• Samsung Galaxy Store (Distribution)
• Dynatrace (Monitoring)
• Split.io (Feature flags)

See them all on our Integrations page. And you want to really dig into all our new features from the past year, read our continually updated and very detailed Product Updates page.

Events

This year wasn’t just about features, it was also about traveling on planes to distant locales to meet other mobile folks.

In 2024, we sponsored more conferences and hosted more happy hours than we ever have before. We traveled all around (part of) the world to spend time with other folks from the mobile community at:

• AppDevCon (Amsterdam)
• ReactNativeConnection (Paris)
• Android Makers (Paris)
• Deep Dish Swift (Chicago)
• Swift Craft (Kent, UK)
• droidcon San Francisco (uh, San Francisco)
• One More Thing Conf (Cupertino)
• droidcon Berlin (Berlin)
• Chain React (Portland, Oregon)
• NSSpain (Logroño, Spain)
• droidcon NYC (Queens)
• Swift Connection (Paris)
• SwiftLeeds (Leeds, UK)
• droidcon London (London)

Lots of trips to Paris and the UK there. In these post-Covid years, it feels like Europe has become the center of the mobile conference community while the US is just starting to come back with strong events like Deep Dish Swift (which we’re thrilled to be sponsoring again in 2025).

On top of these events, we also hosted a ton of happy hours in Amsterdam, Chicago, San Francisco, Cupertino, Berlin, Portland, NYC, Copenhagen, and Sao Paulo, with anywhere from 20 to 200 people in attendance at each.

Shot taken four hours into our WWDC happy hour across the street from Apple HQ

Regardless of where and when we did it, we met with over 3,000 people and gave out over 1,500 of our signature, miniature lego airplanes, and countless t-shirts, stickers, pilot wing pins, postcards, Biscoff cookies, and (for a few lucky winners) LEGO space shuttles and LEGO Concordes.

And we gather for a company offsite in April in Barcelona. We collaborated, connected, brainstormed, hacked, ate too much good food, played too much Quiplash, and got too sunburned while floating around on a boat.

We’re spread across North America and Europe, with team members in NYC, Seattle, CDMX, Baja, the Canary Islands, Montevideo, Boston, Austin, Dallas, Lisbon, and Valencia. Being so spread out means we don’t often get to see each other outside the confines of Zoom and Slack, which is why we all travel to an offsite on occasion to spend time together in one place.

Barcelona is a very nice place to have an offsite

2024 was a wonderful year for Runway. We hope it was also a great one for you and your team. And we’re looking forward to an even more wonderful year in 2025.

Happy Holidays, Happy New Year, Joyous January, Fabulous February, and many additional alliteratively awesome months ahead.

Original source Report a problem

Managing the work that makes it out with any given app release is tricky.

Late-arriving changes are directly correlated to increased bugginess in releases, so teams typically try to establish a stabilization period or “freeze” to prevent new changes from entering the diff while testing and other release prep is finalized. Actually enforcing that freeze can be difficult. It requires some combination of thoughtful branching strategy, branch protection rules, and well-documented processes that the entire team buys into, adheres to, and keeps up to date.

What makes this even trickier is that sometimes you do still need to pull late changes into a release. You can’t just lock the diff immediately after you kick off a release and call it a day, as issues are sometimes only identified during the stabilization period. This is especially true for teams that ship fast and frequently. Since final validation often happens in parallel with freeze and other release prep, it’s more likely that issues get discovered post-freeze. Plus, it’s possible that the preceding release is still early in its rollout, a critical issue is discovered there, and the team wants to squeeze a fix into the on-deck release.

The mechanics of actually getting late-arriving work into a release (and making sure all changes are synced with the working branch) involves extra Git wrangling (a cherry-pick or backmerge workflow, say), and that alone can be more insidious than you might expect. In a vacuum these aren’t difficult processes to run, but in a high-pressure situation where the team is rushing to get fixes in and avoid a delayed release, the extra wrangling is unwelcome busywork and context-switching. Given the context, it’s more likely that mistakes are made or steps are missed. (Teams that backmerge: ever apply a fix and then forget to backmerge, landing right back where you started with another broken release??)

Perhaps the hardest part of handling late-arriving work is deciding what actually gets to arrive late. Is anyone and everyone allowed to apply late fixes to a release if they feel like it? Could someone even squeeze in that last feature ticket they just managed to finish post-freeze but pre-release? Even for teams that release frequently, there’s often a lot of pressure to fit more work into a given release, bug fixes and feature work alike. Ideally there are guidelines in place that dictate when a late change is allowed – no feature work, only bugs that impact a critical path or some set of key metrics, that sort of thing – but guidelines still require enforcement and approvals (read: humanpower) and teams often struggle to stick to the rules.

All of these challenges combine into the sort of problem that we’re all about solving here at Runway, at the intersection of tooling and humans, automation and coordination. Runway’s newest feature, Fixes, helps mobile teams better manage and protect their release diffs by applying real guardrails around late-arriving changes. Now, teams have a consistent way to escalate and review late-arriving work, and then pull those changes into the release automatically but only if they get OK’d. Read on for more on how Fixes works!

Make it crystal clear when a late change is incoming, and why

Part of the reason late-arriving work can be so insidious is that it often sneaks into a release unannounced. At best someone might flag a pull request with a required fix, but that often disappears into the black hole that is your noisy Slack workspace; at worst (but not at all uncommonly) they’ll just go right ahead and cherry-pick or merge it into the release, unbeknownst to much of the rest of the team. With Fixes, Runway allows your team to capture a piece of late-arriving work as an actual entity that gets surfaced clearly alongside a release. The team can follow the item’s progress, with full context so everyone across engineering, product, and QA can stay on the same page.

You can add a fix from within Runway on a given release’s feature readiness view, either creating it from any item that already appears on the working branch or using an explicit “+ Add a fix” action. Or, take advantage of a new

/runway add fix

slash command to create a fix on the fly, without leaving Slack. Wherever you create a fix, you’re prompted to include additional details on the fix and why it’s needed. This context is surfaced alongside the fix and helps your team build a culture of accountability and standards around what kind of work should actually be allowed to enter a release late in the cycle. You might use this space to capture the scope or severity of a showstopping bug the fix is addressing, or some business level justification for why the change needs to make it in.

Add real guardrails with optional approvals and status checks

Making late-arriving work more visible and attaching context that explains why a change absolutely needs to make it into a frozen release diff can be a big first step. But even then, you’re still relying on team members to be on the same page when it comes to expectations around late-arriving work and to adhere to whatever agreed upon processes you have in place to protect a release that’s stabilizing. With Fixes, you can apply actual guardrails by optionally enabling an approval flow that each and every fix must pass through. With the approval flow enabled, new fixes are highlighted as ‘pending approval’ in the release’s feature readiness view. Pending fixes must be reviewed and can be either approved or rejected by certain folks on your team.

To further enforce approvals, you have the option of enabling GitHub status checks that tie into fixes in Runway. If enabled, status checks will appear on any PRs open against the release branch and they will only pass if and when the associated fix in Runway is approved.

Automate your Git wrangling to avoid mistakes and save time — safely

Some readers may already be familiar with Runway’s cherry-pick automation, which previously allowed you to have Runway automatically pull work into a release based on a specified token being present in a target item’s PR title. With Fixes, this automation has both expanded and become more safeguarded.

Now, with the cherry-pick automation enabled, Runway will automatically pull any fixes over into the release — no need to include some token in an associated PR’s title. (Sidenote: if a PR title does include a designated token and a corresponding fix doesn’t yet exist for that work item, Runway can automatically create the fix.) Rather than executing unchecked, the automation is gated on any conditions that would otherwise apply to your fixes. If you have the fix approval flow enabled, Runway will wait for a fix to be approved before automatically pulling it over into the release.

Keep tabs on your team’s hygiene around late-arriving work with fix metrics

In order to improve your team’s practices around late-arriving work and release stabilization, it’s helpful to track things like how often potential fixes are being raised, how often they’re actually pulled in, and how much of a given release’s diff is made up of these late items. Runway collects metrics like these as you work and surfaces them per release, as well as at an app and org level.

With Fixes, Runway is giving your mobile team a better way to manage your release diffs and increase consistency & confidence around late-arriving changes. By making late inclusions more visible and auditable, and by adding real guardrails that ensure risky changes like these are properly reviewed and approved before they make it into a release, Fixes protects release health and helps your team establish clear standards around this tricky part of the mobile release process. Go ahead and lock down your release branches, and turn your internal fix request guidelines from forgotten lists of easily ignored suggestions to a built-in, structured part of each and every release.

Get in touch at [email protected] with any questions or feedback or, better yet, schedule a live tour of Fixes with our team!

Original source Report a problem

Introducing Rollbacks by Runway

The first and only platform to enable rollbacks for native mobile apps. Undo a bad binary release with a single click.

No one is immune from shipping critical bugs to production. No matter how extensive your test coverage, no matter how thorough your QA, no matter how much you put behind feature flags — your mobile team will ship irreversibly-bad updates that break things.

This is especially problematic for mobile because you can’t roll back immediately like your web or backend friends can. Rather, once you detect a critical bug, 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.

But what if it didn’t have to be that way? What if you could instantly resolve a critical issue in prod, with a single click? We set about building the answer. Runway’s new rollback feature means your team is always just one click away from resolution of critical bugs in prod. We handle the busywork needed to prepare and stage rollback builds, each and every release, enabling a “break glass in emergency” action that is always there when your team needs it. Read on for the full story on how rollbacks work in Runway, and the kinds of problems we’re solving for.

Recover from production issues in zero time — literally

With Runway’s rollback automations, we ensure all the pieces are in place to allow you to roll back instantly if a critical issue is discovered in prod. In the background, for each and every release cycle, Runway automatically re-signs the previous stable, live build and gets it prepped for release — including submission for review as soon as possible (iOS only) — to get all possible sources of delay out of the way. Then, if something goes terribly wrong in production with the release you were just working on, you have the rollback build ready and waiting for a single-click release in Runway.

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

• Your team is busy getting your next regularly-scheduled release out the door. Let’s call it version 1.2.0.
• 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.
• Your team releases 1.2.0 as scheduled. Nice!
• 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.
• Your team is monitoring the rollout of 1.2.0 and identifies a critical issue 🚨You halt the rollout.
• 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.

Take the pressure out of hotfixes, so you can triage more fully and fix more confidently

Even if you decide to leverage Runway to quickly ship a rollback to address an issue in prod, it doesn’t mean you’ll necessarily wait until your next regularly-scheduled release to roll forward and issue a fix for the original issue. In fact, it’s likely you’ll often use rollbacks in conjunction with roll-forward hotfixes, and the two complement each other. Because rollbacks allow you to instantly stabilize the situation when you detect critical bugs, your team doesn’t have to scramble to get a hotfix prepared and out the door. Instead, you can take your time in triaging, investigating the root cause, implementing the necessary fixes, and then working through your hotfix release process. Removing the commotion and pressure that’s typically involved in hotfixes results in better hotfixes, and helps you avoid the hotfixes-on-hotfixes(-on-hotfixes) rabbit hole that can swallow teams whole.

More predictable resolution timelines, and fewer unanswerable “when??” questions from stakeholders

Every team knows the feeling of dread that hits when you’ve shipped a breaking change and leadership shows up in your #mobile Slack channel. Mistakes happen, sure, but once a mistake has been identified, stakeholders are often breathing down your neck wondering how long until your team can get it addressed. Is the fix in yet? Is the build approved by Apple? How about now? With rollbacks in Runway, you can actually respond to these kinds of asks and give stakeholders confidence that the situation is under control. When you choose to ship a rollback, the answer to the inevitable “when” question can be “already”, and stakeholders can rest assured that the situation has been stabilized.

When you need a rollback, it’s there for you (batteries included). When you don’t, we’ll handle all the cleanup.

Runway’s rollbacks functionality encompasses quite a few dependencies and steps which, if approximated manually each and every release, would require a lot of work — not just to prepare each rollback, but also to clean up unused rollbacks along the way (to unblock subsequent releases). In handling all the heavy lifting, Runway unlocks the massive upside in situations where your team would want to deploy a rollback, while eliminating the continuous manual wrangling that is required along the way just to make that possible. As a result, you no longer have to choose between investing huge amounts of time and effort into setting up rollbacks manually or else forfeiting the safety net instant rollbacks provide.

With rollbacks, Runway is giving your mobile team the quickest possible way to respond to critical issues in production. Instead of scrambling to identify, implement, and ship a fix, you can address the situation with a single click. Stakeholders won’t hover anxiously wondering when a resolution will land, and your team will be able to triage and implement fixes more confidently, without all the pressure that typically accompanies hotfix situations. Plus, rollbacks mitigate the serious negative impact to revenue and app store reviews that comes with a buggy app being in users’ hands for even just a couple of hours.

As always, we would love to hear your thoughts! Get in touch at [email protected] or, better yet, schedule a live tour of rollbacks with our team!

Original source Report a problem

Build Distro by Runway: Untangle your builds and get them where they need to go, without all the hassle

Mobile build distribution is hard. There’s the provisioning and signing gauntlet, of course, but the challenges don’t end there. Getting the right builds in front of the right teammates takes constant effort and shepherding, and creating an install flow that’s pain-free is difficult. Unfortunately, existing tools for distribution tend to be clunky and incomplete in their approach.

The impact of not doing build distribution well is pretty significant. When you don’t have a clear separation of different build flavors and audiences, folks might waste time testing the wrong builds (best case) or you could mistakenly ship a pre-production build to prod (disaster case). And when there’s confusion around distribution and a less-than-seamless install flow, the natural tendency on a team is to simply avoid doing much with distributed builds — meaning there are fewer eyes on fewer builds throughout your dev and release cycles, with a domino effect on collaboration, transparency, and app quality.

This is the human factors side of build distribution — the challenge of getting the right builds to the right people, and making it easy for them to do something next (install and test). Existing tooling options seem to treat this aspect as secondary, or ignore it altogether. Very often, distributed builds all land in a single, jumbled pile and your team has to carefully pick specific build flavors out of it (from one-offs and nightlies to RCs and prod builds). Where certain tools do offer some kind of grouping, these tend to be groupings of testers, not builds — meaning there’s no clearly defined separation of different build flavors, and any flavor of build could make it in front of a particular group of testers (or, worst case, in front of users). Context is also often lacking for folks on the receiving end, with only build numbers to ping back and forth over Slack (maybe also a commit hash or message if you’re lucky).

Build Distro by Runway: Untangle your builds and get them where they need to go, without all the hassle

What’s missing is a way to clearly and concretely define the different types of builds your team distributes, and then group those distributed builds accordingly — from work-in-progress builds that engineers want to get into the hands of PMs and designers, to staging builds for QA to regression test, to production builds destined for end users. For a given grouping of builds, you should be able to target specific audiences and any viewer — technical or non-technical — should be able to understand at a glance what kinds of builds they’re looking at and grab a particular build without any hunting around. Plus, team members should be able to install seamlessly, and with full context alongside each build to avoid the whole build number back-and-forth.

With that goal of foolproof, more human-centric mobile distribution in mind, we set about building a better way.

Get the right builds into the right people’s hands

Build Distro introduces the idea of build buckets to allow you to clearly define and group different flavors of builds. Instead of having all distributed builds landing in that jumbled pile, you can now separate different kinds of builds using definitions based on branch, CI workflow, or some combination of both — or using more freeform, ad hoc buckets. Not only are build flavors logically separated into buckets, but you can set up targeted notifications and scope access per bucket to ensure the right people are aware of and able to seamlessly install new builds relevant to them.

Share one-offs & early test builds more easily

With branch-based and ad hoc, personal build buckets, Runway makes it much easier to share work-in-progress builds. You can create dedicated buckets for test builds and nightlies on your main development branch or any feature branches, and everyone on your team can also have their own personal buckets to drop updates into as they work. Product managers, QA, designers, and other engineers and stakeholders can now easily grab any WIP builds, earlier and more often during the development cycle, helping your mobile org improve quality and shift left.

Make it impossible to ship the wrong build to prod

One of the worst failure modes around build distribution has to do with test or staging builds getting accidentally shipped to production. It may be rare, but when it happens, it can be devastating. Confusion around distributed build flavors is often to blame, and Runway’s build buckets remove this risk. Clearly delineate prod and pre-prod builds, and scope access accordingly.

Install app builds with less hassle, and more context

Even once someone has tracked down a build they want to check out, actually getting it onto their device comes with its own hassles. Runway makes installation foolproof and seamless: with each build, you can install directly by scanning a QR code or sending yourself a link in Slack. Plus, alongside each build you can see full context on the build flavor and exactly what work it contains — no more guesswork, pinging build numbers back and forth and hoping you’re grabbing the right version of the app.

Integrate with your existing tools for zero extra overhead

Getting up and running is simple: connect your existing CI and… that’s it. Once you’re connected, Runway will get you started with a few default shared buckets for development and RC builds, and anyone on your team can easily create scoped personal buckets. To define a new shared bucket, simply select a workflow (from among any defined in your CI, automatically pulled in by Runway), a branch, or some combination of both.

Standalone or tightly integrated with the rest of Runway

Exactly how you leverage Build Distro is up to your team. You can spin up Build Distro by itself and use it as a standalone tool. Or, for a tightly integrated experience across the entire dev and release cycle, Build Distro plugs seamlessly into Runway’s end-to-end release management platform as a beta integration, allowing you to manage everything to do with pre-prod builds and testers alongside the rest of the release context.

With Build Distro, the Runway platform is unlocking yet another aspect of a more collaborative and streamlined mobile development experience for teams — not just for engineers, but for each and every role and stakeholder involved. We would love to hear your thoughts, and invite you to reach out for a personalized, guided tour!

And stay tuned for more: our roadmap includes Build Distro iterations that will tackle things like provisioning and signing, triggers and other bucket-level automations, and even more ways to create and share one-off dev builds.

Original source Report a problem

Quickstart CI/CD by Runway

Mobile CI/CD should be table stakes. And yet, despite all the nice GUIs and workflow builders, and despite the awesomeness of fastlane, many teams still struggle to get a basic end-to-end pipeline stood up. It’s not their fault: even with the GUIs and workflow builders and fastlane, everyone still has to reinvent the wheel. To get up and running, you need to know how to piece together the right build and deploy steps, gather the right configs, store the right secrets and store said secrets securely, perhaps even write some Ruby and YAML in whatever provider’s particular syntax-of-choice…

What makes matters worse is that, for the particular kind of team that tends to be making the jump from not having CI/CD to having CI/CD, it’s extra work on their plates coming at the worst possible time. These are usually smaller teams, perhaps teams anticipating or already experiencing growth. They have extremely limited bandwidth and a need to prioritize product work above all else. They likely don’t have mobile infra experts in-house who can spin up new tooling in their sleep. So, a tricky catch-22 presents itself: teams find themselves wanting CI/CD to help streamline their mobile practice and unlock growth, but the non-trivial effort to get CI/CD in place is hard to prioritize relative to critical product work. It’s exactly this catch-22 that explains why so many teams out there are still building locally and distributing manually.

At Runway, we think mobile CI/CD should be the easy part — a true out-of-the-box unlock.

At Runway, we think mobile CI/CD should be the easy part — a true out-of-the-box unlock. With the build piece out of the way, not only can your team stay focused on product work, but you’re able to move on to even more impactful tooling and process improvements when you’re ready for that. The Runway platform is already helping teams with the latter, and we’re excited to announce that we can now help with the former too!

Introducing Quickstart CI/CD by Runway

Introducing Quickstart CI/CD by Runway, a free standalone tool that autogenerates complete, end-to-end build-and-deploy workflows for Android and iOS. If you don’t yet have a CI/CD pipeline for your app — or want to replace an existing flaky one — run the Quickstart CI/CD wizard to get up and running in minutes. There’s no lock-in to worry about, and you’ll be able to build on top of the pipeline as your needs grow. Under the hood, Runway is assembling all the necessary steps, configs, and secrets (and storing those securely for you!), then generating CI-native config files to merge straight into your repo or take with you wherever you like.

How does Quickstart CI/CD actually work?

• Runway connects to GitHub* and App Store Connect or Play Console for you
• We pull together all the necessary configs by scanning your repo and querying the stores
• Runway autogenerates everything you need — a GitHub Actions* workflow file, a fastlane Fastfile, and a Ruby Gemfile — and optionally opens a PR adding all of these right into your repo, ready for use.
• That’s it! Head to GitHub Actions to trigger your new build-and-deploy workflow.

• Initial support for GitHub and GitHub Actions to be followed by other providers.

Read on to learn more about the inner workings of Quickstart CI/CD, or if you’re ready to dive right in, you can get started for free below!

Don’t have a CI/CD pipeline for your mobile app yet? Struggling with a flaky one?
Try Runway Quickstart CI/CD to quickly autogenerate an end-to-end workflow for major CI/CD providers.

Step 1: connect to GitHub

After selecting a platform (Android/iOS), you’ll connect Runway to your GitHub repository using an easy OAuth flow. Connecting GitHub will allow the Quickstart wizard to scan your project files and extract all the necessary configuration details for the build-and-deploy workflow, so you don’t have to dig around for and set them yourself.

Step 2: connect to App Store Connect or Play Console

Next, you’ll connect Runway to App Store Connect or Play Console. Runway uses this integration to grab additional details about your app that are needed for the workflow: things like your bundle identifier or package name, active provisioning profiles for iOS, etc.
During this step, Runway can also optionally upload the API keys your workflow will be needing to talk to App Store Connect or Play Console for certain steps (e.g. uploading your new builds to the stores). We use GitHub’s encrypted secrets functionality for this to keep everything secure.

Step 3: Quickstart scan

This is where the Quickstart wizard really gets to work, scanning your project files and app store records to pull key values and settings needed for the workflow’s configuration. You’ll get a chance to confirm that everything looks good with the resulting output. In some cases, Runway will surface multiple options for certain fields like build target and build type – be sure to select the option you normally use when preparing builds for app store distribution.

Step 4: Signing secrets

Next, you’ll upload the required signing certificates or keys to GitHub. As before, Runway uses GitHub’s encrypted secrets for this so everything stays secure. With these uploaded and safely stored, your workflow will be able to properly provision and sign your builds for distribution.

Step 5: Final YAML and commit to repo

The Quickstart wizard now has everything it needs for your build-and-deploy workflow files. Runway will generate a GitHub Actions YAML file which defines your workflow, a fastlane Fastfile to configure and run your builds, and any additional files needed to install fastlane and set it up properly (e.g. a Ruby Gemfile). You can choose to automatically open a pull request to get these files straight into your repo, or download them instead.

Step 6: Profit! And run your workflow

Once all of the files the Quickstart wizard autogenerated for you make their way into your repo (via Runway PR or manually), head over the Actions tab in your GitHub repo, find your new build-and-deploy workflow in the left hand menu, and click “Run workflow” to see it all in action!

Original source Report a problem

When you’re monitoring an app rollout post-release, you’re in the hot seat. Your team is relying on you to make sense of a tangle of different indicators of release health, across multiple tools, and perhaps with input from multiple other teams and stakeholders as well. You need to continuously digest all of those inputs and be ready to make a big call — to halt the rollout if needed — without hesitating. If you’re lucky, your team shares rollout responsibilities around, to reduce mental load on any one individual, but the exercise is still the same complicated and fragile puzzle.

Rollouts are hard because they’re simultaneously complex and mission-critical.

Rollouts involve many moving pieces, in tools and data and stakeholders collaborating, and your team has to get them right, each and every time — otherwise the negative impact to users can be huge. Without a single source of truth, rollouts typically involve bouncing between different dashboards and looping in other team members who have access to the right tools, and the know-how to interpret that particular data. For example, while engineers are usually the ones monitoring crash data, it’s often product managers who own analytics and who understand expected user behavior. Both inputs are crucial. And despite the complexity of the tools and data, interpretation and action on signals of release health has to be quick and confident. Teams can’t afford to lose any time in halting a bad rollout before it affects even more users.

Rollouts by Runway: a single source of truth for release health, instantly understandable – and actionable

As former mobile engineers ourselves, the Runway team has experienced the challenge of rollouts firsthand — and now, we’ve built something that can help. We’re excited to announce Rollouts, a new part of the Runway platform that helps you navigate rollouts with less collective stress, and more confidence. Rollouts allows your team to easily keep tabs on release health in just one place instead of many, alerts you whenever configured metrics become unhealthy, and safeguards release health by automatically halting rollouts based on thresholds you define.

Rollouts integrates with the mix of different tools you use to measure app health – crash reporting, observability & product analytics, the app stores (for per-version user ratings) – to create a single source of truth and unified dashboard that gives your team a holistic and instantly understandable view of release health. No more context-switching, no more mental overhead, and no more bugging other folks on the team to dig up and interpret data for you.

Across all tools and every metric, you can configure granular thresholds that together define what “healthy” looks like for your team. Runway will surface a crystal clear view of how each release is tracking relative to that definition. With expectations around health codified this way, there’s no room for ambiguity or hand-waving when it comes to your team’s standards for quality of the product you’re shipping.

The moment any of your configured metrics become unhealthy during a rollout, Runway will alert your team, in specific channels of your choosing and with full context on which metrics are problematic. This helps prevent blind spots and delays: you can be confident that no bad trends will go unnoticed, and that bad releases can be acted on more quickly.

To safeguard and streamline rollouts even further, Runway’s rollout automations can automatically halt unhealthy releases, or even accelerate healthy ones. If any metric falls afoul of one of your defined thresholds during a rollout, Runway can automatically stop the rollout and alert your team. Conversely, if all of your metrics are looking good and your rollout has reached a critical mass of users you define, Runway can accelerate things and release to all users. These automations prevent delays and human error during a critical part of the release process, when the consequences of a bad release making it out to even more users are serious — and when getting a good release out to all users more quickly can be equally impactful.

Rollouts is a key next step in furthering Runway’s mission of helping mobile teams build and ship better products, more collaboratively, and we’re excited for everyone to try it out! Let us know what you think, and feel free to reach out for a personalized, guided tour!

Original source Report a problem

Runway raises $2M seed, launches its air traffic control system for mobile app releases (TechCrunch)

Today, the Runway team is incredibly proud to announce that we’ve raised seed funding to help us build on the foundation we’ve already laid and accelerate towards our expansive vision of better releases for the mobile world. And, to that end, today we’re also announcing that Runway is launching out of private early access mode and opening up to all mobile teams! We’re thrilled to now welcome all comers to the Runway platform, and we’re grateful to be propelled into this next chapter with the support and belief of our funding partners in this round (among them Bedrock Capital, Array Ventures, and Chapter One).

Seeing the impact we've already had on our early adopters over the past year has cemented our dedication to this Runway project, and we’re excited to continue the journey alongside more amazing mobile teams.

We’ve lived through the releases pain point ourselves

Our co-founders Gabriel, Isabel, Dave, and Matt first met nearly 10 years ago on the nascent iOS team at Rent the Runway, charged with designing and developing the company’s first ever mobile app. We each had some prior experience with mobile, but it was our first taste of working on a cross-functional team with a full complement of (multiple) engineers, a product manager, design, and QA. We quickly clicked and became a close-knit group entrusted with a ton of independence to steer product strategy and build something we believed in.

The app was a huge success, and it quickly became the company’s flagship platform — both from a user perspective and, crucially, from a business standpoint too. The opportunity that the app presented, along with the exploding popularity of mobile e-commerce in general, meant that there soon had to be more players involved. And so, gradually, the friction and overhead that comes with mobile at scale crept up on us — juggling the contributions of more and more decentralized feature teams, tackling a larger roadmap, and aggressive release calendars, and scaling up resources to meet all of these new challenges.

Some of us eventually left for other mobile teams, but we kept encountering the same issues — particularly when it came to releases. Among the constants we observed: back-and-forths on Slack to get everyone on the same page around release time; disappearance of teammates into the void when it was their turn for release manager duties; and lots of unnecessary waiting around, missed deadlines, and buggy binaries. Looking back, it’s obvious that we were (individually and collectively) living through the growing pains of a mobile space that had found itself explosively evolving. What had been a casual side project for most companies became seemingly overnight a critical platform that demanded serious resources and planning and tooling.

Of course, knowing a pain point exists isn’t the same thing as solving it. Back then, the challenges were so new that a lot of our teams didn’t fully realize that the pain point existed, but even now that there’s more awareness, real solutions remain elusive. Too often, the terminal conclusion is: releasing a native mobile app built by a team is complicated and frustrating and difficult, and that’s just how it is.

Building the solution

Coordinating teammates is hard. Keeping up with little changes in Apple and Google’s submission tools and rules is annoying. Writing elaborate scripts, adding headcount, or even building entire in-house platforms are possible approaches to the problem space, but only if you want your engineering org to be in the release management business (at least part time). Scripts need to be maintained, knowledge gets siloed and lost, and every team-member-hour you dedicate to solving release management is a team-member-hour not going towards the stuff you’re releasing.

When we first started building Runway, our conviction came from the knowledge that we were building the tool that we wished we had on those old mobile teams of ours. That initial conviction remains strong, but it’s now augmented by a year of insights in the trenches with scores of other mobile teams. Our early adopters in particular have come to rely on Runway to make their releases less of an event, and continuously challenge us to expand and refine our vision.

We’re excited to now bring Runway to the wider mobile world, delivering that same impact and helping even more teams redirect their energy and resources away from releases, and back to where they belong — building great apps. We can’t wait to see more teams grow alongside and level-up with Runway, and we’re humbled to have the opportunity to learn from everyone’s experiences and build those lessons into the future of the platform. If you’re already with us, our genuine thanks, and if you’re just joining us, welcome onboard!

Gabriel, Isabel, Dave, Matt, Ale - The Runway team

Original source Report a problem