What's configurable

SDK UI settings – outside the Workbench

Most card content and visual styling can be managed in the Workbench. The sections below explain built-in SDK behaviour and choices made during integration. Product, design and development teams should review these behaviours and choices before integration.

Built-in behaviour is defined in the SDK and can't be changed.

SDK configuration refers to settings that can be adjusted in the SDK integration.

Host-app implementation means code your engineers build in your app.

Configuration support varies by SDK

Behaviour and configuration options can vary between SDKs, display variants and platforms. Differences are noted below. This page reflects iOS SwiftUI 26.3.0, Android Compose 26.2.0, Web 26.2.0, React Native 26.2.1 and Flutter 26.1.0. React Native and Flutter wrap the SwiftUI SDK on iOS and the Compose SDK on Android, so they mostly follow those SDKs on each platform.

Container layout and interaction

Built-in behaviour

Modal container dismissal

A modal container presents cards in a full-screen takeover/overlay.

• Dismissal: Built into the SDK – users can't swipe the modal away or close it by clicking the background.
• Automatic closing: The modal closes after the user submits, dismisses or snoozes every card in the container.
• Overlay colour: Set in the Workbench theme editor's Modal container section.

Modal support and integration options vary by SDK and version.

Modal container, Web, iOS SwiftUI, Android Compose, React Native, Flutter

Mobile gestures

Mobile SDK gestures provide quick card actions and feed refresh.

• Swipe left: Exposes snooze and dismiss quick actions in vertical containers and single-card views. Horizontal and modal containers don't support swipe actions.
• Pull-to-refresh: Reloads the feed where supported.
• Gesture support: Built into each display variant and can't be changed.
• Visible actions: Set in the Workbench, for the environment and per card. See Secondary card actions. Turning off both swipe actions for a card in the card editor removes swiping for that card.

This applies to SwiftUI, Compose, React Native and Flutter. The Web SDK has no swipe or pull-to-refresh gestures.

SwiftUI horizontal containers, Compose horizontal containers

Subview presentation

A subview is a secondary layout within an action card, reached from the top-level view customers see first.

• Navigation: Open a subview from a Link button, an inline text/Markdown link, or an image/banner configured to link to it.
• Content and styling: Managed in Workbench.
• Presentation: Depends on the SDK, platform and display variant rather than a Workbench setting.

SDK	Vertical, horizontal and single-card	Modal
Web	Vertical and launcher: the subview replaces the card list in place, with a back arrow. Horizontal and single-card: the subview opens in a separate overlay, with a close icon. The host app positions this overlay with CSS.	Replaces the card content inside the modal, with a back arrow.
iOS SwiftUI	Opens on another screen. If the container is inside a navigation stack, the subview is pushed onto it with a Back button; otherwise it opens full screen with a Close button. The host app can force full-screen presentation for vertical containers. Lazy horizontal and single-card containers always open full screen.	Pushed inside the modal, with a Back button.
Android Compose	Opens on a separate full-screen screen. Users return with the Close icon or the system Back button.	Same as other variants.
React Native and Flutter	iOS: opens full screen with a Close button. Android: same as Compose.	iOS: pushed inside the modal, with a Back button. Android: same as Compose.

Apart from the SwiftUI navigation option and the Web overlay position, presentation is built in.

Subview links, Image interactions, Web single-card subviews, Web modal behaviour, Compose subview navigation

Host-app implementation

Closing a container view

A 'Close' or 'Back' button lets users leave a card screen without dismissing its cards.

• Host-app implementation: The customer adds the button during integration, choosing its label, styling and tap action.
• Updates: Workbench and SDK wording overrides can't change an app-owned button.
• Supported views: SwiftUI and Flutter 26.1.0+ describe this approach for vertical, horizontal and single-card views.

Dedicated modal containers close automatically after every card is submitted, dismissed or snoozed – users can't close the modal with a background click or swipe.

SwiftUI closing a stream container, Flutter closing a stream container

Custom header

A custom header adds app-designed content above cards, such as an introduction or app controls. It is separate from the built-in header title.

• Host-app content: The integration team chooses content and behaviour during integration. Workbench can't create or edit it.
• Support: Only supported in Web SDK launcher and vertical containers.
• Other current SDKs: SwiftUI, Compose, React Native and Flutter don't provide a custom-header option. Your app can place its own content above the container instead.

Web custom headers

SDK configuration

Modal container layout

A modal container presents a full-screen takeover. That presentation is built into the SDK and can't be changed.

