Skip to main content

Overview

The new Rive Apple runtime is a near-complete rewrite of both the public API and the internal architecture. While conceptually most operations have an equivalent, the two APIs are incompatible. Any existing work in the legacy API that you would like to migrate must be rebuilt using the new API. This guide covers:
  1. Shared Features - Common operations and their equivalents.
  2. New Exclusive Features - Capabilities only available in the new runtime.
  3. Legacy Exclusive Features - Features no longer available in the new runtime and migration guidance.
This guide is not meant to be exhaustive as it would be redundant with existing general documentation. Please refer to the relevant sections of the documentation for more details on specific topics.

Package and Import

The new Apple runtime is available in the same Swift package and CocoaPods pod as the legacy runtime. Both runtime APIs are available in the same package, so you can import the runtime using the same import statement.

Asynchronous APIs

The new runtime is built around Swift Concurrency. Most setup and query operations are asynchronous and should be called from an async context.

For more information, see the Apple getting started guide for end-to-end setup examples.
Common examples include:
  • Creating a Worker asynchronously
  • Creating File and Rive objects
  • Creating artboards, state machines, and view model instances

Lifecycles and Threading

The legacy runtime is effectively main-thread driven through RiveViewModel and RiveView. The new runtime introduces Worker objects for background processing while still enforcing API calls on the main actor. In practice:
  • Worker owns the background processing context
  • File strongly references its Worker
  • Out-of-band assets registered on a worker can be shared across files created with that worker

For more information, see the Threading section for additional details.
For most apps, a shared worker is recommended:

Shared Features

Shared APIs

The main shared API area is fallback fonts through RiveFont.fallbackFontsCallback. For fallback font types and behavior, see Fallback Fonts.

RiveViewModel to Rive

Use the sections below as a migration map: Loading a File from Disk, Creating a Rive View, and Data Binding. Legacy RiveViewModel flows in these areas become explicit File + Rive setup, then RiveUIView/SwiftUI representables in the new runtime.

Loading a File from Disk

Legacy Runtime

New Runtime

Loading a File from URL

Legacy Runtime

New Runtime

Loading a File from Data (Bytes)

Legacy Runtime

New Runtime

Use the .data file source when your .riv bytes are already available in memory.

Tracking Loading and Error State

For common setup operations (loading files, creating artboards, creating state machines), the migration pattern is:
  • Legacy runtime: many lookup APIs return optionals (nil on failure), so handle with guard let / fallback logic.
  • New runtime: APIs throw errors, so use do/catch.

Legacy Runtime

Legacy APIs commonly return nil for lookup/create-style operations:

New Runtime

New runtime APIs throw errors, so failure handling moves to do/catch:
This pattern applies equally in UIKit and SwiftUI. The key migration change is optional unwrapping in legacy vs error catching in the new runtime.

Choosing an Artboard and State Machine

For more information, see artboards documentation for more details.

For more information, see state machines documentation for more details.

Legacy Runtime

New Runtime

Creating a Rive View

Legacy Runtime

New Runtime

Setting Fit and Alignment

For more information, see the layout docs for all fit and alignment options.

Legacy Runtime

To use artboard layout sizing in the legacy runtime:

New Runtime

To use artboard layout sizing in the new runtime:

Default Layout Scale Factor

When using layout fit, both runtimes support automatic and explicit scale factors.

Legacy Runtime

Use RiveViewModel.layoutScaleFactorAutomatic (default) or set an explicit numeric value on layoutScaleFactor.

New Runtime

Use .layout(scaleFactor: .automatic) or .layout(scaleFactor: .explicit(...)) on Rive.fit.

View Models

For more information, see the data binding docs for complete view model instance APIs.

Legacy Runtime

In legacy, view models are queried from RiveFile, then instances are created from that queried view model.

New Runtime

In the new runtime, the view model is represented as source metadata passed directly into createViewModelInstance.
You can also source the view model from an artboard default:

View Model Instance Properties

Legacy Runtime

Legacy data-binding instances expose typed property objects that you query from the instance.

New Runtime

