Runway Release Notes

Org overview revamp with custom dashboards and AI-powered insights

With everything that's changing in how engineering teams build, measuring performance and tracking trends is more important than ever — not just as they relate to your apps and their health, but also your team and how you all operate and collaborate. We reworked the organization-level overview in Runway to pull in even more data, give you more ways to drill in and view trends over time, and help you understand if what you're looking at is normal or needs attention.

You can now customize your Org overview dashboard, rearranging and resizing charts and selecting exactly which metrics you want to surface. Date filters are much more flexible now, you can adjust the aggregation of certain data, and there are new types of filters that allow you to drill down by apps, platforms, teams, and team members where applicable. The different charts available to you have expanded, with new options that include:

• Checklist, approval and regression item completion rates (How often is your team actually actioning requisite tasks in your process? How often are test cases passing?)
• Target date hit rates (Do you tend to kick off, submit, and release on time? Where do delays tend to crop up?)
• Cherry-pick volume and acceptance rate for late fixes (How many changes does your team add post-cut? How often are late changes pushed back on?)
• Any or all of the stability and health metrics you have configured for rollout monitoring (How are key health metrics tracking over multiple releases? What are the baselines that should inform where you set your alerting and automation thresholds in the rollout context?)

To help you actually make sense of all this data, we now surface benchmarks sourced from comparable teams and summarize key changes and trends in AI-powered insights at the top of the page, which link directly to the specific charts they concern.

Build size alerting

It can be hard to keep tabs on binary size release to release, and even small increases can affect download and install metrics. We’ve added a new type of notification that monitors build size and alerts you if build size increases beyond some allowable threshold compared to your previous release. You can configure the threshold as a percentage or absolute delta, as well as choose to be alerted for all builds that surpass the configured threshold or only the first build in a release that does so. You also have the choice of monitoring download size (Android and iOS), install size (iOS only) or both (iOS). On the iOS side, you can choose a specific device model to monitor if your team prefers that to Universal, and you can also configure an additional alert that fires if your bundle is approaching Apple’s 200 MB cellular download limit.

Support for Claude as AI provider and BYOK

Runway’s AI-related features (e.g. Release ATC, user reviews analysis and translation, release summaries, org overview insights) were previously built on top of and tightly coupled with the OpenAI API. We abstracted that dependency away and now also offer Claude as an alternative provider. Your team can configure your choice of provider in org-level settings, and you can now also drop your own API key in there if you prefer to BYO.

Chat with Runway Release ATC anywhere, not just in DM

Many of you are already chatting with Runway's Release ATC chatbot in DM, asking it for release info, status updates, and even having it handle certain release tasks for you. We wanted to make this kind of interaction available beyond the confines of a one-on-one conversation, so you can now pull Release ATC into any channel or thread and leverage it as a team. The same granular permissions apply, so you can be confident that anyone taking write actions will only be able to do what they’re allowed to do.

Configure automations per release type

Previously, automations supported a single configuration which would apply for all release types — normal releases, hotfixes, and rollbacks alike. We’ve now shipped changes that allow you to configure automations discretely per release type, determining not just whether they’re enabled or disabled in those different contexts, but also controlling any automation-specific options that a given automation offers. For example, you might want your auto-submit automation to run with one set of trigger conditions for regular releases and a lighter set or even full “submit on green” for hotfixes. Or, set up a shorter customized staged rollout schedule for hotfixes and disable staged rollouts altogether for rollbacks.

Just-in-time, automatic re-signing to allow new devices to install ad hoc builds

Apple doesn’t make it easy to distribute ad hoc builds, and all the overhead involved in registering devices and managing provisioning profiles and signing discourages teams from doing as much with internal distribution as they otherwise might. Runway’s automatic device onboarding and management as well as provisioning profile regeneration already help remove a lot of the friction, and our latest Build Distro re-signing automation eliminates much of the remaining complexity. Now, if a user tries to install a build with a new device which wasn’t included in the provisioning profile that build was originally signed with, Runway can detect that, sync the device and generate a new provisioning profile if needed, then re-sign the original build and redirect the user straight to install. The whole process typically takes a matter of seconds.

Automatically manage a dynamic release pilot Slack handle

Many teams maintain a Slack handle for their rotating release pilots so team members can easily ping @ios-pilot, for example, and reach the right person without needing to hunt them down. This normally requires constant manual work to assign and reassign the right pilot at the right time, but Runway can now manage a pilot handle for you, automatically updating the associated Slack user based on your release schedule and pilot rotation while also accounting for any swaps or schedule changes.

Build Distro improvements: new filtering for bucket rules, custom bucket ordering, easier navigation on mobile, and more

We shipped a number of changes in Build Distro to give teams even more ways to group builds automatically, get builds in front of the right audience, and improve the experience on mobile. On PR-based buckets, you can now configure filtering based on labels, automatically including or excluding builds associated with PRs that have (or don’t have) certain labels set. We’ve also added the ability for teams to set an explicit ordering for their Build Distro buckets in the main bucket list view — for now this is configured on our backend, so reach out if you'd like your buckets reordered! Testers accessing Build Distro on mobile will find improved navigation including a search bar to help with switching between a large number of apps. And, teams that push builds up to Runway via our API can now optionally include PR info in order to take advantage of the additional functionality that’s otherwise available with a fully-integrated, PR rule bucket (e.g. the automation that posts build info and install links as comments on the corresponding PRs).

Redesigned main navigation

We reworked Runway’s main sidebar to make navigation around the platform faster and more intuitive, especially for organizations with many apps and for stakeholders who need to manage releases across multiple platforms. Now, you should be able to navigate between any apps in your org and any releases within those apps in just one or two clicks. The new navigation also makes it easier to jump up a level and access key areas like Org overview and Org settings.

Share public install links in build notifications with configurable expiration

To make it easier for folks who aren’t Runway users to get their hands on certain test builds, you can now optionally add public install links to the notifications that are sent when new internally distributed builds become available. To keep things secure, you have the new option of adding expiries to these links, either based on number of installs, time elapsed, or both.

New Feature Readiness filter to view changes in specific builds

Runway’s Feature Readiness view is your single source of truth when it comes to the work your team is shipping with each release, pulling together code changes, project management tickets, build info and more. But teams often want this kind of complete picture not just for the full release diff, but also to visualize changes from build to build over the course of a given release cycle. The new “Item is new in RC build” filter now lets you do just that, surfacing only those changes which were new in any specific build you select.

Expanding our MCP server and public API with new tools and endpoints

We’ve shipped a number of new tools for Runway’s MCP server, as well as new endpoints for our public API. On the MCP side, you and your favorite agent can take additional actions like setting and updating the selected app store build for any release, query adoption rates by version, and pull any and all health monitoring metrics found within a release’s Rollout view or across multiple releases via Org overview. On the Runway API side, we’ve added endpoints that allow you to create regression testing items as well as update their status and add comments (useful for integrating with external automated testing tools). There are also new endpoints for pushing user roles and groups to Runway (helpful for teams using AWS IAM or other identity providers that aren’t compatible with Directory Sync) and for uploading app icons when provisioning new apps via Runway’s config-as-code. To help you stay on top of rate limits and usage across your team, we now show consumption per API key in Org settings.

