At Heap, we have a “capture everything” approach to product analytics, backed by our mix of manual and autocapture SDKs, server-side events, and integrations. Since the release of Heap for iOS in 2013, we’ve expanded our mobile support to include Android and React Native. But a lot has changed in the last decade. It was time for us to rethink the future of our SDKs.

The Changing Mobile Landscape #

Since 2013, the mobile development world has evolved significantly with new languages like Swift, declarative UI frameworks (SwiftUI and Jetpack Compose), more complex applications (multi-window support and new interaction paradigms), additional platforms (tvOS, watchOS, Mac Catalyst), and a rise in mixed technologies (think HTML/JS login screens).

Our SDKs, initially designed for a simpler landscape, were struggling to keep up.

As Heap has grown and matured over the past decade, our focus has naturally shifted from narrow, near-term solutions to a more comprehensive, long-term vision. This evolution, combined with the increasingly diverse technical landscape, exposed the limitations of our original SDK architecture.

A Fresh Start: Mobile SDK Reboot #

Rewrites in software are generally frowned upon. And for good reason! It can be difficult to understand the true scope of features and accretive bug fixes in a long-standing codebase, and rewrites almost always take longer than expected.

But this wasn’t an exercise in technical purity. Our SDKs suffered from behavioral inconsistencies that led to confusion for our customers and Heap support teams. Divergent architectures made it difficult to reason about the costs of adding new features across all platforms. And our monolithic SDKs hampered our ability to rapidly adapt and add new technologies.

After long deliberation, we set out to reboot our mobile SDKs. Not every piece would be written from scratch — we’d lift and port portions of code where appropriate. But we would build all new foundations, with a few key principles in mind:

• Consistency: Behaviors, properties, and core architecture should be as similar as possible across SDKs while still allowing for platform-specific idioms.
• Flexibility: Core capabilities — such as session management, persistence, and networking — should have clear separation from generating autocaptured user interactions. Many types of event capture should be able to co-exist in a given platform.
• Compatibility: Carefully managed dependencies would ensure broad compatibility across different environments and tech stacks. For example, extracting UIKit autocapture from core capabilities means baseline functionality is available across all Apple platforms (iOS, macOS, tvOS, watchOS).
• Open Source: We want to start releasing more of our code as open source. We believe that by enabling our customers and the developer community to make contributions, the Heap ecosystem will flourish in new and interesting ways. Proprietary code should be isolated, and we should assume that our code will be observed by others.

The Heap Capture Platform #

The Heap Capture Platform isn’t really a single entity or SDK running a particular technology. Rather, it’s a collection of concepts and technologies which can be mixed and matched to gather a complete user journey, irrespective of the technology choices made by our customers.

Our old SDKs were largely built with a single platform, single language, and single UI framework in mind. For example, React Native events are captured within the React Native runtime, but the SDK sits on top of the iOS and Android native SDKs. This means that sometimes, a single interaction might produce multiple events — one for React Native, and one for UIKit. Determining which event is the right one could be a difficult task, especially for less technical users.

Our New SDK Architecture #

Our new architecture is much more modular, and consists of four key pillars that we refer to as: Cores, Bridges, Overlays, and REST APIs.

Cores #

Our Core SDKs are the heart of every autocapture SDK, but they don’t provide autocapture support directly. Core SDKs are responsible for the fundamentals of supporting a given platform/runtime/language: session management, ID generation, event queuing/enrichment/redaction, persistence, and networking.

These SDKs follow a common reference architecture and aim for absolute consistency in behavior. We build cores sparingly and aim for maximum compatibility across languages and platforms. Because of the mobile focus of this project, we started with Android Core and Swift Core. Efforts for JS Core are underway.

Bridges #

Bridges are a simple but important part of the Heap Capture Platform. There are many ways to build a mobile application these days, and Bridges serve as a way to provide Core functionality to cross-platform development frameworks written in non-native languages (e.g. Capacitor/JS, Flutter/Dart, Xamarin/C#). These bridges provide a single, idiomatic interface to Heap Core functionality, and reduce the time our customers spend on making Heap compatible with their language of choice.

Autocapture/Overlays #

Platform-specific autocapture functionality has been moved into what we are calling Overlay SDKs. These overlays are responsible for the autocapture magic that Heap is known for, in a much more modular fashion. Isolating autocapture technology by framework (e.g. UIKit, Android View, SwiftUI, Jetpack Compose) allows us to iterate more quickly and to provide more options and flexibility for cutting-edge technologies, while retaining more stable dependencies for mature technologies.

REST APIs (“Server-Side APIs”) #

Heap has long had server-side APIs, but they tended to come with various limitations, such as sending events for identified users only. Behind the scenes of the mobile reboot has been a unification effort to remove platform-specific endpoints and increase feature development velocity. Generalizing these endpoints plays a key role in the new platform orientation of Heap Capture.

Together, these pillars give Heap mobile and SDK teams the ability to more rapidly respond to changes in the app development landscape, and open opportunities for the development community to push the Heap boundaries in a safe, supportable fashion.

What Next? #

The mobile development landscape and Heap have come a long way since 2013. By rebooting our SDKs and introducing the Heap Capture Platform, we’re embracing a new era of product analytics that is consistent, flexible, and compatible — helping developers uncover hidden insights and deliver exceptional user experiences across all platforms and technologies.