Introduction
Throughout the past four years, our app journey has evolved, adapted and accelerated in sync with today’s growing mobile ecosystem and innovations. In 2016, our Native Mobile Architecture team introduced new architecture goals and designs for our eBay app. About two years ago, Google shared new requirements about native application architecture with the release of its Android Architecture Components Library. Our app vision harmonized nicely with Google’s new stance on app architecture, paving the way for features like Dynamic Delivery, a mechanism for deploying specific features of the application independently.
Historical Background
Earlier this year, we fully integrated Android App Bundles to help strengthen our customer experience in using our app. Our initial, native Android architecture served eBay extremely well by providing a stable foundation for features to be written on. As time passed though, we identified additional areas of opportunity for our Android architecture to further evolve, as teams focused on test automation, Continuous Integration/Continuous Delivery (CI/CD) and global infrastructure limitations. Our goals focused on modernizing the tech stack; decoupling the code; and providing for areas with low Internet bandwidth. We outlined a plan to move towards a proven, reactive-based Model-view-viewmodel (MVVM) architecture, which drew clear lines between often CPU intensive background work and UI updates that demanded seamlessness.
Source: https://developer.android.com/jetpack/guide
With this approach, the application will comprise independent and interchangeable modules, each rigorously tested. Highly decoupled layers will have clear boundaries, a clean API and a single responsibility. This is preferable to monolithic framework libraries that are tightly coupled.
Decoupling leads to separation of concerns, resulting in code that is easier to understand; easier to transition to from an unknown application state; and easier to evolve as requirements and technologies evolve over time. This work aligned well with Google’s Application Architecture recommendation when it was released in 2018.
Enter App Bundles
We worked with Google architects and engineers through their various programs as we created modules, moved to Kotlin and port over existing features into modules with the new reactive-based, network-agnostic architecture. During our discussions, we noted the impacts of an increasing Android Package Kit (APK) size and the cost to customers to download large APKs. Here are some impacts of APK size:
● For every 6 MB increase to an APK’s size, we see a decrease in the install conversion rate of 1 percent.
● The download completion rate of an app with an APK size of around 10MB will be about 30 percent higher than an app with an APK size of 100MB.
● Approximately 70 percent of people in emerging markets consider the size of an app before downloading it out of concerns for data cost and phone storage space.
Source: “Shrinking APIs, growing installs”
What Is An APK?
An APK is a compressed file that contains all of the executable code and resources necessary to run an app on native devices.
How Do App Bundles Solve for APK Size Issues?
When an APK is built and delivered to devices, it contains all the possible configurations for the diverse Android ecosystem. In other words, when we build an APK, we are building for every supported Android device, from a high-powered flagship mobile to a budget-friendly device. However, the cost of this approach is extra bloat, packaged into the APK to serve all devices, resulting in increased device data usage to download and more required storage space. App Bundles solve this by requiring users to download the specific libraries and configurations needed for their device.
Source: “How Android App Bundles and Dynamic Delivery will change the way your phone gets software”
How Is This Done?
To provide device-specific downloads, our builds now produce an Android Application Bundle (AAB) format. When a user downloads the eBay application, Google generates the specific APK needed for that device. The download has the specific language, native libraries, image sizes and layouts that are needed for that device's configuration and resolution.
Below is what that means for our eBay application:
We saw a 30 to 50 percent total disk space savings going from roughly 94 MB to 59 MB. This has a very real impact on download and install conversion for every customer. However, reducing APK size opens entire global markets where data can be expensive and users limit app installs based on download size and cost.
eBay was one of the partners called out in this year at Google’s Android 11 Beta event
What’s Next?
Now that we have begun to leverage App Bundles and have decoupled our code into feature modules, we are able to take advantage of Google’s Dynamic Feature Modules. Built on top of the same delivery mechanism as App Bundling, we can now begin to craft features built for specific users and adapt automatically as their needs change.
For example, if a user has limited Internet connectivity for their device, perhaps they may simply want the ability to search, view and purchase an item. Since they are not interested in heavyweight libraries, such as AR/VR, we wouldn’t have to force them to download those capabilities. Should their needs change, the features can be downloaded dynamically, in real-time at some point in the future. This will greatly reduce the initial download size of the app, providing a better global user experience regardless of device level or bandwidth.
The benefits of Dynamic Delivery are enjoyed by every customer, especially given our future desire to power new machine learning data models on device. These models can be quite large and Dynamic Feature Modules will allow us to only download what is needed.
The Journey Continues
The rearchitecting of the eBay native apps has been a multi-year journey. As the pieces fall into place, we have been able to accelerate development to the benefit of our eBay teams and customers. This architecture will power the future of native eBay features and create exciting possibilities for our product teams and customers. We will continue to update our progress and deep dive into other areas of the architecture in future posts.