Augmented reality

ARKit App Review checklist

ARKit experiences depend on camera, device motion, lighting, space, and user safety. Review readiness means the app can be tested without a perfect room or private environment.

Quick answer

Define the AR mode, physical-space assumption, camera use, sample content, and fallback state before submission. Apple ARKit documentation supports building augmented reality experiences that blend digital content with the real world. AppReviewReady interpretation: provide a safe physical-space route and no-camera explanation for review.

01

Define the AR experience mode

Name whether the app uses world tracking, face tracking, image tracking, object placement, measurement, navigation, education, game interaction, commerce preview, or training. Each mode has different safety and review evidence.

If AR is a feature inside a broader app, provide a route to reach it quickly. The reviewer should not need to unlock a long progression before seeing the AR behavior.

02

Design for imperfect physical spaces

  • Show instructions for lighting, space, surface detection, and movement.
  • Handle unsupported device, denied camera, poor tracking, and no surface found states.
  • Avoid encouraging unsafe movement, driving, stairs, or public-space hazards.
  • Make digital objects scale and placement understandable.
  • Use sample content that does not require a private home, office, or customer site.
03

Explain camera and spatial data behavior

AR camera access can reveal people, rooms, screens, documents, and location-like context. The app should describe whether images, scans, anchors, measurements, or derived data are stored or uploaded.

AppReviewReady interpretation: do not describe AR as purely visual if the app sends spatial maps, object scans, or screenshots to a server.

04

Test AR session states

  1. Start the AR flow from fresh install and trigger camera permission.
  2. Deny camera, interrupt the session, background the app, and return.
  3. Test low light, no detected surface, unsupported device, and reset tracking.
  4. Place, move, delete, save, and reload AR content.
  5. Verify screenshots and recordings do not expose private sample environments.
05

Give review an AR test path

Provide a short route that works in an ordinary room. If the app depends on special markers, objects, or printouts, include downloadable samples or a demo mode.

After launch, monitor device compatibility and tracking-failure reports separately. AR problems often happen on older devices, dark rooms, reflective surfaces, or crowded spaces that internal QA did not cover.

If AR output affects purchasing, measurement, design, or safety decisions, label estimates and limits near the result rather than only in Terms.

For shared AR scenes, test what happens when participants join late, leave, or use devices with different tracking quality.

If the AR experience includes downloadable models, test missing assets, slow downloads, and inappropriate placeholder content. The fallback should preserve the user's place in the flow rather than dropping back to a blank camera view.

Copy-ready frameworkAdapt every bracketed field
ARKit review path:
AR mode: [world tracking, face]
How to start: [steps]
Physical space needed: [table, floor]
Sample content: [provided]
Denied-camera behavior: [message]
Data stored/uploaded: [none or fields]
Safety limits: [instructions]
Sources

Primary references checked for this guide

Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.

Put it to work

Check AR readiness

Review camera permission, spatial safety, sample content, and fallback behavior before submission.

Open the tool