SceneKit to RealityKit Migration
SceneKit is deprecated. Move your AR app to RealityKit before it costs you a rewrite.
SceneKit → RealityKit Migration
At WWDC 2025 Apple deprecated SceneKit. It is now in "critical-bug-only" maintenance: no new features, no new platform support, and a documentation set marked deprecated. Apple's message, delivered in the session Bring your SceneKit project to RealityKit, is explicit — new work belongs in RealityKit, and existing SceneKit apps should plan a move.
If your AR app was built between 2017 and 2022, there is a very good chance it renders through ARSCNView and a tree of SCNNodes. It still runs today. This page is about what "still runs" means for the next few years, and how we get you off SceneKit without rebuilding the product from scratch.
What "critical-bug-only" means for your app
- It will not break tomorrow. Deprecated Apple frameworks typically ship for several more OS releases. Your app will continue to install and run on iOS 26 and iOS 27.
- It will stop keeping up. New ARKit capabilities land in RealityKit first and sometimes only there:
RealityView, cross-platform reference objects, visionOS, Reality Composer Pro content, spatial audio, and the modern material system. A SceneKit app cannot adopt them without a rendering layer rewrite. - It is invisible on Vision Pro. SceneKit has no visionOS story. If Vision Pro is anywhere on your roadmap, the SceneKit question is already settled.
- Your hiring pool is shrinking. Engineers starting in Apple AR today learn RealityKit. Every year on SceneKit makes the app harder to staff.
The right time to plan the migration is while the app is stable and the original team's knowledge is still available, not when an OS update finally breaks something.
The migration map
Most of the work falls into a handful of predictable translations. We have done them enough times to estimate them accurately.
| SceneKit | RealityKit |
|---|---|
ARSCNView (UIKit) | RealityView in SwiftUI (iOS 18+), or ARView where UIKit must stay |
SCNScene / SCNNode tree | Entity hierarchy with components (ECS) |
SCNGeometry + SCNMaterial | MeshResource + PhysicallyBasedMaterial / UnlitMaterial |
SCNLight per node | Image-based lighting by default; DirectionalLight / PointLight / SpotLight components where needed |
SCNAction / SCNAnimation | Entity.move(to:relativeTo:duration:), AnimationResource, USD-authored animations |
SCNPhysicsBody | PhysicsBodyComponent + CollisionComponent |
ARSCNViewDelegate anchor callbacks | AnchorEntity and ARKit anchor updates via ARSession / RealityKit anchoring |
.scn / .dae assets | USDZ, authored or converted in Reality Composer Pro |
SCNView.hitTest | RealityView entity hit testing and CollisionComponent raycasts |
Two things do not translate cleanly and we flag them early: custom SCNProgram Metal shaders (RealityKit uses ShaderGraphMaterial authored in Reality Composer Pro or CustomMaterial with Metal surface shaders, which is a rewrite rather than a port) and highly dynamic procedural geometry (RealityKit's LowLevelMesh covers it, but the code looks nothing like SCNGeometrySource).
Typical effort tiers
Every app is different, but our engagements cluster into three tiers:
Viewer apps. Load a model, anchor it, let the user walk around it. Usually a clean swap to RealityView with USDZ assets. Days to a couple of weeks, including converting the asset library.
Interactive AR. Gestures, animations, physics, custom materials, scene-state logic. The entity/component model changes how state is organized, so this is a structured port, not a find-and-replace. Several weeks, with the original app kept shippable on a branch throughout.
Multi-user and enterprise. Shared sessions, persistent anchors, object tracking, backend sync, and often a visionOS target added at the same time. This is a phased program where the migration is also the moment to adopt cross-platform ARKit and a modern content pipeline.
In each tier we start by running your app through a migration audit — an inventory of every SceneKit API the codebase touches, classified as direct translation, restructure, or rewrite — and give you the estimate in writing before anyone commits.
What you get
- A migration audit and written plan with a tier estimate
- A RealityKit build that matches the existing app's behavior, delivered behind a branch so your release cadence never stops
- Your assets converted to USDZ and organized in a Reality Composer Pro project your designers can maintain
- Optional: a visionOS target sharing the same RealityKit content
Free migration assessment
Send us a build or a repository link and we will tell you which tier you are in and what it will take. No commitment. Contact us, call +1 (415) 993-7206, or email info@realityrogue.com.