SceneView: A Compose-Native 3D and AR Layer That Replaces Archived Sceneform

The gap SceneView is filling after Sceneform went away

Google archived the Sceneform Android SDK in 2021 and, according to the README, ships no first-party declarative AR renderer, with its current ARCore samples hand-rolling a throwaway OpenGL framework. That leaves an Android developer who wants 3D or AR in a Compose screen choosing between raw OpenGL, a lower-level engine binding, or an unmaintained fork. SceneView positions itself in that hole: it descends from the maintained Sceneform community fork and is described as the actively-developed, Jetpack-Compose-native way to build 3D and AR on Android. The intended audience is narrow and identifiable. It is the Android engineer who already writes Compose, has a model file to display, and does not want to own a render loop, a lifecycle, or a camera permission dance. The secondary audience is anyone who wants the same mental model on Apple platforms, though the maturity table tells a different story there.

ARCore for perception, Filament for rendering, Compose for the surface

The Android architecture is a three-layer split. ARCore handles perception: plane detection, anchors, depth and geospatial. Filament, Google's real-time renderer, handles drawing. Jetpack Compose is the surface you write against. The public API is a composable that takes a modifier and a content lambda, and inside it you resolve a model instance and hand it to a node. The README's Android example is short enough to quote in full: a SceneView composable with Modifier.fillMaxSize(), a rememberModelInstance call against a modelLoader for "models/helmet.glb", and a ModelNode with scaleToUnits and autoAnimate parameters. There are no lifecycle callbacks in that snippet, which is the point the README makes explicitly: the runtime handles everything. The Apple side mirrors the shape with a SceneView that takes an environment value and a ModelNode built from a named USDZ file, so the concepts transfer even where the renderer underneath does not.

Format support is decided by bytes, not by file extension

This is the most concrete engineering claim in the repository. On Android, glTF and GLB go through Filament. 3MF, STL (binary and ASCII), OBJ with MTL, and PLY (binary and ASCII) are parsed by pure Kotlin code that converts to GLB in memory. The README states that 3MF millimetres are honoured, that OBJ material colours are carried across, and that PLY vertex colours are too. Apple platforms get glTF, GLB and USDZ through RealityKit, and no 3MF, STL, OBJ or PLY. The web column shows glTF and GLB only. The sniffing behaviour matters more than the table: the format is decided by the bytes, so a file arriving as application/octet-stream with no filename still opens. On Android the demo app registers as an Open with target, so a file tapped anywhere on the phone lands in the viewer and then in AR. If your product receives model files from chat apps or download folders, that byte-level detection and the in-memory GLB conversion are the two mechanisms doing the work.

Getting it running: Maven coordinates, a composable, and an MCP command

The README points at Maven Central for the Android artifacts, published as io.github.sceneview:sceneview for 3D and io.github.sceneview:arsceneview for AR. The README does not print the Gradle dependency block, so copy the exact version from the badge or from central.sonatype.com rather than from this article. The minimum viable integration is the Compose snippet above: a modelLoader, rememberModelInstance, and a ModelNode with scaleToUnits for real-world sizing. For the AI-assisted path, the README gives one command: claude mcp add sceneview -- npx sceneview-mcp, followed by a natural-language request such as building an AR app with tap-to-place furniture. The web path is two script tags from jsDelivr, one for filament.js and one for sceneview.js, then a single call: SceneView.modelViewer("canvas", "model.glb"). There is also a demo deep-link convention, https://sceneview.github.io/open?demo=<id>, which opens a specific demo screen from a link or QR code. That is useful for pointing a colleague at a behaviour instead of describing it.

The AI-first framing is a distribution strategy, not a rendering feature