• Padding: All current SDKs use the theme's top-level container padding around the card. If the theme doesn't set padding, the SDK applies a small default.
• Card position: SDK configuration sets top, centre or bottom placement. Centre is the default.
• Top/bottom spacing: In SwiftUI, Compose, React Native and Flutter, an optional top or bottom offset adds space on top of the theme padding. On iOS, when space is short, the offset shrinks first and the theme padding stays the same. On Web, a vertical-padding setting replaces the theme padding on the top or bottom edge, matching the placement.
• Horizontal alignment: All current SDKs can set a maximum card width with leading, centre or trailing alignment. By default, the card fills the available width. The theme padding is kept.
• Safe areas: The mobile SDKs keep cards clear of the device's safe areas. On iOS, engineers can opt out.
• Tall cards: A card taller than the screen scrolls.
• Overlay: The Modal container theme section controls its background.
• Workbench: Controls the theme padding and overlay, but can't change position, offsets or alignment.

Web layout and padding, SwiftUI theme padding, Compose positioning, Workbench theme settings

Container display variants and sizing

Container display variants determine how cards appear in the app.

• Variant: Choose vertical, horizontal, single-card or modal, or the Web launcher, through SDK integration.
• Width and position: Where supported, SDK configuration sets full or maximum card width and leading, centre or trailing placement. Horizontal containers have a separate card-width setting.
• Lone horizontal card: SwiftUI, Compose, React Native and Flutter can keep its width and place it at the leading edge or centre, or stretch it to fill the container. There's no trailing option. A stretched card is inset by the theme's top-level container padding.
• Workbench: Controls theme padding, but can't change the variant, card width or horizontal position.

On Web, maximum card width applies to the modal container. In React Native, it applies to vertical and modal containers on both platforms, and to single-card views on iOS only.

SwiftUI single-card sizing, Flutter single-card sizing, Container display variants, SwiftUI sizing, React Native sizing, Web sizing

Horizontal container behaviour

A horizontal container displays cards side by side.

• Scrolling: Where supported, SDK configuration chooses 'free' (continuous) scrolling or 'snap', where cards snap into place instead of stopping partway between cards. SwiftUI snapping requires iOS 17+.
• Empty container: SDK configuration chooses whether it collapses or keeps its space on screen. If the header is enabled, it still shows when the container collapses.

These choices are made during integration and can't be changed in Workbench.

SwiftUI horizontal options, Compose horizontal options, Web horizontal options

Header and footer

Vertical and horizontal containers, including the Web launcher's card list, can show a header. Single-card views and modal containers have no header.

• Header: Appears above the cards. SDK configuration controls visibility and wording – the title defaults to 'Cards' and can be overridden.
• Footer: Appears below the last card in vertical containers on iOS only – SwiftUI, and React Native and Flutter on iOS. It's off by default and has no default wording – SDK configuration turns it on and supplies the text. Web, Compose, and React Native and Flutter on Android don't show a footer.
• Styling: Use Top-level for the header and Footer for the footer message in the Workbench theme editor.

Horizontal container header alignment

A horizontal container's header title can sit at the left edge ('leading' in SwiftUI) or be centred within the visible container area.

• SDK setting: Chooses title alignment when no theme alignment overrides it.
• Workbench override: Header alignment set in the theme editor takes precedence over the SDK setting in all current SDKs.

Vertical container headers take their alignment from the theme only.

Theme settings, SwiftUI settings, Web alignment, Compose settings, React Native settings, Flutter settings

Light and dark mode

Containers use a default theme, with an optional dark theme, designed in the Workbench.

• SDK configuration: Follow the user's device appearance or always show one mode. 'Always light', for example, uses the default theme even when the device is in dark mode.
• Workbench: Controls theme appearance, but can't change the SDK's mode-selection setting.

All current SDKs support this setting on iOS, Android and Web.

Web, SwiftUI, Compose, Flutter, React Native

Web container layout options

The Web launcher opens a card list from a launcher button.

• Launcher button: Choose appearance and visibility during integration.
• Card height: Web SDK configuration provides a minimum-height setting.
• Toasts: Web SDK configuration sets how long toasts show. For single-card and modal containers, or when using a custom toast container, the host app positions toasts with CSS.

Workbench can't change these integration settings.

Web style and presentation, Minimum card height

Empty-state messages

Empty containers show a message. The SDK supplies default wording, which can be changed through SDK configuration.

• Default message: 'All caught up' in all current SDKs.
• Before the first card: Web and iOS show a separate default message until the container has shown its first card. This is tracked per container on each device, not per user. Android shows 'All caught up' instead.
• Override: Keep the defaults or change the messages through SDK configuration. Workbench can't edit this wording.

Single-card views and modal containers don't show an empty state.

SwiftUI, Compose, React Native, Flutter, Web

