In December 2018, eBay team was approached to build up another Android and iOS experience for purchasing and selling vehicles on eBay, intended to motorists. They were offered self-governance to research, plan and build the eBay Motors App as they saw fit. Notwithstanding, they expected to go from idea to both application stores in under a year, and it needed to incorporate a list of capabilities that current eBay clients had generally expected. They were both energized and slightly scared by this chance, and they needed to surpass expectations.
eBay team had been building native applications together for a long time. They comprehended what they were able to do, and furthermore realized this would be a colossal endeavor. It would be nearly impossible to build two separate applications with a little team if they keep using traditional native development.
Previously, they had investigated cross-platform SDKs and had been left unimpressed. Luckily, only weeks before their group were given its task, Flutter 1.0 was delivered, and it moved toward the cross-platform issue in a promising new manner. eBay team had been following the turn of events and see arrivals of Flutter, and they were very much aware of the enthusiasm that was developing around the technology. The primary stable release, just as Google’s sound roadmap, recommended that Flutter likely could be the answer for their group to convey on the two stages in a convincing manner under the strictly limited time. Apparently, Flutter definitely appeared to approach UI development in a way that solved many of our problems.
All things considered, they knew betting everything on a new innovation was an unsafe suggestion. Fortunately, the product manager Richard Sipe and designer Thai Dang required chance to build up a product vision, so they had a touch of slack to appropriately assess if Flutter was the correct fit. They planned to organize team workshops to learn more about Flutter and the Dart language. They approached this with a healthy amount of skepticism and bent over backwards to identify areas where Flutter might not meet our needs. To their joy, the innovation faced every one of their difficulties. After a short time, even those engineers, who did not expect it, were thrilled.
It was found out that Flutter enables to solve unusual problems faster than assumed. They could easily build a user experience that was very consistent between iOS and Android, because the development experience was far more pleasant. Their team wanted to make a high-quality product and they knew that automated testing was an essential requirement. To their surprise, Flutter’s testing story was one of the best they had seen. After several weeks of working with Flutter, they were sure that it was their best chance to achieve their goals on time.
Fast forward nineteen months, they were able to meet every deadline. Their first beta was in their CEO’s hands within three months of receiving their first product requirements, and a few months later they released the app to the public. They are excited to be the team that positioned eBay among the first enterprise companies to use Flutter in a production app. Their experience has demonstrated how Flutter provides speed and agility, even with all the overhead inherent with an enterprise product. However it was not easy. eBay team worked hard and dedicated itself to being successful. On the way, they discovered unexpected benefits that continue to pay dividends as they have added new functions to the eBay Motors App. Let’s sort out some of the details.
One Does Not Simply Accelerate
Their first task was to scale and involve the rest of their team. They were aware that they had to hit the ground running once their product requirements started rolling in. No one had prior experience with Dart and Flutter. Everyone spent time learning the new stack, and went through the excellent introductory course at AppBrewery.
Developing their team working agreement was harder, but more valuable learning. They had to take two teams with different approaches to solving problems, and bring them together into one cohesive unit. This was a difficult process that caused them to put aside many of their prior beliefs about developing apps, and made them to re-evaluate what they truly valued in building quality software. They had fierce discussions about design patterns and architecture, automated testing, and the guard rails that were necessary for them to move quickly, and innovate. This upfront process was very valuable. It allowed them to truly start building this app as one team, and gave them a voice in working with Product.
When they began building their app, they were surprised at the amount of code sharing Flutter enabled them to achieve. Today, their repository consists of:
- 98.3% Dart code (~220k lines of Dart)
- 1.1% Scripts, CI, various Automation Tools for our development lifecycle
- 6% split across Kotlin, Java, Swift and Objective-C
This level of cross-platform code sharing far exceeded their expectations. The reality is they hardly ever spend time thinking about or working on platform specific integration, and instead they focus exclusively on building product features. At an early stage, they expected to jump through hoops as they needed to access native capabilities. What they discovered was that it was trivial to integrate with device APIs to enable use of the camera, video capture, machine learning, geolocation, secure storage, and other device capabilities. The Flutter ecosystem gives great plugins for these services. On rare cases, they wrote their own plugins to encapsulate native 3rd party SDKs. These tasks were approached with hesitation but they were all completed in hours.
Spending most of their time fully submerged in Flutter code, they realized the holy grail of cross-platform development: everything was truly “write-once”. This held true throughout the entire stack. Everything in the UI from layout, navigation, animation, and localization was shared. All of the business logic, domain models and network stack were shared. All of the table stakes like analytics, crash logging and accessibility features were implemented with shared code. They even got to share a single CI pipeline! Writing software in this fashion was a huge accelerator and allowed them to build new features very quickly.
One of the advantages of this high degree of code sharing was the impact it had on test automation. Flutter’s out-of-the-box testing support exceeded their expectations. They have been especially impressed with how deeply they can automate the verification of the app, from complex UI interactions to the finer details of an animation. This is a testament to Flutter’s architecture in that it fully controls the pixels that are rendered across all devices and platforms, but it is also because testing is a first class concept in the framework.
When they discovered the power of Flutter’s testing support, they agreed to a higher goal: all production code must have 100% code coverage. Although at first it was scary, we learned this was very attainable, and enforced the rule with automation in our pull requests. That automation is still existing today and has never wavered. This upfront discipline and our trust in Flutter’s test framework gave us the confidence to deliver quickly without fear. Usually features are built and test without ever manually testing on a device. They gained so much confidence in our test suite that our quality engineers started writing production code and became full-time Flutter engineers.
The advantages of code sharing are not unique to Flutter, even if they would argue that Flutter delivers on the cross-platform promise more successfully than its competitors. Although one of their biggest surprises was that, developing in Flutter exceeded the traditional native development. They informally surveyed the team to help validate their decision to use Flutter, and the responses showed the majority of the team believed developing in Flutter was over twice as fast as developing for their prior platform. More importantly, 100% of those surveyed enjoyed Flutter development more than iOS or Android. As it turns out, happy developers are more engaged and productive.
Their decision to choose Flutter let them move quickly because of many other reasons. They worked alongside Product and Design as a single team, with the shared mentality they were building a single app. Requirements for platforms were rarely diverged, and entire classes of work such as managing platform specific backlogs were removed. The reduced overhead impacted not only the engineering team. In most cases, they were able to replace paper prototypes with functioning prototypes for user testing. There was no need to create unique designs based on each platform. Prebuilt Material and Cupertino widgets allowed them to prefer good defaults and create custom user experiences only when necessary. This led to a consistent end user experience on every device without sacrificing the specific platform mechanics that eBay customers have come to trust. Designs could then be iterated on in real-time with a full hot reload, a Flutter function that allows developers to quickly reload the code on a running device without changing the running state of the app.
These kind of interesting changes to the way they work have resulted in increased confidence. They send a new version of their app on Android and iOS at the same time almost every week. There is never any unintentional feature drift between the two platforms. Time savings layered on top of each other has allowed them to be quick. For example, in the past, they might be concerned if they rolled out the same feature in both the Android and iOS versions of an app, and their analytics showed the feature was used significantly more on one platform versus the other. In these instances, their first assumption was that the platform with the underused feature contained a programming error. However, with Flutter, the implementations on iOS and Android are identical. So they don’t waste time and energy searching for programming errors that don’t exist.
Unexpected Payouts
The team continued to add features as a live-chat feature and an escrow account to securely transfer funds to the seller to the eBay Motor App.
Flutter has far exceeded their expectations. This has been much more than a technology choice. In several ways, Flutter has changed and enhanced the way the team operates, making its members more productive and happier in their day-to-day work. Development teams would be well served to look into Flutter for production apps of any size with provided speed and agility.
