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.
