Greetings, traveler!

AI agent skills are reusable instructions that teach an agent how to handle a specific type of task. They can define its focus, workflow, constraints, and reference materials, so the agent does not need to approach every request from scratch.

This article is part of a series about building practical AI agent skills for iOS development. The first article explains what skills are, how they differ from files such as AGENTS.md and CLAUDE.md, and how they can support real development workflows.

If you want the broader picture, I covered the idea in more detail here.

This article covers a more specific case: the iOS Perceived Performance skill. It helps an agent review whether an app feels responsive from the user’s point of view.

What the skill focuses on

The ios-perceived-performance skill deals with the visible part of performance.

Users do not see CPU samples, network traces, database timings, or task graphs. They see whether the interface responds after a tap, how long a screen stays blank, whether useful content appears gradually, and whether the app explains what is happening.

Because of that, a screen may feel slow even when the underlying operation is reasonably efficient. It may simply provide no feedback until the operation finishes.

The skill teaches the agent to begin with that user-visible delay or uncertainty before recommending lower-level optimization.

When the skill should be used

The skill applies to screens and flows that feel stuck, blank, jumpy, or unresponsive.

Typical cases include:

• no visible response after a tap;
• delayed first meaningful content;
• unclear loading, empty, error, or retry states;
• refresh flows that remove existing content;
• screens that wait for every request before rendering anything;
• optimistic updates without pending or rollback behavior;
• repeated submissions during asynchronous work;
• actions that show success before the server confirms the result.

The agent can also use the skill when reviewing skeletons, placeholders, progressive rendering, stale-while-refreshing interfaces, and section-level loading.

Perceived performance and execution time

Perceived performance does not replace technical performance work. It answers a different question.

A profiler may show that an operation takes two seconds. This skill asks what the user sees during those two seconds.

For example, the interface could acknowledge the action immediately, keep existing content visible, show a pending state, and update individual sections as their data arrives. The operation still takes two seconds, but the app no longer appears frozen.

The opposite can also happen. A relatively quick request may still feel slow when the screen becomes blank or ignores the user’s action until the request completes.

The skill therefore separates actual execution-time improvements from changes that improve feedback and continuity.

The review workflow

The agent starts by identifying the visible symptom. It may be missing feedback, all-or-nothing loading, unstable layout, unclear progress, repeated submissions, or premature success.

It then finds the state transition responsible for that behavior.

Before suggesting profiling or architectural changes, the agent checks a few product-level questions:

• Does the interface acknowledge the action immediately?
• Can critical content appear before secondary content?
• Can refresh preserve useful existing data?
• Are loading, empty, error, refreshing, pending, and failed states distinct?
• Can the same operation be submitted more than once?
• Is an optimistic update safe and reversible?

The goal is to recommend the smallest change that makes the flow clearer and more responsive.

Progressive rendering and loading states

Many screens delay all content until several unrelated requests finish. This makes the loading time depend on the slowest request.

The skill encourages the agent to check whether the screen can render in stages. Critical content may appear first, while secondary sections continue loading independently.

It also examines whether refresh should keep existing data on screen. Clearing the interface during every update often creates unnecessary blank states and layout changes. When stale content is still safe to show, the app can preserve it and indicate that a refresh is in progress.

The skill does not recommend splitting every screen into separate loading sections. Partial content should still make sense to the user. A fragmented screen can be more confusing than a short, well-explained loading state.

Optimistic updates

Optimistic UI can make low-risk actions feel immediate. The app updates locally first and reconciles the change with the server afterward.

This works well only when the action is reversible and the flow defines what happens if the request fails.

The skill checks for:

• a visible pending state;
• rollback behavior;
• retry handling;
• conflict resolution;
• local and server reconciliation;
• protection against duplicate requests.

Without these parts, optimistic UI can make the interface fast but unreliable.

High-stakes actions

Some actions should not display final success optimistically.

Financial operations, destructive changes, identity verification, security settings, legal agreements, and other server-authoritative actions require explicit progress and confirmed results.

For these flows, the skill tells the agent to prefer immediate acknowledgement followed by a pending state. Final success should appear only after the backend confirms the operation.

This distinction helps the agent avoid applying the same responsiveness pattern to every interaction.

What the agent can verify

From code, the agent can inspect state models, async transitions, loading behavior, duplicate-submission protection, and whether existing content disappears during refresh.

It can also identify cases where the UI waits for an operation to finish before providing feedback.

However, code inspection cannot prove that a screen feels fast enough. It also cannot confirm behavior on older devices, under poor network conditions, or in production.

The skill requires the agent to state this limitation instead of presenting assumptions as measured results.

Evidence and validation

The skill favors evidence that represents the user’s actual experience.

Useful validation methods include screen recordings, tap-to-feedback measurements, time to first meaningful content, slow-network testing, UI tests, Instruments traces, MetricKit data, and production logs around loading stages.

Low Power Mode may expose limited performance headroom during manual testing, but it does not simulate an older device.

When evidence is incomplete, the agent should describe the expected effect carefully. For example, preserving existing content should reduce blank-screen time, but the result still needs validation in a release build.

Boundaries with other performance skills

This skill does not replace low-level performance analysis.

CPU usage, memory allocation, ARC traffic, SwiftUI invalidation, scrolling hitches, compiler behavior, Swift Concurrency internals, and launch diagnostics belong to more specialized skills.

The perceived performance skill should be selected when the main problem concerns user feedback, loading behavior, continuity, staged content, or trust in an asynchronous flow.

A single issue may involve several skills. For example, a delayed first screen may require launch profiling as well as a better loading experience. The perceived performance skill keeps its part of the analysis focused on what the user sees.

Structured review output

The skill also defines a consistent response format for reviews.

The agent describes the finding, explains the user impact, points to available evidence, recommends a focused change, adds implementation notes, and provides a validation plan.

This structure prevents vague advice such as “improve the loading experience.” It connects each recommendation to a specific state transition and a visible user problem.

Final thoughts

The iOS Perceived Performance skill gives an AI agent a product-oriented way to review responsiveness.

It helps the agent distinguish missing feedback from slow execution, choose safer loading and optimistic-update patterns, and avoid claiming performance improvements without evidence.

The skill is available in the iOS Performance Agent Skills repository.