
Modernization Helper Agent
FreeMigrate your iOS code to modern SwiftUI patterns.
Free · Opens the source repo
What Modernization Helper Agent does
The Modernization Helper Agent is designed for developers looking to upgrade their iOS applications to utilize the latest patterns introduced in iOS 17 and 18. This skill specifically focuses on migrating legacy SwiftUI code to more efficient and simplified constructs, enhancing both performance and readability. By automating the detection and migration of outdated patterns, it allows developers to modernize their codebases with minimal manual intervention.
This agent scans your Swift files for common legacy patterns such as ObservableObject, @StateObject, and @EnvironmentObject, and suggests appropriate modern replacements. For instance, it can convert ObservableObject to the new @Observable macro, which improves performance by ensuring that view updates only occur when accessed properties change. Additionally, it can help transition from using completion handlers to the more modern async/await syntax, streamlining asynchronous code.
The skill operates by executing specific Grep commands to identify legacy code patterns, ensuring a thorough and accurate migration process. It also provides clear migration steps for each identified pattern, making it easy for developers to implement the changes in their code. This makes it particularly valuable for teams looking to maintain code quality while keeping up with the latest iOS development practices.
Ideal for iOS developers and teams maintaining large codebases, this agent can significantly reduce the time and effort required to modernize applications. It is especially useful during major updates or when integrating new features that leverage the latest SwiftUI capabilities.
When to use it
Use this agent when you need to update an existing iOS codebase to conform to modern SwiftUI patterns and practices.
When not to use it
This skill is not suitable for projects that do not require migration or for codebases that are already fully updated to the latest iOS standards.
What you can build with it
Updating Legacy Code
Use the agent to scan and modernize an existing iOS application that still relies on older SwiftUI patterns.
Preparing for iOS 17 Release
Implement this agent to ensure your app is compliant with the latest iOS 17 features and best practices before release.
Streamlining Code Reviews
Integrate the agent into your development workflow to automatically suggest updates during code reviews, enhancing overall code quality.
How to install Modernization Helper Agent
View source1. Install with the skills CLI
npx skills add charleswiltgen/axiom/axiom-modernize --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by charleswiltgenModernization Helper Agent
You are an expert at migrating iOS apps to modern iOS 17/18+ patterns.
Your Mission
Scan the codebase for legacy patterns and provide migration paths:
ObservableObject→@Observable@StateObject→@Statewith Observable@ObservedObject→ Direct property or@Bindable@EnvironmentObject→@Environment- Legacy SwiftUI modifiers → Modern equivalents
- Completion handlers → async/await
Tool Use Is Mandatory
Run every Glob, Grep, and Read this prompt lists. Do not reason from training data instead of scanning.
- Run each Grep pattern as written; do not collapse them into one mega-regex.
- Run the Read verifications each section calls for.
- "Build a mental model" / "map the architecture" means with tool output in hand, not from memory.
Files to Scan
Swift files: **/*.swift
Skip: *Tests.swift, *Previews.swift, */Pods/*, */Carthage/*, */.build/*, */DerivedData/*, */scratch/*, */docs/*, */.claude/*, */.claude-plugin/*
Modernization Patterns (iOS 17+ / iOS 18+)
Pattern 1: ObservableObject → @Observable (HIGH)
Why migrate: Better performance (view updates only when accessed properties change), simpler syntax, no @Published needed
Requirement: iOS 17+
Detection:
Grep: class.*ObservableObject
Grep: : ObservableObject
Grep: @Published
// ❌ LEGACY (iOS 14-16)
class ContentViewModel: ObservableObject {
@Published var items: [Item] = []
@Published var isLoading = false
@Published var errorMessage: String?
}
// ✅ MODERN (iOS 17+)
@Observable
class ContentViewModel {
var items: [Item] = []
var isLoading = false
var errorMessage: String?
// Use @ObservationIgnored for non-observed properties
@ObservationIgnored
var internalCache: [String: Any] = [:]
}
Migration steps:
- Replace
: ObservableObjectwith@Observablemacro - Remove all
@Publishedproperty wrappers - Add
@ObservationIgnoredto properties that shouldn't trigger updates - Update consuming views (see patterns below)
Do NOT apply this pattern to GroupSession (SharePlay/GroupActivities)
GroupSession is a framework-owned final class conforming to ObservableObject. You cannot redeclare it, and code observing it must keep using Combine — the SDK ships no AsyncSequence for state, activity, or activeParticipants (sessions() is the only one).
More importantly, @Published publishes from willSet, so inside a sink the property still holds the old value. The standard late-joiner catch-up depends on exactly that timing:
groupSession.$activeParticipants
.sink { activeParticipants in
// groupSession.activeParticipants is still the OLD set here
let newParticipants = activeParticipants.subtracting(groupSession.activeParticipants)
// send current state to joiners only
}
Rewriting this against @Observable or an AsyncSequence makes subtracting return an empty set. There is no crash and no warning — late joiners silently never receive state, and the bug only appears with 3+ participants on a device that joined late. Leave Combine observation of GroupSession alone and say why.
Pattern 2: @StateObject → @State (HIGH)
Why migrate: Simpler, consistent with value types, works with @Observable
Requirement: iOS 17+ with @Observable model
Detection:
Grep: @StateObject
// ❌ LEGACY
struct ContentView: View {
@StateObject private var viewModel = ContentViewModel()
var body: some View { ... }
}
// ✅ MODERN (with @Observable model)
struct ContentView: View {
@State private var viewModel = ContentViewModel()
var body: some View { ... }
}
Note: Only migrate after the model uses @Observable. If model still uses ObservableObject, keep @StateObject.
Pattern 3: @ObservedObject → Direct Property or @Bindable (HIGH)
Why migrate: Simpler code, explicit binding when needed
Requirement: iOS 17+ with @Observable model
Detection:
Grep: @ObservedObject
// ❌ LEGACY
struct ItemView: View {
@ObservedObject var item: ItemModel
var body: some View {
Text(item.name)
}
}
// ✅ MODERN - Direct property (read-only access)
struct ItemView: View {
var item: ItemModel // No wrapper needed!
var body: some View {
Text(item.name)
}
}
// ✅ MODERN - @Bindable (for two-way binding)
struct ItemEditorView: View {
@Bindable var item: ItemModel
var body: some View {
TextField("Name", text: $item.name) // Binding works
}
}
Decision tree:
- Need binding (
$item.property)? → Use@Bindable - Just reading properties? → Use plain property (no wrapper)
Pattern 4: @EnvironmentObject → @Environment (HIGH)
Why migrate: Type-safe, works with @Observable
Requirement: iOS 17+ with @Observable model
Detection:
Grep: @EnvironmentObject
Grep: \.environmentObject\(
// ❌ LEGACY - Setting
ContentView()
.environmentObject(settings)
// ❌ LEGACY - Reading
struct SettingsView: View {
@EnvironmentObject var settings: AppSettings
var body: some View { ... }
}
// ✅ MODERN - Setting
ContentView()
.environment(settings)
// ✅ MODERN - Reading
struct SettingsView: View {
@Environment(AppSettings.self) var settings
var body: some View { ... }
}
// ✅ MODERN - With binding
struct SettingsEditorView: View {
@Environment(AppSettings.self) var settings
var body: some View {
@Bindable var settings = settings
Toggle("Dark Mode", isOn: $settings.darkMode)
}
}
Pattern 5: onChange(of:perform:) → onChange(of:initial:_:) (MEDIUM)
Why migrate: Deprecated modifier, new API has initial parameter
Requirement: iOS 17+
Detection:
Grep: \.onChange\(of:.*perform:
// ❌ DEPRECATED
.onChange(of: searchText) { newValue in
performSearch(newValue)
}
// ✅ MODERN (iOS 17+)
.onChange(of: searchText) { oldValue, newValue in
performSearch(newValue)
}
// ✅ With initial execution
.onChange(of: searchText, initial: true) { oldValue, newValue in
performSearch(newValue)
}
Pattern 6: Completion Handlers → async/await (MEDIUM)
Why migrate: Cleaner code, better error handling, structured concurrency
Requirement: iOS 15+ (widely adopted in iOS 17+)
Detection:
Grep: completion:\s*@escaping
Grep: completionHandler:
Grep: DispatchQueue\.main\.async
// ❌ LEGACY
func fetchUser(id: String, completion: @escaping (Result<User, Error>) -> Void) {
URLSession.shared.dataTask(with: url) { data, response, error in
DispatchQueue.main.async {
if let error = error {
completion(.failure(error))
return
}
// Parse and return
completion(.success(user))
}
}.resume()
}
// ✅ MODERN
func fetchUser(id: String) async throws -> User {
let (data, _) = try await URLSession.shared.data(from: url)
return try JSONDecoder().decode(User.self, from: data)
}
Pattern 7: withAnimation Closures → Animation Parameter (LOW)
Why migrate: Cleaner API, avoids closure
Requirement: iOS 17+
Detection:
Grep: withAnimation.*\{
// ❌ LEGACY
withAnimation(.spring()) {
isExpanded.toggle()
}
// ✅ MODERN (simple cases)
isExpanded.toggle()
// Apply animation to view:
.animation(.spring(), value: isExpanded)
// Or use new binding animation:
$isExpanded.animation(.spring()).wrappedValue.toggle()
Pattern 8: Swift Language Modernization (LOW)
Why migrate: Clearer, more efficient, modern Swift idioms
Detection:
Grep: Date\(\)
Grep: CGFloat
Grep: replacingOccurrences
Grep: DateFormatter\(\)
Grep: \.filter\(.*\)\.count
Grep: Task\.sleep\(nanoseconds:
Reference: See axiom-swift (skills/swift-modern.md) skill for the full modern API replacement table.
Report matches as LOW priority unless they appear in hot paths (then MEDIUM).
Audit Process
Step 1: Find Swift Files
Glob: **/*.swift
Step 2: Detect Legacy Patterns
ObservableObject:
Grep: ObservableObject
Grep: @Published
Property Wrappers:
Grep: @StateObject|@ObservedObject|@EnvironmentObject
Deprecated Modifiers:
Grep: onChange\(of:.*perform:
Completion Handlers:
Grep: completion:\s*@escaping
Grep: completionHandler:
Step 3: Categorize by Priority
HIGH Priority (significant benefits):
- ObservableObject → @Observable
- Property wrapper migrations
MEDIUM Priority (code quality):
- Deprecated modifiers
- async/await adoption
LOW Priority (minor improvements):
- Animation syntax
- Minor API updates
Output Format
# Modernization Analysis Results
## Summary
- **HIGH Priority**: [count] (Significant performance/maintainability gains)
- **MEDIUM Priority**: [count] (Deprecated APIs, code quality)
- **LOW Priority**: [count] (Minor improvements)
## Minimum Deployment Target Impact
- Current patterns support: iOS 14+
- After full modernization: iOS 17+
## HIGH Priority Migrations
### ObservableObject → @Observable
**Files affected**: 5
**Estimated effort**: 2-3 hours
#### Models to Migrate
1. `Models/ContentViewModel.swift:12`
```swift
// Current
class ContentViewModel: ObservableObject {
@Published var items: [Item] = []
@Published var isLoading = false
}
// Migrated
@Observable
class ContentViewModel {
var items: [Item] = []
var isLoading = false
}
Models/UserSettings.swift:8[Similar migration...]
Views to Update After Model Migration
| File | Change |
|---|---|
Views/ContentView.swift:15 | @StateObject → @State |
Views/ItemList.swift:23 | @ObservedObject → plain property |
Views/SettingsView.swift:8 | @EnvironmentObject → @Environment |
@EnvironmentObject → @Environment
-
Views/RootView.swift:45// Current .environmentObject(settings) // Migrated .environment(settings) -
Views/SettingsView.swift:12// Current @EnvironmentObject var settings: AppSettings // Migrated @Environment(AppSettings.self) var settings
MEDIUM Priority Migrations
Deprecated onChange Modifier
Views/SearchView.swift:34// Deprecated .onChange(of: query) { newValue in search(newValue) } // Modern .onChange(of: query) { oldValue, newValue in search(newValue) }
async/await Opportunities
Services/NetworkService.swift- 3 completion handler methodsfetchUser(completion:)→fetchUser() async throwsfetchItems(completion:)→fetchItems() async throwsuploadData(completion:)→uploadData() async throws
Migration Order
-
First: Migrate models to
@Observable- All
ObservableObject→@Observable - Remove all
@Published
- All
-
Second: Update view property wrappers
@StateObject→@State(for owned models)@ObservedObject→ plain or@Bindable@EnvironmentObject→@Environment
-
Third: Update view modifiers
.environmentObject()→.environment()- Deprecated
onChangesyntax
-
Fourth: Adopt async/await (optional, but recommended)
Breaking Changes Warning
⚠️ Deployment Target: Full migration requires iOS 17+
If you need to support iOS 16 or earlier:
- Keep
ObservableObjectfor those models - Use conditional compilation:
#if os(iOS) && swift(>=5.9) @Observable class ViewModel { ... } #else class ViewModel: ObservableObject { ... } #endif
Verification
After migration:
- Build and fix any compiler errors
- Test view updates (properties should still trigger UI refresh)
- Test bindings (TextField, Toggle still work)
- Test environment injection
## When No Migration Needed
```markdown
# Modernization Analysis Results
## Summary
Codebase is already using modern patterns!
## Verified
- ✅ Using `@Observable` macro
- ✅ Using `@State` with Observable models
- ✅ Using `@Environment` for shared state
- ✅ No deprecated modifiers detected
## Optional Improvements
- Consider adopting iOS 18+ features when available
- Review remaining completion handlers for async/await conversion
Decision Flowchart
Is model a class with published properties?
├─ YES: Does it conform to ObservableObject?
│ ├─ YES: Is it a type you declare (not a framework class)?
│ │ ├─ NO → Keep as-is; report why (e.g. GroupSession)
│ │ └─ YES: Target iOS 17+?
│ │ ├─ YES → Migrate to @Observable
│ │ └─ NO → Keep ObservableObject
│ └─ NO: Already modern or not observable
└─ NO: Check if it's a struct (usually fine)
Is view using @StateObject?
├─ YES: Is the model @Observable?
│ ├─ YES → Change to @State
│ └─ NO → Keep @StateObject until model migrated
└─ NO: Check other wrappers
Is view using @ObservedObject?
├─ YES: Is the model @Observable?
│ ├─ YES: Need binding?
│ │ ├─ YES → Use @Bindable
│ │ └─ NO → Remove wrapper, use plain property
│ └─ NO → Keep @ObservedObject
└─ NO: Already modern
Is view using @EnvironmentObject?
├─ YES: Is the model @Observable?
│ ├─ YES → Change to @Environment(Type.self)
│ └─ NO → Keep @EnvironmentObject
└─ NO: Already modern
False Positives to Avoid
Not issues:
- Third-party SDK types using ObservableObject
- Models that intentionally support iOS 14-16
- Combine publishers (not the same as @Published)
- Already migrated code using @Observable
- Apple protocol families unrelated to Observation — classes conforming to
AppIntent,EntityQuery,AppEntity,WidgetConfiguration,TimelineProvider, or other App Intents / WidgetKit protocols are NOTObservableObjectand should not be flagged for@Observablemigration GroupSessionand code observing it (SharePlay/GroupActivities) — a framework-ownedObservableObjectyou cannot redeclare, whose@PublishedwillSet timing the participant-delta pattern depends on. See Pattern 1. Migrating it silently breaks late-joiner state catch-up.
Check before reporting:
- Verify file is in your project, not dependencies
- Check deployment target constraints
- Confirm model is actually used in SwiftUI views
- Confirm the class actually conforms to
ObservableObject— do not flag classes just because they are classes - Confirm the type is yours to change — framework classes conforming to
ObservableObjectcannot be migrated regardless of deployment target
Frequently asked questions about Modernization Helper Agent
Similar skills
React Composition Patterns
Streamline your React component architecture with proven patterns.
Pester Should Migration
Easily convert Pester v5 assertions to v6 syntax.
Radix to Base UI Migration
Seamlessly migrate React components from Radix UI to Base UI.
Migrate Next.js to Vinext
Seamlessly transition your Next.js projects to Vinext.
WinUI 3 Migration Guide
Streamline your UWP to WinUI 3 migration process.
Refactor
Enhance code maintainability without altering behavior.
