Mobile development at scale

Engineering leaders at adidas Runtastic, Eventbrite, and Citymapper discuss app performance, how mobile fits into their org structures, and native versus cross-platform development.
Part of
Issue 18 August 2021

Mobile

Christian Orgler

VP of product engineering, adidas Runtastic
adidas

62,000+ employees
43 mobile engineers

Natalia Gatti

Engineering manager
Eventbrite

600+ employees
20 mobile engineers

Jorge Cohen

Product engineering manager
Citymapper

60+ employees
10 mobile engineers


How does your company think about mobile?

We see mobile as being central to our business, which is about building engaging sport experiences. You’re not going to go out for a run with your laptop, after all. Yet mobile works best in combination with the right mix of platforms for your experience. For example, you might use our app with Facebook Portal for a quick workout in your living room. 

We’ve undergone several phases during our growth, from delivering and maintaining more than 30 apps, to narrowing it down to just four accompanied by a web platform, to focusing on only two apps, adidas Running and adidas Training, following our acquisition by adidas in 2015.

—Christian Orgler, adidas Runtastic

Our native apps enable us to connect our users with interesting events around the globe, as well as deliver a more personalized and seamless experience by leveraging location information, notifications, digital wallets, and more. Mobile is our users’ preferred platform, demonstrated by substantial engagement, conversion, retention, and login rates. 

—Natalia Gatti, Eventbrite

Citymapper is all about helping people navigate cities, so we need to be deeply mobile. Features start mobile-first and are later adapted for the web. While we’re quick to adjust to new technologies, we usually don’t adopt new frameworks if they don’t provide a clear benefit to the user. And since not everyone can afford the latest device, we take pains to support old operating systems and keep our APIs backward compatible so a wider range of people can benefit from our service. Citymapper versions from five or six years ago still work!

—Jorge Cohen, Citymapper

What tools and technologies does your company use for mobile development? 

Our build infrastructure uses open-source tools like fastlane and Jenkins. These are connected to Bitbucket, our code management system. Our monitoring tools include the standard Apple and Google console dashboards, as well as our own more customized app performance monitoring (APM) tool, New Relic, which is linked to our backend services. 

Before we roll out any changes, we go through alpha tests (with our employees) and beta tests (with a pool of real users) distributed through App Center, TestFlight, or Google Play, depending on the testing phase. With millions of active users, we sometimes observe issues that require us to recreate a user’s exact hardware and data environment when a simulator isn’t sufficient, so we’re currently testing a third-party remote access tool that will allow us to choose any physical device and recreate the exact hardware an issue is appearing on. We’ve paired this with internal debugging features built into our apps for use by QA engineers. 

—Christian Orgler, adidas Runtastic

For iOS, we use Apple’s own developer tools, such as Xcode, because they reduce friction with iOS updates. We write our tests with the XCTest framework, and we choose community standards like fastlane and SwiftLint to encourage platform unity among apps. For Android, we use Android Studio and Kotlin for development and Firebase Test Labs for integration tests. We also build repositories to share business logic and tools across our iOS and Android apps. We rely on Sentry to track issues and crashes and Google Analytics to track app usage. CircleCI is our continuous integration pipeline, and we use Code Climate to review code quality, including code coverage.

—Natalia Gatti, Eventbrite

We use fastlane on top of Github Actions and Bitrise CI for building and deploying, Mixpanel and Crashlytics for client-side monitoring, and custom Grafana dashboards to monitor the backend. Our Android team uses Firebase’s Test Lab for on-device tests. We’ve also recently started snapshot testing components using the open-source tools swift-snapshot-testing by Point-Free, Showkase by Airbnb, and paparazzi by Cash App. We do all of our code reviews using Phabricator and use feature flags to avoid shipping unfinished features. We also use various tools for pair programming, primarily Pop.

—Jorge Cohen, Citymapper

How does mobile engineering fit into your company’s team structure?

