performance-optimization_skill

This skill helps you make informed performance decisions for iOS/tvOS by profiling, selecting tools, and balancing optimization with user impact.
  • Shell

6

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill kaakati/rails-enterprise-dev --skill performance-optimization

  • SKILL.md14.2 KB

Overview

This skill provides concise, expert guidance for iOS and tvOS performance decisions: when to optimize, which profiling tools to run, SwiftUI view identity and update strategies, and practical memory management fixes. It focuses on measurable outcomes—reduce UI jank, stop memory growth, and improve battery life—by encouraging profiling-first workflows. Useable as a checklist and decision tree during debugging and design reviews.

How this skill works

It codifies decision trees for whether to optimize, maps common symptoms to the right Instruments tool, and gives concrete SwiftUI and memory fixes. The skill inspects symptoms (stutter, memory growth, battery drain, crashes) and recommends targeted actions: Time Profiler for main-thread work, Allocations/Leaks for memory, Core Animation for GPU issues, etc. It also supplies patterns to avoid (wrong identifiers, excessive @Published, strong self captures) and safe replacements (NSCache, downsampling, background tasks).

When to use it

  • You observe visible stutter, dropped frames, or slow screen transitions
  • App store reviews or users report slowness or high battery usage
  • Memory warnings, crashes, or steady memory growth during use
  • Before adding micro-optimizations—use when profiling evidence exists
  • When SwiftUI lists re-render unexpectedly or list performance degrades

Best practices

  • Profile first, optimize second—measure bottlenecks with Instruments before changing code
  • Use stable IDs and Equatable rows for lists; never use indices as identifiers
  • Move expensive computations out of View.body into ViewModel or cached properties
  • Avoid strong self in escaping closures; invalidate timers and remove observers in deinit
  • Use NSCache with count/size limits and downsample images to display size
  • Run heavy work off the main thread (Task.detached / background queue) and update UI on MainActor

Example use cases

  • Investigate a screen that drops frames while scrolling and trace heavy main-thread work with Time Profiler and Core Animation
  • Fix memory growth after navigating through screens by checking retain cycles with Allocations and Leaks and converting strong captures to [weak self]
  • Reduce app startup CPU and energy by profiling launch with Time Profiler and Energy Log and deferring non-essential work
  • Optimize image-heavy list by downsampling images, using NSCache with limits, and lazy list containers
  • Debounce search input and cancel previous tasks to prevent cascading network and UI updates

FAQ

Avoid changes when you only have a hunch. If no user-facing issue or measurement shows a bottleneck, prefer clean code and add profiling hooks to gather evidence later.

Which Instruments for memory leaks?

Start with Allocations to view growth and object lifetimes, then run Leaks to find leaked objects. Use object graph and retain path to locate strong reference cycles.

How do I prevent SwiftUI list re-renders?

Give rows stable IDs (not indices), make row views Equatable when possible, and move expensive transforms into a ViewModel so body is cheap.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational