Should I use MobileApplication or WebApplication for a cross-platform product with both a mobile app and a web app?

Use both. Mark up the web product with @type WebApplication on the web app's canonical page, and mark up the mobile product with MobileApplication on the app marketing page. Cross-link the two with sameAs or a parent SoftwareApplication graph. AI engines treat the two surfaces as distinct citation targets — a query like "free productivity web app" should not match the mobile entry, and vice versa.

How do I mark up a cross-platform iOS + Android app with one shared rating?

Ship two MobileApplication entries inside a JSON-LD @graph, one per operatingSystem. If the rating is genuinely a single cross-platform aggregate (rare in practice — App Store and Play Store usually publish different ratings), set the same aggregateRating on both. More commonly, set the platform-specific rating on each variant. Either way, do not collapse the two variants into a single entry with operatingSystem omitted; the variants are how AI engines satisfy platform-specific queries.

Do App Store and Play Store data feed AI engines directly?

Generally no. App Store and Play Store catalog pages are gated by robots.txt and authenticated rendering paths that public-web AI crawlers (GPTBot, PerplexityBot, ClaudeBot) do not reliably resolve. AI engines lean on publisher-owned marketing pages with MobileApplication markup as the canonical grounding source. Some platforms have direct catalog access through commercial agreements, but treating publisher markup as the source of truth is the durable pattern.

What's the difference between MobileApplication and SoftwareApplication for AI citation purposes?

MobileApplication is a SoftwareApplication subtype. AI engines that filter on @type=MobileApplication get only mobile entries; engines that query the parent type get all software. For mobile-distinct queries ("best iOS app", "Android only"), the subtype materially improves match precision. For general software queries ("best note-taking app overall"), either type is acceptable. Default to MobileApplication for any product whose primary distribution is the App Store and Play Store.

How often should I update aggregateRating numbers?

Refresh on every meaningful change — major release, rating-bucket shift, or quarterly at minimum. AI engines weight freshness for citation-eligibility checks; an aggregateRating timestamped 18 months ago can be discounted or skipped. Automate the refresh from the App Store Connect and Play Console APIs into the JSON-LD payload at build time so the markup never goes stale.

Will MobileApplication markup help with traditional Google search rankings?

Indirectly. Google's standard rich-results treatment for software apps surfaces the rating snippet on classic SERPs when markup is valid, which improves CTR (Google Search Central, 2026 — https://developers.google.com/search/docs/appearance/structured-data/software-app). The larger value in 2026 is AI-answer citation: AI Overviews, ChatGPT, Perplexity, and Gemini all increasingly cite MobileApplication-grounded pages for app queries, and that citation surface is growing alongside classic SERP traffic for app-related intents.

MobileApplication Schema: JSON-LD Guide for AI Citations

MobileApplication is the schema.org subtype derived from SoftwareApplication that AI engines — Google AI Overviews, ChatGPT, Perplexity, and Gemini — parse to ground app-related answers. Correct markup of operatingSystem, applicationCategory, offers (with Price=0 for free apps), and aggregateRating drives citation eligibility for 'best app for X', download, rating, and platform-specific queries.

TL;DR

MobileApplication extends SoftwareApplication with mobile-specific fields: operatingSystem, applicationCategory, carrierRequirements, fileSize.
For cross-platform apps, ship two variants — one iOS, one Android — with operatingSystem set per variant and a shared aggregateRating where appropriate.
offers (with Price=0 for free apps), price, and aggregateRating are the fields AI engines parse to qualify a citation.
AI Overviews, ChatGPT browse, and Perplexity all surface MobileApplication-grounded answers for 'best app', download, and rating queries.

Definition

MobileApplication is a schema.org type that extends SoftwareApplication to describe applications distributed through mobile-specific channels — primarily Apple's App Store and Google Play. It inherits the SoftwareApplication property set (name, applicationCategory, applicationSubCategory, offers, aggregateRating, screenshot, featureList) and adds mobile-only fields, most notably carrierRequirements (a free-text constraint such as "Verizon" or "iOS only") that desktop or web software does not need (schema.org, 2026 — https://schema.org/MobileApplication).

In practice, app publishers and ASO teams use MobileApplication to mark up the canonical app page — the URL on the publisher's marketing site that links out to App Store and Play Store listings. That page becomes the schema-grounded source AI engines consult when they cannot scrape the closed App Store or Play Store catalogs directly. The MobileApplication graph declares which platforms the app runs on (operatingSystem: "iOS 15+", "Android 10+"), what category bucket it competes in (applicationCategory: "ProductivityApplication", "GameApplication"), what it costs (offers.price: "0", offers.priceCurrency: "USD"), and how users have rated it (aggregateRating.ratingValue, aggregateRating.reviewCount).

For AI search optimization, MobileApplication is the structured contract that lets answer engines confidently cite "the free Android productivity app rated 4.7 by 12,000 users" instead of paraphrasing a marketing page they only half-trust. Without it, AI engines fall back to fuzzy text extraction from app marketing pages, and citation eligibility drops sharply — particularly for download, rating, OS, and install-size queries that demand a specific datum.

Why this matters

App-related queries make up a large share of mobile-context searches — "best meditation app for Android", "free PDF editor iOS", "what's the rating of Notion app" — and AI answer engines like Google AI Overviews, ChatGPT browse, Perplexity, and Gemini all answer these queries with citations, not raw rankings. The catch: App Store and Google Play product pages are gated behind authenticated platforms, robots.txt restrictions, and rendering paths that public-web crawlers cannot reliably resolve. AI engines therefore lean on publisher-owned web pages — the marketing site, blog, or landing page — for grounding (Google Search Central, 2026 — https://developers.google.com/search/docs/appearance/structured-data/software-app).

When that fallback page lacks structured data, the AI engine has three uncomfortable options: paraphrase the marketing copy (low confidence, low citation rate), skip the result (zero visibility), or surface a third-party listing such as G2, Product Hunt, or a "best apps" roundup (the publisher loses the citation to a competitor or aggregator). MobileApplication markup converts the publisher's own page into the high-confidence grounding source: the app's name, OS variants, price, rating, screenshots, and feature list are unambiguous, machine-readable, and trivially extractable.

There is also a category-discovery angle. AI engines that surface "best app for X" lists rely on extractable applicationCategory and aggregateRating fields to populate the candidate set. Publishers without MobileApplication markup are typically invisible to that selection step regardless of their actual quality or marketing spend. The cost of skipping the spec is measured not only in lost direct citations but in lost inclusion in comparative answers, where AI engines select 3-5 apps from structured candidates rather than scanning unstructured pages. For any app category where the buyer's first move is an AI query — productivity, fitness, finance, education — MobileApplication markup is the difference between being a candidate and being invisible.

How it works

AI crawlers parse MobileApplication graphs in roughly five stages. First, the crawler fetches the publisher's app page and extracts the JSON-LD payload from the