Asset Requirements and Store Listing Optimization

Publishing an app successfully across major platforms like Google Play, the Apple App Store, and the Microsoft Store is far more than a technical exercise in uploading a binary. The store listing itself is a product — one that must be carefully engineered with the right graphical assets, compelling descriptive copy, strategically chosen keywords, and legally compliant privacy documentation. Each element of the listing influences whether a user discovers your app in the first place, decides to tap the install button, and whether the store review team approves the submission without rejection. This topic covers in depth the four pillars of a high-quality store listing: icon and branding standards, screenshots and preview videos, App Store Optimization (ASO), and privacy policy requirements.

App Icons and Branding Standards

The app icon is the single most visible element of your brand on any app store or device home screen. It must simultaneously communicate the app's purpose at a glance, remain legible when scaled down to small sizes, and stand out visually in a crowded grid of competing apps. Each major platform imposes specific technical requirements that must be met precisely or the submission will be rejected outright.

Google Play requires a high-resolution icon delivered as a PNG file at exactly 512×512 pixels. This "hi-res icon" is what appears in the Play Store listing itself, in search results, and in promotional placements. Google Play applies its own adaptive icon masking on devices running Android 8.0 (Oreo) and later, so your icon artwork must be designed so that the focal point of the design sits within a "safe zone" of roughly the inner 66% of the canvas — elements near the edges may be cropped by the circular, squircle, or rounded-square masks applied by different device manufacturers. Separately, app developers must also supply adaptive icon layers (foreground and background) within the APK or AAB itself for device display, but the store listing requires that 512×512 PNG as a standalone marketing asset.

Apple App Store requires a single icon at 1024×1024 pixels in PNG format with no transparency and no pre-applied rounded corners. This is a critical point: iOS applies the rounded corner mask automatically and uniformly across all icons on the home screen and within the store. If you supply an icon with rounded corners already baked in, the system's mask will create an awkward double-rounding effect at the corners. The icon must also have no alpha channel — a flat, fully opaque background is required. Xcode compiles the icon into the app binary from an asset catalog containing multiple sizes (e.g., 60×60 @2x for iPhone, 76×76 @2x for iPad), but the App Store Connect submission requires the 1024×1024 marketing icon. It should be noted that Apple's guidelines prohibit icons that closely resemble Apple's own system app icons or that use screenshots of real device hardware.

Microsoft Store operates across a wider variety of display contexts — desktop applications, Xbox, HoloLens, and more — so it requires logos at multiple sizes. The two most commonly referenced sizes for standard UWP and desktop app submissions are 300×300 pixels (used in the store listing page and large tile contexts) and 50×50 pixels (used in search results and list views). Additional sizes such as 150×150 and 71×71 may be required depending on the app type. All assets should be provided as PNG files, and Microsoft's guidance recommends designing on a transparent background so that the store can apply its own theming appropriately in light and dark UI modes.

Beyond raw technical specs, effective icon design follows several well-established principles:

• Use a single, recognizable symbol or letterform. Complexity does not scale down. An icon that looks detailed at 512×512 pixels often becomes an illegible blur at 29×29 pixels. Test your design at the smallest size it will appear on device, not just the largest.
• Avoid placing text in icons. At small sizes, any text becomes unreadable. If a letter or monogram is the primary design element, that is fine — but full words are strongly discouraged by Apple's Human Interface Guidelines and Google's Material Design guidelines alike.
• Use color intentionally. High contrast between the foreground element and the background color improves legibility. A distinctive color palette also helps users re-locate your icon on a crowded home screen.
• Maintain brand consistency. The icon should share visual language — color, shape vocabulary, typography style — with the in-app experience and any marketing materials. Inconsistency between the icon and the app interior erodes user trust.

The table below summarizes the primary icon specifications for each major platform:

Screenshots and App Previews

After the icon draws a user to your listing, screenshots and preview videos are the primary visual content that converts a curious browser into an installer. They are among the most impactful elements of the store listing and are frequently underinvested in by developers who focus almost entirely on the app itself.

Device size requirements vary by platform and change periodically as new hardware is released. For Apple, screenshots must be provided for specific device "families" — for example, the App Store currently requires screenshots for at least one iPhone size (commonly the 6.9-inch display class used by the iPhone 16 Pro Max series) and optionally for iPad if the app supports iPadOS. Google Play allows a more flexible approach: you upload screenshots and select which device types they apply to, though providing phone, 7-inch tablet, and 10-inch tablet screenshots is recommended for broad coverage. Microsoft Store similarly requires screenshots that reflect the Windows desktop experience, with additional sets for Xbox if applicable. It is important to check the current specifications in each platform's developer documentation before a release cycle, as required dimensions change when new flagship device screen sizes are introduced.