Set notification channels per checklist item

Previously, notifications related to checklist, regression testing, and approval items (e.g. for status updates and commenting) were all directed to a single channel configured in app-level notification settings. You can now configure a specific channel override in each individual item’s settings, and all comms related to that item will go to the selected channel. This is particularly useful for routing reminders and updates to the right stakeholders — e.g. marketing sign-offs to #marketing, leadership review to #mobile-leadership, specific testing gates to the right QA group, etc.

More flexibility in AI-generated release notes with customizable prompts

There are a few places in Runway where you can leverage AI to auto-generate a release summary or release notes based on the changes (both code and project management tickets) shipping with the release. Our built-in prompts are tuned for this purpose, and we offer a couple of different defaults (e.g. targeting internal versus external audiences). But to give teams even more control over the end result, we introduced the option to add additional text to the prompts that are used, so you can adjust content and tone as needed.

Require multiple approvers on fix requests

For teams with stricter sign-off requirements on fix requests — e.g. if you need both a tech lead and a product owner to OK late changes before they’re pulled into a release — you can now configure multiple approvers per fix in your fix request settings. In the Feature Readiness step fixes will surface at-a-glance progress towards approval completion, and for notifications you can choose whether to be notified for each approval (or rejection) that comes in or only when the overall approval status changes. Either way, every individual approval action is captured as a timeline event so you have a full audit trail.

Tag user groups in Microsoft Teams notifications

For teams leveraging our Microsoft Teams integration for notifications, you can now @mention user groups via tags. Based on a mapping you define between your user groups in Runway and tags in Teams, Runway will expand any group mentions you add to notifications (which can be configured per notification type and on things like checklist or regression items) to ping the right folks on the Teams side.

More options for managing access control with app membership inheritance from user groups

To make it easier to manage your team’s access in Runway, we added the option to have a user’s app membership inherit from the user groups they are a member of. In user groups settings, you can now map a given user group to one or more apps in your org. Any users who are members of that group will also be automatically granted membership of the corresponding apps, removing the need to configure both user groups and app membership separately for each user.

New integrations: Statsig, Rootly

Statsig joins LaunchDarkly and Optimizely as a supported feature flagging integration in Runway. Once connected, like with those other integrations, Runway will surface a focused list of relevant flags alongside each release with status, targeting rules, variations, and other context included. Runway diffs this flag data over time to capture any and all changes, then overlays that info on top of rollout metrics charts to help you spot app health issues that are caused by flag updates, not just new binaries.

We’ve also added Rootly as a supported scheduling integration. Similar to our other scheduling integrations, Runway will sync with your on-call schedules and map those to your release pilot rotations in the platform, automatically assigning pilots to releases and handling swaps or schedule changes where needed.

Original source

Introducing Flightpaths by Runway

Mobile release management built around your team, your apps, and your process

Every mobile organization has its own unique setup, and its own unique way of releasing. Maybe you ship native Android and iOS apps side by side, or “build once, release twice” with a cross-platform app, or work on a single codebase that powers dozens—or even hundreds—of white-label variants. On top of that, no matter what kind of apps you ship, there’s the particular process any given release needs to follow from dev to staging to prod, with various checks, approvals, and hand-offs along the way. Mobile release complexity compounds and, at a certain scale, release processes and tooling that are subpar—or even “just fine”—have a real negative impact on your team’s productivity and happiness, and on the quality of the apps you ship.

Runway first came about to tackle those challenges, and the platform is now better positioned than ever to accomplish that, for even more kinds of mobile teams. Flightpaths unlocks entirely new ways to set up, manage, and automate your end-to-end release cycles. Your team has complete control, with the ability to rearrange release steps, leverage multiple steps of the same type for different parts of your cycle, and define more complex dependency graphs between steps. Under the hood, it’s a complete re-architecture of Runway designed for flexibility at scale, allowing teams to consolidate apps into shared overviews and pipelines, delivering unified visibility and enabling batch actions and automations across however many apps.

Monitor all your apps and releases in one place

With Flightpaths, you can now keep tabs on everything to do with releases, across all of your apps, in one place. A new tabular view pulls together release status and milestones, build information, app store review and release updates, rollout progress, and any other key pieces of information you choose to include, giving you a complete, at-a-glance overview of releases across your entire org.

For multiple apps that share a single release workflow—for example, the Android and iOS constituents of a cross-platform app, mobile and wearable packages for a given product, or the various branded flavors of a white-label app—there are new summary views at the release step level that consolidate information about each respective part of the release process. This gives your team clearer and quicker insight into where action may be needed, and not only eliminates the need to bounce between tabs in App Store Connect and Play Console, but also between different apps in Runway.

Take actions in bulk across all your apps

While Runway was already positioned to save you quite a few clicks throughout the release process, irrespective of the kinds of apps your team ships, Flightpaths takes that to the next level by enabling bulk actions across multiple apps. Instead of navigating into individual apps to submit to the app store or to halt a rollout, you can take these sorts of actions across multiple apps or platforms at once. Select all or just a subset of apps within a given workflow, depending on the use case, and skip the usual tab- and context-switching. This is especially powerful for cross-platform and white-label teams, turning dozens or hundreds of clicks into just one or two and removing the need to juggle credentials or sign in and out of app store accounts. Of course, where it makes sense in your release process, you can still also configure automations across all your apps to reduce manual clicks to zero!

Customize every step of your release process

In addition to unlocking new ways to centralize and streamline releases across apps, Flightpaths enables powerful customization at the release level itself. You can now configure Runway’s release steps to perfectly suit your team’s unique process and get as close to fully-automated as you want to get, with just the right gates and checks in place and with visibility throughout. You can now leverage any given Runway step type in multiple locations in your workflow—for example, to monitor the stability and health of pre-production builds during beta distribution, in addition to production rollouts; or to hook into various different CI workflows, covering not just release candidates but also end-to-end tests or other pre-prod build flavors. With this, Runway also now lets you configure specific dependencies between steps to ensure the flow of release data and execution of automations is fully representative of your team’s process.

Define a release blueprint once, reuse as needed

One of the most powerful aspects of Flightpaths is the ability to configure a centralized definition of your release process and apply that across any number of apps, while still leaving room for one-offs and app-specific behavior where necessary. By enabling shared settings for everything from release schedules, to step automations, to rollout safeguards, you can codify a standard release process across apps to increase efficiency, reduce tech debt and process drift, and generally make stakeholders’ lives easier in the process. Where certain teams or products need to ship differently, you can configure that—you get shared structure where it makes sense, and app- or platform-specific flexibility where you need it.

Built for every kind of mobile (and mobile-adjacent) team

Whether you're managing hundreds of white-label apps, building cross-platform and releasing Android and iOS together, or shipping multiple native products across a complex mobile org, Flightpaths can match your unique use case and make releases a non-event.

