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