How eBay Motors Made Use of Flutter to Increase Performance

How eBay Motors Used Flutter

In December 2018, the eBay team was invited to create a new Android and iOS interface for buying and selling vehicles on eBay aimed at motorists. They were given autonomy to investigate, develop, and build the eBay Motors App as they thought fit. Regardless, they anticipated getting from concept to both application shops in less than a year. It had to have a list of characteristics that current eBay clients had typically expected. They were both energized and slightly terrified by this opportunity, and they needed to outperform expectations.

For a long time, the eBay team had collaborated on the development of native applications. They recognized what they were capable of and that this would be a massive undertaking. If they continue to use the traditional native product, it will be impossible to construct two independent applications with a small crew.

They had previously studied cross-platform SDKs and had been underwhelmed. Fortunately, only a few weeks before their group was assigned its mission, Flutter 1.0 was released, and it took a promising new approach to the cross-platform issue. The eBay team had been watching the events unfold, and the arrivals of Flutter, and they were well aware of the excitement that was developing around the technology. The primary stable release, as well as Google’s good roadmap, suggested that Flutter might be the answer for their crew to express on the two stages convincingly in a strictly constrained period. Flutter approached UI development in a way that answered many of our concerns.

They realized that staking everything on a new invention was a risky proposition. Fortunately, product manager Richard Sipe and designer Thai Dang needed time to develop a product vision, so they had some wiggle room to determine whether Flutter was the right fit. They intended to hold team workshops to learn more about Flutter and the Dart programming language. They viewed this with suspicion and worked backward to uncover places where Flutter would fall short of our expectations. To their delight, the idea overcame all of their challenges. Even those engineers who had not expected it were ecstatic after a short period.

It was discovered that Flutter could solve uncommon issues faster than expected. Because the development process was significantly more pleasurable, they could quickly construct a user experience that was relatively consistent between iOS and Android. Their team intended to create a high-quality product, and they recognized that automated testing was a must. Flutter’s testing tale, to their amazement, was one of the greatest they’d heard. After a few weeks of working with Flutter, they were convinced that it was their most excellent chance of meeting their deadlines on time.

They were able to meet every deadline after nineteen months. Their first beta was in the hands of their CEO within three months of getting their first product requirements, and the app was introduced to the public a few months later. They are thrilled to be part of the team that made eBay one of the first enterprise firms to deploy Flutter in a production app. Their experience has shown that Flutter provides speed and agility despite the overhead of an enterprise offering. However, it was not a simple task. The eBay crew worked hard and was committed to success. They discovered unanticipated benefits along the road that have continued to pay dividends as they have added additional functionalities to the eBay Motors App. Let’s work out some of the kinks.

One Does Not Simply Accelerate

Their first objective was to scale the project and enlist the help of the rest of the crew. They were well aware that once their product requirements began to pour in, they’d have to get right to work. Dart and Flutter had never been used before. Everyone took the effort to learn the new stack and took the fantastic AppBrewery beginning course.

It was more difficult but more valuable to develop their team’s working agreement. They had to bring two teams with opposing approaches to problem-solving together into a single cohesive one. This was a difficult process that forced them to reconsider many of their previous assumptions about app development and re-evaluate what they genuinely valued in creating high-quality software. They got into heated debates about design patterns and architecture, automated testing, and the safety nets they needed to move swiftly and innovate. This step-by-step approach was quite beneficial. It gave them a voice in working with Product and allowed them to genuinely start building this software as a team.

When they started working on their project, they were shocked at how much code-sharing Flutter allowed them to do. The following is a list of their current holdings:

  1. Dart code makes up 98.3% of the regulation (there are 220k lines of Dart code).
  2. 1.1 percent Scripts, Continuous Integration, and a variety of Automation Tools for our development lifecycle
  3. Kotlin, Java, Swift, and Objective-C each received 6% of the vote.

