Agoda’s Journey from Native to Cross-Platform Technology — a Product Manager’s Summary
Cross-platform technology and hybrid apps using WebViews have been rapidly gaining traction among tech companies that have a strong presence on both web and mobile platforms. While newer companies can readily adopt these technologies, for established tech companies, like Agoda, with complex systems and extensive legacy codebases, this transition is a monumental task. This article aims to highlight the problems that WebView and cross-platform technologies solve and highlights Agoda’s journey towards adopting them.
Before diving into the details, let’s set the context.
What is Cross-Platform Technology?
Problem statement: An online business can maintain its presence across four different platforms: Android App, iOS App, Mobile Website, and Desktop. Developing any feature requires separate development efforts for each platform as well as hiring resources with different capabilities. This not only delays the time to market for features but also increases the lines of code and development costs.
Additionally, new features or changes on Mobile Websites or Desktop are instantly visible to all users through over-the-air (OTA) updates, with no action needed from them. In contrast, updates to Native apps require a new deployment, meaning users must upgrade their apps to access new features or changes. As a result, new features or experiments on apps initially reach only a subset of users and can take a long time — sometimes years — to be seen by everyone. Forcing app updates is an alternative but may lead to conversion loss.
Solution: Online businesses usually leverage the following approaches to address these problems:
1. WebViews or Hybrid apps using web technologies: This approach involves building hybrid apps using HTML, CSS, and JavaScript, which are encapsulated in a WebView. These WebViews are wrapped in a native container to render the web content in an app and have access to native device features via plugins (example: how LinkedIn opens YouTube videos inside the app itself and not redirect to a browser).This solution is ideal for less complicated user interfaces, where there are limited user interactions (example: a check-out page where user needs to enter some details, confirm items and make the payment). Some examples of frameworks using WebView technology include PhoneGap, Cordova, and Ionic (when used with Capacitor). Additional benefits include well-established open-source frameworks and strong community support, thanks to significant technological advancements in recent years.
WebView solutions support over-the-air updates, allowing new features to be rolled out to all users without requiring them to update their apps. However, they typically don’t provide a native user experience due to web loading times.
2. Other cross-platform technologies: Other cross-platform technologies use frameworks and tools that allows code to be written once and deployed across different platforms, ensuring an ‘almost’ native-like user experience. Proper usage of this technology helps build the platform while respecting major to minor differences in layout, navigation, state management, performance, and testing across different platforms. Examples of frameworks using cross-platform technology include React Native, Flutter, Xamarin, and .NET MAUI.
These cross-platform technologies, on the other hand, offer a more native-like experience and enable writing code once for both iOS and Android apps, but they generally don’t support the web well and don’t typically include over-the-air updates out of the box.
Apart from the once mentioned above, Server Driven UI (SDUI) is also a possible approach to address the problems. SDUI is a design pattern where the server controls the presentation logic, sending data and layout instructions to the client. This allows for dynamic UI updates based on server responses, providing a unified approach across platforms. However, in our experience, implementing SDUI proved challenging as the engine became increasingly complex, resembling a custom-built browser. This complexity, coupled with the difficulties in achieving a seamless user experience, led us to reassess our strategy and shift focus. SDUI supports over-the-air updates for server-driven components, but if new components are to be built on the client, over-the-air updates may not apply.
Let us look at how these technologies have evolved over the years.
In 2010, Apple revised its App Store guidelines to allow cross-platform development tools like Unity (for gaming), Adobe Flash, and PhoneGap (later Apache Cordova), which had previously been restricted. This change, spurred by competitive pressure from Android’s open ecosystem, enabled developers to create apps for multiple platforms using a single codebase, significantly advancing the adoption of cross-platform technologies.
As almost all comparison videos, tutorials, and blogs suggest, the technology an online business chooses depends on its capabilities and user requirements. Many technologies have become obsolete over the years while new ones have emerged, and this trend is expected to continue. The four major companies behind these technologies — Ionic, Facebook, Google, and Microsoft — are expected to keep investing in them.
Agoda’s Approach to Cross-Platform Technologies
At Agoda, we began incorporating WebViews into our app development as early as 2012. However, their use was initially limited to the post-booking user funnel, specifically the “Manage Booking Page,” due to concerns about the negative UX impact of using non-native solutions on the pre-booking user funnel, which is quite conversion sensitive.
With technological advancements over the past few years and leveraging our prior experience, we decided to incorporate WebView into the pre-booking user funnel. This initiative aimed to provide a clear understanding of the impact on conversion and business, as well as potential challenges and valuable data on other metrics such as performance, navigation, and context/cookie passing. We decided to initially build a hybrid page by reusing our existing Mobile Web and rendering it inside the app. We made this bet because maintaining code for four platforms is a huge overhead, and the overall impact of slower loading became an acceptable tradeoff.
To make an accommodation booking on Agoda, a user goes through the following journey:
- Home: To select the type of booking the user intends to make.
- Search List: To show the list of properties in the desired location.
- Property Info: To present all relevant property information.
- Room Info: To show benefits and amenities for a specific room and offer.
- Checkout: To collect guest and payment information.
After completing these steps, the user proceeds to booking confirmation.
As a company driven by data and experimentation and fueled by a culture of building rapidly and embracing fast failures, Agoda tackled this initiative with both caution and speed. In Q3 2022, we chose to experiment with WebView by migrating the Mobile Web UI to native apps (iOS and Android), focusing initially on the Checkout page. This page, while less sensitive to performance, offered significant advantages from a shared codebase and posed an intriguing challenge due to its critical role in conversion.
Following a design review, the effort was estimated to require approximately 25 developer quarters of work. We began laying the foundation with a team of 12 developers in the last quarter of 2022, aiming to finish by mid-second quarter of 2023. However, as is often the case with complex projects, our initial estimates were significantly off!
Migrating Checkout Page to WebView
Agoda serves its customers via Mobile, Desktop Websites, and Apps. The task at hand was to render the Mobile Website inside a native container and display it on the Mobile Website. Since we already had a running Mobile Website, this task may sound quite straight forward. But, as you may have guessed by now, it was not!
We divided the project into four phases, each increasing the percentage of users we experimented with migrating to WebView. The phases were based on the user’s origin and logged in/out status. The selected origins would define;
- The payment methods we needed to support first (for example, card payments can be made on the same screen, whereas bank payments require interaction with native to open bank apps) and
- Localized and legally required features. The logged-in/out status of the user was crucial for technically handling state management.
With the majority of our bookings coming through app, the teams had optimized the app’s UI and UX more than the Mobile Website over the years. So, we split the team into two: one to optimize the Mobile Website UI/UX using learnings from previous app experiments, and the other to focus on solving technical complexities to move to the next phase, i.e., unlocking more origins and user segments to experiment with WebView. Thus began our immense learning journey!
Major Challenges Faced During the Migration
- Platform inconsistencies
Maintaining four platforms (Android App, iOS App, Mobile Website, and Desktop), as separate codebases, over time, inevitably results in implementation discrepancies, some intentional and some unintentional. We observed that the apps had become more optimized in terms of UI/UX, with more user-friendly features. As a result, similar improvements were necessary for the Mobile Website to match the conversion rates of the apps. Our focus was to achieve parity in price, availability, and major features between the Mobile Website and the Apps.
1a. Price and availability inconsistency:
Both price and availability consistency are crucial for a user. Prices for the same property can vary based on several user factors, such as VIP tier, logged-in status, discounts, and cashback eligibility. Room availability also depends on sending the correct parameters to backend systems, and any errors can cause users to bounce back to the Room Info page or other errors.
To ensure price and availability consistency, we conducted an experiment by sending the same response from both the native app and WebView using identical user search and selection criteria. This “shadow price and availability experiment” helped us identify inconsistencies between different platforms during the testing and development phase. Our robust data collection abilities made it easy to replicate real-time requests in the testing environment without impacting the users.
Initially, due to the complete change in backend systems, the accuracy between native and WebView was only about 60%. Through systematic fixing of issues, we eventually achieved a final accuracy of over 99.5%, which was within our acceptable range. This process also revealed significant differences in feature flags across different platforms. Even iOS and Android had noticeable differences, let alone discrepancies between Mobile Web and Apps. Thanks to this analysis, the following cleanup is planned in different teams.
1b. UI/UX and features inconsistency:
As mentioned earlier, with the increase in booking share on Apps, the UX/UI had been more heavily optimized for conversion on Apps than on the web. This meant that if we were to replace the Mobile Web UI and use it within the native app, our A/B experiment — where A is the native UI, and B is the WebView or Mobile Web UI — would likely lose significantly.
To account for this potential loss, we conducted several negative experiments on native as well as leveraged prior experiments to come up with an acceptable conversion loss percentage. Using the RICE framework, we also prioritized building a similar experiment for the Mobile Web. This effort not only refined our approach but also enhanced the experience for our Mobile Web users, leading to conversion improvements there. In addition to UX/UI optimizations, we discovered that several features had been built exclusively for the native app over time and did not exist on the Mobile Web. The team also undertook tasks to achieve feature parity between platforms.
2. Navigation (internal and external) and deep links
Internal navigation requires seamless back and forth between different pages of the app, such as moving from Room Info to Checkout and back or from Home to Checkout and back. These transitions must be meticulously managed on the client-side. Additionally, consistently injecting and synchronizing crucial contextual information (appInitContext), which includes feature flags, user preferences, user agent, analytics IDs, etc., across different pages is essential. Any failure in managing navigation or appInitContext could lead to user bounce backs or changes in prices and availability.
Conversely, external navigation often faced challenges, particularly when redirecting users to external apps such as bank applications for payment processing, disrupting the user experience. Additionally, managing deep links, which are crucial for redirecting users to specific in-app content, required precise handling to ensure that users land on the correct page without encountering errors.
These challenges can be addressed by creating an abstraction layer that conceals the complexity of navigation and allows developers to work uniformly without worrying about these intricacies. Following the migration, we are gradually transitioning to such a framework, which we are developing in-house.
3. Testing and analytics
Testing was particularly challenging for Checkout due to the complexities surrounding payments. Agoda supports over 90 payment providers across nine categories, including cards, online banking, eWallets, ATM, OTC, and installments. Although most payments were already supported on the Mobile Website, the interactions between native and WebView environments made the migration process complicated. With extensive support from our truly global Agoda team and a third-party testing company, we identified regional, device-level, payment category, and provider-level differences.
Additionally, to identify user segments where the experiment or conversion was underperforming, it was essential to ensure a direct comparison between A (Native) and B (WebView). This requirement led us to improve our data logging and address discrepancies across Mobile Websites and Native front-end analytics.
After a little over a year of dedicated effort by the team and support of other corresponding teams, we successfully migrated the Checkout page from Native to WebView for both iOS and Android Apps. Contrary to our initial estimates of experiencing a short-term conversion loss in exchange for long-term efficiency and speed, we achieved a decent conversion win on WebView. This increase in conversion was primarily driven by resolving bugs that were present on Native but unknown before the WebView project.
Top Learnings Coming Out of the WebView Project
1. Migrating to WebView does lead to significant increase in velocity:
It has been just over a quarter, and we’ve already observed a substantial increase in efficiency and development speed. The Checkout team has experimented with over 15 new features affecting iOS, Android, and the Mobile Website simultaneously, utilizing only about a third of the developer time that would have been required for separate development across the three platforms. In terms of KPIs, the team has targeted and achieved three times the quarterly commitments compared to last year.
WebView implementation ensures consistent UI and similar UX across platforms, potentially not fully optimizing overall conversion rates. However, from our prior experiments, these UI/UX differences show minimal long-term impact. One downside is that testing now takes twice as long to address, so we are implementing a robust testing strategy. Overall, WebView has been a huge win for us, seeing the overall development efficiency and faster time to market for features.
2. WebView slower than native; however, didn’t significantly impact conversion:
As expected, WebView is indeed slower than native. Several efforts were made to ensure that the loading time of WebView is as fast as native. A major enhancement involved preloading elements of the Checkout page while the user was on the Room info page. After several other bug fixes, we reached a point where on iOS, WebView took approximately 30% more time to load than Native, while on Android, WebView took around 70% more time to load at 90th percentile. Although the overall loading time is currently longer, the actual interface is just as responsive, and the same level of UI complexity was achievable.
We noticed that WebView loaded more slowly on older Android devices, negatively impacting conversion rates in regions where such devices are more prevalent. Despite this, our experiments showed that most users were willing to wait longer for the Checkout page to load, resulting in an acceptable short-term conversion loss. Efforts are ongoing to make WebView load faster on both platforms. We are also exploring pre-bundling of web code into app with OTA (Over-the-Air) updates, which should significantly improve initial load times. Overall, the slower loading is not unsolvable; we have decided to address it in “phase 2” due to the minimal impact on our customers.
3. Critical roles of Engineers and Product Managers:
Engineers are the most valuable assets for any tech organization. At Agoda’s product organization, we affectionately refer to them as “Our Precious” (a nod to Lord of the Rings). Building a strong engineering team for a technical project of this magnitude was crucial. While we had a couple of new faces at the start of the project, everyone worked as a solid team to move things fast. Also, the role of engineering lead in such projects is vital, as they are responsible for making tough decisions and taking significant risks. The role requires them to be right most of the time because once an approach is adopted and developed, changing course can be time-consuming, challenging, and painful.
While some may question the role of a product manager in such technical migrations, I believe it is quite essential too. Product managers not only manage stakeholders and timelines but are also required to analyze user pain points, experiment results, and prioritize rigorously, which makes them equally responsible for the success and fast execution of the project. With learning over the years, at Agoda, product teams are always involved in such migrations, allowing the team to adjust and make decisions efficiently, preventing delays.
What’s Next for Agoda
After successfully migrating a page in the pre-booking funnel to WebView and seeing clear benefits from it, Agoda now plans on:
1. Rendering WebView checkout on Desktop:
By making the UI components responsive according to the screen size, we have started an effort to render the WebView layout on our Desktop. This would help us build only once for all four platforms. We expect this change to noticeably improve Desktop as well as Tablet users’ experience.
2. Evaluating other cross-platforms and WebView:
While working on getting the Mobile Website on to the App for the checkout page, we funded another team that initiated work to determine the best fit for Agoda by doing an MVP with React Native, Flutter, and Ionic. The goal was to evaluate each framework in terms of UI and UX similarity to native apps, developer experience, and feasibility of implementation for Agoda’s specific use cases. Each criterion was broken down into sub-criteria for cumulative scoring. For building an MVP using different frameworks, we aimed to test the riskiest assumption first in the shortest possible time.
Based on our analysis, Flutter performed well in terms of performance and matching the capabilities of native mobile. However, it wasn’t the ideal solution for us as it does not support OTA (over-the-air) updates or SEO (search engine optimization) tags. Additionally, Flutter posed numerous challenges when rendering mobile websites and desktops using the same code, such as responsiveness issues, non-functional platform plugins, and security exceptions. React Native supported OTA updates and SEO tags but required third-party libraries to render mobile websites and desktops, which we anticipated could lead to critical scalability challenges. Building further on WebView with frameworks like Ionic coupled with native plugins proved to be the clear winner for us, as it not only supports OTA updates and SEO tags but also was easily customizable to meet Agoda’s changing requirements.
After extensive research and building POCs with different cross-platform frameworks, we decided to use Agoda’s internal Design System for responsive UI components with some of Ionic capabilities, and custom solutions to handle seamless navigation, state sharing, and passing common context (such as headers and cookies) from the server. We plan to test the performance and feasibility of our in-house developed technology on the “Room info” followed by the “Property info” page. The project is already in full swing and progressing rapidly!
Acknowledgements
Only a few tech companies have motivated teams that constantly challenge the status quo, adapt to evolving technologies, and manage to move swiftly. Agoda and its culture, in my view, has consistently demonstrated its ability to attract, develop, and retain such driven individuals. Achieving a project like implementing WebView on the Checkout page in just over a year without causing any major disruptions for our users is a remarkable accomplishment. I’m glad to have been part of this initiative and would like to express my gratitude to Valerio Muzi, my engineering counterpart, the entire Checkout team, other corresponding teams, and the technology and product leadership — Idan Zalzberg, Ittai Chorev, Royee Goldberg, Gavin Stevens and Max Panasenkov — for their immense contributions and support.
