At WWDC 2017 Apple shipped two frameworks on the same day, and we wrote about both. ARKit brought a documented augmented reality foundation to iOS. Core ML made on-device machine learning a normal thing an app could do. We described them as a pair, and for nine years they have been diverging.
Core ML's underlying bet was correct so completely that the framework has been superseded by successors built on the same premise. ARKit's bet was correct about the technology and wrong about where it would be used. Both outcomes are useful, and the difference between them is a reasonable guide to evaluating any new platform framework.
Core ML: the bet was on-device inference, and it won outright
The argument we made in 2017 was that processing happening locally on the device - rather than on a server - would matter for speed and for privacy. That was the entire premise of Core ML, and every subsequent development has reinforced it.
The framework itself has now been overtaken by a more specialised stack. Apple's current on-device machine learning offering, as of WWDC 2026, separates into distinct layers: the Foundation Models framework provides a native Swift API onto the on-device model that powers Apple Intelligence, and Core AI - announced at WWDC 2026 and built directly into the OS for Apple Silicon - is the route for loading and running your own models on device. MLX handles training and experimentation. Core ML remains for traditional machine learning conversion workflows.
The framing Apple now uses for Core AI is worth noting precisely because it is the 2017 argument restated at a larger scale: models run entirely on device, with no server dependency and no token costs. In 2017 that meant image classification and text analysis. In 2026 it means running generative models locally.
For product decisions this is the single most consequential change. Inference with no per-token cost and no requirement to transmit user data changes what is commercially viable, particularly for products carrying sensitive information. Features that were unaffordable as a per-request cloud call, or unacceptable as a data transfer, are neither when the model runs on the handset.
ARKit: right about the capability, wrong about the venue
ARKit worked, and it still works. The technical claims held up - plane detection, scale, anchoring, lighting estimation. Our 2017 assessment that this made high-quality AR feasible for ordinary developers was accurate.
What did not happen was the broad adoption we implied. We wrote that we anticipated steady adoption of AR in general consumer apps, and that was too optimistic by a wide margin. AR did succeed, but in a narrow band of commercial applications - product visualisation and virtual try-on in retail - rather than as a general capability that most apps eventually acquire.
The framework landscape reflects where Apple's attention went. RealityKit is now the primary path for spatial content, and it has continued to advance substantially: MaterialX support, rendering of 3D Gaussian splats for photorealistic scanned objects, and in visionOS 27 additions including physical space lighting, projective textures and cloth simulation. ARKit persists as the tracking and scene-understanding layer beneath it.
The reality check is the platform size. visionOS has on the order of a few thousand native applications and an installed base in the hundreds of thousands rather than the millions. That is a serious, well-supported platform with a genuinely small addressable market, which is a specific commercial situation rather than a failure - it is a good place for a funded enterprise use case and a poor place for a consumer product that needs scale.
The commercial side of the AR story, and which use cases repaid the investment, is scored separately in which AR use cases actually made money.
What the divergence teaches about new frameworks
Both frameworks worked. The difference was in what each depended on.
Core ML required nothing except a device people already owned. Its adoption curve was the adoption curve of iPhones, which was already resolved. ARKit's most compelling applications required hardware that did not exist yet, so its adoption depended on a market that had to be created.
That is the test worth applying to any new framework at any WWDC. Not whether the technology is impressive, but whether the value it unlocks depends on something the user already has. A framework that makes existing hardware more capable can be adopted immediately. A framework that anticipates future hardware is a bet on a market, and it should be sized as one.
Applied practically, it changes how we scope this kind of work. We have rescued 15+ platforms in the past 3 years, and the ones that got into trouble over a platform bet were rarely wrong about the technology - they had built a product whose economics required an addressable market that did not arrive. Building the capability behind an interface you can retarget, rather than as the organising principle of the product, is what makes that survivable.
For the broader version of this scorecard across four 2017 predictions, see how our 2017 predictions scored. If you are weighing whether to build on a new Apple framework now, talk to us - or see our iOS development work.