How to Fix App Store Guideline 1.1.6 Trick or Joke Functionality Rejection
Diagnose whether a fictional chat, simulated phone, fake location, or prank feature can deceive users, then choose a product fix, clarification, or appeal.
Direct answer
Do not resubmit with only an entertainment disclaimer, category change, or longer explanation. Apple expressly says an “entertainment purposes” statement does not overcome Guideline 1.1.6. First determine what the exact release lets a user create, export, share, or present as real. Remove anonymous or prank calling and SMS/MMS functionality; Apple says those apps will be rejected. If a creator tool can generate believable false conversations, locations, device data, calls, or notifications, reduce the deceptive capability in the product itself and submit a new build. If the app is a fixed fictional narrative that cannot contact real people, alter real data, or create reusable deceptive output, clarify with a capability map and full-flow recording, then appeal only if Apple maintains a factual misunderstanding. Apple does not publish a guaranteed design recipe, so fictional styling, persistent output labels, and disabled real-world communication should be presented as verifiable risk-reduction measures, not approval guarantees.
Match the wording in your rejection
“The app includes trick or joke functionality which is intended to or may be used to deceive users”
Treat this as a capability finding, not a metadata-only problem. Inventory what the submitted build can simulate, generate, export, share, or present outside its fictional context.
“The app allows users to create fake chat conversations”
Review the exported artifact as well as the editor. An in-app disclaimer does not travel with a saved video or image unless the disclosure is part of the output itself.
A fictional phone, messages, calls, photos, or notifications inside a narrative game are cited
Document the fixed story context, the absence of real communication and device-data changes, and the limits on user-authored or exported content. If the interface closely imitates an Apple product such as Messages, also audit Guideline 5.2.5.
The response says the app is “for entertainment purposes”
That statement alone cannot resolve 1.1.6 because Apple explicitly rejects it as an override. The next submission must address the underlying capability or prove that the reviewer misunderstood what the build can do.
What this rejection usually means
Guideline 1.1.6 covers false information and features, including inaccurate device data and trick or joke functionality. Apple names fake location trackers as an example, says that an entertainment disclaimer does not overcome the rule, and rejects apps that enable anonymous or prank calls or SMS/MMS messages. The central recovery question is therefore what the product can do, not what the developer intended. A fixed fictional story, a video editor that exports realistic chat conversations, and a utility that changes or fabricates device information present different capability profiles. Apple does not publish a safe-harbor checklist for fictional interfaces, so the recovery should separate confirmed policy requirements from design measures that make non-deceptive use verifiable. Similar apps already on the store are not proof that the submitted build complies.
Likely rejection signals
- The app recreates Apple Messages, a phone screen, a location tracker, a call log, a notification, a system alert, or another trusted interface closely enough to appear authentic
- Users can enter real names, profile photos, contact details, timestamps, delivery states, locations, or device readings and export the result without persistent fictional context
- A disclosure appears only during onboarding, in metadata, or inside the editor but disappears from exported images or videos
- The app imports screenshots, contacts, profile images, or message history to reconstruct a believable conversation involving a real person
- Templates, remote catalogs, deep links, or server configuration can re-enable prank, fake-location, anonymous-calling, or deceptive simulation features
- The product name, subtitle, screenshots, keywords, ads, or sample projects promote “fake,” “prank,” “spoof,” “secret,” or deception-oriented use
- A narrative game lacks an unmistakable story shell, fixed fictional characters, chapter context, or other cues separating gameplay from a real device interface
- The review notes describe intent but do not explain the app’s technical limits, export behavior, communication APIs, and relationship to real device data
Recovery plan
- Preserve the exact rejection, reviewer screenshots, app version, build number, device, OS, submission ID, review date, and the release archive. Record the production configuration, remote content, and sample projects that were active during review.
- Build a capability map for the exact release. List every simulated element, what the user can edit, which real data can be imported, whether the app can contact another person, whether it changes device or location data, and every image, video, message, or link it can export or share.
- Classify the product honestly. Separate a fixed fictional narrative, a general creative editor, a generator of realistic false artifacts, and any prank, anonymous-communication, spoofing, or device-data feature. Do not rely on the app category or developer intent to erase what the build can produce.
- Remove any anonymous or prank phone call or SMS/MMS capability. Also remove hidden, remotely enabled, deep-linked, or legacy paths that can restore the rejected functionality. Verify the compiled release and production backend, not only the visible navigation.
- For creator tools, reduce the ability to pass output off as real. Consider a clearly fictional visual system, non-identical service names and assets, removal of real screenshot or contact reconstruction, and a persistent “Fictional conversation” or creator mark embedded in every export. These are risk-reduction measures rather than an Apple-published guarantee.
- For fixed narrative games, make the story context intrinsic to the experience. Use an unmistakable game shell, fictional cast and branding, chapter or objective framing, and no route to real calls, messages, contacts, locations, or system data. If users can author or export content, reassess the app as a creator tool instead.
- Audit confusing similarity separately. Apple’s Guideline 5.2.5 restricts apps that appear confusingly similar to Apple products or interfaces such as Messages. Replace copied icons, layouts, terminology, status indicators, and system chrome when the submitted design could be mistaken for an Apple interface.
- Align the product page and review information with the corrected capability. Remove prank or fake-use marketing, show the real creative or narrative workflow, use only fictional sample identities, and give App Review numbered steps through the complete experience.
- Test the processed release from a clean install on every supported device class. Exercise editing, import, sharing, export, deep links, notifications, remote content, offline state, restored state, and denied permissions. Verify that the fictional disclosure remains visible in every output where you chose to use one.
- Prepare a before-and-after evidence packet and choose the recovery path. Submit a new build when capability, interface, export, or remote behavior changed. Clarify or appeal only when the preserved build already lacked the cited deceptive capability and the evidence can demonstrate that fact precisely.
Evidence to prepare
- Complete rejection text, reviewer attachments, submission ID, app version, build number, device, OS, review date, and exact release archive
- Capability map covering editable fields, real-data imports, device-data access, communication APIs, generated artifacts, export and sharing, deep links, and remote configuration
- Representative before-and-after screenshots or videos for every simulated interface and export format
- Sample exported artifacts showing whether fictional context or a creator mark persists outside the app
- Release-build inventory confirming the absence of anonymous calling, SMS/MMS, fake-location, spoofing, hidden test routes, and remotely enabled rejected features
- Clean-install recording of the complete creative or narrative flow using the production configuration and fictional sample data
- App Store metadata and Notes for Review that describe the exact capability without prank, fake-use, or unsupported compliance claims
- A concise comparison between the rejected and corrected build tied to concrete product changes, or a build-specific explanation of why the cited capability never existed
Appeal or fix first?
Clarify first when the exact rejected build is a fixed fictional experience that cannot contact real people, change real device data, generate a fake location, or produce reusable deceptive output. Provide a capability map, full-flow recording, export examples, and the relevant technical limits. Appeal only if App Review continues to attribute a capability that the preserved build demonstrably does not have. Do not make approval of other apps the core argument.
Fix before resubmitting when users can create, export, or share believable false information or communications; when a disclosure disappears outside the app; when the interface can be mistaken for a real Apple or messaging interface; or when prank, anonymous-communication, fake-location, or deceptive simulation paths remain in the binary or backend. Product-level changes require a new build even if the metadata is also corrected.
Reviewer response framework
Your response should be factual, short, and limited to the submitted build. Cover these points:
- Identify the exact app version, build number, and Guideline 1.1.6 wording being addressed.
- State whether the app is a fixed narrative, a creator tool, or another product type, then list what users can and cannot create, import, communicate, export, and share.
- Describe only completed changes in the submitted build, exports, remote content, and metadata; distinguish them from optional future work.
- Provide numbered review steps, a full-flow recording, and representative exported output using fictional data.
- If the capability never existed, ask Apple to identify the exact screen, action, or output viewed during review rather than relying on comparisons with other apps.
Frequently asked questions
Is an “entertainment purposes only” disclaimer enough for Guideline 1.1.6?
No. Apple explicitly says that stating an app is for entertainment purposes does not overcome this guideline. The product capability or the factual misunderstanding behind the rejection still has to be addressed.
Can a fictional chat-video editor be approved?
Apple does not publish a safe harbor for that category. Approval depends on the submitted product and review. Reduce the ability to create believable deception, make fictional context persist in exported content, avoid copying trusted interfaces, and document the exact limits without promising that those measures guarantee approval.
What if my app is a narrative mystery game with a simulated phone?
If the experience is fixed fiction and cannot contact real people, alter device data, or generate reusable deceptive output, clarify those facts with a capability map and complete recording. Strengthen the game and story framing if the interface can otherwise be mistaken for a real phone.
Does Apple require a watermark on fictional exports?
Guideline 1.1.6 does not state a specific watermark requirement. A persistent fictional label or creator mark is a practical risk-reduction measure because it keeps context attached to exported media, but it is not an approval guarantee.
Can I point to similar apps already available on the App Store?
You may use comparisons as background, but they do not prove that your build complies. Center the response on the exact capabilities, limits, interface, outputs, and evidence in your submitted version.
Should I resubmit the same build or appeal?
Submit a new build when you changed functionality, interface, exported output, remote content, or any other app behavior. Clarify or appeal only when the exact reviewed build already lacked the cited deceptive capability and you can prove that with preserved evidence.
Need a rejection-specific plan?
Start with the free diagnosis. The $29 Fix Pack adds the prioritized remediation plan, evidence checklist, reviewer-ready reply, and preflight.
Source: Apple App Review Guidelines — 1.1.6 False Information and Trick or Joke Functionality. Platform policies change. Verify the official rule before submitting. Resubmit AI provides technical and editorial decision support, not an approval guarantee or legal advice.