Installing Atomic SDKs
Overview
Atomic provides SDKs for client developers to integrate into their mobile and web apps. The SDKs provide the UI and functionality for displaying streams of cards, displaying response views, responding to cards, theming and analytics, all via the Atomic Platform.
SDKs are available for:
SDK Guiding Principles
All Atomic SDKs adhere to the following guiding principles. These principles inform the development of each SDK, making them performant, reliable and easy to integrate.
Lean
Atomic SDKs are designed to be as small as possible, generating a low space and memory footprint in your own app. For example, as of 11 December 2024 the sizes of our SDKs are:
| SDK | Version | Size |
|---|---|---|
| Android | 24.3.0 | 2.4MB (AAR only) |
| iOS | 24.3.1 | 6.5MB (arm64 including resources) |
| Web/Cordova | 24.3.0 | 427KB (gzipped) |
| Web/Cordova (excluding icons) | 24.3.0 | 217KB (gzipped) |
| ReactNative | 24.1.0 | 11.5MB (Unpacked Size) |
| Flutter | 24.2.4 | 403KB (Entire Git repo) |
We also build our SDKs with as few 3rd party dependencies as possible; this allows us to more readily update our SDKs for new versions of operating systems or browsers, reducing the risk of ensuring that 3rd party dependencies also work.
The Web SDK offers a variant of the sdk bundle which does not include the font used for icons in cards. Instead the font is fetched as required via CDN. You may choose to use this variant if you wish to have a smaller bundle size for the initial page load. Both variants function identically in all other respects.
Native
Atomic SDKs are native, leveraging the performance and architectural patterns of each platform. Our native SDKs not only result in great performance, but also make integration easy, as they follow predictable patterns for instantiation and manipulation. We regularly review the performance of our SDKs across our supported devices, to ensure they continue to run smoothly.
Cross platform parity
Atomic's SDKs offer the same features and functionality across platforms, but aim to follow standard UI and behavioral conventions for each. This means there may be minor differences in how features appear on different platforms.
Our documentation highlights those instances where feature parity hasn't been achieved, e.g. in the Card element reference section. The workbench's Theme editor UI shows icons where certain settings are only available in a specific platform. The screenshot below shows the menu mask setting is only available in the Android and iOS SDKs.
Easy to integrate
Our developers leverage their experience integrating SDKs to understand the key points that make SDK integration difficult and easy. Those lessons have been applied to the Atomic SDKs, making them easy to integrate. The integration process is supported by code-level documentation and readmes.
Performant
We appreciate how important it is for you to have a fast app experience for your customers. We ensure our SDKs have a negligible impact on performance. We use WebSockets as the default approach to acquire the card feed, so the update speed is almost real-time. However, we still have HTTP polling as a fallback and in that case you can ensure your apps remain performant by setting the polling interval to be only as low as is required.
Well-tested
Atomic SDKs have extensive automated test suites that run as part of our build pipeline. Unit tests and snapshot tests help ensure that visuals and functionality do not change unexpectedly between releases, and also help us understand the impact of future changes, new operating system releases and browser versions.
Dependencies
Our Android SDK has some dependencies, which we list in the Dependency Graph section of our Android SDK article.
Changelogs
Changelogs are supplied with each new release of the SDKs, detailing the changes made and potential impact on existing integrations.
View the Changelog
Stream containers
Each Atomic SDK provides a stream container. A stream container provides UI to render a list of action cards, generated from a single stream. The stream rendered inside of a stream container is configurable via the Workbench. While each stream container displays cards from only one stream, a stream may display its cards in multiple stream containers.
A stream container is identified by a unique key - this key is displayed in the Workbench and is specified in code when configuring a stream container using the SDKs. By identifying a stream container by its key, a different stream can be displayed in a stream container (using the Workbench) without requiring a re-release of your app. Your app can contain multiple stream containers, or multiple instances of the same stream container if desired.
Stream containers have been built with isolation in mind - they are designed to exist on their own without impacting other stream containers in your app.
Stream containers can be rendered in a variety of modes - the modes differ for each platform. See the “Display modes” documentation of each platform for more on the available modes.
Logging
To support integration of the Atomic SDKs, verbose logging can be enabled, which logs detailed information on key events in the SDK lifecycle.