For white-label teams, Flightpaths helps you scale while dramatically reducing the overhead that comes with each release cycle. Bulk actions and automations save you from repetitive clicks, and dedicated overviews show you every white-label app's status at a glance.

For cross-platform teams, Flightpaths lets you realize the full efficiency of building cross-platform in the first place. Define a unified release blueprint that spans both platforms, manage the entire release lifecycle in one place, and ship new versions without needing to set foot in App Store Connect or Play Console.

For mature teams with complex releases, Flightpaths allows you to customize Runway to perfectly capture all the different steps and dependencies that exist in your release process. Whether you’re shipping for mobile, TV, wearables, auto or all of the above, you can manage and automate releases exactly how you want to.

With Flightpaths, our goal is the same as it’s ever been: help mobile teams release their apps with less wrangling and safeguard app quality in the process. Now, Runway is positioned to deliver this for even more use cases and to enable teams to get even further down the path to mobile release excellence.

To check out the new experience firsthand, head to our sandbox or schedule a live tour with our team!

Original source

Release ATC: an AI-powered chatbot for release info and actions

We're very excited to announce Runway's new Release ATC: you can now chat with the Runway Slack app in DM to get all your release questions answered and even take actions on releases.
We wanted to make it dead simple for anyone on your team to access everything Runway knows about your releases and to handle tasks needed to move release cycles forward—without them having to leave the one tool they use most for day-to-day collaboration and communication. Access is scoped by Runway's granular user permissions, so everyone automatically has the ability to do exactly and only what they're allowed to do, with no extra oversight needed.
To get started, just open up a DM with the Runway Slack app and say hello!

New tabular views to see release data across multiple apps and releases at a glance

We've rolled out a new style of tabular view at both the org and app level that lets you quickly scan release information and status across multiple apps and releases—even dozens of them—all in one place. You can customize exactly what data is shown, making it easy to focus on the metrics and information most relevant to your team. This is especially useful for stakeholders who need the bigger-picture view across a mobile org, and for cross-platform teams or those that manage whitelabel apps.
Currently available in closed beta — reach out if you’d like early access.

Add custom content to any notification

Sometimes you need to include additional context or instructions in the notifications Runway sends, beyond what’s included by default. You can now append custom text to any notification, and with Runway’s pattern tokens this custom text can be dynamic, allowing you to pull in relevant information like build numbers, release pilot names or even work item diffs.

Powerful new options for customizing how and when automations run

You now have much more control over Runway’s automations with a number of new ways to configure them beyond their default behavior. Target deadlines can be set per automation such that they trigger at specific times relative to your release milestones – for example, run a particular CI workflow four hours before your scheduled submission, or start auto-assigning testers to beta builds 12 hours after your release kicks off. Or, configure gating conditions that require previous release steps to be completed before an automation proceeds. You can also combine both approaches, running an automation with specific timing but only if certain steps are “green”. And, you can now also control which release types a certain automation can run for, giving you even more ways to segment your process between normal releases and hotfixes.

More ways to filter Feature Readiness for monorepo teams

Because the Feature Readiness view in Runway defaults to showing a full release diff—from previous tag to HEAD of the release—teams using monorepos will find that a lot of items unrelated to the app in question are included. In addition to the filtering that’s already possible via the Feature Readiness UI, there’s a new way for monorepo teams to configure more permanent filtering that will cause Runway to only surface items whose commit messages, PR titles, or PR labels contain certain keywords. Unlike the UI-based filtering, this also ensures that downstream automations on Feature Readiness (e.g. auto-applying labels or fix versions to project management tickets) only act on the correct subset of items.

Automatically pause your release schedule and automations during code freezes

Are you a retail app heading into Black Friday or a sports app heading into the Super Bowl? Instead of needing to manually disable your release schedule and related automations (e.g. auto-kickoff, submit, and release) in Runway, you can now configure “lifecycle freezes” that will automatically put your train on pause during selected dates. Once outside the window, Runway will either resume the in-progress release or kick off a new one based on your schedule.

Safeguard build selection based on regression testing results, and more options for regression testing behavior

Runway’s automatic app store build selection is an efficient, hands-free way to ensure you’re always ready to submit, but if your team tends to distribute many builds to the stores, you need to be very clear and careful about which one is the final RC that you want to ship. You can now configure the build selection automation to “lock” to whichever build is selected and marked as passed on the Regression Testing step, rather than always defaulting to the latest available build.
To give you more ways to manage how regression works within Runway, you now have four different options for how the Regression Testing step behaves when it comes to builds and statuses. You can choose to have the step clear the currently selected build and regression status whenever a new build is detected, automatically update to any new build and reset status to "In progress," keep build and status selection manual, or disable explicit build and status selection entirely and let Runway determine the overall regression result based on individual regression testing items you’ve configured.

Early warnings and more control over rollout health alerting

We’ve made some updates to our popular rollout health alerts to give teams an earlier indication of impending problems and to help avoid any signal-to-noise issues. Now, for any given health metric you have configured, you can opt in to receiving warning notifications if they approach within 10% of their unhealthy threshold, in addition to the usual alert if they actually cross into unhealthy territory. In the notification’s settings, you can also configure exactly when these alerts should start sending based on adoption percentage or day of rollout, allowing you to fine tune your signal-to-noise ratio based on sample size.

A new, more configurable strategy for automated backmerges‍

Runway’s backmerge automation now supports a third backmerge strategy. In addition to options to backmerge all changes once at the end of the release cycle or backmerge continuously per change, you can choose to cherry-pick changes continuously from the release branch to your working branch branch. This approach gives you more control: you can configure the automation to skip certain kinds of pull requests (e.g. late changes that were pulled over from your working branch in the first place), or skip changes that affect certain file types that you don't want backmerged (e.g. avoid backmerging unsquashed PR commits in favor of the merge commit only). As always, if merge conflicts occur, Runway will notify you and create a timeline event so you can resolve and move on.

Bookmark-friendly URLs that automatically resolve to the right release

For folks that want to save quick links to their most top-of-mind releases—perhaps to add to some internal documentation, to pin to a Slack channel—a new kind of dynamic URL is available. Instead of bookmarking and then re-bookmarking specific releases, you can now use special path parameters like next and live to always be taken to the correct place. For example, …/releases/live/rollout/summary would always take you to your current version’s rollout page. For folks that are in-office, this is especially useful for throwing Runway dashboards up on a big screen.

Manage release checklist items at the org level for all of your apps

To make it easier to manage parts of your release process that should be standardized across multiple apps, you can now create and edit checklist items at the organization level. Org-level checklist items automatically populate to all releases across all apps in your org, eliminating the need to manually recreate checklist items that each app has in common and keep all of those updated if they need to change along the way. This is particularly valuable for teams with standard compliance, legal, or other sign-off tasks that should be part of the release process for all apps.

More ways to pull fixes into releases and manage the fix lifecycle

