Currently, uploading simulator builds is not easy. Users need to compress them as ZIP files and then deploy them to Bitrise Artifacts. This also doesn't generate public URLs due to format limitations. This restricts sharing without granting Bitrise access.

Launch the right workflow based on whether the pull request is ready for review or approved.

A dynamic pipeline is a pipeline that can be modified at runtime, for example, one stage/workflow can determine the number of workflows to be run next.

Safely check for config/syntax errors after you've made a change to your pipeline/workflow config without kicking off a production build or using any credits.

What if bitrise.yml changes made in the Workflow Editor could be automatically pushed to your repo in a pull request?

At the momenrt, Bitrise allows you to store your bitrise.yml file in your repository, but if you use the Workflow Editor UI to make config updates you have to then manually cut and paste the updated YAML file into your repo 😩

Create templates which define which parameters the build needs and a choice of valid values for each parameter. This can be useful when e.g. a developer or QA person wants to generate a build manually to get a specific flavour of an app for testing.

Feature developers no longer need to visit Bitrise in order to debug failures, speeding up the debugging process and decreasing cycle times. When a build fails, all the information about the failure is visible right in the GitHub pull request.

We are considering adding the ability to get Test Coverage in your builds. This feature will help you track how much of your mobile codebase your automated tests cover.

With Mobile Test Coverage, you can quickly identify untested parts of your app or introduce quality gates for your PR. You can even use that information to guide automated testing efforts across your organization.

Right now, the Bitrise GitHub App only supports connection of one GitHub organization. This is a pain if you have multiple GitHub organizations and need them all connected to Bitrise.

Change failure rate is how often a change cause failure in production.

Software leaders can use the change failure rate metric to gain insights into the quality of the code being shipped. High change failure rate may indicate an inefficient deployment process or insufficient automated testing coverage.

Bitrise currently uses your GIT system's data to compute cycle time. Customers who rely on task management systems like JIRA to track team velocity could benefit from an integration with JIRA

Bitrise currently supports notifications via Slack, Teams, and emails for alerts. Some alerts can be potential incidents and it would be useful to notify via Incident Management Systems such as PagerDuty, and Opsgenie so that prompt action can be taken.

Code coverage (or test coverage) is a metric that shows the percentage of your codebase exercised by your automated tests. It tells you which parts of the codebase are covered by tests and which are not.

Low code coverage areas are where bugs or vulnerabilities could lurk undetected, posing future risks.

On Insights, you may be able to track code coverage over time. 

Currently, configuring the Google Play service connection for the step requires uploading a service account JSON key file as a Step input. We aim to enhance this by enabling the use of the project's existing Google Play service connection directly within the Google Play Deploy Step.

With this new feature, the Google Play Step will integrate seamlessly with Google Service connections in your Bitrise project. This improvement is designed to streamline your deployment workflow, making the process of deploying to the Google Play Store more seamless and efficient.

Get a detailed, easily accessible test report for each Gradle or Bazel invocation right on the Invocation Details page! This feature offers developers a powerful view into their test performance, highlighting bottlenecks and flaky tests to optimize workflows. By integrating with Test Insights, you’ll see trends and patterns across both local and CI environments, empowering you to make informed, data-driven decisions that improve reliability and efficiency.

With the "Command Logs on Invocation Details" feature, you’ll gain instant visibility into Bazel and Gradle command executions. By accessing logs directly on the invocation's Details page, you can quickly diagnose failures and fine-tune performance with ease. No more digging for logs—just clear, actionable insights right where you need them.

Introduce monitoring to see performance bottlenecks on the machine side from CPU, memory, and free disk space point of view.

The current Linux Bitrise Runner binary only supports x86_64, due to the fact that Android tools are not supporting arm64.

We are considering providing an arm64 Linux Bitrise Runner binary to support using cheaper arm Linux machines or your Apple Silicon machines.

Please vote Google's issue up if you also need Android tools to be supported in arm64: https://issuetracker.google.com/issues/227219818?pli=1

Bitrise Remote Access enables you to ssh or vnc into your build machine for easy debugging.

Support for Bitrise on AWS would enable you to do the same with the builds running on your EC2 machines powered by Bitrise AMIs.

Blocked by Apple.

Android emulators can run on our VM-based macOS AMI, as Apple Silicon machines don't support nested virtualization.

Blocked by Google.

Supporting arm Linux EC2 machines - Graviton - can reduce infra cost, as these machine types are cheaper.

Please vote Google's issue up if you also need Android tools to be supported in arm64: https://issuetracker.google.com/issues/227219818?pli=1

The AWS Cloud Controller automates managing your EC2 machine pools at scale to avoid error-prone manual work.

Support for Linux AMIs would provide the same benefits for customers using Linux AMIs

To avoid issues with long-living EC2 machines, the AWS Cloud Controller can automatically reboot machines.

Based on our observation, the EC2 macOS machines start to have issues after one week of usage.

The AWS Cloud Controller could scale your EC2 machine pools up or down to fit your weekly usage pattern based on the cron-like schedule you provide.

To be up-to-date with the latest mobile build environment, the AWS Cloud Controller could automatically distribute the new AMI version, once Bitrise releases it.

Our bare-metal macOS and Linux AMI offerings allow our customers to tailor the prepared mobile build environment to their needs by creating a new AMI version and installing and prewarming it. The AWS Cloud Controller's custom AMI support would enable the utilization of these custom AMIs by managing the machine pools.