RunAnywhere ships five SDKs (Swift, Kotlin, React Native, Flutter, Web) for on-device AI, and the platform-specific pages are reasonably thorough — but the cross-cutting surfaces (quickstart, parity matrix, top-level claims) repeatedly contradict the per-SDK pages, and several declared APIs aren't actually implemented.
Location:/quickstart vs /swift/installation and /flutter/installation
Problem:/quickstart shows .package(url: "https://github.com/RunanywhereAI/runanywhere-sdks.git", from: "0.1.0") for Swift and runanywhere: ^0.1.0 for Flutter. But /swift/installation shows from: "0.19.1" and /flutter/installation shows runanywhere: ^0.16.0 (plus required sibling packages runanywhere_llamacpp: ^0.16.0 and runanywhere_onnx: ^0.16.0). The Kotlin tab in /quickstart also pins 0.1.0 across all three artifacts.
Consequence: A developer (or agent) following the top-level quickstart resolves to a ~16-to-19-release-old SDK. Worse, the Flutter quickstart shows only the runanywhere package — but the install page makes clear that runanywhere_llamacpp and runanywhere_onnx are required for LLM/STT/TTS/VAD. The quickstart user gets an old version and a broken dependency set.
The fix: Drive all install snippets from a single versioned source. At minimum, bump the quickstart pins to match the per-SDK install pages, and include the LlamaCPP/ONNX dependencies in the Flutter and Kotlin quickstart blocks the same way the install pages do.
Location:/sdks ("Feature Comparison") vs /swift/introduction, /swift/diffusion, /kotlin/lora, /kotlin/rag, /llms.txt
Problem:/sdks states: "All SDKs have feature parity and provide the same core capabilities" with a check-mark matrix showing every feature ✓ across all five SDKs. But:
Image Generation (Diffusion) is a Swift-only page (/swift/diffusion), backed by Apple's . No equivalent for Kotlin/RN/Flutter/Web.
Code verification
Runtime snippet checks
Run the public examples from this audit in an isolated sandbox and attach the pass, fixed, skipped, and failed counts to the report.
VLM (Vision) is shown on /swift/introduction and listed under Kotlin in /llms.txt; not on RN/Flutter/Web.
LoRA adapters (/kotlin/lora) and RAG pipeline (/kotlin/rag) are Kotlin-only.
Structured output / JSON schema-guided generation is called out for Web and React Native specifically in /llms.txt.
Consequence: Agents and developers reading the parity table will believe Web supports image generation or that Flutter has RAG, and will draft architectures around features that don't exist. This is the worst kind of contradiction for AI agents — the parity table is the most-parseable artifact and it is wrong.
The fix: Replace the blanket parity claim with the actual matrix. The existing check table already has columns per SDK — fill in the advanced features (Diffusion, VLM, LoRA, RAG, Structured Output) as additional rows with accurate ✓/✗ values, and remove the "All SDKs have feature parity" sentence.
Location:/index vs /quickstart (Kotlin/React Native/Flutter tabs)
Problem: The landing page asserts: "All AI inference runs 100% on-device. Once models are downloaded, no network connection is required for inference." But every non-Web initialization snippet requires an API key and a base URL pointing at a network service:
The Web SDK's init takes neither: RunAnywhere.initialize({ environment: 'development', debug: true }). There is no auth section, no page explaining what the API key is for, where to obtain one, what api.runanywhere.ai does, whether calls go to it at runtime, or what happens offline if the SDK can't reach it.
Consequence: Developers can't reason about offline behavior, privacy guarantees, or what fails when api.runanywhere.ai is unreachable. The "100% on-device" marketing claim and the mandatory remote-looking config are irreconcilable without a paragraph of explanation that doesn't exist.
The fix: Add an Authentication / Telemetry page that explains (a) where to get an API key, (b) what baseURL is actually called for (model registry? telemetry? license check?), (c) whether the SDK functions when offline at init time, and (d) why the Web SDK doesn't require either. Cross-link from /index and every /*/quick-start.
4. Web SDK shown at full feature parity but every Web page warns "Early Beta" (significant)
Location:/sdks Feature Comparison vs /web/installation, /web/quick-start, /web/tool-calling
Problem: The /sdks matrix gives the Web SDK ✓ on LLM, STT, TTS, VAD, Voice Agent Pipeline, Streaming, Offline, and GPU (WebGPU). Yet every Web SDK page leads with: "Early Beta — The Web SDK is in early beta. APIs may change between releases." The Tool Calling page additionally notes that imports come from @runanywhere/web-llamacpp and not from @runanywhere/web — a non-obvious split not reflected in the matrix.
Consequence: A reader scanning the comparison table will choose the Web SDK assuming production readiness, then discover (page-by-page) that APIs are unstable and import paths differ. The stability signal lives only inside Web pages.
The fix: Add a "Stability" or "Maturity" row to the /sdks matrix marking Web as Beta. Surface the @runanywhere/web-llamacpp vs @runanywhere/web split in the Web introduction so agents can find the right import path without crawling individual feature pages.
5. transcribeFile() is in the public surface but throws at runtime (significant)
Location:/react-native/stt/transcribe
Problem: The page explicitly states: "transcribeFile() is declared in the SDK but not yet implemented. Calling it will throw: 'transcribeFile not yet implemented with rac_* API'. Use transcribe() or transcribeBuffer() instead."
Consequence: An AI coding agent indexing the React Native API surface will see transcribeFile as a callable method, suggest it in code, and the user only finds out at runtime via an exception. This is the canonical "looks documented, breaks silently for agents" trap.
The fix: Either remove transcribeFile from the public API until it's implemented, or move the warning to the very top of the method's signature block and mark the method @deprecated / @unimplemented in the SDK's type definitions so IDE tooling surfaces it before runtime.
6. Quickstart pages exist for every SDK but appear to be stubs (significant)
Problem: In the indexed content for these pages, the body collapses to just a heading (e.g. # Quick Start followed by Source: … and nothing further; # Error Handling / ## SDKError with no schema, no error list, no examples). The substantive quickstart content is on the global /quickstart page, and Flutter's actual error reference lives on /flutter/error-handling — but the per-SDK quick-start entries in the nav don't carry content.
Consequence: Developers clicking the platform-specific "Quick Start" in the sidebar land on near-empty pages. Agents indexing llms-full.txt see entries with no body and have nothing to extract, so they fall back to the global quickstart which has its own version-pin problems (see issue 1).
The fix: Either populate each /<sdk>/quick-start with a self-contained 5-minute walkthrough that includes installation, init, and a runnable LLM call — or delete those pages and redirect the nav to the global /quickstart. The /swift/error-handling page in particular needs a real SDKError enumeration table comparable to the one Flutter has at /flutter/error-handling.
Location:/quickstart (Kotlin vs React Native vs Flutter tabs)
Problem: The Kotlin tab includes an explicit ModuleRegistry.register(LlamaCPP::class) line. The React Native and Flutter tabs do not show any equivalent module-registration step, even though both SDKs use the same multi-package architecture (runanywhere_llamacpp / runanywhere_onnx for Flutter, @runanywhere/llamacpp / @runanywhere/onnx for RN per /react-native/introduction). The Web quickstart skips initialization-of-backends entirely and jumps straight to TextGeneration.loadModel(...).
Consequence: A developer following the Flutter or RN quickstart verbatim will hit "no backend registered" / "module not found" failures at first LLM call, because the quickstart never tells them to wire up the LLM backend. The Kotlin tab proves the SDK requires this — but the parallel tabs hide it.
The fix: Show backend registration in every tab where it applies. If RN/Flutter auto-register backends when the package is imported, state that explicitly in the quickstart so the asymmetry is intentional and visible.
8. Flutter RAM guidance recommends 7B models at 4–5 GB without device-feasibility caveat (minor)
Problem: The table lists 7B (Q4) with 4–5GB RAM as "High quality" — recommended alongside the smaller tiers — with no note that 4–5 GB of available RAM is unrealistic on the vast majority of mid-tier Android devices and even many current iPhones once the OS and app overhead are accounted for. The same page elsewhere warns sternly about emulator performance but says nothing about device-class feasibility for the largest tier it suggests.
Consequence: Developers will pick the 7B tier for "best quality," ship to production, and discover their model can't even load on most user devices. The page already has the right framing for emulators; the same realism is missing for memory.
The fix: Add a "Device class" column to the model-selection table (e.g., "7B Q4: high-end devices only; on iOS, A16+ / 8GB devices recommended; on Android, flagship devices with 12 GB RAM") and link to a runtime memory-probing API if one exists.
9. llms.txt exists but omits SDK stability and feature-availability signals agents need (minor)
Location:/llms.txt
Problem: The llms.txt index enumerates platforms and lists platform-specific features (e.g., Kotlin VLM, LoRA, RAG; Swift Vision/Image Generation; Web/RN structured output), but does not mark the Web SDK as Early Beta, does not state the current SDK version per platform, and does not flag the unimplemented transcribeFile. The site has the right file in place; it just doesn't carry the metadata that would prevent agents from generating broken examples.
Consequence: Agents that prefer llms.txt over crawling will not see the stability disclaimers that live only on per-page Notes/Warnings. They'll happily generate "production-ready" Web SDK code against an unstable API.
The fix: Extend llms.txt (or generate llms-full.txt from a single source of truth) to include, per SDK: current published version, stability tier (GA / Beta / Early Beta), and per-feature support flags so an agent can answer "is Web's tool-calling stable?" from one fetch.
What they do well
Per-platform best-practices pages are unusually specific — the Flutter "Platform Gotchas" section (use_frameworks! :linkage => :static, PERMISSION_MICROPHONE=1, WAV-header construction for TTS playback, PCM16 16 kHz mono for STT) is exactly the kind of buried-detail content most SDKs omit, and it's well placed.
Voice Agent event taxonomy is well structured — the VoiceSessionStarted → VoiceSessionTurnCompleted event table on /flutter/voice-agent gives agents a parseable contract instead of prose.
First-time CoreML compile time is disclosed — the /swift/diffusion "5–15 minutes" Warning sets correct expectations rather than hiding the cost in a footnote.
Top 3 recommendations
Reconcile the parity story. Either deliver true feature parity or replace the "All SDKs have feature parity" sentence and the universally-✓ matrix with an accurate per-feature, per-platform support grid that includes Diffusion, VLM, LoRA, RAG, Structured Output, and a Stability column.
Fix version drift across install snippets. The top-level /quickstart should be regenerated from the same source as /swift/installation, /flutter/installation, etc., so quickstart pins never lag the platform pages by 16+ releases.
Add an Authentication & Connectivity page. Explain what apiKey and baseURL actually do, when the SDK contacts api.runanywhere.ai, what fails offline, and why the Web SDK doesn't need either. Without this, the "100% on-device" claim and the network-looking init are visibly inconsistent.