How Creating an Agile Code Base Helped eBay Pivot for Apple Silicon

eBay’s native code base has grown and evolved for over 13 years, but is still nimble enough to quickly incorporate the latest features into the app.

As one of the pioneer e-commerce sites and very first companies to launch an iPhone app, eBay’s native code base — encompassing our iOS and Android applications — has grown and evolved for more than 13 years. But it is still nimble enough to quickly incorporate the latest features into the app.

Spanning diverse marketplaces in disparate geographies, the stack is both voluminous and complex. Over the years, our eBay team has consistently found ways to keep pace with the changing technological landscape and deliver a seamless mobile customer experience. How did we create a stack which is flexible and adaptable enough to power a consistently top-rated app? I’ll explain in this article.

Creating an Agile Code Base

At eBay, the Mobile Architecture team is responsible for planning and building the foundational code of our native mobile apps. Part of our job is to try to peek over the horizon and see where Google and Apple are headed so that eBay can best take advantage of new technologies as they arise.

eBay’s tenure in the tech sector has taught us how to make our codebase as nimble as possible — by sharing code where it makes sense and maintaining consistency in architecture across the app. For sharing code, we isolate changes to a single location that can be quickly validated and seen across the app, without much intervention into each section. For example, using a shared user interface (UI) component library in our app allowed us to adopt Dark Mode very quickly in 2020. We were one of the first amongst our competitors and industry peers to support this feature.

Where sharing code isn’t feasible, building and maintaining a consistent architecture helps facilitate planning for the future. When an app lives as long as eBay has under constant development, architectural patterns can change and divergences happen. It takes effort to avoid having code evolve to a state where two or three different architectural patterns are being used at a time. Since old code and new code have to then be patched through layers of translation, the situation makes it more difficult to adopt broad new features without having to also update the older parts of the app.

Lastly, adopting new technology means keeping up with new technology — which may sound tautological, but it means having a model of constant adoption. You cannot wait until a new game-changing feature is announced at a developer conference; you need to dedicate time to lay the groundwork. Chances are that new releases assume you have already been keeping up with earlier — but perhaps more mundane — updates. If you ignore technologies A and B because there was no immediate perceived value, you will have a lot of work to do when technology C is announced with great fanfare (with dependencies on A and B). Therein lies a little bit of prediction, though: You need to be a student of your platform and recognize where updates are leading, and make an educated guess about where they will go next. Then you can decide where to place your bets and spend time for a later payoff.

A Case Study: Apple Silicon

For example, the retrofitting we had done to support iPad Multitasking in our iOS app recently paid dividends when we chose to support Apple Silicon. Multitasking allows our customers to do things like comparison shopping or to reference external information when creating a listing, and eBay was happy to support the experience even though it was not necessary for any of our major initiatives or features. However, for the architects working in the code every day, it was clear that Apple was laying the groundwork for some major changes — and it was important for eBay to stay in sync with those upgrades.

Under the hood, supporting multitasking required eBay’s code to stop assuming that the screen size was constant on any given device. In the old days, an app could check at startup if it was on an iPhone or iPad and then run accordingly without change. However, this model assumed the user cannot adjust the window size. As the number of device sizes increased and patterns of usage changed, Apple introduced the idea of size classes — where an iPhone was considered to have a “compact” width and an iPad had a “regular” width. This allowed developers to describe layouts relatively and by rough device size. Furthermore, support was added for a size-class change happening at runtime. So, eBay’s code had to evolve to depend less on the actual device and more on the size class; as well as to react to size-class changes at any point. This was not a simple change, but it made the entire app more flexible. While these changes were predominately in service of multitasking, we were also planning for the future.

Implementing multitasking and being prepared for major changes paid off this past summer, when Apple announced their plans for Apple Silicon at the Apple Worldwide Developers Conference in June 2020. By using their own chips for desktop and laptop Macs, Apple was able to share the CPU architecture across their Mac and iOS product lines. With that came the very intriguing idea of running iOS apps on Macs with little to no change.

Now, what does this have to do with multitasking? This ability to run our iOS app on desktop and laptop Macs is exactly the kind of future tech we cannot precisely predict, but we at eBay want to take advantage of it when it arrives. Without multitasking, eBay’s app would be available to these new machines, but the window size would be fixed to the size of an iPad — which, on modern displays, feels relatively small. That would make the app feel inflexible and less useful. But because the Mobile Architecture team had already tackled multitasking, eBay’s iOS app users can resize the window on a new Mac and take advantage of the extra screen size.

The Mobile Architecture team was able to very quickly evaluate eBay’s app on a pre-release Apple Silicon machine, make some minor changes, and then approve the distribution of the iOS app for Apple Silicon at the end of the year. The cost to release this version was small and the opportunity to learn more about our customers will be big.

Looking Ahead

The ability to resize our app on a bigger workspace has already piqued the interest of our design team, which is extending eBay’s tablet/iPad designs to accommodate even larger screens; and is also starting to consider what eBay’s app would look like with multiple windows. Getting buyers and sellers to try the app on a Mac will help us understand their preferences better and how they use extra screen real estate on a Mac. These insights will help eBay modernize our UI design and feature adoption. It is even possible that features unavailable on iPhones will be added for users on these larger displays if there are advantages in doing that. Simply supporting multitasking has opened many avenues for investigation and possible innovation in the future.

Part of good architecture is planning for the future, even when that future is influenced by platform vendors. We at eBay are very proud of our high rating in the App Store (4.8 as of this writing!). Our customers expect a stable, feature-rich application that adopts the new technologies that eBay’s platform vendors announce. It is an important part of our development process to continue building in a way that never leaves us far behind and allows us to pivot quickly when the time is right.

Interested in pursuing a career at eBay? We are hiring! Please take a look at our current job openings.

This article was initially published on The New Stack on Feb. 25, 2021.