Taking Bug Reporting Further

This week we released a new major update for Aardvark, our open source bug reporting framework for iOS. Aardvark makes it dead simple to create actionable bug reports from right inside your app. This latest release makes it even easier to build out powerful bug reporting flows that capture a greater amount of information than ever before and provide increased flexibility in how your bug reports are submitted.

Modularizing the Components

In 2016, Aardvark was split into two frameworks: Aardvark and CoreAardvark. The basic mechanisms for creating, distributing, and storing log messages lived in CoreAardvark, which could be used across the application itself and app extensions, while everything else lived in Aardvark. As the amount and variety of functionality grew over time, this two framework system led to a lot of complexity within Aardvark and an unclear boundary for exactly what the framework did.

In the latest release, we split the components down even further, bringing the project to a total of four frameworks. CoreAardvark still contains the basic structures for logging that are safe to be used in app extensions. Aardvark now contains only the core components for building a bug report, as well as some extensions for logging around UIKit. The email-based bug reporting flow has been moved to a new framework, AardvarkMailUI. And the in-app log viewing functionality has been moved to another new framework, AardvarkLoggingUI.

All of the existing functionality is still available through these new frameworks, with some simple changes to the dependency structure and a few small API updates. New areas of functionality can now more easily be added in new frameworks as extensions to these core frameworks.

Building a Bug Reporting Platform

Breaking the bug reporting functionality into smaller, more modular components makes it easier to build out customized bug reporting flows on top of the Aardvark platform while still providing simple-to-use, high level abstractions when desired. Currently, bug reports are filed by populating a mail composer with details about the device and app install. This email also includes attachments representing the app logs, a screenshot, and other custom attachments.

In internal Cash App builds, we’ve taken this functionality and extended it in a number of ways. In addition to the attachments automatically included in the bug report, we generate attachments containing data specific to the state of our app, such as a description of the feature flags that have been synced to the device and a compressed copy of our Core Data store. We also have a custom bug reporting prompt that shows a list of all the potential attachments and lets you select which ones to include when the bug report is filed. The default selection states in this list dynamically change based on which screen in the app you trigger the bug reporting prompt from. This is made possible by hooking into various delegate calls in the Aardvark email bug reporter.

Screenshots of Cash App’s bug reporting flow in internal builds. The screen on the left shows the initial prompt that lets the reporter input a description of the bug and select which attachments to include. The screen on the right shows the pre-populated email that contains the details of the bug report.

The latest release of Aardvark pulls much of this functionality out of the default email-based bug reporter into reusable utilities, making it simpler to write a completely custom bug reporter implementation that submits the report directly to an API instead of via email, or triggers the bug report via a mechanism other than a gesture, or collects the information for the bug report in a totally different way unique to your app.

The Power of Attachments

The concept of email attachments has been extended to generalized “bug report attachments” that can be generated and attached to any bug report, regardless of how it’s submitted. The code for generating the default attachments has been extracted into reusable, self-contained utilities. This makes it easy to build up a custom bug reporter from these components that fits the exact needs of your app.

Don’t worry, the email-based bug reporter isn’t going anywhere. You can keep using the standard flow with its simple one line setup and still optionally hook into the existing customization points to add attachments as needed.

We’re working on some exciting new attachment generators that will be available soon. And we can’t wait to see what new types of attachments you create to enhance the bug reports in your apps!

Adopting the Latest Changes

If you already use Aardvark in your app, we’ve created a simple migration guide to help you update your dependency to the latest version. In most cases, there will be little to no code change required.

And if you don’t already have a bug reporting tool built into your app, there’s never been a better time to adopt Aardvark.