Submit documented app integration evidence

Prepare an evidence submission by email

Use the existing public contact address, [email protected], to present an app for editorial consideration. A suggested subject is App integration evidence: followed by the app name and public version. This is a suggested email format, not a message already sent. Start with your relationship to the app, a concise description of the proposed capability and links to the strongest public evidence. Developers, publishers and users can make the origin of their information clear without claiming to represent another organization.

This page is a static submission hub. It does not provide an upload form, submission backend, receipt number or response deadline. An email is an entry into a possible evidence review, not acceptance into the directory. Keep the initial message readable: summarize the claim first, then provide release details, action descriptions and supporting material. If a capability is still in a preview, say so prominently rather than presenting it as a feature already available to every customer. Published contact details alone do not establish that the mailbox is monitored or that a reply will be sent.

• Browse documented app capabilities

Identify the exact public app release

Include the public App Store URL, app name, publisher or seller, version number and release date. Explain which platform the evidence covers: iPhone, iPad, Mac, Apple Watch or Apple Vision Pro. If separate listings or releases exist, identify each relevant one instead of assuming that a shared product name means identical functionality. Give the minimum operating system stated by the publisher for the particular capability, and distinguish that requirement from the operating system used in any supplied reproduction record.

Provide the public version history needed to check whether the app has received an update within the preceding twelve months, a directory eligibility criterion. Do not substitute an undated marketing page for a release date. If the feature appears only in a beta or private build, label that build separately and explain what remains unconfirmed in the public release. Missing version evidence should remain an open question; it must not be filled with an estimated number or inferred launch date.

Use integration labels with a defined evidence scope

Use Shortcuts documented when first-party material establishes Apple Shortcuts actions or workflows. That label describes documented support; it does not imply that this site reproduced the workflow or verified the new Siri AI integration. Use Announced rollout when an attributable announcement describes capabilities being introduced, while preserving its platform, timing and availability qualifications. Reserve Siri AI verified for a specific public integration supported by matching release information, official documentation and reproducible evidence sufficient to establish the stated scope.

Treat these as evidence labels rather than promotional tiers. A developer article, an Apple support resource and a downloadable app are different resource types; being an official resource does not itself earn an integration label. Where documentation describes conventional Siri support without establishing Shortcuts actions, explain that capability in prose instead of forcing an inaccurate classification. Where the evidence does not support a status, state the unresolved question or defer the claim. A submission can contain a well-supported older capability alongside a newer claim still awaiting verification.

• Understand documented Shortcuts workflows

Separate Apple's system rollout from third-party releases

Apple's November 3 developer announcement describes an action rollout across Calendar, Files, Finder, Journal, Mail, Maps, Messages, Music, Notes, Photos, Preview, Reminders, Safari, Shortcuts and Weather. Attribute that list to Apple and describe specific actions only where a source supports them. Finder and Preview should not be presented as apps available on every platform. Apple's example concerns archiving files that have not been opened for over a year; it does not establish a file-deletion action or demonstrate this site's own testing.

The same announcement introduces a third-party Developer Preview with the iOS, iPadOS, macOS and visionOS 27.3 betas. It describes App Intents, custom actions and content, skills that combine actions, and entities in the Spotlight semantic index. Its references to customers in a few months and App Store submissions in spring do not supply a precise public launch date. Apple's November 5 setup article describes broader OS 27 availability. Keep consumer setup, Apple's system actions and a third-party app's public release as separate evidence questions.

Document exact actions and their operating conditions

For each proposed action, provide its exact documented name, what information it accepts, what result it produces and the official page that describes it. Distinguish creating a record from searching, appending, exporting or deleting one. If you supply a spoken phrase, identify whether it is a publisher's verbatim example or your own suggested wording. A user-created shortcut name should be described as such, not presented as an official Siri command. Include relevant permissions, sign-in requirements and any stated restrictions on locked content or background execution.

