Today I’m thrilled to announce the release of Build Stacks in Appflow. With this exciting new feature, Appflow users now have much greater control over their cloud build environments to unlock better native build stability and easier troubleshooting.

To view all available Build Stacks, refer to the Appflow docs or create a new native build within Appflow.

Today, we’re thrilled to announce Web Previews in Appflow, the easiest way to share what you’re working on with coworkers, stakeholders, and more.

Web Previews represent the next step in our belief in the web first development strategy, and we’re especially excited for what this feature enables for teams who want a quick and easy way to share pre-production versions of their app, without the overhead and complexity of managing TestFlight, iOS enterprise certs, or any of the more complicated methods of showing off what you’ve built.

Enterprise teams building mobile apps are looking to add Mobile CI/CD capabilities to their existing CI/CD workflows in use for their backend and frontend web apps.

Teams running or using Jenkins, Circle CI, Azure or AWS CI/CD solutions, and more, often ask how they can start to continuously build, test, and deploy their mobile apps utilizing their existing CI/CD investments.

While it’s possible to do so, it’s important to understand the aspects that make Mobile CI/CD uniquely challenging, and why there’s a good chance your team should buy rather than build their own solution for mobile builds.

Before jumping in, if you’re new to Mobile CI/CD, take a look at our introduction to Mobile CI/CD to understand what tasks are required to build, test, and deploy mobile apps in a continuous fashion.

With that in mind, what would a team need to build in order to add Mobile CI/CD capabilities to their existing CI/CD service and workflows?

A feature of highly productive engineering teams is their ability to ship new features and updates frequently.

For backend and frontend web teams, shipping is straightforward: push a commit to a git repo, trigger a build in CI/CD, and deploy a new version of the code on backend infrastructure or a static hosting service.

But for Mobile, shipping is a completely different beast, requiring a complex chain of events that culminate in an app store publishing and approval process that goes far beyond anything in the backend and frontend worlds.

Even with this considerable complexity, highly productive mobile teams are shipping frequently, with some shipping multiple times per day!

How do they do it, and how frequently should your mobile teams be shipping? Let’s take a look at some highly productive mobile teams to find out:

Continuous Integration and Continuous Delivery (CI/CD) is one of the fastest growing sectors of the developer market. Focused on enabling teams to continuously test and integrate their apps (instead of doing it all at once before shipping), and then helping teams deliver those apps in an automated fashion, CI/CD has transformed the way developers build and ship software.

A staple in the backend and, more recently, frontend ecosystems, CI/CD services have proliferated to help developers perform a set of tedious tasks on every commit to their app, including:

• Running builds every commit to every branch in a git repo
• Running test suites and tracking failing and succeeding tests
• Performing webhooks and other actions after builds
• Launching or deploying apps to hosting destinations after successful builds

This list applies to nearly every type of software application, whether it’s a backend, frontend web, or mobile app. This has led to a proliferation of general purpose CI/CD services that integrate with popular code repository hosting services, provide on-demand clean build infrastructure, and a system to trigger actions before and after builds.