The Five Major Distinctions Between Mobile DevOps and Web DevOps
In the previous stories, we defined What CI/CD is and What Mobile CI/CD is and briefly mentioned why mobile CI/CD is different.
There are a number of differences between mobile CI/CD and traditional CI/CD stacks such as web CI/CD and now, let’s list the five major distinctions that set mobile CI/CD apart.
1. The rules and the standards in mobile CI/CD are based on the mandates of Apple and Google:
The way the mobile operating systems, iOS, and Android, works determines how mobile CI/CD is conducted for the full app lifecycle.
Therefore, many of the general CI/CD practices are not directly applicable for mobile CI/CD and they need to be worked out based on the unique needs of mobile platforms.
This is exactly why there is a need for a dedicated mobile CI/CD platform and this is just a single reason.
2. Mobile DevOps is usually managed by the developers, not the specialized DevOps teams in most enterprises:
Mobile development and mobile CI/CD require very specific domain knowledge and this knowledge is usually unbeknownst to the DevOps specialists.
For this reason, mobile developers tend to manage mobile CI/CD, but they also struggle with the DevOps domain, so there is a solid need for a mobile CI/CD platform that can combine the knowledge and experience of both worlds and eliminates the need to know DevOps or mobility inside out.
3. The ceremonious codesign process complicates the pipeline:
For iOS and Android, there are separate code signing requirements with very specific limitations. Especially for iOS, the codesigning process has multiple layers for different use cases.
Such a complicated codesigning structure is unique to mobile development and the pipeline must be configured to accommodate it. Then, there is the issue of keeping these code signing identities safe and secure just like any other certificate. Yet another reason why a specialized mobile CI/CD platform is required.
4. You need to have a binary to run your app:
As if the code signing is not sufficient, you have to pack the final output in an installable binary to run on the mobile devices, so you cannot deploy any code right away as you would on the web apps, reducing the flexibility and increasing the volume of each release.
It’s like traveling to the past where we had to struggle with single, monstrous executable files all the time for any kind of app. Every time there is an update, you have to download the full binary and reinstall the app.
Thus, the mobile CI/CD pipeline has a special structure for binaries and this requires a different approach and specialized tools for deployment and delivery.
5. Apple and Google have the final say for the delivery to the final user
And the last, but not the least is that the entry to the walled gardens of iOS and Android is guarded by unrelenting gatekeepers.
There is a rigid review process that may take days in the worst cases, so you have to be able to squash any bugs before it makes it to the end-user. Once an app is released to the app stores, you cannot revert it to a previous version.
This is where continuous testing comes in the picture. You need to test every single release so that the issues are identified early and for that, you need a mobile CI/CD platform that supports continuous testing specifically for mobile apps.
All in all, mobile CI/CD is different than web/backend CI/CD in many aspects and as we always emphasize in this publication, it is recommended to use an all-in-one, specialized mobile CI/CD (and CT) tool like Appcircle. instead of trying to set up a mobile CI/CD pipeline with the combination of multiple tools and environments.
