A frame-rate setting is not meaningful without the device, display, scene, graphics mode, measurement method, and stability target around it. Document the decision so another developer or tester can reproduce the result and understand the tradeoff. Keep measured data separate from design targets, and never label a menu setting as proven performance until the agreed test has passed.
Define the experience target
Record the game build, platform, device class, operating-system version, display resolution, refresh rate, graphics preset, input mode, and whether dynamic resolution, upscaling, frame generation, or synchronization is enabled. State the target frame rate, the reason for it, and the player experience it supports. Include any lower-power, quality, accessibility, handheld, docked, battery, or thermal mode.
Apple's Metal best-practices guide emphasizes a consistent and stable frame rate. It explains the time budget relationship between frames per second and frame duration and advises selecting a lower supported factor when an app cannot maintain its maximum target, rather than creating unstable pacing (Apple Metal frame-rate guidance). Treat that as platform-specific guidance, not a universal prescription for every engine or display.
Record the complete settings contract
List every setting that changes rendering cost or presentation: resolution, render scale, texture and shadow quality, anti-aliasing, ray tracing, effects, crowd or simulation detail, view distance, frame cap, vertical synchronization, variable-refresh behavior, interpolation, and latency options. Record defaults by platform and whether the game can change them automatically.
For each preset, state what is fixed, what can vary, expected image-quality tradeoffs, memory assumptions, and unsupported combinations. Name the design owner who approves the experience target, engineering owner who implements it, performance owner who measures it, QA owner who accepts it, and release owner who authorizes a default change.
Specify a repeatable measurement method
Define the capture tool and version, sampling interval, warm-up, run length, test scene or replay, starting save, camera route, network conditions, background-process policy, power source, device temperature state, and number of runs. Record frames per second alongside frame time and pacing; an average alone can hide stalls. Preserve raw captures, build identifiers, logs, and exact settings.
Apple's current game-technology documentation describes Metal tools for validating graphics work, investigating artifacts, finding causes of low frame rates, and using the Metal Performance HUD for real-time CPU and GPU metrics (Apple game technologies). Choose platform-appropriate profilers and state whether the measurement comes from a development tool, a built-in benchmark, field telemetry, or external capture. Do not compare unlike tools as if they used identical methods.
Define scenes and acceptance criteria
Use several representative scenarios: a typical traversal, the heaviest known combat or simulation scene, menus, loading transitions, networked play if relevant, and a long session that can expose thermal or memory effects. State the target, allowed duration and frequency of misses, pacing threshold, input-latency concern, visual defects, and crash or memory guardrails. Include the exact device list and minimum supported configuration.
An acceptance decision should show raw evidence for each required scene and device. Record anomalies, whether a run was excluded, and why. If a feature improves the average but introduces visible artifacts or unstable pacing, document the tradeoff and the accountable approval rather than hiding it in a preset name.
Control changes and rollback
Every default or cap change should name the request, reason, affected platforms, before-and-after values, expected performance and visual effect, implementation reference, test evidence, approver, release, and rollback. Keep engine configuration, platform code, user setting, and live-service overrides distinct. If an emergency override exists, document who can use it, its audit trail, expiration, and recovery procedure.
Review the record after engine upgrades, major content additions, graphics-feature changes, platform updates, new hardware tiers, and repeated player reports. Close each decision with known limits and a next review date. This creates a frame-rate contract that can be tested and transferred, rather than a number that changes without context.
Sources
- Metal Best Practices Guide: Frame Rate — Apple Developer, March 27, 2017
- Game technologies — Apple Developer