App navigation

Host-app implementation

Custom actions

A custom action lets a card ask the host app to do something, such as open an account screen.

• Workbench: Defines the information sent by the button or image.
• Host-app implementation: Engineers implement the requested app behaviour during integration. Workbench can't create that app behaviour.

All five current SDKs support custom actions, with elements and handling differing by SDK. Compose needs additional handling when navigating from a subview.

SwiftUI, Compose, Web, React Native, Flutter

Container loading, errors and notifications

Built-in behaviour

Loading and error states

Some display variants take up no space while loading or after a loading failure.

• Single-card views: Collapse instead of showing a spinner or error message, in all current SDKs.
• Horizontal containers: Also collapse in SwiftUI, Compose, React Native and Flutter. On Android, the header can still show. Web horizontal containers show the spinner and error message.
• Modal containers: Appear only once there are cards to show.
• Workbench: Has no setting to change that presentation.

Loading and error states, React Native, Flutter

SDK configuration

First-load styling

A container's first loading/error screen appears before its Workbench theme is available on the device.

• First launch: Engineers set initial colours in SDK configuration.
• Later launches: The cached Workbench theme replaces those initial settings.
• Single-card view: Collapses during loading or error instead of showing a loading/error screen.

All five current SDKs provide first-load styling options, with settings differing by SDK.

Loading and error styling, Compose, Web

Error messages and retry labels

The SDK shows error messages and a retry button when cards can't load. The SDK supplies default wording, and most of it can be changed through SDK configuration.

• Default wording: 'No internet connection', 'Couldn't load data' and 'Try again'.
• Override: All current SDKs can override the offline message and retry label. The load-failure message can be overridden on Web and iOS. Android shows the offline message for any loading failure.
• Fixed wording: Failure toasts such as 'Couldn't dismiss' and 'Couldn't snooze', and their 'Try again' action, can't be changed.

Workbench can't edit these messages or labels.

SwiftUI, Web, React Native, Flutter, Compose

Toast messages

Toast messages briefly confirm actions such as dismissing or snoozing a card.

• Default wording: The SDK uses default messages when no custom wording is supplied.
• SDK configuration: All five current SDKs support wording overrides and visibility controls.
• Workbench: Themes control styling; Workbench can't change message wording or visibility.

Web also configures duration, and lets the host app position some toasts. Failure toasts use fixed wording.

SwiftUI, Compose, Web, React Native, Flutter

Update frequency

Containers receive updates through a live WebSocket connection or polling – checking Atomic at regular intervals.

• Polling default: Every 15 seconds across the five current SDKs.
• SDK configuration: Changes the polling interval.
• Workbench: Can't change this interval.

The polling setting doesn't control updates received through WebSockets, which happen in real time.

SwiftUI, Compose, Web, React Native, Flutter

Card UI, feedback and media

Built-in behaviour

Overflow-menu action order

Secondary actions appear in the overflow menu on a top-level card.

• Order: Built into the SDK: 'This is useful', 'This isn't useful', then 'Remind me' and 'Dismiss'. It can't be changed in the Workbench or at SDK integration level.
• Visibility and labels: Which actions appear is controlled in the Workbench. Supported labels can be changed through SDK configuration – see 'Overflow-menu labels' below.

Feedback length

Text feedback for vote up and vote down is limited to 280 characters.

• Character limit: Built into the SDK and can't be changed.
• Text feedback: Enable or disable it in Workbench.
• Validation message: Has default SDK wording, such as 'Feedback is limited to 280 characters'. All current SDKs can override the wording; the character limit stays the same.

Voting and feedback, SwiftUI, Compose, Web, React Native, Flutter

Voting feedback

When users vote on a card, the SDK can ask for feedback. Vote down asks users to choose from preconfigured options. Vote up only collects optional text and has no preconfigured options.

• Vote down options: 'It's not relevant' and 'I see this too often'. These are built into the SDK, and their wording can't be changed.
• Text feedback: Turned on or off for each card in the Workbench. When it's on, vote down adds a third option, 'Something else', which opens a text box, and vote up opens a text box.
• Vote down button on the card: Always shows all three options, whether or not text feedback is on.
• Vote up button on the card: Always sends the vote immediately, without asking for feedback.
• Vote up from the overflow menu: Opens a text box when text feedback is on. When it's off, the vote is sent immediately.

Voting and feedback, Web, React Native, Flutter

Snooze picker

Snoozing from the overflow menu, or with a Snooze button that has no preset period, opens the SDK's date and time picker so users can choose when a card returns.

