Beyond Continuous Deployment: A Mobile App Workflow That Actually Works

Julia Müller

6 min read

In today's fast-paced development world, continuous deployment has become the gold standard for many web applications. Push a change, run your tests, and deploy to production—sometimes dozens of times per day. But for mobile app developers, the reality is quite different. App stores introduce unavoidable delays, review processes, and regulatory hoops that make traditional continuous deployment challenging, if not impossible.

This gap between ideal and reality forces mobile developers to think strategically about versioning—a practice that, when done well, can actually strengthen your development process rather than hinder it.

Why you still need to think in versions

While web developers might deploy features as soon as they're ready, mobile app developers face several constraints that make version management essential. App store review processes can take hours or days, creating unavoidable delays. Users expect stability and may be sensitive to frequent updates. There's often a need to coordinate releases across multiple platforms simultaneously, and comprehensive QA is required before releases reach end users.

These realities necessitate a disciplined approach to version management. Imagine a scenario where version 1.0.0 of your app is already in production. Your team is busy working on exciting new features for version 1.1.0, and perhaps exploring experimental concepts for 1.2.0. Then, inevitably, a critical bug surfaces in the production version.

You can't wait for the 1.1.0 release—which might be weeks away—to fix this issue. You need to ship a hotfix as version 1.0.1 immediately. Suddenly, you're managing four parallel versions of your codebase: the current production release (1.0.0), an urgent hotfix (1.0.1), the next planned release (1.1.0), and a future release with experimental features (1.2.0).

How do you manage this complexity without creating a tangled mess of branches and merges?

A Git-based approach to version management

The solution lies in adapting the popular Git Flow branching model with a version-first naming convention. This approach structures your Git branches hierarchically by version, making it immediately clear which version each piece of work belongs to.

Here's how it might look:

- 1.0.0/main                        # Current production release
  - 1.0.1/dev                       # Hotfix development
  - 1.0.1/bug/critical-crash-fix
  - 1.0.1/main                      # Ready for hotfix release

- 1.1.0/dev                         # Next version development
  - 1.1.0/feature/new-login-flow
  - 1.1.0/feature/dark-mode
  - 1.1.0/main                      # Ready for next release

- 1.2.0/dev                         # Future version development
  - 1.2.0/feature/experimental-ui
  - 1.2.0/main

What appears complex in text becomes elegantly organized in modern Git tools like GitKraken, where nested branches create a clear visual hierarchy.

The beauty of this approach is its simplicity. There's no complex tool or process—just a naming convention that brings order to potential chaos. Developers can easily switch between versions while always maintaining context about "where they are" in the development timeline.

Bridging Git and deployment with Appisto

Where this workflow truly shines is when paired with a streamlined deployment process. This is where Appisto enters the picture.

After your CI/CD pipeline builds your app from a specific version branch, the next step is distribution to your internal team for testing. Traditionally, this involves a cumbersome process of manually collecting device identifiers for iOS testers, setting up provisioning profiles, creating build archives, distributing them via email or internal servers, helping team members through installation, and organizing feedback.

Appisto eliminates these friction points by providing automated UDID collection from testers' devices, direct integration with your CI/CD pipeline via REST API, a central hub for accessing the latest builds, and instant distribution without App Store review delays.

In the Appisto workflow, developers commit code to version-specific branches such as 1.1.0/feature/dark-mode. The CI/CD pipeline automatically builds the app from every branch commit and uploads each build to Appisto via the REST API. Team members can instantly install and test any branch build, providing immediate feedback. When features are complete and verified through this process, they're merged to the version's dev branch for integration testing. After successful integration, the code moves to the version's main branch, representing the release candidate. With comprehensive feedback gathered throughout this process, the final submission to app stores is made with confidence.

This approach creates a tight feedback loop that's particularly valuable for addressing hot fixes. When a critical bug is discovered, developers can create the fix in a dedicated branch like 1.0.1/bug/critical-crash-fix. The fix is automatically built and deployed to Appisto, allowing team members to immediately test it directly from the bug branch. Once verified, the fix can be merged to integration branches and finally to the main branch before submission to app stores. This entire process happens without the delays typically associated with app store reviews.

The power of automation

The version-first naming convention also enables powerful automation. For example, you can extract version numbers directly from branch names during the build process:

# Extract version from current git branch
BRANCH_NAME=$(git symbolic-ref --short HEAD)
VERSION=$(echo $BRANCH_NAME | cut -d'/' -f1)

# Use it in your build processes
echo "Building version $VERSION"

This extracted version can be automatically injected into Info.plist for iOS or AndroidManifest.xml for Android, eliminating the need to maintain version numbers in separate config files or environment variables. Combined with Appisto's API, this creates a nearly frictionless path from code commit to internal testing.

Benefits beyond the technical

This workflow doesn't just solve technical problems—it creates significant business advantages. Teams experience faster feedback cycles by getting immediate testing input without waiting for app store approvals. Quality improves as issues are caught before they reach production users. Team collaboration strengthens when everyone has clear access to the latest builds from any branch. Coordination overhead decreases dramatically, eliminating the familiar "Did you get that build I emailed?" conversations. And with clear version tracking, teams always know exactly which version contains which features or fixes.

For mobile development teams dealing with the realities of app store constraints, this combination of structured Git branching and streamlined internal distribution creates a workflow that offers many of the advantages of continuous deployment while acknowledging the unique challenges of mobile app development.