The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
The future is mobile. Everyone globally either has or will have a mobile phone available in the near future. Companies, especially B2C ones, need a mobile strategy to interact with their customers. Today the main two players are iOS and Android platforms. Every single developer and organization is affected by them and their processes around apps. Notably, these practices change often and hard to interact with - especially in a CI/CD manner.
GitLab's vision for Mobile DevOps, is to provide high-value, best-in-class capabilities for enterprise flagship apps. This will include features that build on our SCM offering and adapting our existing CI platform and introducing new features such as multi-device and emulator testing, new security scans, and automated app signing and submission.
A mobile app takes many steps to go from an idea to being in the hands of end-users. We will initially focus on the developer persona that builds the apps and their related jobs-to-be-done. Over time, we will address the needs of other personas, such as the UX and UI designer for designing and prototyping concepts, the QA team member who ensures high quality across a variety of device and OS versions, as well as PMs who need to be able to understand what is working and what is not in the app.
Our primary focus will be on enabling users to build mobile apps on GitLab, rather than GitLab producing mobile apps itself.
We will approach this using a single-engineer group to enable us to rapidly explore this area. This also means we will focus on smaller iterations and use cases we can quickly make progress in.
Our near-term plan is focused on addressing pain points that we can quickly address to start showing GitLab as a valuable platform for Mobile DevOps and to gauge interest from our users and customers. We will iterate to address several "vertical slices" of use cases, so that users can get immediate value, rather than having to wait for an entire Mobile DevOps platform to be built. These vertical slices will also be related to areas GitLab is currently strong in to allow us to quickly iterate.
Because we already have existing CI capabilities that can run Linux, we will begin by focusing on the Android platform. Building for iOS will require that we create a macOS fleet of runners with Xcode, which is more involved than using our existing Linux and CI infrastructure.
We will ensure that our existing Auto DevOps can support apps that use common Android coding languages, such as Java, Kotlin, and C++. The goals of this will be that a user can add the source code for their app, enable Auto DevOps, and the pipeline will produce the APK they need to upload to Google Play. This will extend the existing Android Auto DevOps support we have today to remove some of the friction points and better document it.
We will focus on making the Android app signing process easier by letting users store their App Signing keys and keystores inside GitLab and easily use them in their pipelines. This will allow our users to write, build, and test their apps all inside GitLab and then push them to the Google Play Store once ready. This provides value because users will be able to manage their sensitive app signing information value in GitLab, where they do all their development already, rather than requiring a team to manage a separate data store for this. We could also consider integrating with Secrets Management & Vault.
We will provide a better testing experience for Android by making it possible to interact with an Android emulator through GitLab. This will be analogous to our Review Apps for web apps. Developers will add a job to their CI file to run the emulator and be given a URL they can connect to with ADB from their local machines. In the future, we will consider hosting an interactive GUI and allow direct interaction with the emulator as part of a GitLab project. We will also investigate if it will be possible to record and create UI tests for test suites through this.
Testing an app is difficult because it requires many different types of phone and the emulators provided with the platform are not always sufficient. We will focus on enabling multi-device testing for users so they can see how their app behaves on multiple types of phones and multiple OS versions.
This is a longer-term goal, since it will require a large amount of hardware devices and a maintenance and upgrade process around them. We will need to procure a variety of hardware devices running multiple OS versions and offer them as a pool for customers to run against.
Longer term we will offer enhancements to our WebIDE that can improve the experience for developers of mobile apps. Examples of this include being able to edit UI layout files and be presented graphical previews. This will enable developers to easily update apps, collaborate with designers, and quickly iterate on interfaces for their apps.
Longer term we will focus on surfacing in-app reporting events inside of GitLab. Examples of this would be showing events or the consoles from technologies such as Firebase directly inside existing GitLab environments features. This will allow developers to easily manage bug reports from their apps as well as better understand how their users use the app.
We will offer mobile security scanning and in-app protection by leveraging open-source projects and our own developments. This will be integrated into Auto DevOps as part of building and testing the apps. Runtime security will be embedded into the produced app so it can be directly deployed. We will also investigate partnerships to deliver these capabilities more quickly.
Some app publishers prefer to self-publish their apps, rather than delivering them through either Google Play Store or the Apple App Store. This is difficult for them to manage and hard for end-users to interact with. GitLab can make this easier by creating a "registry" or "app store" that can be added directly to a GitLab project to host the app files for distribution and download. We can also put together instructions for end-users to explain how to side-load apps from us, rather than requiring them to figure it out themselves.
This will provide value to app publishers since they will have more flexibility on when, where, and how they publish their apps than they do today. It could enable them to self-publish the app to a smaller audience or for a preview version before a broad launch on the App Store or Play Store. If they wish to self-publish to avoid licensing fees associated with both stores, this also gives them that option. By making self-publishing built-in to GitLab, it allows our users to focus on designing, building, and testing their app rather than the logistics of how to provide it to end-users.
We will begin by focusing on our first Mobile DevOps related category, App Signing and Deployment Management.
We'll focus on Apple iOS later, since we'll need shared macOS runners to enable this.
Write-once platforms such as React Native, Xamarin, and others are not where we plan to focus in the short-term.
We will not focus on specific-support for apps written with game engines, such as Unity or Unreal Engine. These types of apps will be able to built using our normal app pipelines, but specific features for those platforms are not something we'll prioritize in the short term.
GitLab identifies who our DevSecOps application is built for utilizing the following categorization. We list our view of who we will support when in priority order.
To capitalize on the opportunities listed above, the Secure Stage has features that make it useful to the following personas today.
As we execute our 3 year strategy, our medium term (1-2 year) goal is to provide a single DevSecOps application that enables collaboration between developers, security teams, SecOps teams, and QA Teams.
Last Reviewed: 2020-10-28
Last Updated: 2020-10-28