The new runtime uses typed path descriptors with methods on ViewModelInstance for set/get/observe.

Bindable Artboards

Legacy Runtime

Legacy artboard property binding uses a bindable artboard wrapper type.

New Runtime

The new runtime binds artboards with a typed property descriptor and setValue on the instance.

Data Binding

For more information, see the data binding docs for full API coverage.

Legacy Runtime

You can also manually bind a specific instance:

New Runtime

Updating a Data Bind Unsettles the State Machine

Legacy and new runtime behavior differ here:
  • Legacy: after changing a data bound property, you typically call play() to advance/unsettle and apply the change if the graphic has settled.
  • New runtime: setting a data bound property no longer requires an explicit play() call, simplifying the API.
Best practice for migration: if you need initial values, set them before creating and presenting a view. This avoids showing default values for a frame before your app-provided values are applied.

Legacy Runtime

When updating a bound value after the view is created, keep a reference to the instance and call play() after mutation:

New Runtime

In the new runtime, update the bound value after the view is created. No explicit play() call is needed.

Playing and Pausing

For more information, see playback controls in the Apple runtime guide.

Legacy Runtime

New Runtime

Frame Rate

For more information, see frame rate controls and ProMotion notes.

Legacy Runtime

New Runtime

Loading Referenced Assets

Legacy Runtime

The legacy runtime uses a pull model via a callback that resolves assets on demand.

New Runtime

The new runtime uses a push model, where assets are registered on the worker ahead of use.

Logging

For more information, see the logging guide for shared concepts and filtering options.

Legacy Runtime

New Runtime

Fallback Fonts

Both runtimes support fallback fonts.
  • RiveFont.fallbackFontsCallback remains available
  • Existing fallback font strategies can be reused across both runtimes

New Exclusive Features

Worker-Based Concurrency

The new runtime introduces Worker as an explicit concurrency primitive. This is a substantial change from the legacy runtime, which did not expose an equivalent concept. Benefits include:
  • Better control over background processing
  • Shared global asset registration per worker
  • More predictable architecture when rendering multiple files
A shared worker is usually the best default. Use multiple workers only when you need additional parallel processing, such as when rendering multiple heavyweight graphics.

Async Initialization APIs

The new runtime supports async constructors and async view wrappers (RiveUIView with async closure and AsyncRiveUIViewRepresentable) to better model real-world loading flows.
The async wrappers are useful when a view must own its own loading lifecycle. If you need reuse and caching across screens, prefer creating and storing File/Rive objects at a higher level.

Legacy Exclusive Features

Some features in the legacy runtime are intentionally not present in the new runtime.

CDN Assets

Legacy file loading may use CDN-backed asset flows (for example via loadCdn behavior). The new runtime’s asset model is worker-based and push-oriented via explicit asset registration APIs.

State Machine Inputs

The legacy runtime supports state machine input APIs directly. The new runtime does not expose equivalent input APIs, and migration should move to data binding properties (number, boolean, string, trigger-style interactions). The Rive Editor provides a conversion tool in Menu > Convert Inputs to ViewModels that can help with initial migration.
There are no current plans to reintroduce direct state machine input APIs in the new runtime.

Events

The legacy runtime supports event listeners. The new runtime does not currently expose an equivalent event listener API. For many migration scenarios, a data binding contract is the recommended replacement for app-runtime communication. Simple event-like behavior can often be modeled with trigger-oriented view model properties.
There are no current plans to reintroduce legacy-style event listener APIs in the new runtime.

Linear Animations

Legacy integrations can directly target linear animations. In migration, graphics are required to contain a state machine. For existing files that rely on linear animations, create a state machine in the Editor with a single state that plays the desired animation.

Observing State Machine State

Legacy integrations often used state-change delegate callbacks (for example, RiveStateDelegate.stateChange(...)) to react to animation state. The new runtime does not expose a direct state-name observation API in this guide. For migration, model those app-facing signals as data-binding properties and observe them from the bound instance.

Getting by Index

Where possible, prefer named queries and explicit sources (for example, ViewModelSource and named artboard/state machine queries) over index-based coupling.