We’ve enhanced Fix Requests and cherry-picking in Runway so teams can pull in fixes earlier in the development lifecycle, track those fixes more easily, and clean them up with less manual effort. First, you can now get fixes on the radar as soon as you know they’ll be needed for a particular release—well before work on them has necessarily started—by selecting from among any and all project management tickets in the fix creation flow, not just those already associated with the release and regardless of whether code changes already exist. If needed, Runway can also automatically apply the appropriate fix version or label for the release in question when you create a fix this way.
Other changes make it easier to manage and track the lifecycle of fixes. Now, if an engineer removes a cherry-pick token from the title of a PR associated with a fix (maybe the fix is no longer needed or it won’t be shipping with the release in question), Runway will automatically remove the fix and post a timeline event explaining what happened. In situations where multiple project management tickets are referenced by the same code item and that code item is part of a fix, Runway now associates both tickets with the same fix, rather than creating separate fixes for each ticket. This prevents issues where duplicate fixes could be out of sync or where PR status checks might be overwritten.

New integrations: Apple Power & Performance Metrics, Jira Service Management

We have a new 'Observability & Analytics' integration available. Connecting Apple Power and Performance Metrics in Runway allows you to monitor launch times, memory and battery usage, terminations and more, and configure alerting and rollout automations based on defined thresholds. This gives you another data source to help catch performance regressions before they impact your users.
If you use Jira Service Management for on-call scheduling, Runway can now integrate with JSM to automatically manage your release pilot rotation based on your JSM schedule. This requires that you also have Jira connected as a project management integration, but once set up, your release pilot assignments will automatically stay in sync with your broader on-call schedule without any manual updates needed.

Even more granular app-based access control

By default, all users in a Runway org have at least read-only access to every app in the org. For many teams this works well, since they don’t mind that all teams and stakeholders are able to see what everyone else is up to, even if they’re not directly involved in a given app’s releases. But we also understand that there are situations in which a team would want app access to be locked down more. Building on top of Runway’s app membership functionality, we’ve introduced a new optional setting that, when enabled, requires that a user be a member of an app in order to even view any of that app’s data. If a user does not have access to a given app, they won’t even see it in Runway’s navigation.

Automatically pull a previous submission when skipping a release

The “skip” functionality in Runway offers a quick way to move past a given release cycle if you’re no longer going to ship that version to prod (if a critical bug was identified during regression, say, and you’ll fix forward in the following release instead of delaying the previous). There are a number of automations that run when you skip a release, to ensure that state is correctly cleaned up across all the tools involved, and we’ve added another option to help you move past a problematic release even more seamlessly. Now, when skipping a release on the Apple side, you can have Runway automatically pull any previously submitted build, since that would otherwise block your ability to move on to the next version.

More accurate release calendar predictions for accelerated rollouts

The release calendar views in Runway – and resulting data synced to your team’s internal release calendar, if integrated – are designed to not only surface concrete release milestones but also upcoming release and rollout timing based on historical data. This is especially helpful for managing stakeholder expectations around version availability, but for teams with Runway’s rollout acceleration automation enabled, the calendar’s illustration of rollouts could be misrepresentative. Now, if your team has Runway configured to accelerate stable releases to 100%, the release calendar will factor that in and display the optimistic rollout schedule assuming acceleration (with messaging alongside to make that clear).

More ways to navigate automation and notification settings

We understand that managing your Runway automation and notification settings can be tricky, especially as our list of available automations and notifications grows. To help with this as well as improve discoverability of new automations and notifications your team may want to leverage, we added new sort options to Runway’s automation and notification settings pages.

Original source

Get release info and take actions right from your favorite AI agent with our new MCP server

There’s a powerful new way to integrate with Runway and manage your releases through our MCP server. You can now point Cursor or Claude or [insert your other AI agent of choice] to Runway and ask questions like "What's our next scheduled release?", "How healthy is our latest app version?", and "Which team members are part of the Checkout user group?" You can also tell your agent to take actions: "Update the current release's regression testing status to 'passed'", "Add 'Here's what to test' as tester notes on our latest nightly bucket build", or "Complete the 'Sync with marketing' checklist item for our next iOS release." Access to MCP tools is granularly scoped just like our API, so you can give just the right level of permissions to different team members. See our docs for more info.

Workflows project: support for CI, Metadata, Screenshots, and Rollout steps

As a reminder, our ongoing Workflows project is a wide-ranging rebuild of Runway’s foundations, unlocking many more ways to configure and customize the platform to cover new use cases and different ways of releasing. We’ve shipped another set of important release steps under the new Workflows experience, with support now for multiple CI, Metadata, Screenshots and Rollout steps in a single release sequence. Arrange steps in parallel to streamline cross-platform or whitelabel use cases, where you might want to manage metadata and screenshots across multiple stores in one place, for example. Or you can add multiple steps in serial, to integrate different CI workflows at different stages of the release lifecycle, or monitor both beta and production rollouts.

If you’re interested in trying out the Workflows beta for your apps, get in touch!

Minimize the long tail of users stuck on old versions by automatically accelerating prior releases to 100%

Depending on your team’s release cadence, it’s not uncommon to have a given version going live while a previous version isn’t yet out to 100% of users. To avoid exacerbating mobile’s already tricky “long tail” problem and reduce the number of different versions your team needs to support, Runway can help you first accelerate the previous version to 100% (if healthy) before releasing the subsequent one. Now, you can select an option in the release flow that will have Runway accelerate a previous release to all users if not already fully rolled out — whether you’re releasing manually, or leveraging Runway’s release automation.

Get immediate context on new stability issues with event-level data in rollout notifications

We've added even more info to the rollout notifications that Runway sends, now including specific event-level details on crashes and exceptions to complement the aggregate health metrics we already surface and help your team triage emerging issues more quickly. When you enable the corresponding option in the rollout notification settings (enabled by default), each notification will include a bulleted list of new and trending stability issues identified via your stability monitoring integration, complete with descriptions and occurrence counts.

New warnings to help you avoid accidentally shipping without important late-arriving changes

Late-arriving commits can be easy to miss, and it’s important to ensure your team doesn’t accidentally submit (or, worst case, release) an incorrect RC build that was generated before the late changes landed. Runway now continuously checks whether there are newer commits in your release diff that aren’t contained in the currently selected RC and will display a prominent warning on the Submission step if so. The submit button will remain enabled so you can still move forward if needed, but you'll have context to decide whether to select a newer build first. (Depending on your team’s specific workflow, leveraging Runway’s ‘select latest build’ automation could also help safeguard against this kind of situation!)

Keep stakeholders in the loop even if they're not in Slack or Teams — or Runway — with expanded email notifications

Previously, Runway’s email notifications were managed at the user level: to receive emails, you would need to be a Runway user and handle your own notification settings per email type. Now, to make it much easier to send certain comms to people on or outside of your team, you can enable email notifications for any company-owned addresses, whether or not they correspond to a Runway user, and manage those settings in one place alongside the rest of your app’s notification settings.

Reduce noise in Slack with additional threaded notifications