Our product engineering teams are set up cross-functionally to include mobile, backend, and QA engineers, along with a product designer and manager. Inspired by the Spotify model, teams clustered together form “tribes” focused on our two apps or on overarching social experiences available in both. Our tribe leadership team, which consists of a principal designer and heads of product, marketing, and engineering, is responsible for the tribe’s success in connection to our company goals. 

This structure helps support team autonomy and creates a sense of belonging within the wider organization, but it can be challenging when dealing with features or requirements that can’t be worked on by one tribe in isolation, like single sign-on. We’re currently focused on reorienting tribe and team goals around experiences rather than a single app so we can benefit from this team structure while also becoming more app-independent and experience-led as an engineering organization.

—Christian Orgler, adidas Runtastic

Our mobile engineers sit on two teams, iOS and Android, which also include a dedicated product manager and product designer. The benefit of this structure is a greater focus on internal knowledge sharing and support, allowing for cross-pollination between the two apps as well as cross-team mentoring. The product team also benefits from this structure because it affords them a holistic view of each app. It does, however, require a high degree of collaboration and coordination with the feature teams that own backend services, which can lead to compromises and trade-offs in terms of coordinating releases and aligning on roadmaps. 

—Natalia Gatti, Eventbrite

All of our mobile engineers sit in one team, with a sub-team for each platform. Any engineer can work on any part of the app, which enables context sharing across different features and products. This also means we can be more flexible with priorities, since any engineer can jump on any task. Sometimes this makes project management harder when there are multiple high-priority project needs. When that happens, we may assign certain engineers to certain tasks or reevaluate our priorities.

In rare cases, we’ll build temporary feature teams to help us focus on a particularly challenging project or to jump-start a new product. We recently did this for our B2B SDKs. These teams are short-lived and are dissolved once we’ve tackled the challenge. We then share knowledge about the new feature across the rest of the team through documentation and internal talks.

—Jorge Cohen, Citymapper

Do your mobile teams develop natively or use cross-platform frameworks?

We primarily develop on native platforms, but we occasionally like to explore, test, and validate cross-platform frameworks for specific needs. For example, we developed our social feed using React Native, but decided to transition back to a natively developed feed for several reasons, including stability, the domain knowledge required, and workarounds we had to apply to enable proper interoperability with native code. 

During our quarterly, company-wide “Days of New Ideas,” our engineers sometimes develop in-house apps with cross-platform frameworks like Flutter, then determine whether such technology suits our current needs on an enterprise scale. We’re currently evaluating Kotlin Multiplatform Mobile to share some specific business logic between platforms.

—Christian Orgler, adidas Runtastic

Our mobile teams develop natively so we can provide the best possible user experience and keep up with the latest iOS and Android updates. While this does result in a duplication of efforts, we find we have to make fewer concessions to design and user experience than we would if we were using a non-native platform. This also allows us to adopt new platform-specific features more quickly. We share code between apps within the same platform, but we also use embedded web views across iOS and Android apps to provide identical features when features are too challenging to build or wouldn’t yield a return on investment to develop natively.

—Natalia Gatti, Eventbrite

Our consumer apps are fully native so we can make use of the latest features on every OS, with iOS written in Objective-C and Swift and Android in Java and Kotlin. Some of our screens are built with web-based technologies, but we make sure those feel as native as possible through a combination of design, CSS, and JavaScript. We looked into Kotlin Multiplatform and Swift for cross-platform logic in our B2B SDK, but they didn’t feel mature enough. We want to keep the tech we use for the SDK as close as possible to what the platform vendors use in order to deal with the unpredictability of clients’ project structures.

—Jorge Cohen, Citymapper

How do you measure the performance of your mobile apps?

