At WWDC 2025 Apple deprecated SceneKit. The wording was measured — the framework moves to "critical-bug-only" maintenance, it keeps shipping in iOS, and Apple published a session titled Bring your SceneKit project to RealityKit rather than a kill date. If you own an AR app built on ARSCNView, that measured wording can make it easy to do nothing. This post is the argument for doing something, and a plan for doing it over twelve months without disrupting your roadmap.
What actually changed
Deprecation at Apple is not removal. Your SceneKit app runs on iOS 26 today and will run on iOS 27 in September. What changed is the direction of every new capability:
- New AR features land in RealityKit.
RealityView, Reality Composer Pro content, spatial audio, cross-platform reference objects in iOS 27 and visionOS 27 — none of it is reachable from a SceneKit renderer. - visionOS has no SceneKit. If Apple Vision Pro appears anywhere in your plans, the rendering layer has to change first.
- Bugs you hit will not be fixed unless they are critical. Rendering glitches on new devices and OS versions become your problem to work around.
- The talent pool is moving. Developers entering Apple AR in 2025 and 2026 learn RealityKit. SceneKit maintenance will get harder to staff every year.
None of these force a migration this quarter. Together they guarantee one eventually, on a timeline you will not choose if you wait for a breaking change.
First, triage your app
Not every SceneKit app is the same migration. Spend a week answering these questions before planning anything:
How much SceneKit is there? Run a search for SCN across the codebase and count files. An app with one view controller and a handful of nodes is a different project from one with custom SCNProgram shaders and a physics-driven game loop.
Which parts have no direct RealityKit equivalent? Custom Metal shaders, per-frame procedural geometry, SCNParticleSystem effects, and SceneKit editor scenes all need redesign, not translation. Inventory them explicitly; they drive the estimate.
What is the app's future? A product that is winding down may legitimately ride SceneKit to the end. A product with a roadmap — new features, new devices, new customers — needs RealityKit underneath that roadmap.
Is visionOS in scope? If yes, the migration is also a platform expansion, which changes the budget conversation from "technical debt" to "new market."
Our migration service page describes the three effort tiers we see — viewer apps, interactive AR, and multi-user/enterprise — and most apps fall cleanly into one of them after this triage.
The 12-month plan
This assumes a product team with ongoing feature work. Compress it if the app is small; do not stretch it past a year, because the cost of carrying two rendering stacks grows the longer the branch lives.
Months 1 to 3: decide and de-risk
- Complete the triage above and write down the tier and the list of "no equivalent" features.
- Freeze new SceneKit-specific features. Anything new that touches rendering is built on RealityKit or waits.
- Convert your asset pipeline to USDZ now. This is independent of the code migration, designers can own it, and it removes the single biggest source of surprises later. Reality Composer Pro is the tool.
- Build a throwaway spike: your main scene rendering in
RealityView, no interaction. It calibrates the estimate better than any spreadsheet.
Months 4 to 6: the core port
- Stand up the RealityKit build behind a branch (or a feature flag if your app structure allows it).
- Port in this order: view and camera, anchoring, models and materials, lighting, then interaction, then animation. Our practical walkthrough has before-and-after code for each step.
- Run both builds side by side on the same devices with the same assets. Visual parity is the acceptance criterion; exact pixel parity is not achievable and not the goal.
- Keep shipping from
mainon SceneKit during this phase.
Months 7 to 9: the hard parts
- Rebuild the "no equivalent" features: shaders as Reality Composer Pro shader graphs or
CustomMaterial, particles asParticleEmitterComponent, procedural meshes asLowLevelMesh. - Beta the RealityKit build with real users through TestFlight. AR apps have environment-dependent bugs that no internal test catches.
- If visionOS is in scope, start the visionOS target here; the RealityKit content is now shared, so the incremental work is input and windowing.
Months 10 to 12: ship and delete
- Ship the RealityKit build as a regular release. Keep the SceneKit build available as a rollback for one release cycle.
- Delete the SceneKit code. Do not keep it "just in case"; dead rendering code is a maintenance tax.
- Update the hiring plan and the engineering docs. The team is now a RealityKit team.
What this costs, honestly
For a viewer-tier app, the whole plan collapses into a few weeks and the calendar above is overkill. For interactive AR, expect one to two engineers over the core phases. For multi-user and enterprise apps, it is a program with its own PM. In every tier the asset conversion is the piece most often underestimated, and the piece most easily started today.
What it costs to not do it is harder to see: it is the feature you cannot build in 2027, the Vision Pro deal you cannot bid on, and the OS-update fire drill on somebody else's schedule.
Next step
If you want a second opinion on the triage, RealityRogue offers a free migration assessment: send us a build or repository and we will tell you which tier you are in and what the plan above looks like for your app. Contact us.