We already support threaded notifications for fix requests, and we’re now expanding threading to other notification types: phased rollout progress updates and notifications related to regression testing items. When the threading option is enabled, notifications that are related (e.g. multiple rollout updates for a given version, or status changes or comments on a given regression testing item) will be sent in a single thread rather than posted as separate messages in your channel. Note that critical notifications like those for phased release halt and resume will use the “Also send to channel” option to ensure maximum visibility.

More ways to generate rollback builds

Previously, as part of Runway’s rollback flow we prepared rollback builds by re-signing an older, stable build. This is a quick and clean approach, but it comes with some limitations for certain teams. Now, there’s an alternative option for rollbacks, allowing Runway to automatically trigger the appropriate CI workflow on the appropriate commit and use the resulting build as it would a re-signed rollback build.

More flexibility and granularity with user permissions

We've introduced several changes to user permissions and RBAC to give you finer control over who can do what in Runway (and your release process). First, you can now customize the permissions on Runway’s default user groups, making it easy to quickly adjust the out-of-the-box options to suit your team's needs. This can be especially useful for teams who wish to adjust permissions for the release pilot role, which can’t be substituted with a custom user group. Additionally, we've split the permissions for starting staged rollouts and updating them, so you can give team members the ability to initiate rollouts but lock down subsequent rollout changes. On the Build Distro side, admins can now assign the “archive build” permission to other users without granting full admin access.

Better handling for edge cases around completed Android releases

Due to some pesky Publishing API limitations, Android releases sometimes require more handling post-completion, so we’ve added some new ways to accommodate that in Runway. Android releases can now be marked as skipped even after they've been completed, giving you more flexibility in managing your release history. We've also added the ability to un-complete an Android release when needed, as long as the version is still on the production track in Google Play Console.

Start a hotfix’s staged rollout at the same percentage as the previous release

When creating a hotfix for Android, you can now choose to start its staged rollout at the percentage at which the preceding release left off, to match the exposure of the version you’re patching. Runway can then further increment the rollout from there, based on the remaining days of your configured staged rollout sequence.

Expanded functionality for pinging owners on Feature Readiness

We've added more ways to streamline the cat-herding that sometimes needs to happen around feature work. With the “ping” action on the Feature Readiness step in each release, you can now choose to ping all owners of work in the release, not just those with pending items. And when you have filters applied, the ping action will respect those filters and only tag owners of the filtered subset of work items. Finally, to help you understand exactly what action Runway will take, the ping action now presents a confirmation modal showing exactly who will be tagged before the notification is sent.

A new way to integrate unsupported or custom CI

We understand that, due to custom setups or certain other technical constraints, some teams are unable to take advantage of Runway’s out-of-the-box CI integrations. There’s new API-based functionality that supports “push” versus “pull”, allowing teams to instead send build metadata and artifacts to Runway and take advantage of much of the same functionality available as when you have CI integrated ‘natively’.

More transparency and control around integration refreshes

On Runway’s integrations tooltip, you can now see when the last automated, full refresh of data ran for each of your connected integrations, and admins and release pilots can also trigger refreshes manually if needed. You'll see new status indicators if a refresh is already in progress or if you've reached a refresh rate limit.

Improvements to the release calendar for easier viewing and clearer context

We've made several updates to the release calendar view to help highlight the most important info and give you more control over the presentation. Skipped releases now have lower priority in the calendar items list so that non-skipped releases will be more visible. You can also choose to hide skipped releases entirely from the calendar view. Finally, the calendar will dynamically reorder items based on which release you're mousing over, making it easier to see relevant context.

Receive Slack notifications for Google Play Console rejections

Rejections in Google Play Console are often slow to get picked up on because the notification emails from Google are often sent to one team member’s inbox, or a shared inbox that’s hard to monitor. Plus, the Publishing API surfaces nothing about rejections. Now, if you have email forwarding set up for your Google Play Console integration, Runway can send Slack notifications whenever your app is rejected during the review process. And, as with any notification type, you can tag specific users or groups to ensure rejections are handled as quickly as possible.

Ability to set in-app update priority for Google Play Console releases

The Google Play Publishing API recently added support for setting the in-app update priority on releases, which is used to indicate how strongly to recommend a given update to users. Leveraging this, you can now set your desired update priority per release without leaving Runway.

Original source

An entirely new way to manage cross-platform and whitelabel releases, and more customization for release steps, with our first Workflows project milestone

Up until now, cross-platform and whitelabel teams have managed releases under separate apps in Runway. While our automations helped streamline things as much as possible for teams fitting into these common use cases, we knew the experience could be made even better for shipping “one to two”, and especially for “one to many”. Our Workflows project has seen us rebuild Runway from the ground up to more naturally accommodate the different ways the mobile world ships apps, not just for cross-platform and whitelabel, but for any team wanting to customize Runway further to fit their way of releasing.

The first big set of Workflows changes to become available in beta allows your team to configure multiple Beta testing, Submission, Review, and Release steps within a given app in Runway. This means a cross-platform team can now set up a unified process for their Android and iOS releases that follows a single pathway from Kickoff until Beta testing or Submission, at which point it splits into platform-specific store steps that allow for managing both sides in one place. Similarly, a team shipping 10s or 100s of whitelabel apps can seamlessly manage releases for all of those in a single workflow.
In addition to “parallelized” workflows like the ones just described, these Workflows changes unlock the possibility of having multiple “serial” steps of a given type. So with the Beta testing step, you can now have more than one of those per release — allowing for a couple of discrete stages of pre-prod distribution, e.g. Alpha and then Beta.
If you’re interested in trying out the Workflows beta for your apps, just get in touch!

Better visibility into automation outcomes with expanded context and coverage on event timelines

Automation is great for obvious reasons, and it’s a big focus in Runway. However, we recognize that increasing automation in your release process can also introduce more “black box effect”, with lots happening under the hood and less immediate visibility into what’s happening, and why (especially when automations fail). Building on other recent changes to event timelines in Runway — the revamped, dedicated timeline view, filtering, and additional events — we’ve expanded the footprint of automations in timelines.
First, given only a small subset of automations were previously captured in timelines, we reworked all of Runway’s available automations to ensure each one is fully captured in timeline data — whether one-off and release-level, or recurring and app-level. We also expanded the kind of data that’s captured and surfaced, to ensure you have full context alongside each and every automation run. In addition to including more info around status, Runway also saves and surfaces the exact settings that were configured at the time the automation ran.

Build out a clearer runbook for your release process with with time-based checklist and approval items

Teams use Runway’s checklist and approval items to capture parts of their release process that can’t or shouldn’t be automated — e.g. certain manual actions or updates that different folks on the team need to take care of throughout a release. You can locate these items in different steps within your release workflow to vaguely position them in time relative to the release cycle. But, the reality is that these kinds of actions often need to be taken at specific moments. You may have a reminder that needs to go out three days before kickoff, and simply having a corresponding checklist item on your Kickoff step doesn’t make that very clear.

