What should a hypothetical iPad app for planning garden layouts, with its grid of beds, plant library and sun-path chart, become on visionOS? The move forces calls nobody made on a flat screen. The plant library probably stays a window. The garden might become a 3D volume sitting on a desk. A full immersive space where you stand inside the finished garden could be wonderful, or a gimmick nobody opens twice. Making those calls well, then building them in Swift, is this job. Among the remote apple vision pro developer jobs open worldwide, this one is full-time, pays $95,000 per year USD, and is built entirely on Apple's stack of SwiftUI, RealityKit, ARKit and Xcode. The rest of this Apple Vision Pro developer job description follows that stack from scene types to shipping.
Every feature starts with where it lives. A window is a SwiftUI scene floating in the room, right for lists, forms and anything people read. A volume holds bounded 3D content people can view from different angles while other apps stay open beside it. An immersive space takes over more of the surroundings, from mixed content placed in the real room to a fully immersive environment.
You will argue for windows more often than you expect, because they are comfortable and respect the person's space. Volumes earn their place when depth adds meaning, such as a product model or a terrain map. Immersive spaces are for moments that justify asking someone to step away from everything else. You also handle the plumbing: opening and dismissing scenes, sharing state across them and making sure people can always find their way back.
On visionOS, SwiftUI gives you glass backgrounds, ornaments that attach toolbars to a window's edge, side-mounted tab views and system-rendered hover effects. Depth modifiers lift elements slightly off the window plane without turning a settings screen into a sculpture. An iPad codebase written in SwiftUI with clean state often carries over well; older UIKit screens may need a rewrite. Part of the job is estimating honestly which screens port in an afternoon and which need real redesign.
3D content arrives through RealityView, the bridge between SwiftUI and RealityKit. Inside it you work with entities and components: models, materials, lighting, collision shapes and input targets. You will write custom components and systems for per-frame behaviour, and attach SwiftUI views to entities when a label has to sit in 3D space.
Reality Composer Pro is where scenes and assets are assembled before they reach code, including materials built with its node-based shader graph, packaged for your app to load. You need not be an artist, but you should open a scene, check polygon counts and texture sizes, and tell the art side what the hardware can carry.
When an experience needs the real room, ARKit supplies data providers for world tracking, plane detection, scene reconstruction and hand tracking. You might snap an object to a detected table, let real furniture hide virtual content or build a custom gesture from hand joints.
Privacy shapes all of it. These providers generally run only while your app has an immersive space open, and the person grants permission through system prompts driven by usage descriptions you write. Those strings must say plainly why the app wants the data. Often the better move is asking whether a feature needs raw tracking at all, since system gestures cover many cases without requesting anything.
Input is mostly look and pinch. Apps never receive where someone is looking; the system highlights the target and delivers the tap. That means generous hit targets, clear hover states and no reliance on precise aiming. Direct touch, reaching out to nearby objects, needs different spacing again. Comfort is a requirement too: content placed too close, too high or moving unexpectedly tires people quickly. Apple's Human Interface Guidelines for visionOS will be a constant reference, and you should feel able to push back on a mock-up that looks striking on a slide but would be uncomfortable after ten minutes.
The visionOS simulator in Xcode covers most daily work: scenes, a few simulated rooms, windows, volumes and basic interaction by mouse and keyboard. It does not reproduce real hand tracking, a reconstructed physical room, the feel of eye targeting or true rendering performance. Those only show up on hardware. A dropped frame is felt rather than seen, so you will use Instruments, including its RealityKit tools, to find heavy draw calls, oversized textures and expensive per-frame work, then confirm fixes on device.
Builds go out through Xcode, TestFlight and App Store Connect. Review looks closely at what this platform makes sensitive: accurate privacy usage strings, sensible behaviour when permissions are denied and an app that matches its listing. Teams also choose between leaving an iPad app available as a compatible app and shipping a native visionOS target, and you will help weigh what each means for review and maintenance.
An Apple silicon Mac is expected, since the visionOS SDK and simulator in Xcode run only on Apple silicon. Having a Vision Pro to test on is a plus. Beyond that, this work from home role needs a reliable connection for code review, design critiques and simulator screen shares, plus the habit of writing clear pull request notes and recorded demos that make sense to colleagues hours ahead of or behind you.
The typical applicant brings three or more years of Swift and iOS development with shipped apps, plus hands-on visionOS work. A computer science degree is common but not mandatory. Core Apple Vision Pro developer skills are SwiftUI, RealityKit, ARKit and Xcode, with familiarity with the Apple Developer Program for signing and distribution.
The overlap with iOS is large: Swift, concurrency, Instruments and App Store habits transfer directly. What is new is spatial: 3D maths, entity systems, scene lifecycles and input designed for a body rather than a thumb. Openings for true beginners are rare. The practical answer to how to become an Apple Vision Pro developer without professional Swift experience is to ship iOS apps first.
Apple's documentation, sample code and session videos are the best starting point. Any paid Apple Vision Pro developer course should target a recent visionOS release, since material dates quickly. Apple does not offer a Vision Pro-specific certification; the Developer Program is a distribution membership, so check its current terms on Apple's site. To start, create a visionOS project and take one small idea through a window, a volume and a short immersive moment. On a resume, a TestFlight link or screen recording beats a list of frameworks. In interviews, expect to defend why you chose a volume over an immersive space.
Teams doing this work include studios building apps for clients, companies adding spatial features to existing iOS apps, and groups in medical training, retail, design visualisation, education and entertainment. Openings come and go with product cycles, so treat any list of roles hiring now as a snapshot. An Apple Vision Pro developer salary at another employer will depend on scope and shipped work; this role pays $95,000 per year. visionOS is still young. Developers with shipped visionOS work are still relatively scarce, which can help early movers, but the device base is smaller than iPhone's and nobody can promise how fast that changes. The safe bet is that spatial skills sit on top of iOS skills, so this experience stays useful wherever you go next.