• Built-in picker: Can't be replaced. SDK configuration changes only its title, through the snooze label (see 'Overflow-menu labels'). Its colours and fonts follow the Workbench theme.
• Card expiry: On iOS and Web, the picker prevents selecting a time after card expiry. On Android, it only prevents selecting a time in the past.
• Preset duration: A Snooze button with a period set in Workbench snoozes immediately, without opening the picker. The period isn't checked against the card's expiry.
• Expiry while snoozed: If a card's expiry passes while it's snoozed, the card expires and doesn't return.

Snooze buttons, SwiftUI, Compose, Web, React Native, Flutter

Reminder notification title

A push notification for a returning snoozed card starts its title with 'Snoozed:'. Atomic adds this prefix to the notification, and it can't be changed through SDK configuration.

SwiftUI, Compose, React Native, Flutter

Accessibility text sizing

Accessible text sizing lets supported card text follow the user's preferred text size.

• Workbench: Enable scaling for supported typography, and set minimum and maximum sizes.
• iOS: The device supplies the user's text-size setting. SDK-defined adjustments add to or subtract from the base size at each setting. These adjustments can't be customised.
• Android: The SDK multiplies text sizes by the device font scale.
• Web: Text scales with the browser's default font size.

Sizes stay within the Workbench minimum and maximum. There is no SDK setting for text scaling.

SwiftUI Dynamic Type, React Native font sizing, Flutter font scaling

Host-app implementation

iOS camera-permission message

The iOS system permission prompt asks users to allow camera access.

• Host-app implementation: The integration team supplies the message in the app during integration.
• Workbench: Can't edit this system permission message.

SwiftUI camera permissions

Video audio

Video audio follows the platform's defaults.

• iPhone: Video follows the mute switch by default. Engineers can allow audio while the phone is muted through the app's native audio settings. This applies to SwiftUI, and to React Native and Flutter on iOS.
• Android: Video plays at the device's media volume. This can't be configured.
• Web: Video plays with sound after the user starts it. This can't be configured.
• Workbench: Can't change audio behaviour.

SwiftUI audio, Flutter audio

SDK configuration

Upload and camera messages

SDK upload and camera messages guide users through file selection and permissions.

• Default wording: The SDK supplies messages and button labels.
• Override: Keep defaults or change supported wording through SDK configuration. Workbench can't edit it.
• iOS: SwiftUI, and React Native and Flutter on iOS, can override the upload progress, cancel and failure messages, and the camera-access message and Settings button.
• Web: Can override the upload progress, cancel and failure messages. Web uses the browser's file picker, so it has no camera messages.
• Android: Compose doesn't support file upload yet, so it has no upload or camera messages.

SwiftUI uploads, Flutter settings, Web settings

Overflow-menu labels

The card overflow menu uses SDK-provided labels.

• Defaults: 'Dismiss', 'Remind me', 'This is useful' and 'This isn't useful'.
• Override: All current SDKs can change these labels through SDK configuration. Workbench can't edit their wording.
• Visible actions: Workbench Menu actions controls which options appear.
• Snooze title: The snooze label also sets the snooze screen title.
• Feedback title: Defaults to 'Send feedback' and has a separate SDK override.
• Icons: Built into the SDK and can't be swapped. The theme can only change their colour.

For how overflow-menu actions are set up in the Workbench, see Secondary card actions.

SwiftUI, Web, Flutter, React Native, Compose

Thumbnail action labels

Thumbnail media has an action label that opens the image or video.

• Defaults: 'View' for images and 'Watch' for videos.
• Override: All current SDKs can change both labels through SDK configuration; Workbench can't edit this wording.

Card titles and descriptions remain editable in Workbench.

SwiftUI, Web, Flutter, React Native, Compose

Fonts

Card typography can use theme fonts or fonts embedded in the host app.

• Theme font: Upload or link a font by URL in the Workbench theme editor.
• Embedded app font: Engineers register a font mapping during integration; Workbench then selects the typography that uses it. SwiftUI, Compose, React Native and Flutter support this. Flutter supports it on Android from 26.1.0.

Web uses theme-configured fonts only.

Theme fonts, SwiftUI app fonts, React Native app fonts, Flutter app fonts

Runtime variables

Runtime variables display app-supplied values when a card appears, such as a current balance.

• Workbench: Defines the variable and fallback wording.
• Host-app implementation: Engineers supply the current value.
• Timeout: SDK configuration defaults to 5 seconds across the five current SDKs. If the app doesn't respond, the fallback is used.
• Analytics: SDK configuration chooses whether to share displayed values with Atomic analytics; off by default.

Workbench can't change the timeout or analytics setting.

SwiftUI, Compose, Web, React Native, Flutter

---

There may be differences in unsupported SDK versions, see version support here.