Sign in Subscribe

Efficient OTA Distribution via GitLab Pages: Our Solution for iOS, Android, Windows, and Web

Efficient OTA Distribution via GitLab Pages: Our Solution for iOS, Android, Windows, and Web
AppCenter discontinued – why is GitLab Pages a good alternative? How secure is access for external stakeholders without a GitLab login?
Unlike third-party providers, GitLab is a core piece of infrastructure. The solution is capable of being "self-hosted" or run in a "sovereign cloud", which eliminates the risk of sudden service shutdowns or unpredictable price hikes. We use a hybrid structure: the pages are accessible via obfuscated URLs (unique path prefixes). This enables rapid testing for partners, whilst your source code remains completely secure within your private repository.

Does GitLab Pages also support multi-platform projects (e.g., Flutter or React Native)? How does a GitLab Pages workflow help us comply with regulatory frameworks (NIS-2)?
Yes, but with one limitation: because GitLab Pages is designed exclusively for hosting static content (HTML, CSS, JavaScript), only the web versions of these projects can be directly published and hosted through it. Because the distribution remains entirely within your own DevOps environment, sensitive test data never leaves your controlled perimeter. This significantly simplifies audits and risk management within your software supply chain.

Table of Contents

Introduction: Benefits of OTA Distribution

Modern software engineering workflows, the seamless delivery of app builds to testers, stakeholders, or clients is a critical success factor. For mobile applications (iOS/Android) and desktop apps (Windows), distributing builds manually via USB or relying on third-party services can quickly become a bottleneck.

Microsoft’s AppCenter used to be a popular choice for Over-The-Air (OTA) distribution. However given that it is scheduled to be sunset, app developers need to explore alternatives pathways to effective and secure distribution. At Hybrid Heroes we have developed our own robust alternative approach: an OTA distribution pipeline that is fully integrated into GitLab Pages. It supports all relevant platforms—iOS, Android, Windows, and Web—leveraging existing CI/CD pipelines to allow pain-free installation via QR codes or direct links.

The Hybrid Heroes Solution

Our solution utilises GitLab’s ability to natively host static content via GitLab Pages. In tandem with our build pipeline, we automatically generate an OTA download page for every platform. The interface is context-aware:

  • On Desktop: Users can retrieve QR codes for mobile installation alongside download buttons for ZIP files containing all relevant build variants.
  • On Mobile: A single, prominent "Install" button is displayed for the specific device's build.

These pages are publicly accessible (no GitLab login required), making them ideal for sharing with external stakeholders or beta testers. We use GitLab Pages’ flexibility to distinguish clearly between Merge Requests and the Main/Master branch.

Technical Implementation

Cross-Platform URL Structure

Each platform follows a consistent, predictable path to ensure links remain shareable throughout the development lifecycle:

  • Merge Requests:
    https://<team>.gitlab.io/<projekt>/preview-<merge_request_id>--<plattform>-testing
  • Branch Builds (e.g. main):
    https://<team>.gitlab.io/<projekt>/preview-main--<plattform>-testing

This results in unique, reproducible links that remain consistent when shared, both throughout development and after merging.

Device-Responsive Presentation

The OTA pages adapt dynamically.

  • If accessed via desktop, QR codes (e.g. for iOS installation) and buttons for downloading ZIP archives containing multiple app variants will appear.
  • If opened on a smartphone, the system provides the specific file required (e.g., .apk for Android or .ipa for iOS).

CI Pipeline Workflow

A dedicated pipeline is defined for each platform. Beyond the build process, it generates HTML templates and deploys them to GitLab Pages.

iOS (via Fastlane)

  • The build_preview lane in Fastlane creates an ad-hoc signed .ipa file.
  • Additionally, an HTML file containing icons and metadata is generated. T
  • he finished builds are stored in a preview structure and published as GitLab Pages.

Crucially, an iOS OTA manifest is automatically generated to enable installation via the Safari browser.

Android (with and without Fastlane)

  • For Android, .apk and .aab files are built for different environments (e.g., prod, staging).
  • A Fastlane or Ruby script is used to fill out an HTML template.
  • ZIP files and a clean, mobile-friendly OTA (Over-the-Air) website are created.

Windows (e.g. via Electron)

  • For Windows projects (such as the PHYWE measureAPP), .exe files are generated.
  • The finished file is packaged as a ZIP and published on a landing page via GitLab Pages.
  • The process runs in a PowerShell shell on a Windows runner machine.

Web (e.g. via Expo)

  • Web applications also benefit from this structure.
  • After every commit to a Merge Request or the main branch, a version of the app is automatically deployed as a static page.
  • To ensure assets are delivered correctly, the baseUrl in the app configuration must exactly match the GitLab Pages URL—specifically, it must not start with a digit (otherwise, this would lead to build errors on Android).

Lessons Learned

We have gained several important insights when developing this workflow:e

  • Variable Constraints: GitLab Pages has specific constraints on variables within the path_prefix. Dynamic constructs using logical operators (||, &&) are not supported.
  • Merge Requests Constraints: Using CI_MERGE_REQUEST_IID is ideal since it is always available in Merge Requests – unlike CI_COMMIT_BRANCH, which is only available in branch pipelines.
  • Length matters: Variables like CI_COMMIT_REF_SLUG can generate URLs that are too long, resulting in 404 errors.
  • Web Configuration: For web apps, the baseUrl must start with a letter; starting with a digit (common in some project IDs) can trigger Android build failures.

Conclusions

By migrating to a GitLab Pages-based OTA solution, we haven’t just replaced AppCenter, we’ve improved upon it!

  • Consolidated builds in a single location.
  • Automated distribution triggered by Merge Requests.
  • Device-specific UI for a better user experience.
  • Zero reliance on external third-party testing tools.

For teams managing multi-platform projects, this setup drastically reduces friction for developers, QA teams, and clients alike.