Screenshots should be designed, not merely captured. The most effective listings treat each screenshot as a mini-advertisement:

• Lead with the value proposition. The first one or two screenshots are the most important because they are visible without scrolling or swiping. They should answer the question "What does this app do for me?" immediately. Use brief, benefit-driven captions overlaid on the screenshot rather than relying on the user to infer meaning from a raw UI capture.
• Show real, populated UI. A screenshot of a to-do app showing an empty list communicates nothing. Show the app in a realistic, data-rich state that demonstrates the experience at its most compelling.
• Use a consistent visual style across all screenshots. A coherent color palette, consistent device frame treatment, and uniform caption typography across all screenshots creates a polished, professional impression.
• Highlight key features sequentially. Use the screenshot sequence to tell a story — onboarding, core functionality, secondary features, and any unique differentiators.

App preview videos (called "Preview" on the App Store and "Feature Graphic" animations or preview videos on Google Play) are short — typically 15 to 30 seconds on Apple and up to 30 seconds on Google Play. Key principles for effective previews include:

• Show the app in action, not a brand film. Store policies on both Apple and Google explicitly require that preview videos demonstrate actual in-app functionality. Conceptual lifestyle footage or animated advertising that does not reflect the real app interface can result in rejection.
• Assume the sound is off. A large percentage of users view app preview videos without audio, especially when browsing in public or at work. Visual storytelling and on-screen text captions should convey the message entirely without relying on a voiceover.
• Front-load the compelling content. Many users will not watch to the end. The most exciting, differentiating feature should appear in the first five seconds.

Critically, all screenshots and videos must accurately represent the current version of the app. Both Apple and Google prohibit misleading store assets — showing features that do not exist, UI that has been redesigned and removed, or performance that the app cannot actually deliver. Beyond the policy risk, misleading screenshots damage user trust: a user who installs based on expectations set by inaccurate screenshots will leave a negative review when the experience does not match.

App Store Optimization (ASO) Fundamentals

App Store Optimization is the discipline of improving an app's visibility in store search results and its conversion rate (the percentage of listing visitors who install). It is the mobile equivalent of Search Engine Optimization (SEO) for websites and deserves the same level of ongoing research and iteration.

Title and subtitle are the highest-weighted textual fields. Both Apple's App Store and Google Play's search algorithms assign significantly more ranking weight to the app title than to any other metadata field. On Apple, the title can be up to 30 characters and the subtitle (displayed below the title in search results) is also up to 30 characters. On Google Play, the title is up to 30 characters and a "short description" of up to 80 characters appears in some listing views. Including a primary target keyword naturally in the app title has a direct and measurable impact on ranking for that term. For example, an app named simply "Mira" will rank poorly for the term "expense tracker" compared to one named "Mira – Expense Tracker", all else being equal. However, keyword stuffing — filling the title with comma-separated terms that read unnaturally — violates both Apple's and Google's metadata guidelines and can result in rejection or suppression.

Keyword research is the foundation of effective ASO. The goal is to identify terms that have a high enough search volume to be worth targeting but low enough competition that a new or mid-tier app can realistically rank on the first page of results. Tools such as AppFollow, Sensor Tower, AppTweak, and MobileAction provide search volume estimates and competitive difficulty scores for keywords on both major platforms. A practical research process looks like this:

• Begin with a broad brainstorm of terms your target users would type to find your app.
• Expand that list using competitor analysis — examine the titles, subtitles, and visible descriptions of the top-ranking apps in your category.
• Score each term for volume and difficulty using an ASO tool.
• Prioritize terms with the best volume-to-difficulty ratio that are also highly relevant to your app.
• Place the highest-priority terms in the title and subtitle; use remaining slots in Apple's hidden keyword field (100 characters, not visible to users) for secondary terms.
• Avoid repeating terms across fields — Apple's algorithm does not reward repetition and the space is wasted.

Localized listings represent one of the highest-ROI levers available to app publishers. Both App Store Connect and Google Play Console allow you to submit entirely different metadata — title, subtitle/short description, full description, keywords, screenshots, and preview videos — for each locale you support. An app optimized only in English will have no presence in search results conducted in French, Japanese, Portuguese, or German, regardless of whether the app itself has been translated. Localization is not merely translation; effective localized ASO also adapts the keyword strategy to reflect how users in that country search, which may differ substantially from a direct translation of English terms.

