Guideline 1.1 rejection cites "templates for intimate contact" - app contains no templates (App ID 6806898848)

App: Mirra: You in Any Photo (App ID 6806898848), version 1.0. Latest Submission ID: 06677de2-a0fa-489c-8635-65998191f4e6.

We have received the same Guideline 1.1 rejection three times, each with identical wording:

"Specifically, the app includes templates for generating content showing people making intimate contact with each other, such as hugging, kissing, or other intimate templates."

We are asking for help identifying what App Review is referring to, because the app does not contain templates of any kind:

  • There is no template gallery, preset list, sample scene, or bundled content anywhere in the app. The asset catalog contains only the app icon and an accent color.
  • The app has one function: the user supplies a reference photo (from their own library or a link they share) and the app renders that scene with the user's own enrolled face.
  • Our server records show that no images were generated from the review account in any of the three review sessions.
  • The service already declines any reference image showing more than one person, and the next build restricts generation to single-person photos end to end, with the reason shown on screen.

Each resubmission included these facts in the review notes and returned the identical paragraph. We have replied in the Resolution Center and requested a call.

If anyone from App Review can tell us the specific screen, screenshot, or asset that is being read as a template, we will remove it immediately. Otherwise we would be grateful for a review of the actual build. A demo account with pre-enrolled selfies is in App Review Information.

Thank you.

This may be a terminology mismatch rather than App Review finding a literal template gallery.

Apple may be treating the user-supplied reference image as a “template”: it defines the scene into which the enrolled face is rendered. If arbitrary photos or URLs can be used, the concern may be the app’s capability to create intimate or non-consensual face-swap content, not content bundled in the binary. That would also explain why removing assets or showing that the review account generated nothing has not changed the response.

I would avoid another resubmission based only on explanatory notes. Instead, make the safeguards directly testable and give App Review a compact evidence package:

  • Enforce the single-person rule both before upload and on the server.
  • Reject sexual or intimate reference images and generated outputs, with visible reason messages.
  • Consider removing arbitrary URL input temporarily if its content cannot be validated reliably.
  • Add an explicit confirmation that the user owns or has permission to use the reference image.
  • Record moderation decisions using timestamps and reason codes, without retaining unnecessary image data.
  • Provide a short, unedited recording showing installation, login with the supplied review account, an allowed generation, and several blocked cases.
  • Include a one-page flow describing every input and output moderation check.
  • Attach a bundle inventory or asset manifest confirming that no templates, sample scenes, or remotely configured galleries exist.

In the Resolution Center, I would ask one narrow question:

“Does App Review use the term ‘template’ here to include a user-supplied reference image or URL? If not, please identify the exact screen, metadata item, remote resource, or review step that produced the cited content.”

Also state the exact build number containing the safeguards. This makes it easier for Apple to verify the current binary instead of repeating findings from an earlier review.