iOS 27, iPadOS 27 and macOS 27: what Core AI changes for apps

On 31 August 2026, iOS 27, iPadOS 27 and macOS 27 Golden Gate are still upcoming releases. Apple says the free updates are coming this fall, while parts of the new intelligence stack remain in beta or are scheduled for later. That timing matters: the architecture is public enough to analyse, but features, availability and performance still need to be verified against the final software.

The most visible story is Siri AI and the next generation of Apple Intelligence. The more consequential developer story may be Core AI: a new framework and toolchain for preparing, deploying and running an app’s own neural-network models on Apple silicon.

Core AI is not a switch that makes an application intelligent. It is an execution layer. A team still has to choose the task, model, data contract, device range, fallback, evaluation method and interface. What Apple is changing is the path between a model built in a machine-learning environment and a private, responsive feature inside a Swift app.

What is actually new across the three operating systems

Apple’s WWDC26 overview places Siri AI, expanded Apple Intelligence, child-safety controls and system performance work across the 27 generation. The details vary by device.

On iOS 27, Apple is previewing a conversational Siri AI with personal-context search, actions across apps, broader online knowledge and a dedicated conversation app. Visual Intelligence moves into the Camera, while Photos gains Spatial Reframing, Extend and a more capable Clean Up tool. Safari can group tabs and watch pages for changes, Passwords can help repair weak or compromised credentials, and Shortcuts can be assembled from a description.

iPadOS 27 carries much of the same intelligence to a larger workspace. A person can ask about onscreen material from a screenshot, tap an object or circle it with Apple Pencil, continue Siri conversations across devices and use writing assistance in more contexts. Apple also highlights faster file transfer to external drives, smoother network transitions and broader system refinements.

On macOS 27 Golden Gate, Siri AI can be reached from Spotlight or its own app, reason over a screenshot or PDF and take actions in supported apps. Apple is also refining Liquid Glass for readability and consistency, improving AirDrop and network-file performance, adding more relevant Mail search and extending support for ultrawide displays.

This is a broad platform update, not a Core AI product list. Apple’s own apps use a mixture of system models, Private Cloud Compute, frameworks such as Foundation Models and App Intents, and product-specific logic. A third-party app does not gain those behaviours merely because it runs on OS 27.

The Romania and EU availability boundary

For a Romanian audience, the launch conditions are as important as the feature list. Apple’s announced Apple Intelligence languages do not include Romanian. A supported device set to another supported language may receive available features, but that is not equivalent to a Romanian-language product experience.

Apple has also said that Siri AI will not ship initially on iOS 27 or iPadOS 27 in the European Union. The company says it will be available to EU users on macOS 27 and visionOS 27 when the other language and device requirements are met. As of 31 August, Apple gives no timeline for the iPhone and iPad EU release.

That limitation concerns Siri AI, not every form of local machine learning. A developer can use a custom model whose vocabulary and behaviour include Romanian, provided the model, framework, device and application meet the deployment requirements. This is one reason to keep Siri AI, Apple Intelligence, Foundation Models and Core AI conceptually separate.

Core AI is not Siri AI

Apple describes Core AI as the on-device inference framework that powers Apple Intelligence and is now available to developers. Its role is to load and run custom neural models across the CPU, GPU and Neural Engine, with a memory-safe Swift API and a supporting Python, Xcode and Instruments toolchain.

The surrounding technologies operate at different levels:

• Apple Intelligence is the user-facing intelligence system integrated into Apple products.
• Foundation Models is the higher-level Swift framework for language-model sessions, structured generation and tool calling. It can use Apple’s system models and, in OS 27, models supplied through other providers.
• Core AI is the deployment path for neural networks an app team chooses, trains or downloads, including language, vision, audio and multimodal models.
• Core ML remains supported. Apple now points new neural architectures and inference techniques toward Core AI, while Core ML continues to cover existing deployments and model types such as decision trees and tabular workflows.
• MLX is the lower-level research and numerical-computing environment for experimentation, training, fine-tuning and larger distributed work on Apple silicon.

The practical rule is to start at the highest level that satisfies the product. If Apple’s on-device language model can perform a text task on the required devices and languages, Foundation Models may be the shortest route. If the app needs its own segmentation model, specialist audio model, Romanian-capable language model or fixed model version, Core AI becomes relevant. Existing Core ML features do not need to be rewritten simply because a newer framework exists.

How Core AI works from model to app

The Core AI introduction at WWDC26 shows a complete deployment lifecycle rather than one runtime call.

1. Define the task and choose the model

Development starts outside Xcode. The team defines the inputs, outputs, accuracy threshold, response time, supported devices and failure behaviour, then trains a model or selects an open-source one whose licence and capabilities fit. Apple’s Core AI models repository provides export recipes and Swift runtime libraries for several popular architectures, but a downloadable model is only a starting point. It still needs product-specific evaluation.

2. Optimize and convert it

Core AI fits into a PyTorch-based workflow. Core AI Optimization can apply techniques such as quantization and palettization to reduce size and improve execution characteristics. Core AI PyTorch Extensions then export one or more inference functions into the .aimodel format.

Conversion is not proof of equivalence. Apple’s own demonstration runs the source PyTorch model and the converted model on the same representative inputs, then checks that the numeric difference stays within a threshold appropriate to the feature. Compression, conversion and a new execution backend can each change results.

3. Inspect and distribute the model asset

Xcode can display an .aimodel file’s size, target platforms, functions, tensor shapes and metadata. The app can bundle that asset, include it in a Swift package or download it when the feature is requested.

That distribution choice affects every user. Bundling a 600 MB model makes the base app and its updates heavier even for people who never use the feature. An on-demand download keeps the initial app smaller but requires explicit states for consent, progress, interruption, storage shortage, verification, versioning and deletion.

