A guide through publishing white label apps in a healthy way

Given at Mobile DevOps Summit 2022

Publishing and releasing one Android app is easy.

But what if you have to publish 5 apps, or 10, or even 50?

You have to start thinking about the build time on your continuous delivery server to build all of those apps. You have to think about how to roll them out in a comfortable way. You have to think about your architecture and a lot more...

We are at ioki creating white label apps and have, as of today, 38 apps public in the Play Store.

In this talk, I will guide you through the challenges we had to publish more and more apps over the years in a healthy way. I will show you what we did - release process-wise as well as code architecture-wise - to scale further to stay in this healthy environment we have today.

Takeaways from this session:
1. A reliable continues delivery server is important
2. Architecture is important when you publish multiple apps
3. What does it mean to growth in a healthy way

Transcript

1. A guide through publishing white label apps in a healthy way
2. This is me • Stefan May • Live in Germany • Android Development since 2014 • Senior Android Developer @ioki since 2020 StefMa.medium.com twitter.com/@StefMa91 github.com/StefMa
3. This is ioki • Founded in 2017 • Subsidiary of Deutsche Bahn • Complements existing public transport with an demand responsive transport (DRT) system • Providing an platform to customers to enabling them to provide a DRT service ◦ SaaS ◦ Consulting ◦ APIs ◦ White Label Apps (WLA)
5. … and counting
6. • 2017, 1 app “ioki” (test balloon) • Setup “default” release process ◦ Bitrise as CI/CD ◦ Automated releases via an Gradle plugin • Releasing at end of sprint (each two weeks) ◦ Release officer, changing responsibility in the Android team (3/4 people) • Bitrise -> CreateRelease Workflow ◦ Version name ◦ Version code (will be calculated) ◦ Bitrise fetch `main` branch, lint + test, build and release to Play Store (internal track) ◦ Manual testing of this app (Head of Mobile) ◦ Test succeeded, release office go to Play Store and move app to production (and alpha) track Where it starts
7. This process is good
8. This process is good … as long you have only one app
9. • Decision: We do white label apps • Code: build flavors ◦ Small flag within the app to create “a clone” of the app to create multiple apps ioki entered the WLA market
10. Other stuff weren’t touched
11. But we grew… and created one white label app after the other…
12. • Increasing build time ◦ The build tool (Gradle) has “to do” something for each app • Developer productivity (DP) suffers ◦ Time from “start build” to “deployed on device” increased ◦ “What do I wanted to test”? ◦ “Why did I even wanted to deploy the app on the device”? ◦ “Ahhh, I found a mistake. Let me quickly change this and build again”! The first problems
13. • Increasing build time ◦ The build tool (Gradle) has “to do” something for each app • Developer productivity (DP) suffers ◦ Time from “start build” to “deployed on device” ◦ “What do I wanted to test”? ◦ “Why did I even wanted to deploy the app on the device”? ◦ “Ahhh, I found a mistake. Let me quickly change this and build again” • Solution: Build flavor filter The first problems
14. • Flavor were defined in the application module (Gradle project) ➡ All other library modules (Gradle projects) had access to flavors A similar, but other problem
15. • Flavor were defined in the application module (Gradle project) ➡ All other library modules (Gradle projects) had access to flavors • (Interim-) Solution: Flavors as a library module, only applied by the application module A similar, but other problem
16. Who wants to be the release officer?
17. • Remember our publishing process? ➡ Manually moving the apps from the internal track to the production (and alpha!) track Please do the release, officer!
18. 1. Open Play Store 2. Open an App 3. Go to Release Management -> App releases 4. Choose the track that should be updated 5. Click Create Release 6. Choose an APK from the Artifact Library and pick the latest one 7. For release notes, choose Copy from previous release and choose the latest from the current track 8. Click Save then Review 9. Set rollout rate to 30% for the initial publishing 10. Hit Rollout! The publishing process for a single app
19. 1. Open Play Store 2. Open an App 3. Go to Release Management -> App releases 4. Choose the track that should be updated 5. Click Create Release 6. Choose an APK from the Artifact Library and pick the latest one 7. For release notes, choose Copy from previous release and choose the latest from the current track 8. Click Save then Review 9. Set rollout rate to 30% for the initial publishing 10. Hit Rollout! 11. Repeat for other Tracks and Apps I don’t want to live on this planet anymore
20. 1. Open Play Store 2. Open an App 3. Go to Release Management -> App releases 4. Choose the track that should be updated 5. Click Create Release 6. Choose an APK from the Artifact Library and pick the latest one 7. For release notes, choose Copy from previous release and choose the latest from the current track 8. Click Save then Review 9. Set rollout rate to 30% for the initial publishing 10. Hit Rollout! 11. Repeat for other Tracks and Apps Then fun doesn’t stop here
21. 1. … 9. Set rollout rate to 30% for the initial publishing …and increase to 70% after 3 days, and increase to 100% after 6 days 2. … I can repeat the process in 3 and 6 days again!
22. • Own Play Store, managed by us • Another Play Store, managed by us • Another Play Store, not managed by us ◦ Providing APK in another way We have apps in other stores too
23. Solution: Android publishing (CLI) tool
24. Half time show • Local build time isn’t a problem due to flavor filters • Release process is better for developers due to the publishing tool
25. Half time show • Local build time isn’t a problem due to flavor filters • Release process is better for developers due to the publishing tool • but… what about our CI? ➡ He, we have flatrate, doesn’t matter. Right?
26. Half time show • Local build time isn’t a problem due to flavor filters • Release process is better for developers due to the publishing tool • but… what about features for single customers only? ➡ We don’t need it right now. But maybe sooner than we think…
27. • Reminder: app with a dependency to a library which provides flavors • Problems: ◦ Other libraries can include the “white-label” library ◦ Single features are hardly to implement and could accidentally leak into other parts Start of an improved app architecture
28. • Reminder: app with a dependency to a library which provides flavors • Problems: ◦ Other libraries can include the “white-label” library ◦ Single features are hardly to implement and could accidentally leak into other parts • Solution: Move white-label library back to the app and make a standalone project out of it so that other libraries can’t access the white-label parts anymore Start of an improved app architecture
29. Old architecture New architecture - app build.gradle | include("lib-wla") | include("lib-logger") | include("feature-registration") | include("feature-ride-creation") src/main/someKotlinClasses - lib-wla - lib-logger - feature-registration - feature-ride-creation - ioki/app build.gradle | include(":ioki-library:lib-core") - lib-core build.gradle | include("lib-logger") | include("feature-registration") | include("feature-ride-creation") src/main/someKotlinClasses - lib-logger - feature-registration - feature-ride-creation
30. Old architecture New architecture - app build.gradle | include("lib-wla") | include("lib-logger") | include("feature-registration") | include("feature-ride-creation") src/main/someKotlinClasses - lib-wla - lib-logger - feature-registration - feature-ride-creation - ioki/app build.gradle | include(":ioki-library:lib-core") - lib-core build.gradle | include("lib-logger") | include("feature-registration") | include("feature-ride-creation") src/main/someKotlinClasses - lib-logger - feature-registration - feature-ride-creation
31. • Hard separation between “core” functionality and white label apps ◦ Usage of “flavors” in “core” is technically not possible ◦ Single features can be implemented in the “white label apps” project without touching the “core” • Improved build time (also on CI) ◦ Core has only be build once and can be reused for all apps • We can set different responsibilities between our Android teams… wait, what? Solves quite a lot of problems
32. Welcome on board, project implementation team (PIT)
33. • As we focused on creating WLAs, we lost the focus on features and bug fixing Android team can focus on… Android development again!
34. • As we focused on creating WLAs, we lost the focus on features and bug fixing • Solution: A new cross-functional team was born/hired. Focusing on: Project implementation specifics Android team can focus on… Android development again!
35. Summary • Our initial release process is still used as a foundation • Decreased local build times with build flavor filters • Improved (manually) release process by creating a publishing tool • Adapt app architecture to (not only) improve overall build time • Introduced a second Android team who focus on WLAs and specific features only
36. Outlook • Publishing “core” library to internal nexus (and consume library in WLas) ◦ Decrease release build time (on CI) ◦ WLA and core library has independent release circles ◦ No testing on linting on release day anymore (for core lib) ▪ Happen when a core lib does a release ◦ New WLAs and WLA hotfixes are independent from core library changes ◦ … More?
37. • We could only scale and publish so many apps easily and healthy because we ◦ invested in our tooling regarding release process and build times. ◦ tackle problems when we already see potential problems in the (near) future. And not at the time when we already have those problems! • You should care about those process as much as you care about your applications source code. • Releasing is a first class citizen! Conclusion / final words
38. Thank You, Any questions?