Rive Mascot Developer Handoff: A Production Checklist for Web and Mobile

A character waves beautifully in the preview. The designer sends a .riv file. Your developer opens the integration ticket and immediately has questions: which artboard, which State Machine, which properties, and what should happen if the request fails?

Those questions reveal a delivery gap. The animation may be finished visually, but the product interface is still undefined.

A useful Rive mascot handoff gives the next developer enough information to load the character, control it, recover from failure, and update it later. It also gives the founder a concrete way to decide whether the work is complete.

This checklist is for teams commissioning or integrating interactive app mascots, onboarding characters, and AI companions. The example names and ranges are proposed conventions, not requirements imposed by Rive. Use them to build your own delivery agreement before production starts.

1. Separate editable source from the runtime file

Start by asking for two different deliverables: the source you can maintain and the asset your application can load.

Rive exports a .riv file for runtime use. Its backup format, .rev, preserves information that is stripped from the runtime export. That distinction matters when you need to change the artwork or animation later. See Rive’s official guides to runtime export and backup export.

Request access to the editable project or an appropriate backup, plus the final runtime file. Confirm that the arrangement also covers any external artwork, fonts, images, or audio required by the delivered design. Do not assume that receiving a binary export transfers access to everything used to create it.

Use a release name that connects these deliverables. For example, the project revision, exported asset, and documentation might all reference assistant-v1.2. The exact naming scheme is less important than being able to answer, “Which source produced the file currently in production?”

2. Specify the entry point precisely

A developer should not need to open every artboard to find the intended character.

Document the exact artboard name, State Machine name, intended default configuration, and expected initial pose. Include the character’s intended display size and the fit/alignment behavior for narrow and wide containers.

For example:

Asset: assistant-v1.2.riv
Artboard: ProductAssistant
State Machine: AssistantController
View Model: AssistantData
Initial activity: idle
Initial gaze: centered
Initial mouth: closed

These identifiers form part of the integration contract. Treat a public-name change as a coordinated change to both the file and its host code.

Rive allows one exported asset to be used across supported runtimes, but compatibility still depends on the features and runtime versions involved. A file loading successfully is only the beginning of verification; you must also check that the intended behavior is present.

3. Deliver a control schema, not a list of animations

“Idle, happy, wave, talk” is an animation inventory. It does not explain how the application should request those behaviors.

For a new integration, define a small public data interface. Rive’s Data Binding system connects View Model data to scene properties; View Model instances hold the actual values. The official Data Binding overview explains this separation.

An example handoff schema could look like this:

Property	Type	Accepted values	Default	Owner
activity	Number	Integer 0–4	0	Conversation controller
mood	Number	Integer 0–2	0	Product state adapter
mouthOpen	Number	0–1	0	Audio controller
lookX	Number	-1–1	0	Attention controller
lookY	Number	-1–1	0	Attention controller

Below the table, define every discrete value. For this example, activity might mean idle, listening, thinking, speaking, or unavailable. Explain whether unsupported values are rejected, clamped, or mapped to a fallback.

Also document units. A value of 0.5 could mean half-open, half a second, or halfway across an artboard. Developers should never have to infer the meaning from a property name.

4. Decide who can write each value

Many apparently random animation bugs come from competing updates rather than a broken rig.

Imagine an idle timer sets activity to idle while the audio player sets it to speaking. Both updates are valid locally, but only one reflects the overall product state. The handoff should establish one application owner for that decision.

A practical division is to let application logic own business state and let the Rive system own the visual response. The app decides that a submission succeeded. The character decides how the success gesture looks.

Document any values that flow back from the character. If a tap inside the artboard can request an action, distinguish the request from the action’s successful completion. A visual event must not be treated as proof that a network operation finished.

5. Write transition rules as observable behavior

“Smooth transitions” is too vague to test. Describe the conditions that cause a transition and what can interrupt it.

For each primary activity, answer three questions: what enters it, what exits it, and which events take priority? An assistant that is speaking should normally respond immediately to cancellation. A celebratory gesture should not prevent the user from starting a new interaction.

An example rule is: “When playback is cancelled, stop mouth updates, close the mouth, and select the current conversation activity. Ignore completion callbacks belonging to the cancelled utterance.” This is specific enough for a developer to implement and for a reviewer to exercise.

Keep the animation’s timing separate from the network’s timing. A thinking loop should tolerate an unknown wait. Avoid assuming that an answer always arrives before a fixed animation finishes.

Need an interactive Rive character for your product?

Mascot Engine creates app mascots, AI companions, State Machines, lip sync, and developer-ready Rive systems for Web, Flutter, and React Native.

View live work and request an estimate at Mascot Engine. Send your project brief on WhatsApp.

6. Make lip-sync requirements explicit

If the character speaks, the handoff needs more than a “talk” animation.

