iOS app performance problems fall into distinct categories, each with a specific diagnosis tool. This skill helps you choose the right tool, use it effectively, and interpret results correctly under pressure.
Fetches axiom-performance-profiling from charleswiltgen/axiom and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/axiom-performance-profiling
Restart Cursor to activate axiom-performance-profiling. Access via /axiom-performance-profiling in your agent's command palette.
⚠
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
iOS app performance problems fall into distinct categories, each with a specific diagnosis tool. This skill helps you choose the right tool, use it effectively, and interpret results correctly under pressure.
Core principle: Measure before optimizing. Guessing about performance wastes more time than profiling.
Requires: Xcode 15+, iOS 14+
Related skills: axiom-swiftui-performance (SwiftUI-specific profiling with Instruments 26), axiom-memory-debugging (memory leak diagnosis)
When to Use Performance Profiling
Use this skill when
✅ App feels slow (UI lags, loads take 5+ seconds)
✅ Memory grows over time (Xcode shows increasing memory usage)
✅ Battery drains fast (device gets hot, battery depletes in hours)
✅ You want to profile proactively (before users complain)
✅ You're unsure which Instruments tool to use
✅ Profiling results are confusing or contradictory
Use axiom-memory-debugging instead when
Investigating specific memory leaks with retain cycles
Using Instruments Allocations in detail mode
Use axiom-swiftui-performance instead when
Analyzing SwiftUI view body updates
Using SwiftUI Instrument specifically
Performance Decision Tree
Before opening Instruments, narrow down what you're actually investigating.
Step 1: What's the Symptom?
App performance problem?
├─ App feels slow or lags (UI interactions stall, scrolling stutters)
│ └─ → Use Time Profiler (measure CPU usage)
├─ Memory grows over time (Xcode shows increasing memory)
│ └─ → Use Allocations (measure object creation)
├─ Data loading is slow (parsing, database queries, API calls)
│ └─ → Use Core Data instrument (if using Core Data)
│ └─ → Use Time Profiler (if it's computation)
└─ Battery drains fast (device gets hot, depletes in hours)
└─ → Use Energy Impact (measure power consumption)
Step 2: Can You Reproduce It?
YES – Use Instruments to measure it (profiling is most accurate)
NO – Use profiling proactively
Enable Core Data SQL debugging to catch N+1 queries
Profile app during normal use (scrolling, loading, navigation)
Establish baseline metrics before changes
Step 3: Which Instruments Tool?
Time Profiler – Slowness, UI lag, CPU spikes
Allocations – Memory growth, memory pressure, object counts
Core Data – Query performance, fetch times, fault fires
Energy Impact – Battery drain, sustained power draw
Network Link Conditioner – Connection-related slowness
System Trace – Thread blocking, main thread blocking, scheduling
Time Profiler Deep Dive
Use Time Profiler when your app feels slow or laggy. It measures CPU time spent in each function.
Workflow: Record and Analyze
Step 1: Launch Instruments
open-a Instruments
Select "Time Profiler" template.
Step 2: Attach to Running App
Start your app in simulator or device
In Instruments, select your app from the target dropdown
Click Record (red circle)
Interact with the slow part (scroll, tap buttons, load data)
Stop recording after 10-30 seconds of interaction
Step 3: Read the Call Stack
The top panel shows a timeline of CPU usage over time. Look for:
Tall spikes – Brief CPU-intensive operations
Sustained high usage – Continuous expensive work
Main thread blocking – UI thread doing work (causes UI lag)
Step 4: Drill Down to Hot Spots
In the call tree, click "Heaviest Stack Trace" to see which functions use the most CPU:
Self Time = Time spent IN that function (not in functions it calls)
Total Time = Time spent in that function + everything it calls
Common Mistakes & Fixes
❌ Mistake 1: Blaming the Wrong Function
// ❌ WRONG: Profile shows DataParser.parse() is 80% CPU// Conclusion: "DataParser is slow, let me optimize it"// ✅ RIGHT: Check what DataParser is calling// If JSONDecoder.decode() is doing 99% of the work,// optimize JSON decoding, not DataParser
The issue: A function with high Total Time might be calling slow code, not doing slow work itself.
Fix: Look at Self Time, not Total Time. Drill down to see what each function calls.
❌ Mistake 2: Profiling the Wrong Code Path
// ❌ WRONG: Profile app in Simulator// Simulator CPU is different than real device// Results don't reflect actual device performance// ✅ RIGHT: Profile on actual device// Device settings: Developer Mode enabled, Xcode attached
Fix: Always profile on actual device for accurate CPU measurements.
❌ Mistake 3: Not Isolating the Problem
// ❌ WRONG: Profile entire app startup// Sees 2000ms startup time, many functions involved// ✅ RIGHT: Profile just the slow part// "App feels slow when scrolling" → profile only scrolling// Separate concerns: startup slow vs interaction slow
Fix: Reproduce the specific slow operation, not the entire app.
Pressure Scenario: "Profile Shows Function X is 80% CPU"
The temptation: "I must optimize function X!"
The reality: Function X might be:
Calling expensive code (optimize the called function, not X)
Running on main thread (move to background, it's already optimized)
Necessary work that looks slow (baseline is acceptable, user won't notice)
What to do instead:
Check Self Time, not Total Time
Self Time 80%? Function is actually doing expensive work
Self Time 5%, Total Time 80%? Function is calling slow code
Drill down one level
What is this function calling?
Is the slow code in a library you control?
Check the timeline
Is this 80% sustained (steady slow) or spikes (occasional stalls)?
Sustained = optimization needed
Spikes = caching might help
Ask: Will users notice?
500ms background work = user won't notice
500ms on main thread = UI stall, user sees it
50ms on main thread per frame = smooth UI (60fps)
Time cost: 5 min (read results) + 2 min (drill down) = 7 minutes to understand
Cost of guessing: 2 hours optimizing wrong function + 1 hour realizing it didn't help + back to square one = 3+ hours wasted
Allocations Deep Dive
Use Allocations when memory grows over time or you suspect memory pressure issues.
Workflow: Record and Analyze
Step 1: Launch Instruments
open-a Instruments
Select "Allocations" template.
Step 2: Attach and Record
Start your app
In Instruments, select your app
Click Record
Perform actions that use memory (load data, display images, navigate)
Stop recording after memory stabilizes or peaks
Step 3: Find Memory Growth
Look at the main chart:
Blue line = Total allocations
Sharp climb = Memory being allocated
Flat line = Memory stable (good)
No decline after stopping actions = Possible leak (or caching)
Step 4: Identify Persistent Objects
Under "Statistics":
Sort by "Persistent" (objects still alive)
Look for surprisingly large object counts:
UIImage: 500 instances (300MB) – Should be <50 for normal app
NSString: 50000 instances – Should be <1000
CustomDataModel: 10000 instances – Should be <100
Common Mistakes & Fixes
❌ Mistake 1: Confusing "Memory Grew" with "Memory Leak"
// ❌ WRONG: Memory went from 100MB to 500MB// Conclusion: "There's a leak, memory keeps growing!"// ✅ RIGHT: Check what caused the growth// Loaded 1000 images (normal)// Cached API responses (normal)// User has 5000 contacts (normal)// Memory is being used correctly
The issue: Growing memory ≠ leak. Apps legitimately use more memory when loading data.
Fix: Check Allocations for object counts. If images/data count matches what you loaded, it's normal. If object count keeps growing without actions, that's a leak.
❌ Mistake 2: Not Accounting for Caching
// ❌ WRONG: Allocations shows 1000 UIImages in memory// Conclusion: "Memory leak, too many images!"// ✅ RIGHT: Check if this is intentional caching// ImageCache holds up to 1000 images by design// When memory pressure happens, cache is cleared// Normal behavior
Fix: Distinguish between intended caching and actual leaks. Leaks don't release under memory pressure.
❌ Mistake 3: Profiling Too Short
// ❌ WRONG: Record for 5 seconds, see 200MB// Conclusion: "App uses 200MB, optimize memory"// ✅ RIGHT: Record for 2-3 minutes, see full lifecycle// Load data: 200MB// Navigate away: 180MB (20MB still cached)// Navigate back: 190MB (cache reused)// Real baseline: ~190MB at steady state
Fix: Profile long enough to see memory stabilize. Short recordings capture transient spikes.
Pressure Scenario: "Memory is 500MB, That's a Leak!"
The temptation: "Delete caching, reduce object creation, optimize data structures"
The reality: Is 500MB actually large?
iPhone 14 Pro has 6GB RAM
Instagram uses 400-600MB on load
Photos app uses 500MB+ when browsing large library
500MB might be completely normal
What to do instead:
Establish baseline on real device
# On device, open Memory view in XcodeXcode → Debug → Memory Debugger → Check "Real Memory" at app launch
Check object counts, not total memory
Allocations → Statistics → "Persistent"
Are images, views, or data objects 10x expected count?
If yes, investigate that object type
If no, memory is probably fine
Test under memory pressure
Xcode → Debug → Simulate Memory Warning
Does memory drop by 50%+? It's caching (normal)
Does memory stay high? Investigate persistent objects
Profile real user journey
Load data (like user does)
Navigate around (like user does)
Return to app (from background)
Check memory at each step
Time cost: 5 min (launch Allocations) + 3 min (record app usage) + 2 min (analyze) = 10 minutes
Cost of guessing: Delete caching to "reduce memory" → app reloads data every screen → slower app → users complain → revert changes = 2+ hours wasted
Core Data Deep Dive
Use Core Data instrument when your app uses Core Data and data loading is slow.
Workflow: Enable SQL Debugging and Profile
Step 1: Enable Core Data SQL Logging
Add to your launch arguments in Xcode:
Edit Scheme → Run → Arguments Passed On Launch
Add: -com.apple.CoreData.SQLDebug 1
Now SQLite queries print to console:
CoreData: sql: SELECT ... FROM tracks WHERE artist = ? (time: 0.015s)
CoreData: sql: SELECT ... FROM albums WHERE id = ? (time: 0.002s)
Step 2: Identify N+1 Query Problem
Watch the console during a typical user action (load list, scroll, filter):
❌ BAD: Loading 100 tracks, then querying album for each
SELECT * FROM tracks (time: 0.050s) → 100 tracks
SELECT * FROM albums WHERE id = 1 (time: 0.005s)
SELECT * FROM albums WHERE id = 2 (time: 0.005s)
SELECT * FROM albums WHERE id = 3 (time: 0.005s)
... 97 more queries
Total: 0.050s + (100 × 0.005s) = 0.550s
✅ GOOD: Fetch tracks WITH album relationship (eager loading)
SELECT tracks.*, albums.* FROM tracks
LEFT JOIN albums ON tracks.albumId = albums.id
(time: 0.050s)
Total: 0.050s
Step 3: Profile with Core Data Instrument
open-a Instruments
Select "Core Data" template.
Record while performing slow action:
Core Data Results
Fetch Requests: 102
Average Fetch Time: 12ms
Slow Fetch: "SELECT * FROM tracks" (180ms)
Fault Fires: 5000
→ Object accessed, requires fetch from database
→ Should use prefetching
Common Mistakes & Fixes
❌ Mistake 1: Not Using Relationships Correctly
// ❌ WRONG: Fetch tracks, then access album for eachlet tracks =try context.fetch(Track.fetchRequest())for track in tracks {print(track.album.title)// Fires individual query for each}// Total: 1 + N queries// ✅ RIGHT: Fetch with relationship prefetchinglet request =Track.fetchRequest()request.returnsObjectsAsFaults =falserequest.relationshipKeyPathsForPrefetching =["album"]let tracks =try context.fetch(request)for track in tracks {print(track.album.title)// Already loaded}// Total: 1 query
Fix: Use relationshipKeyPathsForPrefetching to load related objects upfront.
❌ Mistake 2: Not Using Batching
// ❌ WRONG: Fetch 50,000 records all at oncelet request =Track.fetchRequest()let allTracks =try context.fetch(request)// Huge memory spike// ✅ RIGHT: Batch fetch in chunkslet request
✓
Make data-driven prioritization decisions faster
Stakeholder Communication
Draft PRDs, status updates, and stakeholder presentations
›Access to product documentation and roadmap tools (Jira, Notion, etc.)
›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
⚠Not validating competitive research—verify facts before sharing
⚠Accepting user stories without involving engineering team
⚠Over-relying on frameworks without qualitative judgment
⚠Not customizing outputs to company culture and communication style
⚠Skipping stakeholder validation of generated requirements
Best Practices
✓ Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
✗ Don't
−Don't publish competitive analysis without fact-checking
−Don't finalize user stories without engineering review
−Don't make prioritization decisions solely on AI scoring
−Don't skip customer validation of generated requirements
−Don't ignore company-specific context and culture
💡 Pro Tips
★Provide context: company goals, constraints, customer feedback
★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
★Use skill for 70% generation + 30% customization to company needs
When to Use This
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path
1Basic: user stories, feature specs, status updates
