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:- Shared Features - Common operations and their equivalents.
- New Exclusive Features - Capabilities only available in the new runtime.
- 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.
- Creating a
Workerasynchronously - Creating
FileandRiveobjects - Creating artboards, state machines, and view model instances
Lifecycles and Threading
The legacy runtime is effectively main-thread driven throughRiveViewModel and RiveView.
The new runtime introduces Worker objects for background processing while still enforcing API calls on the main actor. In practice:
Workerowns the background processing contextFilestrongly references itsWorker- 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.
Shared Features
Shared APIs
The main shared API area is fallback fonts throughRiveFont.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. LegacyRiveViewModel 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 (
nilon failure), so handle withguard let/ fallback logic. - New runtime: APIs throw errors, so use
do/catch.
Legacy Runtime
Legacy APIs commonly returnnil for lookup/create-style operations:
New Runtime
New runtime APIs throw errors, so failure handling moves todo/catch:
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
New Runtime
Default Layout Scale Factor
When using layout fit, both runtimes support automatic and explicit scale factors.Legacy Runtime
UseRiveViewModel.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 fromRiveFile, 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 intocreateViewModelInstance.
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 onViewModelInstance 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 andsetValue on the instance.
Data Binding
For more information, see the data binding docs for full API coverage.
Legacy Runtime
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.
Legacy Runtime
When updating a bound value after the view is created, keep a reference to the instance and callplay() after mutation:
New Runtime
In the new runtime, update the bound value after the view is created. No explicitplay() 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.fallbackFontsCallbackremains available- Existing fallback font strategies can be reused across both runtimes
New Exclusive Features
Worker-Based Concurrency
The new runtime introducesWorker 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 vialoadCdn 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.