Managing App Size for Super App
TL;DR - I’d like to share our initiative in Bukalapak which resulted in a reduction of 35% of app size while continuing new features developed in parallel. This includes raising awareness, technical approaches, product approaches, and managing new and existing features.
Emerging markets, like Indonesia, are very exciting places to work on consumer apps. Indonesia has a 270+ million population with a 1% increase annually, high economic annual growth (~5%), a large base of emerging middle class (20%), high penetration for smartphones (30%), and internet (40%). There are many unserved customer problems and opportunities for tech and online businesses to solve. The tech scene in Indonesia started around 2009–2010 when some companies like Bukalapak, GoJek, Tokopedia, Traveloka started, and now have become unicorns. Their apps have also morphed into super apps. They have grown from solving one customer problem to covering a range of consumer services. For example, Bukalapak which used to be a marketplace for only physical products now has many more products including virtual products, investment, gold, travel products, games, live streaming, and more.
There is a common belief that it’s a mistake to cram too many features into an app. Apps need to do just one thing well. However, the super app model seems to work well in the high growth tech scene in Asia. This article is not to discuss which model is better. But rather, to discuss the challenges in developing a super app in emerging markets with the lens of app size. With more features added to a super app to cover more consumer services, the app becomes bigger, heavier, and requires a more powerful device to run on in general. As a comparison, Bukalapak iOS/Android app size (June 2020) is 161/36 MB, Tokopedia 182/40 MB, Gojek 232/75 MB, while Amazon is 115/42 MB, Netflix 71/15 MB, and Twitter 116/18 MB size. While it’s common for people in developed countries to upgrade phones every couple of years, people in emerging markets keep their phones much longer than that. The bigger the app size, the heavier it is, and the more performance problems it has when running on older phones. There are also problems with internet availability, bandwidth, and stability in emerging markets. It’s common that people in emerging markets have very limited mobile data plans, and may not even have home internet service. The bigger the app size, the more data needed to install, update, and use the app in general. And there is also a limitation imposed by AppStore that only allows app download > 200 MB using wifi, not a data plan.
Here are some steps on how we accomplished a huge app size reduction.
- Raise Awareness and Assemble the Team
We started by tracking what needs to be fixed including app size and performance. We analyzed the trend of the app size increase per quarter and customer complaints we received every time we launch big product updates. Finally, we monitored the size and performance benchmark with competitors. We made the size problem and the data backing it up visible to company-wide because the issue would need to be fixed together by many product teams in the company. Next assembling the team. Because we projected that the effort would require both product and technical approaches, we assembled the team, who to drive the initiative, with members who have more technical aptitude than those required in a regular product team. Technical product manager, technical project manager, architect, and strong engineers.
2. Technical Approach: Refactoring, Modularizing, and Compressing
On the technical approach, we looked for ways to reduce the app size including removing dead code, refactoring old code, improving caching for resources, simplifying CSS, optimizing server-side rendering, breaking down third party libraries, modularizing internal components, and exploring compression technology such as WebP. WebP is a modern image format that provides superior lossless and lossy compression for images on the web. Using WebP, webmasters, and web developers can create smaller, richer images that make the web faster. This article won’t go into the technical details of what we did. It simply points out that in order to reduce app size, some very technical approaches are needed. Hence, the importance of bringing in very technical members early in the project.
3. Product Approach: Build Principle How to Get There
In Bukalapak, there was a tendency to build a feature in the form of a native app by default. However, not every feature is created equal. Some features are more important than others. They provide experiences close to the core of our app which is a marketplace. For example, product search, listing, add-to-cart, payment to name a few. Some features also drive more business impacts than others in terms of active users, transactions, and revenue.
Based on the impact of each feature, we consider three different deployment solutions: native application, dynamic delivery, or web view. Dynamic delivery is a feature in Android where the Google Play Store pushes only the code and resources needed for that module to the device at the time your app needs it such as when a user launches a feature for the first time. Dynamic delivery and web view approaches don’t increase the size of its original app bundle. We use those two approaches for some features not core to our e-commerce experience and not driving high business impacts.
We built principles to guide when to use what and share that with all the product teams. Example below.
4. Managing Existing and New Features
Imagine that you are holding a bucket, the end of a garden hose is in that bucket. The other end is connected to a running water tap. The water flows from the tap, through the hose, and into the bucket. As time progresses, the bucket is getting heavier from water coming in. The water coming in describes the new features. We need to slow down the rate of water coming in.
For product leaders, we need to be aware of all the product features being developed in the company. In Bukalapak, we have a homegrown consolidated product roadmap tool that rolls up roadmap items from 55+ product teams with each’s estimated impact and effort. We have visibility on how much effort we spend on new product development, product improvement, and tech debt. Our ratio is 30% new product development, 60% product improvement, and 10% tech debt of 250–300 total roadmap items per quarter. We looked closely at each new product on the roadmap with its impact. Then we picked some of the new product items to be built with dynamic delivery or web view approaches based on the criteria mentioned earlier, and discussed those with relevant teams.
Then there is water already in the bucket. That’s the weight of the existing features which might have been there for years. We need to take some of those weights out from the bucket. Same exercise. We looked at existing products/features with each’s impact. For some, we discussed with the relevant teams to convert from their original native form to use dynamic delivery or web view approaches. For some others, we suggested sunset forever.
Summary
In summary, it’s critical to understand what is important to your customers in your region. In some regions (emerging markets), users are ok with a lower speed of connectivity but have a lot of concerns on data usage. In some other regions (developed countries), users want everything fast, instant, and also have abundant data plans to be used. Once you figure out what is important to be fixed, treat that as its own feature in the company by resourcing it with a capable team, and aligning support. After two-quarters of effort, we were able to reduce our app size by 35% while maintaining all the product development running in parallel. Through these efforts, we also improved the performance of the app including start time, frozen frames, application not responding, etc.
* I’d like to thank Niranjan Kumar, Hasanul Hakim, Rizky Habibi, Patrick Marshall from the Bukalapak Core App team for your awesome contribution.
