About ABEMA

Based on a joint investment between CyberAgent, Inc. and TV Asahi Corporation, ABEMA was founded in April 2016 as a video streaming business intended to be a new, futuristic TV platform. We at ABEMA offer diverse programs including original dramas, romantic reality shows, animation, sports, and Japan’s only 24-hour news channel that covers breaking news and other stories.

The Development division of AbemaTV, Inc., which runs ABEMA, develops the streaming service with some 150 members consisting of engineers, designers, and project managers among others. Various engineers involved in service development and operation belong to this division. Examples include mobile application engineers, web application engineers, cross-device engineers, streaming client engineers, backend application engineers, content distribution engineers, site reliability engineers, cloud platform engineers, ad streaming engineers, studio tech engineers, and data engineers.

Engineers who develop the ABEMA Android (mobile and tablet) and iOS mobile applications work in a single unit called the Native Team. Android and iOS app engineers used to work in separate teams, but the following issues and needs have pushed us to arrange a team structure that’s non-reliant on platforms:

• Gap in number of iOS and Android team members
• Gap in specification, design, implementation, and feature between platforms
• Standardization of domain logic
• Promotion of mobile DevOps

Mobile DevOps

Some 20 engineers belong to the Native Team, which is arguably on the larger side among domestic services. Many engineers involved in a single service means numerous features tend to get developed concurrently. Providing those features to users as quickly as possible, getting feedback, and making further improvement translates to continuous improvement and competitiveness of the service. The Native Team, to which I belong, has a basic policy to release new versions of the app weekly to improve deployment frequency and shorten deployment lead time.

This is a simplified diagram describing stages from development planning to the release of our app. We refer to this two-week process as a single “sprint” unit. One sprint consists largely of the following four phases:

• Development planning
  • We sort out what should be developed and undergo quality assurance (QA) before the release two weeks down the line, what has been developed, and glitches
• Develop
  • We implement features and run automated testing
• QA
  • We run manual E2E testing
  • We run feature-basis manual testing while concurrently engaging in feature development
• Release
  • Through phased releases, we make early discovery of critical issues that cause significant user impact

Naturally, some development items straddle sprints. But the fixed QA and release schedules allow us to make a trial calculation of the release date based on development man-hours. The biggest advantage for a large team like us is our ability to independently handle the development planning to release phase on a feature-by-feature basis.

This standardized development flow is largely supported by such CI tools as CircleCI and GitHub Actions. The Native Team automates processes including:

• Application version updates (e.g. versionCode and versionName)
• Git tag creation
• GitHub release and milestone creation
• Unit testing, integration testing, and visual regression testing execution
• Binary upload to the store
• Binary upload to App Distribution
• Lint check

and so on.

The development flow is not the only factor speeding up ABEMA’s Mobile DevOps. We are also working on enhancing the observability of important service indices and service quality by using feature flags to turn on or off unreleased app features, as well as by defining service level indicators and service level objectives.

Below are some of our introduction cases involving an open-source library that ABEMA has developed and is using, and the New Relic One observability platform.

• Flagfit
  • Feature flag client library for Android
• koma
  • UI rendering performance measurement library for Android
• Introduction of New Relic One

Architecture

The ABEMA Android app has been using the Flux architecture since the streaming service officially launched in 2016. Currently, we are introducing and migrating to a Clean Architecture-based architecture to:

• Streamline our development cycle
  • Make normalization of specifications and standardization of implementation across platforms easy
  • Separate business logic from UI/data management logic
• Ensure loose coupling between components based on design
  • Develop multi module (Android) and multi framework (iOS)
  • Accelerate build speeds
• Improve internal quality by enhancing testability and maintainability
  • Clarify scope affected by modification and unit testing unit
  • Optimize testing by designing test architecture (e.g., introduce test pyramid)
  • Reduce QA cost
• Enhance safety and productivity of UI development
  • Check display with catalog
  • Introduce visual regression testing
• Eliminate technical debt
  • Optimize areas where requirements are changing (e.g. perpetuate media data)
  • Discontinue coexisting previous-generation design (iOS)

While using the Flux architecture, components were not layered and they tended to be tightly coupled. As such, we clarified the roles of each layer based on a clean architecture approach and redefined dependencies between layers.

This design loosened the coupling between components, providing various benefits such as:

• Easier multi-modularization and multiple frame creation
• Better testability and maintainability
• Easier introduction of visual regression testing

and so on. By fragmenting layers and clarifying roles, we now see fewer cases where logic gets allocated in different locations depending on the implementor.

But then again, despite the many advantages, migrating to another architecture has caused new issues such as an increase in boilerplate codes related to cross-layer model mapping. In light of this, the team is actively discussing to brush up the architecture into a better one while advancing the migration process.

We invite you to read the web page below, where we discuss our architecture migration efforts.

• Efforts and prospects of rearchitecting the ABEMA mobile app

Multiplatform

Migrating to a clean architecture loosened the coupling of components, in turn enabling us to separate application logic and domain logic from a platform-dependent UI layer. Further, standardizing Android and iOS designs has made it easier to split implementation with lower platform dependency from the applications of each platform. The development we’ve been seeing in such cross-platform technology as Kotlin Multiplatform Mobile (KMM) or Flutter has also spurred ABEMA to standardize KMM-based logic.

We chose KMM primarily because of two reasons:

• Difficulty in meeting ABEMA’s design and UI/UX requirements by standardizing code for UI components
• Situation of development and community, digital transformation and potential

We have started to partially introduce KMM in DataSource and are using the technology in a production environment, too. We aim to further expand standardized sections to cover domain and application layers.

Efforts are also increasingly underway at CyberAgent Group, our parent company, to introduce multiplatform and cross-platform technology. For details on the efforts, see the press release below.

• CyberAgent’s efforts for cross-platform mobile apps

Toward becoming a better team

The ABEMA Native Team is undertaking the following initiatives to maximize each member’s ability and achieve greater teamwork:

• Monthly KPT
  • We hold a monthly KPT retrospective to identify problems and solve issues on a steady basis

• Team learning
  • We learn the strengths of team members, share what members are expected from and expect of other members, and align expectations of each member

• Streamlining of onboarding
  • We develop an onboarding template to allow for new members to work on their jobs smoothly
• Implementation-sharing session
  • We share major codebase changes that occurred in each project
  • We suggest introducing new technology or changing implementation

Advancing development more on a project basis as a result of increased member size inevitably causes our structure to become siloed and undermines the team’s unity. The ABEMA Native Team strives to become a better team by respecting each member’s opinions through the above and other efforts.

Summary

More than five years have passed since the launch of ABEMA. With time, the platform has grown larger both on service and development scale fronts. The Native Team will continue to evolve and take on diverse technical challenges, aiming to become a world-class media service.

Career opportunities

CyberAgent is looking for Android engineers. Click here for details.

Tech information

CyberAgent engineers are actively delivering information through various platforms.

• Twitter: https://twitter.com/ca_developers
• Developers Blog: https://developers.cyberagent.co.jp/blog/
• Official YouTube channel: https://www.youtube.com/channel/UCYvmsuoQ32tVY6MpOYhr5jA
• connpass: https://cyberagent.connpass.com/

About the author

Seiya Kokushi

Seiyka Kokushi joined CyberAgent in 2018, straight after graduating from university, and now is an AbemaTV, Inc. Native Team member. As a mobile native application engineer, he is involved with the ABEMA mobile app, TV app, and multi platform development.

• GitHub: ronnnnn
• Twitter: ronnnnn_jp