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
   

   View Slide

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
   

   View Slide

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)
   

   View Slide

4. View Slide

5. … and counting
   

   View Slide

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
   

   View Slide

7. This process is good
   

   View Slide

8. This process is good
   … as long you have only one app
   

   View Slide

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
   

   View Slide

10. Other stuff weren’t touched
    

    View Slide

11. But we grew…
    and created one white label app after the other…
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

16. Who wants to be the release officer?
    

    View Slide

17. ● Remember our publishing process?
    ➡ Manually moving the apps from the internal track to the production (and alpha!) track
    Please do the release, officer!
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

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
    

    View Slide

23. Solution: Android publishing (CLI) tool
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

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…
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

32. Welcome on board,
    project implementation team (PIT)
    

    View Slide

33. ● As we focused on creating WLAs, we lost the focus on features and bug fixing
    Android team can focus on…
    Android development again!
    

    View Slide

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!
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

38. Thank You,
    Any questions?
    

    View Slide