Mobile multiplatform development at McDonald’s
The adoption of a responsive, native user interface for the Global Mobile App is enabling McDonald’s to build a codebase that can be shared across multiple platforms, removing the need for codebase redundancies.
by Austin Keith, Lead Android Developer and Ryan Sander, Senior Manager, Tech Lead, Global Mobile App Platform
At McDonald’s, we’ve been exploring many options to reduce the amount of code in our Global Mobile App codebases. While there are a lot of options out there, many revolve around a web-based solution that results in a sub-par experience for the user.
The obvious solution to performance issues is to develop applications in native code, but this results in needing both platforms to implement the same business logic. Whenever a new feature is added, the development teams need to spend time to understand the requirements and build it out in code.
My team wanted a solution that allows us to have a responsive, native UI that stays up to date with the platform, as well as avoids developing business logic twice.
What is Kotlin Multiplatform Mobile?
Kotlin Multiplatform Mobile (KMM) is a tool that allows a developer to build a codebase using Kotlin language that can be shared across multiple platforms and can even access platform-native libraries and tools.
Some of the advantages of using KMM include:
- Offers a single codebase for business logic and shared functionality, such as networking, storage, and parsing.
- Business logic for platforms can be handled in one location, reducing the test burden on developers as unit tests can be handled for both platforms simultaneously.
- For integration/instrumentation testing, Android and iOS projects can be included alongside the KMM module, allowing databases and networking to be tested through native simulation, emulation, or hardware within the code library.
Some of the challenges of integrating KMM include:
- iOS developers may find it difficult to work within the KMM environment as it requires knowledge of Kotlin language, but it has many similarities to the Swift® software technology, so the learning curve will not be too substantial.
- Not all libraries have a Kotlin-based equivalent, but this can be solved with platform-specific code using the expect/actual code paradigm.
- When using Kotlin versions of commonly used third-party libraries, there may be missing features. This is something that will likely be solved as KMM matures.
- Libraries that use co-routines / asynchronous method calls may crash due to an issue with the old Kotlin memory model. Updating to the latest version of Kotlin should prevent this in most cases.
KMM for enterprise applications
When deciding whether to use KMM within your software stack, you should consider the stage of development and the design paradigm your applications follow or will follow. If your application is designed around dependency injection and/or uses clean architecture, KMM will fit in nicely as it can be treated as another domain layer with the advantage of being shared by both platforms.
Early in a project’s lifecycle, shared functionalities, like networking and data storage, can be developed within KMM to reduce repeated code. Even a mature project can benefit from using KMM as new features can be integrated in this way, reducing the testing burden on individual platforms as each new feature only needs to be developed and tested in one location.
How we use KMM at McDonald’s
At McDonald’s, we serve many locales, each with their own unique requirements and configurations, and our menu’s structure must reflect the complexities involved with servicing each market.
Integrating KMM into the application flow allows us to develop the parsing and storage logic within one location, in addition to the business logic required to properly display the localized data and products on each platform.
There are many considerations when displaying menu items within the application, such as localization, fees, or configuration logic. Implementing these at the KMM level can reduce the time needed to develop these features, as well as the time needed for developers to learn the logic required to assemble this information.
Another advantage of keeping this logic and functionality isolated within the KMM library is the ability to run full end-to-end testing on database and menu business logic without requiring a full build of the application.
To ensure full test coverage, each component within KMM is covered by either a unit test or an instrumentation test. Instrumentation tests are run using a local Android and iOS application within the KMM project structure to verify that any code exposed to each platform works natively. The size of the project and the focused scope make test-driven development possible. When new features have been fully tested, a new version of KMM is pushed to each platform.
Looking ahead
As KMM matures, and as third-party libraries increase capabilities for compatible versions, more functionalities can be moved to KMM and reduced redundant logic within applications. Ultimately — since the code is only written and tested once — there is less code to support and test, which may reduce development time and enables teams to focus on higher testing coverage.
McDonald’s Technical Blog is an independent blog and has not been authorized, sponsored, or otherwise approved by Apple Inc.