User ratings and review volume function as strong quality signals in both platforms' ranking algorithms. An app with thousands of four- and five-star ratings will outrank a competing app with similar keyword optimization but few or poor reviews. This means that encouraging satisfied users to leave ratings — through in-app rating prompts at contextually appropriate moments (e.g., after a user completes a successful action, not at first launch) — is a legitimate and important part of an ASO strategy. Apple provides the SKStoreReviewRequestAPI for requesting ratings in-app without sending users out of the app experience. Google Play similarly provides an in-app review API. Both platforms limit how frequently the prompt may appear to avoid harassing users.

The table below summarizes the key metadata fields and their character limits across the two dominant mobile platforms:

Note the important asymmetry: Apple does not index the long description for keyword ranking, while Google Play does. This means that on Google Play, incorporating relevant keywords naturally and repeatedly throughout the long description provides measurable ranking benefit, whereas on the App Store, the long description serves purely as a user-facing conversion tool.

Privacy Policies and Legal Requirements

A privacy policy is not optional for any app submitted to a major store. Both Apple and Google have made a valid, accessible, and comprehensive privacy policy a hard requirement for all app submissions, regardless of whether the app collects any user data at all. Microsoft Store similarly requires one for apps that collect personal information. The consequences of non-compliance range from submission rejection to removal of a previously published app from the store.

What a privacy policy must cover is defined both by platform policy and by applicable law. At minimum, a compliant privacy policy must clearly describe:

• What data is collected: This includes all categories of personally identifiable information (PII) such as name, email address, and phone number, as well as non-PII data categories that are still subject to regulation, such as device identifiers, IP addresses, location data, usage analytics, and any data collected from third-party SDKs integrated into the app (advertising networks, analytics services, crash reporters, etc.).
• How data is used: Each category of collected data should be mapped to a stated purpose — for example, email addresses collected to send transactional notifications, analytics data used to improve app performance, advertising identifiers used for targeted advertising.
• With whom data is shared: Any third parties who receive user data — payment processors, analytics providers, advertising networks, cloud infrastructure providers — must be identified and the basis for the data sharing explained.
• How long data is retained and how users can request deletion.
• Contact information for the data controller or privacy team so users can submit inquiries.

Accessibility of the privacy policy is itself a requirement. The URL of the privacy policy must be entered in the app store listing (in App Store Connect under "App Information" and in the Google Play Console under "Store Listing"). Beyond the store, the privacy policy must also be accessible from within the app itself — typically linked from the settings or account screens. A privacy policy hosted on a page that requires a login to access does not satisfy this requirement; it must be publicly accessible without authentication.

GDPR compliance applies to any app that is made available to users in the European Economic Area, regardless of where the developer or company is based. The General Data Protection Regulation imposes obligations that go substantially beyond a published privacy policy:

• Lawful basis for processing: Each data processing activity must have a documented legal basis — most commonly informed consent, contractual necessity, legitimate interests, or legal obligation. For most consumer apps, consent is the primary basis, which means users must actively opt in to data collection, not merely be informed of it after the fact.
• Granular consent mechanisms: A single "I agree to the Privacy Policy" checkbox is generally insufficient under GDPR when multiple distinct processing purposes are involved. Users should be able to consent to analytics separately from advertising, for example.
• Data subject rights: The app must provide mechanisms — accessible to the user without undue burden — to exercise rights including the right to access (receiving a copy of their data), the right to rectification (correcting inaccurate data), the right to erasure ("right to be forgotten"), and the right to data portability. In practice, this means providing an in-app request form or a clearly explained email process for handling these requests within the mandated 30-day response window.
• Data Protection Officer (DPO): Certain categories of organizations processing data at scale are required to appoint a DPO and provide their contact details in the privacy policy.

Similar obligations exist under the California Consumer Privacy Act (CCPA) for apps with users in California, Brazil's Lei Geral de Proteção de Dados (LGPD), and a growing number of other national and regional frameworks. A privacy policy drafted with GDPR compliance in mind will often satisfy the core requirements of these other regimes, though local legal review is always advisable before launch in new markets.

Privacy policy rejections are among the most frequent causes of initial App Store submission rejection. Common failure modes include: providing no privacy policy URL at all; linking to a URL that returns a 404 error or a placeholder page; providing a generic, unmodified template that does not reflect the app's actual data practices; and failing to mention third-party SDKs that collect data (such as Firebase, Facebook SDK, or AdMob) even when the developer did not write that data collection code themselves. Each SDK integrated into the app that collects or transmits user data must be disclosed in the privacy policy as if the developer themselves were performing that collection — because legally, they are responsible for it.