4. Specialize the source model for the device

An .aimodel is a portable source representation. Before execution, Core AI specializes it for the particular device and operating-system environment, creating executable artifacts and caching them. Subsequent loads can use that cache, but the first specialization of a large model may be noticeably slow.

Core AI exposes the model cache so an app can check readiness, request preparation at an appropriate moment and remove stale entries. The coreai-build tool can perform part of the compilation ahead of time for selected architectures. The result still needs device specialization, but Apple says substantially less work remains at first use.

This is a product-state problem as much as a compiler problem. “Preparing the AI feature” needs honest progress, cancellation and recovery. Hiding a long first load behind a frozen button is not a deployment strategy.

5. Run inference through Swift

At the direct framework level, an app loads an AIModel, selects an inference function, prepares typed multidimensional arrays and reads the outputs. Core AI can choose an execution engine across the CPU, GPU and Neural Engine according to how the model was exported. Lower-level controls cover inference memory, zero-copy data paths, reusable state and tight compute loops.

Language models can also be wrapped in a Core AI language-model adapter and used through the familiar Foundation Models LanguageModelSession. That provides higher-level features such as streaming and typed output while the app’s selected model runs underneath. Core AI and Foundation Models therefore complement each other; they are not competing names for the same API.

6. Profile, evaluate and repeat

The toolchain includes a standalone Core AI Debugger for inspecting graphs and intermediate tensor values, an Xcode debug gauge for live activity, and a Core AI Instruments template for load, specialization and inference timing. These tools explain where time and memory go. They do not decide whether a result is correct or useful.

The application still needs an evaluation set that represents ordinary, ambiguous, multilingual, incomplete and hostile inputs. Romanian and English must be measured separately. Cold load, warm load, peak memory, storage, energy use and thermal behaviour need tests on real target devices, not only on the developer’s Mac.

What Core AI changes compared with Core ML

Core AI is more than a renamed Core ML file. It introduces the .aimodel format, modern Swift ownership and memory-safety features, explicit specialization and cache management, stateful execution, custom Metal operations, new debugging tools and workflows aimed at current transformer, diffusion and multimodal architectures.

That does not make every Core ML project obsolete. A stable image classifier, Create ML model or tabular predictor may have no business reason to move. Nor should a team assume that a PyTorch checkpoint converts automatically: unsupported operations, dynamic shapes, preprocessing, tokenization, output decoding and memory pressure can all require engineering work. Apple’s direction is clear, but migration remains model-specific.

The real opportunities for applications

Core AI can make sense when local execution is part of the product requirement rather than a slogan. Examples include identifying objects in a live camera flow, segmenting images without uploading them, transcribing or classifying sensitive audio, extracting structured fields from documents offline, and running a specialist language model with a controlled version and vocabulary.

The same Swift integration can support different model sizes on different device classes. A compact model may serve an iPhone interaction, while a Mac with more memory can process a batch or use a larger variant. This can create a coherent product across iPhone, iPad and Mac without pretending that all three devices have identical capacity.

For Romanian products, a custom model can close a language gap only if its training data and evaluation support that claim. A multilingual model that lists Romanian is not automatically good at Romanian terminology, diacritics, regional context or structured instructions. Those are test requirements, not marketing assumptions.

On-device does not mean effortless or free

Core AI removes a server round trip and per-token inference invoice for work that stays on the device. It does not remove cost.

The model consumes download bandwidth, storage, memory, energy and engineering time. Teams must maintain model licences, versions, compatibility, rollback paths and support. Larger models can delay first use, compete with the rest of the app for memory and perform differently under heat or low-power conditions.

Privacy also depends on the whole data path. Local inference can keep a photo or document away from an AI server, but analytics, crash reports, backups, synchronisation and other SDKs can still transmit source data or derived information. “Runs with Core AI” is not evidence that the entire feature remains private.

Output remains probabilistic. Prices, permissions, identity, eligibility, inventory and irreversible actions should stay under deterministic application rules. A model can propose a category or draft a summary; validated code and an authorised person should decide whether a record is changed, a payment is made or a message is sent.

Finally, OS 27 and Xcode 27 are still prerelease at the date of this article. Apple explicitly notes that capabilities can change and that software built against beta documentation must be retested with final releases.

A practical decision before the fall release

An app team considering Core AI should answer these questions before committing to a platform rewrite:

1. What narrowly defined task becomes better because the model is local?
2. Which devices, languages and offline states must the feature support?
3. Can Foundation Models or an existing Core ML model already meet the requirement?
4. How large is the model after optimization, and when will it be downloaded and specialized?
5. What are the measured cold and warm latency, memory, storage, energy and quality on the oldest supported device?
6. What remains deterministic, and what happens when the model is unavailable, slow or wrong?
7. How will model versions, licences, privacy disclosures, evaluation sets and rollback be maintained?

The strongest reason to adopt Core AI is not that it is new. It is that Apple is providing a serious deployment layer for custom neural models: one toolchain from PyTorch conversion to Swift inference, specialization, caching and device-level profiling.

For the right application, that can deliver private, offline and responsive intelligence without operating an inference server. For the wrong application, it can add hundreds of megabytes, a difficult first run and a probabilistic dependency where ordinary code would have been clearer.

The work before launch is therefore not to “add Core AI.” It is to prove that one specific model, on one documented device range, improves one valuable task while preserving a useful fallback.

If you are evaluating an on-device AI feature for an iPhone, iPad or Mac product, tell us what task, data and device range you need to support. We can help turn the announcement into a measured prototype and a realistic deployment decision.