Apple Watch Workout App Built with Cursor & Xcode
A complete walkthrough of building an Apple Watch workout app with Cursor and Xcode. SwiftUI, HealthKit integration, and the unique challenges of watchOS development with AI.
Project Setup
Building for Apple Watch with AI tools is a unique challenge. The watchOS platform has strict constraints — tiny screen, limited memory, battery sensitivity — and SwiftUI on watchOS has its own set of supported components and behaviors.
Terry and Claire's approach: use Cursor for code generation and Xcode for building, running, and testing on the Apple Watch simulator. The two tools complement each other — Cursor handles the code writing speed, Xcode handles the Apple-specific compilation and device management.
The project: a workout tracking app that records exercise sessions, monitors heart rate via HealthKit, and displays real-time workout metrics on the Apple Watch face.
Building the Watch UI
Building SwiftUI interfaces for the tiny watch screen.
Design for the watch constraints
Apple Watch screens range from 40mm to 49mm. Every pixel matters. Terry started by telling Cursor: 'Build a SwiftUI workout tracking view for Apple Watch. Maximum 3 data points visible at once. Use large, glanceable typography. Include a start/stop button.'
Generate SwiftUI components
Cursor generated watchOS-compatible SwiftUI views. Key prompt detail: 'Use only watchOS-supported SwiftUI components — no NavigationView (use NavigationStack), no UIKit wrappers.' This prevents the common AI mistake of generating iOS code that doesn't compile on watchOS.
Test on Watch Simulator
Build in Xcode, test on the Apple Watch simulator. The simulator accurately reproduces the watch experience including Digital Crown input and complications. Fix any layout issues that only appear on the small screen.
HealthKit Integration
Request Permissions Correctly
HealthKit requires explicit permission for each data type. Cursor generated the permission request flow, but Terry had to specify: 'Request heart rate and active energy permissions separately, with descriptive usage strings that Apple will approve during App Review.'
Real-Time Heart Rate Monitoring
The app uses HKWorkoutSession with HKLiveWorkoutBuilder for real-time heart rate data during workouts. Cursor generated the boilerplate, but the session management logic required manual refinement for edge cases (bluetooth disconnection, background mode).
Data Persistence
Workout data is saved to HealthKit using HKWorkoutBuilder. The save operation must complete before the app terminates. Cursor handled the basic save logic; error handling for partial saves needed manual attention.
Cursor + Xcode Workflow
The workflow that emerged:
Cursor handles: SwiftUI view generation, data model creation, business logic, and HealthKit integration code. Its speed advantage is significant — generating a complete SwiftUI view takes seconds instead of minutes.
Xcode handles: project configuration, provisioning profiles, simulator management, and actual builds. There's no substitute for Xcode when targeting Apple platforms.
The handoff pattern: write code in Cursor → save → switch to Xcode → build → test on simulator → note issues → switch back to Cursor → fix issues. The context switch is the main friction point, but the speed gain from Cursor-generated code more than compensates.
Key lesson: always tell Cursor you're building for watchOS specifically. Without this context, it generates iOS code that looks correct but uses unsupported APIs on watchOS. The more specific your platform context, the fewer Xcode build errors you'll encounter.
