October 6, 2021 Read 11 Min

App Size Optimization: Does the Grab Super App Take Up Too Much Space?

Must super apps come in super sizes? We dissect Southeast Asia’s leading super app and talk app size optimization.

App Size Optimization Grab Superapp Snappymob Blog

What was plain old Grab before is now officially Grab Superapp on the app stores. As we’ve mentioned in our introductory article on super apps, Grab has been one of the fastest-growing super apps in SouthEast Asia for a while now. But especially when ASEAN apps are scrambling for the title of SouthEast Asia’s leading super app, this label change was definitely a smart move to call dibs on the title. 

However, with the foreseeable future where super apps take over app stores, there is one concern that may grow among mobile users — storage. Does opting for super apps over single function apps also mean using up more storage space? Does more functionality mean bigger app sizes? And if it does, does this call for special attention on app sizes for super apps

To those who are aware of cache storage, it’s no surprise that social apps like Twitter and TikTok take up relatively more space on devices despite seeming like single function apps. Each of these apps can occupy 1GB and more because of caches filled with images, videos, and other content data. But what about multifunctional utility apps, like Grab? 

How much space do they occupy, and what exactly is taking up that space? Let’s take a deeper look.

Grab Superapp’s Current Size 

To get a ballpark figure of the super app’s size, we surveyed around and gathered its exact size on about 50 different mobile phones. What we found is that the Grab SuperApp averages at 340MB on iOS devices, and 400MB on Android devices.

Grab app size comparison between iOS iPhone 11 and Android Huawei P20 Lite.
Image: Grab app size on iOS (iPhone 11) and Android (Huawei P20 Lite)

Why is it slightly bigger on Android?

This is an interesting observation because in most cases, it’s the other way around. iOS apps are usually bigger than Android apps due to several reasons — their native code, artwork resolutions, private support libraries, and ipa files which act as virtual environment wrappers around their apps.

Grab’s oddity here might be due to certain libraries on the Android counterpart being larger in size compared to iOS.

Grab’s Services and Countries of Operation

Before working our way into the complexities, let’s first explore the general make-up of the app. What’s in the list of services offered by Grab Superapp?

1. Food and Shopping: Food, Mart, Shopping
2. Delivery: Express
3. Transport: Car
4. Top up: Prepaid, Bills
5. Finance: Insurance
6. More Value: Offers (Food and Mart)
7. Home Services (WebView): Clean & Fix (Kaodim)
8. Travel (WebView): Attractions (Klook), Hotels (Agoda, Booking.com)
9. Gifts (WebView): Gift Cards

As of 2021, and since Grab brought over Uber from their South East Asia operations, they’re currently operating in 8 countries: Malaysia, Singapore, Thailand, Philippines, Vietnam, Indonesia, Myanmar, and Cambodia.

Grab Superapp operating countries and cities showing all cities in Malaysia.
Image: Grab Locations (Grab SG)

One possible reason for the app’s size is that it isn’t fragmented into regional versions, e.g. Grab Malaysia for Malaysia, Grab Thailand for Thailand, Grab Indonesia for Indonesia, etc. 

Instead, the app’s services switch to a different region when it detects that you’re in that region. Wherever you go, you’d essentially be using the same app, without the need to download a regional version, create a new account, or set up a new payment system. Users with Business accounts can also keep record of their travel expense claims all in one place wherever they are. 

This multi-regional support is really good for convenience and maintenance. But the Grab super app will have to store the different customisation settings of 8 different countries, and that definitely has an effect on its size.

What’s Taking Up the Space?

Let’s first get the negatives out of the way — what’s not taking up space? What doesn’t occupy much space, or at least more than it needs to, is WebView. WebView, a native component provided by the Mobile SDK Framework, is basically a web browser component inside an app. If done well, WebView can be a seamless experience.

Grab uses this for external vendors under Grab’s Clean & Fix and Shopping tabs. When users tap on Clean & Fix (Kaodim), or any of the shopping vendors like Zalora, Dyson, and Decathlon on the Grab app, they get access through an in-app browser. This requires minimum development work on Grab’s end and gives vendors control over the experience and maintenance.

But in such cases, what app developers can do to minimize the app’s size even further is enable it to pass in data in the form of Cookies. What this means is that when a user browses Grab’s services while logged into their account, Grab can pass in a unique user ID. This way, when a user makes a booking on Kaodim through the Grab app, Kaodim will be able to identify the user while still providing a personalized experience.

Now that we’ve sorted the negatives out, let’s look at what could be fattening up the app.

Speculation #1: Mobile Payment SDK

Software development kits (SDK) are installable third-party solutions that help developers integrate third-party services into apps quicker and easier. They are essentially packages that include documentation, libraries, debuggers, code samples, drivers, protocols, and more. 

SDKs are a powerful and integral part of the app development process, but they can also be the culprit for a large app size. App developers need to look out for an excessive SDK count to prevent an oversized app. Any obsolete or buggy SDKs should be removed from the app. Only necessary, lightweight, well-maintained, and bug-free SDKs should be included. Another tip would be to use modular packages instead of global packages.