A practical approach for developers is to audit every SDK and third-party service integrated into the app before drafting the privacy policy, cataloguing exactly what data each one collects and to where it is transmitted. Apple's App Store Connect now requires a "Privacy Nutrition Label" — a structured declaration of data types collected, their purposes, and whether they are linked to the user's identity — which must be consistent with the written privacy policy. Any discrepancy between the nutrition label declarations and the actual privacy policy text can trigger a review team inquiry.

Building a working app is only half the job of shipping it. Before anything reaches a user, both the Apple App Store and Google Play require a package of graphical and textual assets: an icon in specific sizes, screenshots sized for multiple devices, an optional preview video, a title and subtitle, a short and long description, keyword or category metadata, a content rating, and a link to a privacy policy. These assets are not decoration — they are the interface between your product and a person deciding, in a few seconds, whether to install it.

This topic treats the store listing as a designed interface in its own right. The same HCI principles you have applied to screens apply here: visual consistency and branding in the icon, legibility and information hierarchy in screenshot captions, honest and accessible descriptions, and clear disclosure of what data you collect. App Store Optimization (ASO) is the practice of tuning the searchable and persuasive parts of that listing so the right users find your app and choose to install it.

The three videos below approach ASO from different angles: a conceptual introduction, a strategy overview from a major mobile marketing company, and a hands-on walkthrough using an ASO tool. As you watch, note the recurring vocabulary — keywords, conversion rate, impressions, installs — and pay attention to the distinction between the metadata fields that are indexed for search and the visual assets that drive conversion. Also notice where platform differences between Apple and Google are mentioned, since those differences will shape how you prepare your own submission assets.

App Masters · 5:59 · 12,049 views · 5y ago · captions — Watch on YouTube

About this video

This is the first part of a six-part series that defines App Store Optimization from the ground up, explaining what ASO means and why it exists as a discipline. Expect an overview of the basic components of a store listing that can be optimized — such as the title, keywords, description, and visual assets — and how they relate to being discovered in store search and browse. It is pitched at someone encountering the term for the first time.

Why this video

It is the right starting point because it establishes the vocabulary and mental model of ASO before you dive into tactics, which directly supports the ASO Fundamentals subtopic. App Masters is a long-running channel focused specifically on app marketing, and the short runtime keeps the introduction focused.

AppsFlyer · 7:23 · 42,456 views · 3y ago · captions — Watch on YouTube

About this video

AppsFlyer presents five concrete strategies for improving an app's ranking and install rate, framed as a free alternative to paid user acquisition. Based on its framing, the video should cover practices such as keyword research and placement in metadata, optimizing the icon and screenshots for conversion, using ratings and reviews, and localizing the listing. The content is positioned as current to 2024, so store-specific details should be reasonably up to date.

Why this video

AppsFlyer is an established mobile measurement and marketing analytics company, so the strategies come from a producer that works with store data at scale. It connects the icon and screenshot subtopics to measurable outcomes like impressions and conversion, rather than treating them as purely aesthetic choices.

ASO PRO by ASOMobile · 13:24 · 1,198 views · 1y ago · captions — Watch on YouTube

About this video

A step-by-step beginner tutorial that walks through optimizing an app listing in practice, using the ASOMobile toolset. Expect demonstrations of keyword selection and tracking, how metadata fields are filled in, and how optimization results are monitored over time. Because it is produced by a tool vendor, some segments will showcase that specific product.

Why this video

This video turns the concepts from the other two into an actual workflow, which is the closest match to the task of preparing your own listing. Watch it for the process — research, draft metadata, publish, measure — and treat the specific tool as one option among many.

Together these videos build toward the module outcomes by focusing on the listing side of publication. The introductory ASO video and the strategies video give you the terminology and criteria needed to evaluate your own project's icon, screenshots, title, and description against what stores reward and require, supporting MO2's readiness assessment. The tutorial walkthrough models the practical steps of producing and refining metadata and visual assets, which maps directly to MO3's requirement that you prepare submission-ready assets. All three reinforce MO1 by repeatedly referencing the metadata fields, asset specifications, and platform differences that define the Apple and Google submission processes; you should supplement them with the official Apple and Google guidelines for exact size specifications, content rating questionnaires, and privacy policy and data-disclosure requirements, which these videos touch on only in passing.

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.