How We Build On-Device AI Features in iOS Apps Using Apple Intelligence
No cloud bill. No API keys. No data leaving the device.
A practical engineering guide from our mobile team
Introduction
Your users expect intelligent features – smart suggestions, instant summaries, contextual help. Until now, delivering that meant API costs, cloud dependencies, and your users’ data traveling to third-party servers.
Apple’s Foundation Models framework changes that equation entirely. As a software company that ships iOS apps professionally, we’ve integrated Apple Intelligence into production apps and want to share exactly how we approach it – the architecture, the code patterns, the edge cases, and what it means for your product roadmap.
If you’re a CTO, Product Manager, or founder evaluating on-device AI for your next iOS release, this article is written for you.
Why On-Device AI Is a Game-Changer for iOS Products
Apple Intelligence and the Foundation Models framework give eligible iOS apps access to a powerful on-device language model through a native Swift API. Here’s what that means for your product:
Privacy-First by Architecture
Prompts and responses stay on the device. No third-party LLM vendor sees your users' data. This is a meaningful competitive differentiator in healthcare, fintech, legal, and any privacy-sensitive vertical.
No Per-Token Cloud Billing
On-device inference eliminates the ongoing LLM API cost that typically scales with your user base. Budget predictability improves significantly for AI features.
Offline-Capable Intelligence
When the model is loaded locally, your AI features work even without a network connection - critical for field apps, enterprise tools, and user trust.
Native Swift Concurrency
Apple's API is designed for async/await and SwiftUI from the ground up. No bridging layers, no third-party SDKs, no compatibility headaches.
Understanding the Technology: Apple Intelligence vs Foundation Models
These two terms are often used interchangeably, but they serve different purposes:
Apple Intelligence is Apple’s umbrella brand for all system-level AI features – Writing Tools, Image Playground, and more. It’s what your users see and interact with system-wide.
Foundation Models is the developer framework that gives your app programmatic access to Apple’s on-device language model. This is what we build with – the API surface that lets you embed generation, comprehension, and structured AI output directly in your iOS app.
The two core APIs your iOS team works with are:
- SystemLanguageModel – Identifies which model to use and confirms availability on the current device and OS version.
- LanguageModelSession – A conversation-style session that holds instructions (your system prompt), prompt history, and methods to generate or stream responses.
Device & OS Requirements: What We Tell Every Client Upfront
Setting accurate expectations early prevents the biggest mistake teams make with Apple Intelligence: demoing on a Pro device and shipping to users who don’t have one.
Operating System
Your project must target the iOS SDK version that includes the Foundation Models framework (iOS 26 and above at the time of writing). We set deployment targets deliberately and document this clearly in your app’s requirements.
Device Eligibility – The Critical Variable
Apple Intelligence is hardware-gated. Not all iPhones qualify, and eligibility evolves with each OS release. As a general pattern at launch:
- Supported: Newer Pro-tier models and current-generation devices Apple designates as Apple Intelligence-capable (e.g. iPhone 15 Pro / Pro Max, iPhone 16 family).
- Not supported: Earlier non-Pro models such as iPhone 15 and iPhone 15 Plus, which use chip generations that don’t meet eligibility criteria.
This is not an edge case – it’s a core product decision. We help clients think through their user base demographics and design UX that degrades gracefully for users on unsupported hardware.
User Settings
Even on a supported device, a user may not have Apple Intelligence enabled in Settings. Your app must handle three distinct unavailability states, each with its own user-facing message:
- Device not eligible – hardware limitation, no action available.
- Apple Intelligence not enabled – guide the user to Settings with a clear, friendly prompt.
- Model not ready – model is downloading or warming up; show a loading state.
Our Architecture Approach
A clean, layered architecture keeps AI logic testable, maintainable, and easy to extend. Here’s the pattern we use and recommend for every client:
| Layer | Component | Responsibility |
|---|---|---|
| Presentation | SwiftUI Views | Input fields, loading UI, accessibility |
| State Management | ViewModel (@Observable) | Message history, send/clear, error state |
| AI Service | AppleIntelligenceService | Availability check, session, prompts |
| Testability | Protocol / Mock | CI-friendly unit tests without device |
This MVVM-style separation means your AI feature is independently testable without a physical device in CI, and the service layer can be swapped or extended (for example, to add a cloud LLM fallback for unsupported devices) without touching UI code.
Step-by-Step: How We Integrate Apple Intelligence
Step 1 – Always Check Availability First
We never show AI UI without confirming the model is available. This check runs before any session is created:
import FoundationModels
private let model = SystemLanguageModel.default
switch model.availability {
case .available:
// Show your AI feature UI
case .unavailable(.deviceNotEligible):
// Inform user — no action possible
case .unavailable(.appleIntelligenceNotEnabled):
// Guide user to Settings > Apple Intelligence
case .unavailable(.modelNotReady):
// Show 'warming up' / loading indicator
default:
// Handle gracefully
}
Product tip: This is where your UX earns user trust. A clear, empathetic message – ‘Apple Intelligence isn’t enabled on your device yet’ – is far better than a silent failure or a broken feature.
Step 2 – Create a Session with a System Prompt
A LanguageModelSession is initialized with instructions — your system prompt — that define tone, scope, and safety posture for the feature:
let instructions = """
You are a helpful assistant embedded in our app.
Be concise, accurate, and professional.
Prefer bullet points for lists. Avoid jargon.
"""
let session = LanguageModelSession(instructions: instructions)
We craft system prompts collaboratively with clients — they are the single biggest lever for output quality and brand consistency. A well-written system prompt is often worth more than any code optimization.
Step 3 – Send Prompts and Receive Responses
Apple’s API uses Prompt for user input and returns a typed response. Here’s the core interaction pattern:
let prompt = Prompt("User question:\n\(userInput)")
let response = try await session.respond(to: prompt)
let answerText: String = response.content
Step 4 – Production Service Class
In production apps, we wrap this in a service object that handles availability guards, lazy session creation, input validation, and domain errors your UI can map to user-friendly messages:
import Foundation
import FoundationModels
enum AIError: LocalizedError {
case modelUnavailable
case emptyInput
var errorDescription: String? {
switch self {
case .modelUnavailable: return "Apple Intelligence isn't available yet."
case .emptyInput: return "Please enter a question."
}
}
}
@MainActor
final class AppleIntelligenceService {
private let systemModel = SystemLanguageModel.default
private var session: LanguageModelSession?
private func ensureSession() -> LanguageModelSession {
if let session { return session }
let s = LanguageModelSession(instructions: "Be concise and professional.")
session = s; return s
}
func respond(to userText: String) async throws -> String {
guard case .available = systemModel.availability else {
throw AIError.modelUnavailable
}
let trimmed = userText.trimmingCharacters(in: .whitespacesAndNewlines)
guard !trimmed.isEmpty else { throw AIError.emptyInput }
let prompt = Prompt("User question:\n\(trimmed)")
let output = try await ensureSession().respond(to: prompt)
return output.content.trimmingCharacters(in: .whitespacesAndNewlines)
}
func reset() { session = nil }
}
SwiftUI Integration: Chat UI Pattern
Here’s the ViewModel and View pattern we use for a clean, production-ready chat UI that separates concerns and handles loading, errors, and accessibility:
// ViewModel
@Observable @MainActor
final class ChatViewModel {
struct Message: Identifiable {
enum Role { case user, assistant, system }
let id = UUID(); let role: Role; let text: String
}
private let service = AppleIntelligenceService()
var messages: [Message] = []
var input = ""
var isSending = false
func send() async {
let text = input.trimmingCharacters(in: .whitespacesAndNewlines)
guard !text.isEmpty else { return }
isSending = true; input = ""
messages.append(.init(role: .user, text: text))
do {
let reply = try await service.respond(to: text)
messages.append(.init(role: .assistant, text: reply))
} catch {
messages.append(.init(role: .system, text: error.localizedDescription))
}
isSending = false
}
}
struct ChatView: View {
@State private var model = ChatViewModel()
var body: some View {
NavigationStack {
VStack {
ScrollView {
ForEach(model.messages) { msg in
Text(msg.text)
.frame(maxWidth: .infinity, alignment: .leading)
.padding(8)
}
}
HStack {
TextField("Ask anything...", text: $model.input, axis: .vertical)
.textFieldStyle(.roundedBorder)
Button("Send") { Task { await model.send() } }
.disabled(model.input.isEmpty || model.isSending)
}
.padding()
}
.navigationTitle("AI Assistant")
}
}
}
Streaming Responses: The "Typing" Experience
For demos and user-facing assistants, a streaming response that renders token-by-token creates a dramatically more engaging experience. Apple provides streamResponse(to:) for exactly this.
When we implement streaming, we also handle:
- Task cancellation – so the user can interrupt a long response.
- Mid-stream errors – network interruptions or model-level failures.
- Main actor isolation – ensuring all UI updates stay on the main thread.
Testing Strategy: How We Ensure Quality in CI
Unit Testing Without a Device
We introduce a protocol (AppleIntelligenceServing) so your app logic can be tested with a mock AI service in CI – no physical iPhone required.
Tests cover:
- Message appending rules (user → assistant → system).
- Error mapping (unavailable model, empty input).
- Clear and reset behavior.
UI Testing
We use accessibility identifiers on all interactive elements.
For AI features, we test:
- Correct screen layout and navigation flows.
- Text field and button states (enabled/disabled during send).
- The presence of a response area – not the exact model output, since LLM outputs are non-deterministic.
Simulator vs Physical Device
Important: The iOS Simulator cannot reliably test on-device model availability. We always validate Foundation Models features on a supported physical device with Apple Intelligence enabled. Marketing demos must also be recorded on device – not Simulator.
Limitations We Disclose to Every Client
We believe transparency builds better client relationships. Here’s what you should know before committing to Apple Intelligence as a feature:
- Device eligibility excludes a significant portion of the iPhone install base. We help you design UX for unsupported hardware – not ignore it.
- Regional availability for Apple Intelligence can vary. International product launches require a QA matrix across regions and OS versions.
- Context window limits mean very long conversations require session resets or summarization strategies – we design for this from the start.
- LLM outputs are non-deterministic by nature. We build test strategies that account for this rather than fighting it.
- The feature requires the user to opt in to Apple Intelligence in Settings. Your onboarding flow must guide users there gracefully.
Privacy & Compliance: The Story for Your Stakeholders
On-device AI gives your product a compelling privacy story, but it needs to be told accurately:
- On-device processing means user prompts do not travel to a third-party LLM vendor – this is the correct, accurate statement.
- You still need to disclose what your app logs, analyzes, or transmits elsewhere – analytics, crash tools, support SDKs.
- If your app combines on-device AI with cloud services in other features, keep those stories clearly separated in your privacy policy and marketing copy.
We help clients draft accurate, legally-reviewable privacy language that reflects what Foundation Models actually does – not an oversimplification.
What a Successful Integration Looks Like
Shipping Apple Intelligence features isn’t only a code problem. Our definition of a successful delivery includes:
- Graceful degradation for unsupported devices with honest, helpful messaging.
- Settings guidance UX when Apple Intelligence is off – users guided, not abandoned.
- Thoughtful loading and error states for latency and edge cases.
- A testable service layer that passes CI without physical hardware.
- Streaming responses for demo-worthy, engaging user experiences.
- A system prompt crafted to match your product’s voice and safety requirements.
- Documentation and handover so your team can maintain and extend the feature.
Work With Us
If you’re planning an iOS roadmap that includes on-device AI, we design, architect, and ship Foundation Models features with production-grade quality – not demos that fall apart in the field.