So does Grab Superapp contain one too many SDKs? Let’s take a look at what makes up Grab’s payment system.

GrabPay wallet chat messaging and send money.
Image: Chat Messaging on GrabPay

1. GrabPay: Chat Messaging, Send Money
2. Credit/Debit Card: VISA, Mastercard, American Express, etc.
3. Payment Services: PayPal, Apple Pay, Google Pay, DuitNow QR
4. Linked Bank Account: Maybank2U (WebView)
5. My Rewards: Vouchers, Coupons
6. Top Up: Bills, Mobile Prepaid

Because each vendor has their respective implementations, mobile payment SDKs may occupy a lot of space combined. This might eventually call for the use of a unified payment service that allows for contactless transactions across services.

As of yet, GrabPay DuitNow QR is enabled for all GrabPay preferred merchants where payments are accepted through not just GrabPay but any participating bank and e-wallet apps. If DuitNowQR continues to be adopted across Grab’s services, this would cut down on the need for multiple SDKs in the app.

Speculation #2: Localization

With localization support, the Grab Superapp is incredibly adaptable, versatile, and accessible to a widespread audience. But what this requires is for the app to contain assets for all its supported languages, as well as localized graphic assets and functionalities. 

The question: Do these assets make a huge dent on app size?

What bloats up an app isn’t localization per se. Localized strings and assets in an app’s codebase can fatten the app, but only with inefficient engineering. Here are two use cases that demonstrate the effect of languages, fonts, and image assets on app size:

1. Multiple languages ≠ Big app size. King’s Cup, an app that supports 18 languages, contains localized strings in the form of text. The difference they make on the app size is negligible. With 18 languages, the app size stands at 11.29MB. And when stripped down to 1 language, it only reduced to 11.27MB.

2. Localized images ≠ Big app size. Betacard app supports 100+ fonts, including English and “heavier” fonts like Chinese Simplified, Chinese Traditional, and Thai. When it came to certain parts of the design where the code used typeface files, we replaced the typefaces with images and managed to cut down on the app size by 40%.

Rather than over-engineering an app and stuffing the app with omittable content, using the appropriate tools for each use case is important. Though we can’t peek at the inner workings of the Grab app, considering that its app size is pretty standard, it’s safe to assume that they’ve covered localization well.

Speculation #3: Image Compression Format

Since image assets have to be imported in different resolutions for different screen densities, Grab Superapp’s large amount of images could be taking up a big portion of its overall app size.

Grab superapp GrabFood localized images and graphic assets.
Image: GrabFood tab with localized graphic assets

Since image resolutions work with a multiplier, image assets can get really big really fast. The framework in Android 4.4 and higher supports a hefty list of densities: ldpi, mdpi, tvdpi, hdpi, xhdpi, xxhdpi and xxxhdpi. Meanwhile on iOS, the number of times the pixels in each image are multiplied follows a designated scale factor by @1x, @2x, and @3x. 

These multipliers exist so each device gets only the necessary image resolutions in an app upon installation. Without scaling image assets this way, large images not only take up unnecessary space in the installer, but will take forever to load on smaller devices that may not even have the capacity to display the image. 

Apart from that, any uncompressed or inflated image files can also lead to large app sizes. To combat this, vector graphics, WebP files (Android), and basic image compression for PNG and JPEG files can be used for better optimization.

1. Vector graphics: Vector graphics can be used to create animated images, resolution-independent icons, and other scalable media for a reduced APK footprint.

2. JPEG and PNG: Basic compression can be done on JPEG and PNG files using image compression tools. As an alternative, PNG files located in res/drawable/ can be crunched with lossless compression using Android’s AAPT tool, provided that the image files use 256 or fewer colors.

2. WebP (Android): The WebP file format can be used in place of PNG or JPEG image files, when targeting Android 3.2 and higher. It allows for lossy compression and transparency and can provide better compression than JPEG or PNG.

Speculation #4: Offline Support

Though we can’t verify much on offline support on Grab Superapp, this is one functionality that can fatten up an app. Why? 

Offline support helps apps retain a smooth experience in the event of an unstable network connection. This requires data and assets to be stored on the user’s device so they can be displayed even when the user is disconnected, whether intentionally or unintentionally.

For example, if a user is halfway through a trip and finds himself in an area with a dodgy network, he’ll still be able to navigate with offline support on the app. When a user’s search history and saved locations are cached, they will still have access to their pinned and previous destinations with a weak network connection.

So it’s pretty obvious that offline support is great for user experience — It’s a lot less disorienting than a blank state with a placeholder. However, this resilience to network instability comes with the price of a fatter app size.

Does Grab SuperApp Take Up Too Much Space?

Compared to other much larger apps, Grab Superapp doesn’t actually take up a painful amount of storage space. The only reasons why it may scale above 400MB on certain devices are higher screen resolutions and cumulative cache assets.

However, this doesn’t seem to be an issue. For many, Grab Superapp’s benefits outweigh concerns about its app size. After all, it’s an app that offers multifarious value. Being able to connect your contact details and payment methods to a long list of services that are immediately accessible in multiple regions? 

