iOS production: runtime dlsym failures ('init', 'loadRiveFile' symbol not found) for a subset of App Store users — rive 0.14.11

Submission checklist

• I have confirmed the issue is present in the latest version of the rive Flutter package
• I have searched the documentation and forums and could not find an answer
• I have searched existing issues and this is not a duplicate

Description

Description

Since upgrading to rive: 0.14.11 (from the pre-rive_native architecture), a subset of
our production iOS users gets runtime FFI symbol lookup failures. The same App Store binary
works fine for the majority of users, but for the affected group every Rive call fails:

1. During RiveNative.init():

Invalid argument(s): Failed to lookup symbol 'init': dlsym(RTLD_DEFAULT, init): symbol not found
  ffi_dynamic_library_patch.dart:33  DynamicLibrary.lookup
  rive_text_ffi.dart:534             init (rive_native)
  rive_text_ffi.dart                 initFont (rive_native)
  rive_text.dart:589                 Font.initialize (rive_native)
  rive_native.dart:276               RiveNative.init (rive_native)

2. On any subsequent file load:

RiveFileLoaderException: Failed to load Rive file from asset: assets/animations/onboarding.riv.
Error: Invalid argument(s): Failed to lookup symbol 'loadRiveFile': dlsym(RTLD_DEFAULT, loadRiveFile): symbol not found

Note: the Font.initialize failure inside RiveNative.init() surfaces as an unhandled
async error that escapes a try/catch around await RiveNative.init() — the awaited
future completes normally while the error is thrown from an unawaited internal future.
This makes the failure impossible to handle cleanly on the app side; we had to wrap init
in runZonedGuarded and gate all Rive usage behind a flag to keep production stable.

Impact (Sentry, production App Store builds, last 30 days)

• ~90–100 unique users affected (a noticeable single-digit % of our iOS user base)
• 460+ events across the two signatures, first seen the day we shipped the 0.14.11 upgrade
• OS skew: ~50% of events on iOS 26.6.x; devices from iPhone 11 up to iPhone 16 Pro Max
• 100% production, App Store build type — not a local/dev environment issue

Steps to reproduce

We cannot reproduce locally — our own devices and simulators work. The failure affects a
consistent subset of end-user devices with the identical binary, which points at the
prebuilt rive_native static libraries failing to resolve on some device/OS combinations
rather than at app-side integration. We already tried alternative Xcode build settings
(stripping options, linking flags) with no change.

This looks like the same family as:

• #392 and #432 (closed as not planned — same dlsym 'init' signature)
• #622 (prebuilt rive_native binaries built with Xcode 16.1 incompatible with the
  Xcode 26 toolchain — same symbols, surfacing at link time instead of runtime)

Context / questions

We are a paying Rive customer — the editor subscription and a significant investment in
Rive animations are built into our product. Right now we ship with all animations disabled
behind a fallback for affected users, and we are actively evaluating a migration to Lottie,
which we would prefer to avoid.

1. Is the root cause understood? Is it the Xcode 16.1-built prebuilt binaries (as in #622)?
2. Is there a fix planned (binaries rebuilt with the Xcode 26 toolchain), and roughly when?
3. Is there anything app developers can do today — e.g. a build-from-source path for
   rive_native — that resolves the runtime symbol lookups?

Happy to provide full Sentry event JSONs, affected device/OS breakdowns, or test builds.

Info

• rive: 0.14.11 (latest at time of filing), rive_native via transitive dependency
• Flutter 3.44.2 (stable), Dart 3.12.2, compile mode: release (AOT)
• iOS 26.6.x (majority), also earlier iOS 26.x; devices iPhone 11 → iPhone 16 Pro Max
• Xcode: current stable 26.x toolchain for building

Reproduction steps / code

No response

Upload your reproduction files / stack trace

No response

Source .riv / .rev file

No response

Screenshots / video

Zrzut ekranu 2026-08-30 o 1.59.43 PM.png

Rive Flutter package version

0.14.11

Flutter version

Flutter 3.44.2 (stable), engine revision 77e2e94772
Dart 3.12.2 (stable)
rive: 0.14.11 (latest), rive_native: 0.1.11 (transitive)
Xcode 26.2 (17C52) on macOS
Compile mode: release (AOT), production App Store builds

Device

Affected end-user devices (from Sentry, same App Store binary): iPhone 11, iPhone 13 Pro Max, iPhone 16 Pro, iPhone 16 Pro Max (~34% of events), iPhone 17 Pro. Physical devices only. Our own development devices and simulators are NOT affected — we cannot reproduce locally.

OS version

iOS 26.6.1 (builds 23G82 / 23G83) — ~50% of events; remainder on other iOS 26.x versions.

Additional context

• First seen in production the day we shipped the rive 0.14.x upgrade (previously on the
  pre-rive_native architecture with no such errors); ongoing for 24+ days across multiple
  app builds.
• The Font.initialize failure inside RiveNative.init() escapes a try/catch around
  await RiveNative.init() (the error is thrown from an unawaited internal future), so it
  cannot be handled cleanly app-side. We currently wrap init in runZonedGuarded and gate
  all Rive usage behind a flag, falling back to static UI for affected users.
• Likely related: #392, #432 (same dlsym 'init' signature, closed unresolved) and #622
  (prebuilt rive_native binaries vs Xcode 26 toolchain — same symbols at link time).
• We tried alternative Xcode build settings (strip/link options) with no effect.
• Happy to share full Sentry event JSONs and device/OS breakdowns.

Start with rive_native 0.1.11 and the RiveNative.init(), Font.initialize, and loadRiveFile entry points named in the traces; compare the prebuilt iOS libraries with the Xcode 26 release/App Store build. Review related issues #392, #432, and #622, then test on an affected physical iOS device since local devices and simulators do not reproduce it. Done means a confirmed root cause plus a released fix or documented build-from-source workaround for the symbol lookup failures.