On a team level, we measure specific performance metrics tied to our experiences, such as how often our GPS tracking algorithms have to adjust accuracy and speed and remove outliers to compensate for hardware sensors. On an app level, we look at common metrics such as crash and application not responding (ANR) rates and spin them into user-focused metrics such as “annoyed user rate” and “crash-free user rate,” or categorize them based on when they happen for the user, for example during a run or while completing a workout. We also measure time to UI, startup speed, app size, and many more, including some crucial metrics for emerging markets, like cellular data usage and connection speed.

—Christian Orgler, adidas Runtastic

We monitor our crash-free user session rate with Sentry in order to maintain the stability of each app after a release, and we aim to keep that rate above 99.6 percent. For our iOS apps, we use MetricKit to monitor startup time and hang rate. For Android, we measure core vitals like ANR and crash rates in Google Play Console. Our focus is on preventing performance and network issues during traffic peaks.

—Natalia Gatti, Eventbrite

We primarily measure app start time using a custom-built tool. Engineers use the app daily, and we’ve found that getting annoyed at slow screens is the best way to motivate us to fix things. Our app is meant to be used underground, in the subway, with unreliable connectivity, so we optimize for less stable connections from the get-go, caching relevant data to make sure the app can operate offline. Our team also makes sure to keep old versions of the app running reliably, and we almost never deprecate old APIs.

—Jorge Cohen, Citymapper

How do your mobile teams prioritize accessibility in the product development process?

Our UI/UX designers and product managers incorporate accessibility into product feature development by design. In the last three years, we’ve made improvements to fundamental areas of our apps, such as annotating UI components like buttons for screen readers and creating dedicated sport types like “wheelchair” as options for participating in challenges or virtual races. 

—Christian Orgler, adidas Runtastic

We’ve created a committee of web and native app experts who collect user feedback on accessibility issues and draft guidelines for the larger team. In addition, we use the Accessibility Inspector on iOS and Accessibility Scanner on Android to measure current accessibility issues. Recently, we focused on addressing our login flows to tackle issues with contrast, dynamic fonts, and links. We’re now planning to build accessibility testing into our continuous integration environment so we can be confident new features we develop are accessible. 

—Natalia Gatti, Eventbrite

In 2019, we added step-free routing in some cities (where such data has been available) to support wheelchair users. We’d like to further assist people with visual impairments, so improving VoiceOver support is also on our roadmap.

—Jorge Cohen, Citymapper

What’s something unexpected or unique about your mobile development processes or workflows that you’ve found especially effective?

We’ve defined additional roles for engineers on our product development teams that offer opportunities to grow their leadership skills. For example, we have interest groups, called guilds, led by appointed guild leads, in which members exchange knowledge and learnings through weekly meetings and presentations. We also have a rotating set of release managers who collaborate and manage our two-week release cycle across development teams. Having dedicated release managers has made our release processes smoother and improved our ability to meet our target release dates. It’s become a foundational part of how we work.

—Christian Orgler, adidas Runtastic

Apple and Android products appear in different ratios around the world. As a global organization, understanding these variations helps us prioritize features and integrations, and gives us the freedom to develop for each platform and meet our customers where they are. For example, our point of sale and ticket scanning application for event organizers integrates with a number of third-party barcode scanners, card swipers, and ticket printers with varying availability worldwide. When we need to prioritize platform support for these peripherals, we may develop integrations based on the product-market fit of the mobile platform in the region we’re working to support.

—Natalia Gatti, Eventbrite

Many mobile apps have at least one screen with ad content that needs to change frequently, and Citymapper is no exception. To keep content up to date without involving developers, we use a custom Sketch plugin that allows our designers and product managers to build entire functional screens with no programming required. Moving to this system accelerated the rate of experimentation on messaging and design, and freed the mobile team to focus on higher-priority work. Our app currently has over 10 screens built with this tool.

—Jorge Cohen, Citymapper

Editor’s note: Christian Orgler left adidas in July 2021 to found his own company. His answers reflect his role as VP of product engineering at adidas Runtastic.

Buy the print edition

Visit the Increment Store to purchase print issues.

Store

Continue Reading

Explore Topics

All Issues