400MB of device storage doesn’t sound like a bad deal at all.

On the contrary, if one were to use multiple single-function apps in place of Grab, the damage on their storage space would be much bigger. Here’s a side-to-side average app size comparison between Grab Superapp and its equivalent utility apps by service.

Grab Superapp ServicesEquivalent Apps
GrabCarMyTaxi – 80MB
GrabExpress LalaMove – 90MB
GrabFoodFoodPanda – 180MB
Grab HotelsBooking.com – 130MB
GrabMartHappyFresh – 100MB
Grab Clean & FixKaodim – 120MB
400MB700MB
Table 1: Average cumulative size comparison between Grab Superapp services and equivalent utility apps

Do Super Apps Have to be Super-Sized?

Short answer: No. 

Super apps would already be greatly frowned upon if they must come in large sizes. Nobody likes big-sized apps, and that’s why super apps are favorable.  They aren’t always big; and even if they were, it’d be justifiable. Without having to download new apps to access different functions and services, the perks of having a super app include saving time, energy, and storage.

Circa 2017, smaller apps were found to bring in higher install conversion rates. A study by Google showed that for every 6MB increase to an APK’s size, there was a 1% decrease in the install conversion rate. This universal distaste became pretty much impossible for app developers to ignore. If they wanted their apps to fare well, they’d have to avoid asking for high data consumption, long download durations, and high storage usage. And this is why super apps exist.

So no, super apps aren’t always big just because they accommodate a wide range of services. Developers have great options for reducing app sizes today — more features and functionality doesn’t have to mean bigger app sizes anymore. 

If you’d like more comparisons, most super apps like Grab and Uber range between 300 to 600MB, and don’t take up nearly half as much space as do social apps like Instagram and Facebook due to media cache files.

Super AppApp Size Social AppApp Size
Grab Superapp400MBFacebook370MB
Uber340MBTikTok1.2GB
GoJek350MBInstagram300MB
TnG eWallet200MBTwitter1.3GB
Table 2: Average size comparison between super apps and social apps

How Developers Reduce App Sizes

As we’ve mentioned, small apps perform better in the market. So it’s a must for app developers to be wary of optimization and keeping app sizes at bay. How is this done today?

Back in the early 2010s, APK and universal IPA files were known as a one size fits all solution that could cater to every device. Whether you were on a 4” iPhone screen or a 10” tablet screen, the same file can be installed and used without a problem. But because all of the apps’ binary codes, resources, and profiles are enveloped within a single file, APK and universal IPA files often result in very large sizes. 

As a result, users on devices with smaller capacities had to bear with their storage space being eaten up, while others on larger devices would be left with underutilized space. In other words, APKs and universal IPA files were like stretchable free-size shoes that would squeeze a little tight or hang a little loose on certain pairs of feet.

So Google and Apple tackled the issue with new and improved solutions:

Android: App Bundle

The Android App Bundle allows developers to create multiple APKs with a single artifact without the need to refactor their code or manage different codebases. This app publishing format allows for the fragmentation of single APKs into multiple smaller APKs that are compatible with different screen densities, locales, and modules.

Through modular app development with dynamic feature modules, developers can choose how and when their app loads additional features. This means certain features can be available to specific regions or devices, or delivered on demand only when a user needs them.

So instead of expecting everyone to accept monolithic apps, Android users now get apps that are specifically optimized for their device when they download from the app stores. No extra capabilities and nothing compromised — just exactly what is necessary.

Reducing App Sizes with Apple

A similar practice is recommended for iOS apps except without a fancy name. This process involves creating an app size report with Xcode’s built-in reporting tools, and creating a folder with the app’s artifacts, based on which one can perform basic optimizations to reduce the app size. 

The folder will include:

  • A universal IPA file for older devices, containing assets and binaries for all variants of your app.
  • Thinned IPA files for each variant of your app, containing assets and binaries for only one variant.

Epilogue: The Future and the Takeaways

With existing solutions like dynamic feature modules and IPA app thinning, the future for super apps looks nothing but bright. As far as functionality and size are concerned, they’ve got the best of both worlds. Benefiting consumers, facilitators, and vendors alike, it’s largely a positive thing that super apps are gaining popularity all ‘round the globe today.

What are the main takeaways here?

1. Grab Superapp is storage-economical.

Grab’s app size averages at 400MB and relatively falls on a midpoint between small and big. Considering its array of localized content and services, it’s pretty worth having it installed in place of multiple single-function apps to save on storage space.

2. Small apps win! 

Numbers don’t lie. The larger the app, the lower the install conversion rate. Optimization is key to a high-performance app.

3. Small super apps win even more. 

People generally favor multifunctional apps over single-function apps. If they’re optimized well and reduced in size, they’re even more likely to perform well in the market.

Need Help with Apps?

You’re in the right place. Snappymob is a team of web and app experts who have years of experience in kickstarting and boosting mobile strategies. 

Check out our work to learn more about what we do, or drop us a message for a chat about your ideas!

If you liked this, you may also like: