Integrating MusicKit into your app
At a glance
| Item | Summary |
|---|---|
| Purpose | Enhance your workouts with Apple Music playback. |
| App architecture | A Swift sample with the source-visible chain WorkoutFeedApp → MainView → WorkoutManager → MusicKit APIs. |
| Main patterns | Protocol-oriented abstraction, SwiftUI environment injection, Binding-based state propagation |
| Project style | 14 scanned source file(s) across Swift, organized around ranked entry, type, and file boundaries. |
Project structure
Source bundle/
└── MusicKit2026WWDCSampleApp/
├── WorkoutFeedApp.swift
├── Views/
│ ├── MusicKit Views/
│ │ ├── ScrollingArtworksView.swift
│ │ ├── ActiveWorkoutView.swift
│ │ └── Buttons/
│ │ └── MusicWorkoutButton.swift
│ └── Workout Specific Views/
│ ├── MainWorkoutView.swift
│ ├── WorkoutFeedView.swift
│ ├── MainView.swift
│ └── WorkoutSummaryView.swift
├── Models/
│ └── Workout Specific Models/
│ ├── WorkoutManager.swift
│ ├── Workout.swift
│ └── FitPost.swift
└── ShareSheetView.swift
Structure observations
- Architecturally prominent files are ranked from entry points and role-named declarations; resource-only paths are omitted.
- Primary languages: Swift.
- The verified tree contains 4 project/configuration file(s) and 19 source declaration(s).
Overall architecture
flowchart LR
N1["WorkoutFeedApp"]
N2["MainView"]
N3["WorkoutManager"]
N4["MusicKit APIs"]
N1 --> N2
N2 --> N3
N3 --> N4
Reference code
MusicKit2026WWDCSampleApp/WorkoutFeedApp.swift:12 — architecture anchor
@main
struct WorkoutFeedApp: App {
// ...
}Interpretation
The arrows summarize the source-visible entry, role-named types or folders, and framework direction; when nodes come from structural folders, the sequence is a high-level interpretation rather than proof that every adjacent node calls the next. Ownership is claimed only where the next section cites a stored property or assignment. The diagram is intentionally limited to the dominant path into MusicKit.
Ownership and state
classDiagram
WorkoutFeedApp *-- WorkoutManager : workoutManager
ScrollingArtworksView o-- CollectionOfArtworks : artworks
ScrollingArtworksView o-- Element : selection
ScrollingArtworksView *-- ScrollPosition : scrollPosition
Ownership evidence
MusicKit2026WWDCSampleApp/WorkoutFeedApp.swift:14 — stored dependency or nearest verified ownership anchor
@State private var workoutManager = WorkoutManager()| Owner | Object or state | Relationship | Mutation authority |
|---|---|---|---|
WorkoutFeedApp |
WorkoutManager (workoutManager) |
owns wrapper-managed state | Owning lexical scope |
ScrollingArtworksView |
CollectionOfArtworks (artworks) |
borrows mutable state | The upstream binding owner is authoritative |
ScrollingArtworksView |
Element (selection) |
borrows mutable state | The upstream binding owner is authoritative |
ScrollingArtworksView |
ScrollPosition (scrollPosition) |
owns wrapper-managed state | Owning lexical scope |
Composition arrows indicate a source-visible construction expression or locally owned value state; aggregation means the owner stores or receives a dependency without proving exclusive lifetime ownership.
Class and protocol design
MusicKit2026WWDCSampleApp/Views/MusicKit Views/ScrollingArtworksView.swift:12 — representative type boundary
protocol ArtworkProviding: Identifiable, Equatable, Hashable where ID: Sendable & Equatable {
var artwork: Artwork? { get }
}| Type | Responsibility | Depends on or conforms to |
|---|---|---|
WorkoutFeedApp |
Application entry and top-level composition | App |
ScrollingArtworksView |
User-interface presentation and input forwarding | Concrete collaborators/imported frameworks |
WorkoutManager |
Long-lived feature or framework coordination | @unchecked Sendable |
MainWorkoutView |
User-interface presentation and input forwarding | View |
WorkoutFeedView |
User-interface presentation and input forwarding | View |
ShareSheetView |
User-interface presentation and input forwarding | View |
ActiveWorkoutView |
User-interface presentation and input forwarding | View |
MainView |
User-interface presentation and input forwarding | View |
WorkoutSummaryView |
User-interface presentation and input forwarding | View |
ArtworkProviding |
Defines a capability or collaboration contract | Identifiable, Equatable, Hashable |
The source explicitly defines local protocol relationships: PreviewItem → ArtworkProviding, ApplicationMusicPlayer.Queue.Entry → ArtworkProviding.
Access control
| Symbol | Access | Verified effect | Likely rationale |
|---|---|---|---|
dismiss (MusicKit2026WWDCSampleApp/ShareSheetView.swift:12) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
resolvedSongs (MusicKit2026WWDCSampleApp/ShareSheetView.swift:14) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
isLoading (MusicKit2026WWDCSampleApp/ShareSheetView.swift:15) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
didPost (MusicKit2026WWDCSampleApp/ShareSheetView.swift:16) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
Reference code
MusicKit2026WWDCSampleApp/ShareSheetView.swift:12 — representative boundary
@Environment(\.dismiss) private var dismiss
@State private var resolvedSongs: [Song] = []
@State private var isLoading = true
@State private var didPost = falseSwift declarations without a modifier are internal; explicit private, fileprivate, private(set), public, or open entries above are interpreted by language semantics. Objective-C/C samples instead rely on header and implementation boundaries, which are not equivalent to Swift lexical privacy.
Logic ownership and placement
| Logic | Owning type or file | Placement rationale |
|---|---|---|
| Application entry and top-level composition | WorkoutFeedApp |
The source’s App suffix makes this role explicit. |
| Long-lived feature or framework coordination | WorkoutManager |
The source’s Manager suffix makes this role explicit. |
| User-interface presentation and input forwarding | ActiveWorkoutView, MainView, MainWorkoutView, ScrollingArtworksView |
The source’s View suffix makes this role explicit. |
Design patterns
| Pattern | Source evidence | Purpose or tradeoff |
|---|---|---|
| Protocol-oriented abstraction | MusicKit2026WWDCSampleApp/Views/MusicKit Views/ScrollingArtworksView.swift:79 |
A local protocol and concrete conformance create an explicit capability boundary. |
| SwiftUI environment injection | MusicKit2026WWDCSampleApp/Views/Workout Specific Views/MainView.swift:11 |
The environment supplies state or a capability without threading it through every initializer. |
| Binding-based state propagation | MusicKit2026WWDCSampleApp/ShareSheetView.swift:18 |
A binding exposes controlled read/write access while the upstream owner remains authoritative. |
Naming conventions
- Types: App: WorkoutFeedApp; Manager: WorkoutManager; View: ActiveWorkoutView, MainView, MainWorkoutView, ScrollingArtworksView, ShareSheetView.
- Protocols:
ArtworkProviding. - Methods:
artwork,post,formatDuration. - Files:
MusicKit2026WWDCSampleApp/WorkoutFeedApp.swift,MusicKit2026WWDCSampleApp/Views/MusicKit Views/ScrollingArtworksView.swift,MusicKit2026WWDCSampleApp/Models/Workout Specific Models/WorkoutManager.swift,MusicKit2026WWDCSampleApp/Views/Workout Specific Views/MainWorkoutView.swift,MusicKit2026WWDCSampleApp/Views/Workout Specific Views/WorkoutFeedView.swift,MusicKit2026WWDCSampleApp/ShareSheetView.swift.
Architecture takeaways
WorkoutFeedAppis the main source-visible entry or composition anchor for this sample.- Framework work reaches SwiftUI, MusicKit through a deliberately small high-level chain; the detailed API graph remains inside the cited implementation files.
- Stored-property evidence identifies lifecycle collaboration; it does not by itself prove exclusive object ownership.
- Access-control conclusions separate verified language visibility from the likely design rationale.
- Local protocol relationships provide an explicit substitution boundary.
Source map
| Source file | Relevant symbols |
|---|---|
MusicKit2026WWDCSampleApp/WorkoutFeedApp.swift |
WorkoutFeedApp |
MusicKit2026WWDCSampleApp/Views/MusicKit Views/ScrollingArtworksView.swift |
ArtworkProviding, ScrollingArtworksView, PreviewItem |
MusicKit2026WWDCSampleApp/Models/Workout Specific Models/WorkoutManager.swift |
WorkoutManager |
MusicKit2026WWDCSampleApp/Views/Workout Specific Views/MainWorkoutView.swift |
MainWorkoutView, WorkoutContent |
MusicKit2026WWDCSampleApp/Views/Workout Specific Views/WorkoutFeedView.swift |
WorkoutFeedView, PostCard |
MusicKit2026WWDCSampleApp/ShareSheetView.swift |
ShareSheetView |
MusicKit2026WWDCSampleApp/Views/MusicKit Views/ActiveWorkoutView.swift |
ActiveWorkoutView |
MusicKit2026WWDCSampleApp/Views/Workout Specific Views/MainView.swift |
MainView |
MusicKit2026WWDCSampleApp/Views/Workout Specific Views/WorkoutSummaryView.swift |
WorkoutSummaryView |
MusicKit2026WWDCSampleApp/Models/Workout Specific Models/Workout.swift |
Workout, WorkoutType |