Their hopes for cross-platform code exchange were substantially exceeded. In practice, they rarely think about or work on platform-specific integration, preferring to concentrate solely on developing product features. They expected to have to jump through hoops at first to have access to native capabilities. They noticed that integrating with device APIs to enable camera, video capture, machine learning, geolocation, encrypted storage, and other device features was simple. For these services, the Flutter ecosystem provides excellent plugins. They created their plugins to encapsulate native 3rd party SDKs in uncommon circumstances. Although these activities were undertaken with caution, they were all done in a matter of hours.

After spending most of their time immersed in Flutter code, they discovered the golden grail of cross-platform development: everything was genuine “write-once.” This was true throughout the stack. Everything in the UI was shared, including the layout, navigation, animation, and localization. The network stack, domain models, and business logic were all familiar. The essential features, such as analytics, crash logging, and accessibility, were developed using shared code. They even got to use the same CI pipeline! Writing software in this manner was an excellent accelerator for them, allowing them to add new features quickly.

One of the benefits of such high levels of code sharing was its effect on test automation. Flutter’s out-of-the-box testing support exceeded their expectations. They were astonished by how thoroughly they could automate the app’s verification, from complicated UI interactions to the tiniest aspects of animation. This is a tribute to Flutter’s architecture in that it fully controls the pixels that are rendered across all devices and platforms, but it is also a testament to the framework’s testing as a first-class notion.

They agreed to a higher target after discovering the strength of Flutter’s testing support: all production code must have 100 percent code coverage. Although it was frightening at first, we soon realized that it was highly feasible, and we enforced the rule using automation in our pull requests. That automation is still in place today and has not changed. This upfront discipline, combined with our faith in Flutter’s test architecture, gave us the confidence to deliver swiftly and without hesitation. Typically, features are designed and tested without ever being tested on a device. They were so confident in our test suite that our quality engineers began writing production code and were hired as full-time Flutter engineers.

The benefits of code sharing are not unique to Flutter, even if some argue that Flutter delivers on the cross-platform promise better than its competitors. One of their biggest surprises, however, was that developing in Flutter outperformed traditional native development. They informally surveyed the team to help validate their decision to use Flutter. The responses showed that most of the group believed developing in Flutter was over twice as fast as developing for their prior platform. More importantly, 100 percent of those polled preferred Flutter development to iOS or Android. As it turns out, happy developers are more engaged and productive.

Their decision to go with Flutter allowed them to move swiftly for a variety of reasons. They collaborated with Product and Design as a single team, with the common goal of creating a single app. Platform requirements rarely diverged, and entire types of work, such as handling platform-specific backlogs, were eliminated. The lowered overhead affects more than just the engineering staff. Most of the time, they were able to replace paper prototypes with working prototypes for user testing. There was no need to generate separate designs for each platform. Thanks to pre-built Material and Cupertino widgets, they could prefer reasonable defaults and construct custom user experiences only when necessary. This resulted in a consistent end-user experience across all devices without jeopardizing the unique platform mechanics that eBay customers have come to rely on. Designs may then be iterated on in real-time using complete hot reload, a Flutter method that allows developers to swiftly supply code on a running device without altering the app’s running state.

These intriguing adjustments in their working methods have resulted in improved confidence. Almost every week, they release a new version of their app for both Android and iOS at the same time. There is never any feature drift between the two platforms. They have been able to be swift due to time savings heaped on top of each other. In the past, they would have been concerned if they rolled out the same feature in both the Android and iOS versions of an app, and their analytics revealed that the quality was used substantially more on one platform than the other. In these cases, their immediate thought was that the platform with the underutilized functionality had a programming problem. Flutter, on the other hand, has identical implementations for iOS and Android. As a result, they don’t waste time and energy looking for code faults that don’t exist.

Unexpected Payouts

The team continues to develop features to the eBay Motor App, such as a live chat facility and an escrow account to transfer payments to the seller safely.

Flutter far surpassed their expectations. This was much more than a technological decision. Flutter has transformed and improved the way the team performs in various ways, making its members more productive and happier in their day-to-day work. Development teams would be wise to consider Flutter for production apps of any scale that require speed and agility.


You may also like...