Now, you have the ability to attach explicit timing to your checklist and approval items. For example, you could make an item due “two days before kickoff”, “at submission time”, or “one hour after release”. When you attach timing to an item, that timing is surfaced clearly in Runway as a visual reference, and it can also power optional reminder notifications which fire if a deadline arrives and the corresponding item hasn’t been marked complete.

Easily handle more hotfix edge cases, with base selection and freeform versioning

Runway’s hotfix flow is designed to help you get a hotfix up and running as quickly as possible when you need to address a critical issue in prod. You can have Runway cut a hotfix branch off your last tag, immediately bump the version on that branch, and even pull in fixes via automated cherry-picks. There are a few aspects of the flow that we previously constrained to ensure things are quick and consistent, but those constraints made handling certain edge cases less streamlined.
We’ve introduced a couple of changes to the hotfix flow to allow for more flexibility when things go further off the happy path. Now, you can explicitly select the base to cut a hotfix from — so if you need to start further back in history (say you already shipped a hotfix and it didn’t work out, so you want to restart with the ‘parent’ release instead) you have the ability to do that. Also, where Runway would previously hardcode a predicted hotfix version for you, you can now input a specific version number as needed.

Get late-arriving changes on the radar earlier, and ensure you capture the right context around them, with additional options for fix requests

Many teams use Runway’s fix request flow to safeguard their release diffs, requiring contributors to submit requests when they want to add late changes to a release. Formalizing the process for these requests and making them more visible helps teams stabilize releases better. And the details submitted alongside these requests play an important role, since they help explain why the late change is necessary and give reviewers the context they need to decide whether to let extra work in or not.
A few new changes in the fix request flow make it even more powerful. First, whereas before you could only create a new fix request if the corresponding code change was already in flight (e.g. PR with a fix open against trunk), now you can create a new fix request that references a project management ticket only. This way, you can raise a request as soon as a showstopping issue is ticketed up (and before anyone starts work on it), approve/reject, and track progress across the entire flow.
There are also new settings that give you more control over the details submitted with each fix request. You can now set a details “template” that will be prepopulated in the fix request form, both within Runway and via the Slack flow. This allows you to create sections and specific prompts that requesters will fill in and address. And, you can now make the details field required, so that the necessary context is always submitted alongside each request.

New integrations: Android Vitals, BrowserStack, and Qase

We shipped a number of new integrations at a couple of different integration points in Runway. Android Vitals is our latest observability & analytics integration, allowing you to surface Google-native metrics like ANR rate, slow start rate, excessive wakeup rate and, well, everything else Android Vitals measures. Like any other observability & analytics integration in Runway, you can surface this data during rollouts and define metrics with thresholds for alerting and rollout automations.
We also have two new testing integrations: BrowserStack and Qase. When you connect either of these, Runway will automatically pull in any test runs against a given release, surface live statuses as those progress, and track history across multiple sets of runs if needed. (For other testing integrations like these, Runway can also automatically create your test runs for you, release to release — that functionality will be available in future for these newest integrations.)

Less bookkeeping as you add (or remove) projects in Jira, with automatic project selection

We know that many Jira teams work across a multitude of different projects, and that list of projects is often changing over time. Currently, you need to manually select each project you want in-focus in Runway in your integration settings, and keep the list of selected projects updated.
We’ve added an option on the Jira integration settings in Runway to automatically select all available projects, and keep the list of selected projects updated as projects come and go on the Jira side.

Self-serve support for Bitrise Pipelines

Given Pipelines and builds generated by Pipelines surface differently than Workflows and Workflow builds in Bitrise’s API, support for the former was only possible via a backend config on the Runway side.
To make setup easier for Bitrise Pipelines teams, we brought full support for Pipelines to the Bitrise integration settings UI.

Another option for integrating your team’s Google Calendar

Runway’s Google Calendar integration allows you to automatically sync your Runway release schedules and rollout info to an external team calendar, and also pull any additional events created in your team’s external calendar into Runway’s calendar views.
Google auth can be finicky when it comes to Calendar integrations, and the service account approach was proving difficult for some teams, so we added OAuth as an additional option for connecting Google Calendar. This allows you to integrate with your calendar via an individual user account in your Google Workspace.

Original source

Less copy-pasting and no more scouring diffs or tickets — Runway can autogenerate internal and external release notes for you

It’s important to get the right context about changes contained in each release to the right audience, and doing this often takes more time and effort than you realize. Most teams pull together different kinds of internal release notes and changelogs designed to keep the wider org aware of what’s shipping and to maintain a historical record of updates. There are also external audiences to create release notes for, at least if you’re aiming higher than the usual “Bugfixes and improvements” — which many teams would love to do, if only assembling real release notes weren’t such a headache!

There are now a few different options to have Runway auto-generate release notes designed for different audiences. Using AI, Runway can draft release notes based on the code changes (PRs and commits, no actual source code) and project management tickets, tailored for either internal or external audiences. Where you leverage this for app store release notes, Runway understands the context and any constraints enforced by the store in question (character limits, disallowed special characters, etc.). For more granular and standardized outputs, Runway can also assemble list-like changelogs focused either on the code work in the release’s diff or the project management tickets associated with the release. Finally, you can create template-based release notes that follow a standard form but contain tokens (e.g. {workItems}, {contributorsCount}, {releasePilot}) which are populated dynamically for the release in question.

All of these options are available in Runway wherever you can enter different kinds of release notes: store metadata, release description, release summary, and beta testing notes.

A more comprehensive way to track release actions and config changes, with event timeline updates

There’s a lot going on during releases, from state changes across all your different tools, to automations executed by Runway, to manual actions taken by different folks across your team. Plus, you’re sometimes making changes to settings in Runway, which are also important in the context of releases. Teams have given us great feedback on the value of capturing all of this info, but with very valid asks for more completeness and ways to get granular with the data.

As a result, we’ve revamped Runway’s event timelines in a few ways. First, the event timeline has moved to its own dedicated view, showing all past and upcoming events per release. In addition to search, you can now also filter the timeline by date range, release step, or a specific automation. There’s a new lens to view only timeline events related to automations. And there are new event types covering things like Runway settings changes (e.g. integrations being added/removed/updated), rollout updates, and more.

Watch this space: we’re working on some related changes that will provide even more transparency around Runway’s automations, surfacing important information on automation outcomes, pre-conditions and dependencies.

One more way to get the right info to the right stakeholders, with new email notifications

Though most teams live in Slack or Teams, there are certain situations where a notification or alert is best served via email. Maybe some stakeholders are further from the immediate mobile team or particular team members prefer to keep a record of specific kinds of release updates in their inbox. Whatever the use case, you can now enable email notifications for every existing notification type in Runway and for every app you’re a member of in your org.

Accelerate to an even faster release cadence with support for multi-weekly schedules