Useful evidence includes limitations as well as successful paths. Bear's Shortcuts documentation describes note operations and says locked notes cannot be accessed. That supports a bounded capability description rather than unrestricted access to every note. Craft's Apple Shortcuts article documents actions including Create Document and Add to Document, with stated operating system requirements. Preserve those English action names unless an official Spanish equivalent is established. Do not extrapolate additional actions from a broad claim that an app supports automation.

State platform, language and region boundaries

Record the device model, operating system version and build, app version, device language, Siri language and relevant account region for user-supplied evidence. Keep those observations separate from the publisher's stated support range. Apple's setup article says Siri AI requires matching supported device and Siri languages and an eligible region. It lists English, French, Japanese, Korean, Portuguese and Spanish. Availability in Spanish does not establish availability on every device or in every Spanish-speaking location, and future language announcements do not establish current support.

The same Apple article says Siri AI is unavailable on iOS, iPadOS and watchOS in the EU, while describing availability on macOS 27 Golden Gate and visionOS 27 under its account and language conditions. It also says Siri AI currently does not work with an Apple Account region in mainland China. Report these system conditions separately from an app's own territorial restrictions. Do not suggest changing account regions to obtain access. Where no platform-specific app evidence exists, leave that platform unconfirmed rather than copying another platform's result.

• Review device and regional eligibility
• Read the consumer setup guide

Provide reproducible evidence without exposing secrets

If you provide your own evidence, describe the starting state, required permissions, exact steps, expected result and actual result, with the date and environment. A short screen recording or a sequence of screenshots can help explain a claim, provided you identify it as material supplied by you. Show the relevant app version and action where practical. Explain whether the app was open, the device was unlocked, an account was signed in or a confirmation was required. A successful demonstration under those conditions does not establish unrestricted operation elsewhere.

Use non-sensitive sample content and redact personal messages, documents, account identifiers and unrelated notifications. Never include passwords, API keys, authentication tokens, signing credentials or access to a private account. Do not request that reviewers bypass permissions or weaken device protections. If the workflow depends on data you cannot safely share, describe the dependency and provide a harmless reproduction where possible. These are recommendations for preparing evidence; they are not a claim that this site has run the workflow, received a file or completed a security review.

• Read the privacy guide

Address conflicting documentation explicitly

Craft illustrates why a submission should include conflicting sources rather than select the most favorable one. Its Siri article describes querying document content, creating documents, appending text and managing tasks with OS 27. It limits shared content for the fifty most recently edited documents to their first level, describes other documents through titles and details, and requires a schedule or deadline for tasks. It also excludes rewriting, rearranging or deleting existing document content and identifies Mac support as an Apple beta.

Those vendor statements must be considered alongside Apple's November 3 timeline for the new third-party Developer Preview. The available evidence does not resolve whether the documents describe different API layers or release paths. A suitable statement is: Craft documents updated Siri capabilities; new Siri AI public integration status is not independently confirmed. Provide the corresponding public app version, release notes and documented API scope to help resolve the gap. Similarly, Spotify's reference to Siri with Apple Intelligence does not alone establish release through the new preview. Neither conflict supports declaring all third-party integrations unavailable.

Understand review, corrections and publication limits

Prepare the final package so each claim can be traced to a source: app identity and release history, platform requirements, exact actions, availability conditions, relevant permissions and any reproducible user-supplied evidence. Separate what official documentation states from what you observed and what remains an interpretation. For an existing entry, include its directory URL and identify the sentence, status or release detail you propose to correct. Explain whether the replacement evidence narrows a claim, adds a platform or supports a newer public version.

Evidence review does not guarantee a listing, a particular label, publication timing or a prominent position. This submission route does not offer paid ranking, and supplying more promotional material does not compensate for missing release evidence. A documented shortcut may justify a limited entry while a broader Siri AI claim remains unresolved. The documentation snapshot for this page was reviewed on November 6, 2026; later submissions should supply dated sources for changed claims. Keep the original uncertainty visible until matching public evidence supports a correction, rather than silently upgrading an announcement to verified availability.