Specify whether the mouth uses a simple speaking loop, an audio-level envelope, or timed viseme changes. These are different deliverables. An amplitude-driven mouth conveys speaking activity, but it does not identify the mouth shape associated with each speech sound.

For timed visemes, include the supported mouth poses, their IDs, the expected timestamp units, and the mapping from the speech system’s output. State what happens when timing data is missing or an unfamiliar label arrives.

Define the clock used for synchronization. A sequence based on audio playback position can behave differently from one based on when network messages arrive. Test buffering and interruption deliberately.

Finally, specify ownership of the mouth. If a facial expression and the speech system both animate the same deformation, document how they combine or which one wins. This decision belongs in the asset design as well as the host integration.

7. Include a loading and lifecycle plan

The person integrating the character must know when it is safe to access its properties and who releases the associated resources.

Write down the expected loading sequence: load the asset, create the appropriate controller, bind an instance, obtain property references, apply the latest application snapshot, and display the ready character.

Rive’s runtime guides provide platform-specific APIs. The Web parameters reference, Flutter guide, and React Native guide should be linked from the handoff rather than replaced with an unqualified “works everywhere.”

Record resource ownership separately from visual state. Reusing loaded file data does not mean that two visible characters should share the same mutable activity and expression. Explain the intended sharing boundary.

8. Test the exported file in the actual hosts

An editor preview proves that the design works in the editor. It does not prove that the selected runtime, renderer, and device combination supports every feature being used.

Ask for runtime notes that identify the package version, renderer, operating system, device or browser, and test outcome. Avoid a single ambiguous checkbox labelled “mobile tested.”

Use the same short event sequence on each target:

1. Load from a fresh application start.
2. Enter listening, then thinking.
3. Begin speaking and change gaze.
4. Interrupt speech before it finishes.
5. Trigger a recoverable failure.
6. Retry and complete the interaction.
7. Leave the screen and return.

Include a missing-asset test and an out-of-range input test. Acceptance should cover both the expected path and at least the failures most likely to affect your product.

If performance matters, ask for the measurement method and environment alongside any result. “Runs smoothly” is a subjective observation. A reproducible profile on the supported device tier is more useful than an unexplained frame-rate number.

9. Define the fallback outside the character

A failed character asset should not make the product unusable.

Keep meaningful status text and essential controls in the host interface. A static image or empty decorative area may be an acceptable visual fallback; an invisible Stop button is not.

For an assistant, preserve the transcript and retry path even when animation fails. For onboarding, allow the user to continue without waiting for the mascot to load.

Also agree on reduced-motion behavior. It might reduce idle movement while retaining a concise success indication, or use a static pose throughout. React Native exposes motion-preference information through AccessibilityInfo; the product still needs an explicit policy for how the character responds.

10. Use a small acceptance document

The best checklist is one your team can actually complete during handoff. Put the evidence next to each requirement.

Deliverable	Acceptance evidence
Editable project or backup	Receiving team can access and maintain it
Runtime .riv	Release identifier matches the documented source
Artboard and State Machine	Exact names confirmed in each target integration
Public controls	Types, ranges, defaults, and owners documented
Transitions	Interruptions and recovery exercised
Speech behavior	Timing format and missing-data fallback tested
Lifecycle	Loading, disposal, and return-to-screen behavior checked
Accessibility	Text status and reduced-motion behavior reviewed
Runtime coverage	Versions and environments recorded

Add a named owner for unresolved items. A known limitation can be acceptable if everyone understands it before release. An undocumented limitation becomes a surprise for the next developer.

Common questions before signing off

Is the .riv file enough? It can be enough to run the character, but it is not the whole maintenance and integration package. Ask separately for editable source access, dependencies, and documentation.

Can the same file serve Web, Flutter, and React Native? That is a reasonable design target across supported runtimes. Validate the actual feature set on the chosen versions instead of assuming identical behavior from the file extension alone.

Does the animator need to build the whole app? No. A clear scope can stop at an integration-ready asset and a small demonstration. If production integration is required, name the screens, platforms, and acceptance tests explicitly.

When is specialist help useful? When character rigging, layered behavior, speech synchronization, and host lifecycle decisions overlap. A specialist can help make those interfaces consistent before the work spreads across multiple people.

Send a brief a developer can estimate

For Mascot Engine’s interactive character services, a useful brief includes the target platforms, existing artwork, required states, speaking requirements, deadline, and expected handoff depth. Mention whether your team already has a Rive asset that needs repair or wants a new character system.

Include one concrete user journey: “The user asks a question, interrupts the answer, then retries offline.” That reveals more about the work than a long list of adjectives describing personality.

By Praneeth Kawya Thathsara, founder of Mascot Engine.

Need an interactive Rive character for your product? Mascot Engine creates app mascots, AI companions, State Machines, lip sync, and developer-ready Rive systems for Web, Flutter, and React Native. Explore live work and request an estimate, or send your project brief on WhatsApp.