Runway’s release scheduling has helped many teams accelerate their release cycles, whether from monthly to biweekly, or biweekly to weekly. Often folks stop there; weekly seems to be a sweet spot for mobile. But some teams increasingly want to push the boundaries, especially with a framework like Runway helping to support smoother release cycles end to end — the catch being that Runway’s release scheduling and related automations did not previously support cadences quicker than weekly.

Now you can speed up even further and put multiple releases per week on autopilot. In your release schedule settings, you’ll be able to configure sets of kickoff, submit, and release target dates. For example, you could have your first weekly cycle kick off on Monday afternoons, submit on Wednesday afternoons, and release on Friday mornings, and your second weekly cycle kick off on Wednesday mornings, submit on Friday afternoons, and release on Monday mornings. Aside from establishing your cadence and having Runway manage the schedule for you, you can of course optionally tie automations to each of those targets to have Runway run your releases on autopilot.

More ways to tailor how notifications are surfaced to your team and reduce noise, with Slack threading

Runway gives you a number of ways to direct the right kind of comms to the right audiences, with granular channel settings and optional @-mentions per notification type, even providing handling and automations for release-specific channels. Despite this, we heard that teams wanted even more ways to group certain communication and keep noise down.

So we recently implemented threaded Slack notifications, initially available for fix request notifications specifically. When this option is enabled in app settings, any notifications related to a given fix — creation, approval/rejection, cherry-pick or merge status — will be posted in a thread off of the first notification. We plan to roll out this functionality to more notification types over time — let us know if there are specific notifications you’d like us to keep in mind!

Unlock internal distribution for all Android artifact types with AAB support in Build Distro

Even though AABs are now the required upload format for Play Console and more teams solely build AABs by default, they’re not installable binaries — meaning teams who want to distribute builds internally either need to build APKs all the time alongside their AABs, or forego internal distribution anywhere outside Play Console itself, which is quite limiting.

Now, Runway’s Build Distro supports distribution of AABs. More specifically, we’ll automatically convert any AABs into installable universal APKs that your team can easily download and test.

Spin up new apps easily and reproducibly with config as code

We know that many teams manage a growing number of different apps in Runway, and adding new apps via our UI isn’t always the quickest or most scalable option. And even for teams with fewer apps, we understand the value of being able to handle configuration in code and track changes with source control.

So, we’re working on bringing config as code to Runway, starting with the add app flow. Now, you can express a Runway app in YAML (perhaps copying over from an existing app for ease) and POST that to Runway via our public API to actually create the new app programmatically. Next up is a full bidirectional sync that will let you store config in source control and make changes either there or within Runway.

Original source

Keep your team aligned and up-to-date on release schedules and milestones with new release calendar views

The timelines around releases are an important part of the human process that plays out: you need to set expectations with stakeholders and make sure everyone on your team has a clear understanding of when any given release is expected to kick off, submit, release, and roll out. Most teams try to create some kind of shared release calendar, but there are so many dependencies and inevitable deviations from the happy path that it’s tedious to maintain.

Given that Runway has all the context needed to pull together an accurate picture of release schedules and milestones — and keep it all updated for you — we’ve added new release schedule views in the platform. Both per release and at app level (across all releases), Runway populates a calendar with key lifecycle events like kickoff, submission, and release, as well as info on every step of a phased or staged rollout. In addition to seeing the actual timing of events as they occur and any upcoming targets that are explicitly scheduled (e.g. with a recurring release cadence you have configured), Runway can even predict events for upcoming releases based on timing of your past releases.

Unlimited options for monitoring, alerting, and automating based on release health with a new custom metrics endpoint

Many teams already rely on Runway’s rollouts functionality to build (and act on) a more complete picture of app health, combining signals from crash reporting tools, observability and product analytics platforms, and the app stores. But we know teams are using even more kinds of tools to capture data like this, and many have their own data pipelines set up in-house.

Now, you can stream any and all custom data into Runway using a new API endpoint to surface and use in the rollouts context, just like any other data from Runway’s out-of-the-box integrations. Runway will surface your custom data on time series graphs and you can create health metrics with thresholds set for alerting and rollout automations.

Ensure your team is seeing the same picture whether they’re relying on calendars in or out of Runway, with a new calendar integration

Even with our new release schedule views, it’s likely that folks on your team who spend less time in Runway will rely on calendars outside the platform for information on release timelines and milestones. On the flipside, folks relying on Runway’s calendars might worry that they’re missing important one-off or ad hoc events which are relevant to a release but added only to their team’s external calendar.

Our newest integration type allows you to connect your team’s external calendar to Runway to ensure everything stays aligned. In one direction, you can have Runway automatically sync your Runway release schedules to your external calendar, adding and updating events as needed. In the other direction, Runway can also pull in any additional events created in your team’s external calendar so that your Runway calendar views will always show a complete view of your schedules.

(Currently supported for Google Calendar, with Outlook on our radar — reply to this email to let us know you’re interested!)

A quicker and easier way to catch crashes and other issues caused by feature flag changes, with flag diffing on rollouts

Some of the trickiest app health issues to track down are the ones caused by feature flag changes as opposed to new binary releases. Flag changes are more dynamic and harder to stay on top of, and it can take teams quite a while to connect the dots when a flag change made by someone, somewhere on the team causes a new crash or breaks an important flow in the app.

With your feature flagging tool integrated in Runway, we now perform continuous diffing on your flags to capture not just “on/off” changes but other updates to progressive rollouts, variations, audiences, etc. In addition to surfacing the resulting diffs in feature flag lists in the platform, we also overlay flag changes on your rollout graphs. That way, if you see a spike or dip in an important metric, you have immediate context on any flag changes that were made around that time and some hints as to a possible root cause.

Build funnels and other complex health metrics for rollout monitoring and automations using a new “calculated metric” type

While Runway’s existing metric types give you plenty of ways to monitor health signals from observability and analytics tools, and alert and automate rollouts based on thresholds you set, we understand that teams often want to consider more complex aspects of app health. Certain funnels, conversions and computed values were harder to get at.

Runway now lets you build more complex health metrics based on existing building blocks. All you need to do is select one or more of your existing metrics in Runway, then enter an expression describing how those metrics should be put together. For example, to look at a conversion from user signup to checkout, you might select your “signups per DAU” and “checkouts per DAU” metrics and enter the expression “checkouts per DAU”/”signups per DAU”. Any mathematical expression is valid, and you can even combine metrics from different integrations for a powerful new way to monitor health.

Easily share certain builds with a wider audience using new public build buckets in Build Distro

When distributing pre-production builds, many use cases call for an easy way to share builds with folks who may be a bit further from your immediate team — perhaps internal stakeholders who wouldn’t otherwise spend time in Runway, or even people outside your company. At the same time, you don’t want to overprovision access or jeopardize the security of builds that should be locked down to a specific audience.

Now, you have the option of enabling public access on any of your build buckets in Build Distro. When you enable this on a bucket, you’ll get a public link which allows anyone to access and install any builds in that bucket. No other buckets or areas of Runway will be accessible to users accessing via these public links.

New integrations: Dynatrace, Bitbucket Pipelines (and Google Calendar)

