Mobile assets infrastructure
Introduction
Graphic design assets (icons, vector illustrations, promotional videos) are an integral part of the brand identity of mobile applications. In a typical product development lifecycle, designers hand over design mocks with these visual assets to engineers, who in turn exports them and adds them to a code repository. In some cases, some designers choose to use cloud-based file-sharing solutions to transfer these assets to engineers. Both these approaches are sub-optimal and are prone to various problems:
- Lost source files: The source of these visual assets is typically the design files that use them. Making changes to these assets in the future will be harder due to the untraceable nature of these one-off design files from product designers.
- No standards enforcement: Engineers are tasked with exporting and adding these assets to the code repository. Oftentimes, there are no naming standards, checks for availability of all required resolutions, and measures to monitor duplicates in a repository.
- No performance optimizations: Unlike the web, mobile apps have major app size constraints; for every MB of app size increase, fewer users are likely to update their apps. Without centralized processes around asset optimizations, mobile apps often suffer from unwanted size bloat.
In a simplified version of the product development lifecycle, there are three stages: designers creating product mocks (“design”), engineers building products (“build”), and products shipping to users as apps (“ship”). Between each of these stages, there are hand-offs involved. A good solution should optimize for designer velocity, developer experience, and app-size constraints in mobile apps across these stages, while also cutting down any issues during these hand-offs. Facebook has built a comprehensive asset management pipeline over the years and this article covers some of the basics.
Source-of-Truth
Storing all visual assets in a centralized location — a Source-of-Truth (SoT)— forms a strong base for a robust asset management solution. A central location, that is accessible by all designers and engineers, has many advantages: the ability to track and make changes in the future, discoverability, and federated ownership. Design tools and engineering repositories will be consumers of this source-of-truth. Since visual assets are raw files, a simple cloud-based file storage solution should be sufficient to start with. Alternatively, popular code repositories like GitHub can also be used. Establishing a proper Access Control List (ACL) is key to its integrity; not all roles require write access for this source-of-truth, most will only consume them. Keeping this repository of designer-authored files separate from code repositories (actual files that ship with apps) is important. Such a separation allows designers to make changes without causing any unwanted downstream effects in production.
Design Phase
A. Designs as Creators
Oftentimes, there is a production design team or a design agency that creates visual assets for a company. They store these files in the source-of-truth for consumption by product designers and engineers. Providing them direct access to the source-of-truth will not be sufficient. It is important to perform several sanity checks (naming conventions, availability of assets on all resolutions, usage of correct color spaces) at this stage. A simple “asset management” tool built on top of the source-of-truth to provide input and error validation will greatly help catch quality problems and maintain the integrity of the source-of-truth. More importantly, they need to provide a “design token” — a unique identifier for assets in the source-of-truth — that can be used in subsequent design-engineering hand-offs.
B. Designers as Consumers
By moving visual assets from individual design files to a source-of-truth, this model makes product designers be consumers. Instead of copying assets from other design files, product designers will depend on the source-of-truth for using visual assets in their designs. Downloading assets and using them in design tools make them prone to being out-of-sync with source-of-truth. Modern design tools like Figma allow creating plugins. A good solution here would involve building plugins/libraries for design tools that provide access to the files in the source-of-truth. Such solutions also help keep the visual assets always in sync with the source-of-truth.
Build Phase
A. Engineers Building Products
As engineers build products based on design mocks, the “design token” associated with visual assets comes in handy. Engineers can download these files from the source-of-truth using the “design token” and add them to code repositories. Such a process — rather a lack of standardized process — is prone to several problems: lack of proper naming conventions, exported design files are often too large, and files can go out-of-sync with source-of-truth.
Investing in a command-line script that downloads files from the source-of-truth and commits them to code repositories offers several benefits: files are always added to correct folders thereby allowing tracking, files can be compressed to avoid bloat, and files can be made to stay in sync with the source-of-truth. We’ve found that integrating popular compression algorithms like zopflipng can reduce the overall assets file size by 30% without loss of fidelity.
B. Automatic Asset Sync
The files in the source-of-truth are prone to design changes over time. We cannot rely on engineers to sync assets every time they change; tracking such changes and propagation information is a much larger communication problem. Cron jobs are well-suited for fixing this problem. These nifty programs can be set up to run daily to sync assets from the source-of-truth to code repositories, thereby ensuring consistency across the pipeline.
Ship Phase
The web has made many improvements to the ship phase. Creating sprite-sheets from individual assets to reduce download time has become an industry standard. Illustrations promoting new products can be downloaded selectively on-demand. Unlike the web, all assets — including promotional and low-usage images — have to be packed with the mobile app. This app size bloat has downstream effects on user engagement.
At Facebook, we’ve built solutions to classify visual assets based on their usage in the apps. At app build time, we use this information to determine if an asset should be packed into the app bundle or not. Most-used visual assets that are important for the core app experience are shipped with the app bundles. Least-used and promotional visual assets are uploaded to CDN servers at build time and are replaced with identifiers in the bundle. At runtime, our apps determine if an asset is packed with the app bundle or not, and download them on-demand if necessary.
Tying them all together
- Use a centralized source-of-truth for visual assets. They provide better management and discoverability compared to leaving these assets in design files.
- Build command-line tools and plugins for accessing visual assets from the source-of-truth. This ensures all assets stay in sync across the product development pipeline.
- Aim for designer and developer velocity without compromising their experience. Simple tools to store and access visual assets will go a long way in establishing standardized processes for organizations.
- Only pack most-used visual assets with app bundles. Others can be made to be downloaded on-demand thereby reducing app size bloat.
