Read our new report - 2025 State of Mobile Release Management 📱
Read our new report - 2025 State of Mobile Release Management 📱

Product Updates

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.

workflows_timeline (1)

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 reply to this email!

And there’s a lot still to come on the Workflows front, as we expand support to cover more Runway release steps, add the ability to take bulk actions and automate more across steps, and introduce new summary views and overviews.

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.

Timeline

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.

hotfixes

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.

fixes-1

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.

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.

AICompressed-ezgif.com-crop

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.

Screenshot 2025-04-24 at 13.06.04

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.

Email

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.

Schedule

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!

slack

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.

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.

Screenshot 2025-04-16 at 08.50.09

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.

image (66)

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.

gcal-integration

(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.

feature flag

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.

calculated_metrics-1

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.

public bucket-1

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.

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
Screenshot 2024-11-06 at 15.56.11

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.

org_releases_digest

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.

obaa-metric-filters

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.

profile-warning

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.

Catch even more kinds of app issues, faster, with Runway’s new AI-powered user review analysis

App store reviews can provide an unexpectedly valuable window into your app’s health, highlighting issues that might not otherwise surface in crash reports, observability data, or product analytics. But it’s difficult to actually leverage reviews as part of your team’s overall health monitoring strategy. If you have a lot of users there are simply too many reviews to sift through, and no matter how many users you have there’s still lots of noise that has nothing to do with the app’s functionality – “Terrible customer service”, “My order was late”, etc.

Now, Runway can help you separate signal from noise so you can make the most of user reviews as an additional indicator of app health. We use AI to analyze all of your incoming app store reviews and identify common issues mentioned in them, surfacing these issues (alongside specific examples pulled directly from the reviews) on each release’s Rollout page. Simply evaluating for sentiment isn’t enough, since that would include reviews which have nothing to do with the app, so Runway considers the context of your company and app in order to single out bugs and broken functionality.

review-issues

Less copy-pasting into Google Translate or ChatGPT with automatic user review translations

Sticking with the store reviews theme, there’s a new automation in Runway that will automatically translate any non-English reviews and surface those translations alongside the original reviews in Slack (if you have store review notifications enabled). Avoid the multiple tabs and back and forth with translation tools when you need to figure out what users are saying about your app!

More granular user access and better ways to organize your team with custom user groups

Until now, you’ve used the “roles” functionality to scope access and group users in Runway. But because roles can be used in so many different ways in the platform — not just for RBAC and organization purposes, but also for things like notification pings, checklist item ownership, and syncing users between integrations — teams have been telling us they want to be able to create and manage their own roles. Now, you can do exactly that.

Runway’s roles functionality has expanded into what is now called “groups”. You can create as many custom groups as you like, assigning subsets of users and a list of permissions to each, and you can use these groups to segment users by role, team, or any other functional grouping within your org. As before, you can do things like: assign groups as owners on checklist items, regression testing items, and approval items; set up mapping to your Slack user groups so that folks are pinged in certain notifications from Runway; configure directory sync to automatically bridge from teams and groups in your company’s internal directory to groups in Runway; add groups as members on Build Distro buckets; and more.

custom-group

Even more control over rollouts with checklist items and gating for automatic acceleration

As our team often likes to say, your job isn’t done when you hit the button to release — or when Runway releases for you automatically! Running rollouts is a critical part of the overall mobile release cycle, and there’s already a lot you can do in Runway to automate and safeguard this part of the process. Now, we’ve released a couple of new additions to give you even more control as you roll out.

First, 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. Like checklist items elsewhere, you can set up automatic reminders and interact with them via our API and webhooks for extensibility.

Building on top of that, you can now also gate Runway’s rollout acceleration automation based on one or more checklist items. Runway will 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. This gives your team a powerful way to combine automation with human inputs that bring additional context, influencing whether you want to accelerate a rollout or not. Notifications can also be sent if conditions are met but checklist items are still incomplete.

rollout-cli

Chase down pending work — with less actual chasing — using a new reminder action in Feature Readiness

The Feature Readiness view in Runway is designed to give your team a crystal clear picture of everything you’re shipping, as well as any pending work that’s expected to ship with a given release. Being able to visualize incomplete items and potential blockers is helpful in and of itself, but you often need to take that info and then go track down the people or teams responsible.  

To help you quickly follow up on outstanding items and make sure your releases stay 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 into Slack tagging the respective owners of the code and/or project management tickets associated with the pending work.

ping-pending-owners-1
ping-pending-owners-slack

Support for retained builds in Google Play Console

Many Android teams need to include older builds alongside new ones in each release they ship, to maintain support for certain form factors or other segments of their audience. Previously, in order to do that, teams would have to remember to manually select the older builds to retain on the submission step in Runway for each and every release. Now, you can select any builds to be retained just once and Runway will automatically include those builds alongside your new builds each time you submit and release (or until you clear the retained builds in Runway).

retained-builds

New integrations: Huawei AppGallery and Lokalise

There are two new additions to Runway’s integrations, in two different domains. Huawei AppGallery is our latest app store integration, giving you yet another destination to ship your Android builds to (with even more destinations on the way - see below!). And at Runway’s translations integration point, you can now hook up Lokalise to better visualize the state of localizable strings for each release, and sync changes across your codebase, Lokalise, and even the app stores for localized metadata.

Find the exact build you’re looking for in seconds with search for Build Distro

In designing Build Distro’s bucketing structure, our goal was to help teams take the laundry list of different builds they distribute and break it down into logical groupings based on audience and build flavor. But even with clearer groupings, team members often need to grab builds from various buckets and it can still be hard to find the exact build you’re looking for at any given time.

To help users get to the right build in seconds, we added global search to Build Distro. You can search by build number or against other fields like commit message or PR title.

build-distro-search

More ways to interact with Build Distro programmatically using new public API endpoints

Runway’s out-of-the-box integrations with a range of different CI providers give teams a quick and easy way to spin up Build Distro buckets and automatically ensure the right builds get distributed to the right places. But there are plenty of reasons why a team might want lower-level access to manage builds and buckets directly, and we’ve been prioritizing work to expand Build Distro’s footprint in our public API. Our latest additions include endpoints that allow you to upload builds and create, read, and update buckets.

Details – and a sneak peek at more endpoints that are on their way shortly – are available in our API documentation.