In addition to the entirely new calendar integration type highlighted above, we added two new options at existing integration points in Runway. Dynatrace is our latest stability monitoring integration, for surfacing crash-free and adoption rates in the rollout context, and Bitbucket Pipelines is a new option for CI/CD.

Original source

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

Build info and install links automatically posted on project management tickets

Give your team even easier access to builds with build info and install links automatically posted on project management tickets
We know that not all of your team spends time in Runway – but a lot of those folks are still impacted and involved in different parts of your release process. That’s why one of our goals as we build out the platform is to make everyone’s lives easier and keep everyone on the same page, no matter where they spend most of their day-to-day tools-wise. Runway acts as coordinator between all team members and tools, and this latest automation is a great example of that.

For any project management tickets that are part of a release, Runway can now automatically post comments containing build information and install links for release candidates that contain code associated with a given ticket. This gives your team a quick and easy way to access test builds for a given item of work from the ticket side, and can be especially helpful for folks like Product and QA who spend more of their time in your project management tool.

Each ticket comment will include:

• The build number and workflow name
• A link to the build in your CI
• If the build produced an app store build (e.g. a build in TestFlight), an install link for that build as well
• A list of all associated commits that were included in the build

This new automation is also available in the Build Distro context. If enabled, Runway will look at the diff between a given build and the preceding build in the same Build Distro bucket and will post a comment on any tickets referenced by code items in that diff. In this context, the comment will include some extra build details and a direct link to view and install the build in Build Distro.

Keep your team up-to-date on live, in-flight and upcoming releases across all apps in your org with biweekly digest emails

Sticking with the theme of giving your team quick access to release info and better visibility around the state of releases, even outside of Runway – you’re probably familiar with our various types of notifications and release announcements, and our Slack slash commands. Now, we’ve added a new way for team members and other stakeholders across your org to stay on top of mobile releases.

With Runway’s new biweekly release digest emails, any member of your Runway organization can get a regular digest containing key info about your live, next-up, and upcoming releases for all apps delivered straight to their email inbox. 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.

More ways to monitor and automate rollouts with filtering for observability and analytics metrics

Runway’s rollout features help your team to stay on top of app quality as you release each new version, allowing you to integrate and pull in signals from all the different tools you use to track health and performance. One of the available integration points is with observability and analytics tools, and so far you’ve been able to select key events and monitor them in a number of different ways: by event volume per session or daily active user, or by looking at event property values (measured as averages, means, percentiles, etc.).

Now, you can also track filtered events for an even more granular way to surface exactly the kinds of indicators of app health that your team cares about. For any given event in your integration settings, the property field now lets you enter a string with property names and values to filter using basic query string syntax. For example, if you have a page_load event and want to measure unsuccessful loads on a "cart" screen, you might enter name=cart&error=true for the property value. You can also use greater-than and less-than operators. Just like any other metrics you configure in Runway, you can define acceptable thresholds for these new filtered metrics and they can be included in alerts and used as conditions for Runway’s rollout automations.

Easier options for building on top of Runway, with more customizable webhooks and new API endpoints

Many teams use Runway’s outgoing webhooks and API to extend the platform and integrate it more deeply with their unique tech stacks and release processes, so we’re devoting resources to a number of projects that increase just how extensible Runway is.

One update in this area is that you can now customize the headers and payloads of your outgoing webhooks in Runway, to suit the needs of the endpoints receiving each event on your team’s side. This can help you avoid needing to set up and maintain servers to handle webhooks from Runway. For example, many CI providers offer some out-of-the-box way to accept incoming webhooks (to trigger a workflow, say) but they require certain headers be passed and you may want to include additional parameters in a payload. Now that you can add those headers and payloads to your webhooks in Runway, you have a really simple way to trigger bespoke actions to all sorts of triggers in Runway.

We’re also continuing to expand the Runway API (endpoint requests are always welcome!) and one addition worth calling out is the new “Get all events” endpoint. You’ve probably seen the detailed event logs that Runway surfaces in the dashboard — this endpoint opens up a programmatic way to access those granular breadcrumb trails of release updates and changes. You can filter by app and version as needed.

More ways to sync app store metadata with a new automation that can pull straight from your repo into the stores

Runway already offers teams a few different options for managing app store metadata within the platform and automatically syncing it up to App Store Connect, Play Console, and the other stores we integrate with. These existing options are generally UI-centric, designed for marketing or product folks who may be the ones managing metadata release to release. But we know that many teams choose to check their app’s metadata into version control in their repo, and then grab the metadata from there when they’re ready to update in the app stores.

If your team follows the version control approach, you can now have Runway automatically read all the store metadata from your repo 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 where metadata lives in your repo, and Runway will automatically grab metadata and populate it in the stores as each release is kicked off. Localized metadata is supported and uses the same key specifications as fastlane does.

Avoid getting caught out by expiring Apple profiles, certs, and agreements, with automated alerts and reminders

Just about every Apple developer has experienced the frustration caused by provisioning profiles and signing certificates that expire when you least expect them to. Same with new or updated agreements in App Store Connect, which can cause even more disruption: you need to track down whoever on your team is authorized to handle those agreements, and maybe even get legal folks involved (read: lots of wasted time and delayed releases).

Avoid unwelcome surprises and the domino effect they cause with new reminder notifications in Runway. For provisioning profiles and signing certificates, we monitor the expiration dates of any active profiles and certs in App Store Connect and start sending reminders as expiries approach (you can configure when these reminders start). We’ll also send alerts whenever new or updated agreements need to be accepted. Like all notifications in Runway, you can choose one or more channels to send these new notification types to, and can @-mention individuals or groups in them so nothing gets missed.

Even more ways to make sense of code and tickets with new groupings, filters, and support for custom fields in the Feature Readiness view

Based on feedback from our teams, we continue to evolve the Feature Readiness view to allow everyone on your team to get exactly the kind of view of feature work they’re looking for, across both code and project management tickets. One recent addition is a new “Group by ticket” lens. As the name suggests, enabling this lens will render a Feature Readiness view that keys primarily off of project management tickets – if multiple items of code refer to the same ticket, they’ll be grouped under that ticket on a single row. For Jira teams, we also added support for custom fields: specify as many custom fields as you like in your integration settings and they’ll be available as filters in Feature Readiness, as well as surfaced in each item’s details drawer. Finally, we added more out-of-the-box filters including ticket type and ticket priority.

New integrations: Samsung Galaxy Store and Opsgenie

We have two new integrations to highlight in this edition of updates. Samsung Galaxy Store is our newest app store integration, opening up yet another available destination for your Android builds and allowing you to manage metadata and screenshots, handle submission and release, track user reviews, and more. And, Opsgenie is now an available option at our scheduling integration point. With Opsgenie integrated, Runway can manage your release pilot rotation based on an Opsgenie schedule, automatically assigning pilots to releases, swapping people when coverage changes, and re-assigning pilots if a release rolls over into another team member’s shift – with reminders and alerts along the way.

Original source

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

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

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

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

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

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