SceneView advertises an assistant that reads llms.txt and writes code that compiles first try, plus an MCP server and a ChatGPT/Codex plugin. The MCP server is listed as Stable, which puts it on the same maturity footing as the Android renderer and above every non-Android platform. Treat this as a bet about how developers discover SDKs in 2026 rather than as a capability of the renderer itself. The claim that generated code compiles first try is unfalsifiable from the material here, and it depends on the model, the prompt and the version, so I would not plan around it. What is verifiable is the surface: a llms.txt file, an npm package called sceneview-mcp, and a documented add command. If your team already drives an assistant through MCP, the cost of trying it is one command. If not, the AI layer is irrelevant to your adoption decision and the rendering stack is the whole story.

Platform maturity is uneven, and the README says so

The platform table is unusually honest. Android with Filament and Jetpack Compose is Stable. Android TV with Compose TV is Alpha. iOS, macOS and visionOS with RealityKit and SwiftUI are Alpha. Web with Filament.js compiled to WASM is Alpha. Desktop is Alpha and uses a software renderer, which will not match Filament output. Flutter and React Native are Alpha and use native rendering per platform through PlatformView and Fabric respectively. Compose Multiplatform is Alpha and described as a viewer subset covering Android and iOS only, so the shared-code promise stops well short of the full feature set. The practical reading: if you need AR on iOS, you are choosing an Alpha API with a different renderer, a different file format set (USDZ rather than the Android loader list), and no shared code path with Android. That is a real constraint, not a documentation footnote.

Where SceneView is the wrong tool, and what to use instead

SceneView is the wrong choice when your scene is not a model file. If you are writing a game with a scene graph you control, custom shaders, physics, or a large number of animated skinned characters, a general-purpose engine is the better fit: Filament is exposed here as a rendering backend behind a declarative UI layer, not as an authoring environment. The same applies if you need heavy post-processing or a render pipeline you tune per frame. The closer alternative for Android specifically is to stay on the Sceneform community fork that SceneView descends from, or to follow Google's ARCore sample approach and hand-roll OpenGL. The difference in approach is stark: those routes give you direct control of the render loop and no Compose integration, while SceneView gives you a composable, a node abstraction and a loader pipeline in exchange for accepting its versioning and its Alpha labels outside Android. For Apple-only projects, writing directly against RealityKit and SwiftUI is a smaller dependency than adopting an Alpha wrapper whose Android half you will never use.

Licence, release cadence and the cost of staying current

SceneView is Apache-2.0, which permits commercial and closed-source use and includes a patent grant. That is the same licence family as much of the Android ecosystem, and it means you are not exposed to a copyleft obligation on your app code. I am not giving legal advice; read LICENSE in the repository for the actual terms. On maintenance, the release list shows v4.34.0 and v4.32.0 both dated 2026-09-09 and v4.33.0 dated 2026-08-26, which suggests frequent minor releases rather than long-lived stable branches. The README's own platform table shows why that cadence matters: if you ship on Android only, you track one Stable target. If you also ship the web or Flutter surface, you are tracking Alpha APIs that can move between minor versions, and the Flutter and React Native entries are versioned in lockstep with the SDK at v4.34.0. Budget for reading release notes before each bump, and pin your version rather than floating it.

Editorial conclusion

Adopt SceneView if you are building an Android app in Jetpack Compose and need glTF, 3MF, STL, OBJ or PLY rendered at real size, with ARCore placement on top, because it is the maintained Compose-native successor to the archived Sceneform and the Android target is the only one marked Stable. Do not adopt it as a cross-platform bet today: iOS, macOS, visionOS, web, desktop, TV, Flutter, React Native and Compose Multiplatform are all Alpha, and the Compose Multiplatform entry is explicitly a viewer subset for Android and iOS only. Before committing, verify three things against the repository: the exact Maven coordinates and version for io.github.sceneview:sceneview and arsceneview, whether the ModelLoader in your target version exposes the loaders for 3MF, STL, OBJ and PLY or whether you must wire them yourself, and whether your minSdk and ARCore requirements match what the samples in samples/ actually declare.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sceneview/sceneview on GitHub