How Can I Get Featured on the App Store?

Apple features roughly 25 apps per week across its editorial collections. Google Play features a similar number. Across both stores combined, that is somewhere around 2,600 featured slots per year, against millions of apps competing for them. The question teams invariably ask, "how do we get featured?", is the right question, but the answer they expect tends to focus on pitching, timing, and app store listings. The real answer goes much further back than that.

The apps that get featured earn that position through decisions made long before they ever contact an editorial team.

Featuring decisions are, in large part, made before you write a line of code. The quality of your onboarding, the craft of your interactions, the compliance history of your account, the platform you chose to launch on first, all of these carry weight with editorial teams. By the time you fill in a submission form, most of what will determine the outcome has already happened.

This article covers how featuring works on both iOS and Android, what editorial teams actually evaluate, and how to build a product that stands a genuine chance. Some of it comes from published editorial guidance. A good deal of it comes from things we have learned building products that went through app store review, sometimes smoothly, sometimes not.

How App Store Featuring Actually Works

Both Apple and Google run editorial teams whose job is to find apps worth recommending to their users. The App Store editorial team, based primarily in Cupertino, curates collections like App of the Day, Game of the Day, and themed roundups tied to seasons, events, and cultural moments. Google Play's editorial team does something similar, with featured slots on the Today tab and curated collections tied to categories and themes.

Neither platform operates a simple submission queue where apps are assessed in order and either approved or declined. Featuring is discretionary. Editorial teams browse, test, and respond to pitches, but they also surface apps independently based on what they find in the store. An app can be featured without ever formally requesting it, and an app can request featuring multiple times without success.

Who Makes the Decision

On both platforms, editors are essentially journalists who cover software. They are looking for apps that fit a narrative, something worth writing about, recommending to a specific audience, or tying to a moment in time. A meditation app featured in January makes sense. A travel app featured in late spring, ahead of summer bookings, makes sense. Pitching against the editorial calendar matters.

What Featuring Is Not

Featuring is not paid placement and cannot be bought. It is not guaranteed by a good review history, though that helps. It is not something you get once and hold permanently. Featured apps rotate, and the same product can be featured multiple times or dropped after a single appearance. The goal is to build something editors want to return to.

What Apple's Editorial Team Looks For

Apple publishes editorial guidelines that give developers a clear sense of what its team values. The core criteria cover design quality, functionality, and adherence to Apple's Human Interface Guidelines. Beyond those, the editorial team looks for apps that use Apple-native features, things like widgets, Live Activities, SharePlay, or Shortcuts integration. An app that has been built specifically for the Apple ecosystem, rather than ported across from Android, signals the kind of commitment Apple wants to reward.

Localisation matters more than most developers realise. Apple's editorial team is global and actively looks for apps that have been properly adapted for different regions, not just translated. If your app serves English-speaking markets only, your featuring prospects are limited to those regions. A well-localised product can appear across multiple regional editorial collections.

Design and Craft Standards

Apple's editors respond to visual and interaction quality. The app should feel at home on iOS, not like a web page wrapped in a native shell, and not like an Android product that has been recompiled for iPhone. Typography, spacing, animation timing, and haptic feedback all contribute to the overall impression. Apple uses the phrase "crafted with care" in its editorial descriptions, and that is a fair summary of what they are looking for.

Timing and Relevance

Apps tied to events, seasons, or cultural moments have a higher chance of appearing in themed collections. If your product is relevant to a specific time of year, pitch it six to eight weeks ahead of that window. Apple's editorial calendar is planned well in advance and late submissions tend to miss their moment.

What Google Play's Editorial Team Looks For

Google Play's editorial approach shares some characteristics with Apple's but differs in a few practical ways. Google places more weight on Android-specific implementation, apps that use Material You, adaptive icons, large screen layouts for tablet and Chromebook, and features tied to Google services like Assistant or Maps integration. An app that takes advantage of the full Android hardware and software surface is more likely to attract editorial attention than one that treats Android as a secondary platform.

Google also weighs store performance data more visibly than Apple. Ratings, review volume, crash rates, and ANR (Application Not Responding) rates are all accessible to Google's editorial team through Play Console. A product with strong technical performance metrics alongside a good user rating starts the conversation from a better position.

The Role of Play Console

Google makes it relatively easy to signal interest in featuring through Play Console. Developers can opt in to promotional opportunities and, in some markets, receive direct outreach from Google's partnerships team if their app meets certain quality thresholds. Keeping your store listing accurate, your screenshots current, and your rating above 4.0 keeps the door open to those conversations.

Reach Across Form Factors

Google has pushed hard on large screen support in recent years. An Android app that works well on a tablet or foldable device gets a meaningful advantage in editorial consideration, because Google actively promotes apps that demonstrate the capabilities of its broader hardware ecosystem. Ignoring tablets effectively removes a category of featuring opportunities from the table.

Why Featuring Decisions Are Made Before You Write a Line of Code

This is the part that tends to catch teams off guard. By the time an app is submitted for review, let alone considered for featuring, the decisions that most influence its chances are already fixed. Which platform did you launch on? What compliance framework did you build around? How much of the native design language did you adopt? These are questions for the planning stage, answered months before launch.

We saw this directly on a bootstrapped social football platform, where the client originally wanted to launch on both iOS and Android simultaneously. As the project progressed and the feature list kept expanding, driven partly by one of the client's own team members who was directing design changes without factoring in development cost, the budget became critically strained. Midway through the build, we made the decision to pause Android development entirely and reallocate everything remaining to the iOS product.

The client launched iOS-only, which addressed roughly half the potential market. More significantly, the target audience for a grassroots football platform skews younger, and that demographic leans towards Android. Day-one adoption was roughly half what it would have been had both platforms launched together. The client had to abandon their planned subscription model because the user base was too small to sustain it, and they introduced advertising to compensate, something they had explicitly said they would not do. The platform choice, made under budget pressure midway through development, shaped the product's entire post-launch trajectory.

Choosing a platform under budget pressure is a strategic call, driven by economics. It is a market decision with lasting consequences.

From a featuring perspective, launching iOS-only on a product with a predominantly Android audience meant building the more polished version of the product for the smaller portion of the market. That is not the right setup for a strong featuring push on either platform.

How Platform Choice Affects Your Chances Before Launch

If you are building for iOS, the path to featuring runs through Apple's design standards. Your app needs to feel native, use Apple's system fonts and components where appropriate, and ideally integrate at least one Apple-specific feature that demonstrates a genuine reason for being on that platform. Half-hearted iOS ports rarely get featured.

If you are building for Android, the calculus is different. Google rewards breadth of device support and integration with the Android ecosystem. An app that works well across phones, tablets, and foldables, and that uses Material You theming correctly, signals the kind of investment Google wants to promote.

When Budget Forces a Choice

The football platform situation was not unusual. Budget constraints force platform prioritisation on a large proportion of early-stage products. The decision about which platform to prioritise first should be made by looking at where your actual users are, not by defaulting to iOS because it is perceived as more prestigious. If your audience skews Android, launching iOS-only and then attempting a featuring push is working against yourself from the start.

The Dual-Platform Advantage

Apps available on both platforms have access to featuring opportunities on both stores, which effectively doubles the exposure available. More practically, a strong launch on both platforms generates the kind of download velocity and rating volume that editorial teams notice. A product sitting at 4.5 stars across 2,000 reviews tells a different story to one with 4.5 stars across 200.

Onboarding as an Editorial Signal

Editorial teams test apps. That means the first thing an editor does when they open your product is experience your onboarding. If that experience is confusing, slow, or asks for more than it gives, the evaluation ends there. Think with Google data suggests 21% of users will give up on an app if they cannot make sense of it immediately. An editor is not a patient user.

Good onboarding communicates the core value of the product within the first thirty seconds and gets the user to a meaningful moment as quickly as possible. On a travel booking product we worked on, aimed at younger adults doing group trips, the most effective single feature was a step inside the booking flow that prompted each traveller in a group to download the app for communication and to submit passport details. One person booking a trip for ten people generated nine additional users, each of whom then went through their own onboarding. The viral mechanics and the onboarding were not separate, one fed the other.

Show your app's core value within the first three screens. If an editor cannot understand why they would use your product before they reach screen four, you have lost them.

The broader principle is that onboarding sets expectations. An editor who opens your app and finds a clear, well-paced introduction to a product that does what its store listing says it does will form a very different impression than one who encounters a confusing flow or a mismatch between the marketing and the actual experience. Amplitude's 2025 Product Benchmark Report, covering over 2,600 companies, found that 69% of products with strong early activation also performed well on three-month retention. Editors are experienced enough to read early activation as a proxy for long-term quality.

Interaction Quality and the Craft Standard

Featuring editors, particularly at Apple, are designers and product people. They notice things that ordinary users might not consciously register, the timing on a transition, whether a button feels right when pressed, whether the typography has been set with care. These details are not decorative. They communicate how much attention went into the product.

The distinction we draw between design that looks good and design that feels right is relevant here. Colour and micro-interactions earn their place when they are tied to how the product should make someone feel, not just how it should look. An app that uses haptic feedback to confirm a payment, or that uses a subtle animation to signal a completed task, is doing something that a plain, static interface cannot. That level of considered interaction is what Apple describes as craftsmanship, and it is what separates a featured app from a functional one.

What Gets Noticed

• Transitions and animations that feel proportionate to the action they accompany
• Typography that is legible and consistent across all screen sizes
• Empty states that are useful rather than blank
• Loading states that communicate progress honestly
• Error messages that are written for humans, not for systems

The Gap Between Good Enough and Featured

Apps that reach the store are generally good enough in the functional sense, they do what they say, they do not crash constantly, they pass review. The gap between that and a product that gets featured is almost entirely about the layer of craft on top of the functionality. That layer cannot be added at the end of a project. It requires time, iteration, and the kind of attention that is hard to prioritise when a deadline is approaching.

Run your app through Apple's Human Interface Guidelines or Google's Material Design principles before submission. If you cannot explain why each design decision fits those standards, an editor will notice the inconsistency before you do.

Compliance, Safety and Why Rejections Kill Featuring Prospects

An app with a rejection history is almost never featured. The review record is visible to editorial teams, and a product that has been sent back multiple times for compliance failures signals that the development process prioritised speed over quality. One serious rejection, for privacy violations, unsafe content, or financial compliance issues, can take months to recover from in terms of editorial consideration.

We learned this through direct experience on a peer-to-peer currency exchange product. The core mechanism allowed users to exchange leftover foreign currency with other travellers at interbank rates, avoiding commission. We built the transfer system well, but we had not factored in anti-money laundering requirements. Apple flagged the product as a potential vehicle for money laundering because there were no limits on the number or value of transfers between two parties. We had to go back and retrofit several layers of compliance: more stringent KYC checks, enhanced transfer security measures, and hard limits on transfers between any two users.

On a separate project, an anonymous messaging app, we identified a tension between GDPR, which gives users the right to have their data removed, and the legal requirement to retain data in case of criminal investigation. We implemented a data retention policy of around six months, so that even if a user deleted their account, the data would remain available if police needed to open an investigation. We also added in-product reporting features so users could escalate concerns about inappropriate messages to the client's admin team. Neither of these was optional. Both were requirements that had to be designed in from the start, not retrofitted after review.

Map your compliance requirements before the first design mockup. Financial products, messaging apps, health products, and anything involving minors all carry specific obligations that will surface in review if they have not been addressed in the build.

How to Submit for Featuring Consideration

Both Apple and Google provide formal routes for requesting editorial consideration. Apple's process runs through its developer relations portal, where teams can submit their app for review ahead of a planned launch or update. Google's process runs through Play Console, where developers can opt in to promotional programmes and, in some territories, receive direct outreach from Google's partnerships team.

How to Approach the Apple Submission

1. Request access to Apple's developer relations team through the App Store Connect portal at least six weeks before your intended launch or update date.
2. Prepare a short brief covering what the app does, who it is for, what makes it distinctive, and any Apple-native features it uses.
3. If your launch aligns with a seasonal or cultural moment, name that alignment explicitly.
4. Include a promo code so editors can test the full product without creating an account or making a purchase.
5. Provide high-quality screenshots and, if possible, a preview video that demonstrates the app in use rather than just showing static screens.

How to Approach the Google Play Submission

In Play Console, navigate to the Growth section and look for promotional opportunities. Keeping your store listing complete, including a full description, feature graphic, and current screenshots across device sizes, is a baseline requirement. Google also responds well to apps that have been rated consistently above 4.0 and that demonstrate low crash rates in the Android Vitals section of Play Console. Addressing technical performance issues before submitting for featuring consideration is worthwhile.

What Happens After You Submit

Most submissions receive no response. That is the default. Editorial teams receive far more submissions than they can assess in any given window, and the absence of a reply does not mean the app has been ruled out permanently. Teams that submit consistently, update their apps regularly, and maintain strong ratings over time give themselves repeated opportunities to be noticed.

When featuring does happen, you will typically see it in your analytics before you see any formal notification. A sudden spike in downloads, often concentrated in a specific region or country, is usually the first sign. Apple occasionally sends a notification through App Store Connect, but this is not guaranteed. Google may reach out through Play Console or via a developer relations contact if one has been established.

What to Do While You Wait

The period between submission and any editorial response is not passive. Respond to user reviews promptly, particularly negative ones. Release updates that address common complaints. Improve your store listing based on what users say they expected versus what they found. An editorial team that looks at your app three weeks after submission should find a slightly better product than the one you submitted, or at minimum, one that is clearly being actively maintained.

When to Resubmit

If a major update introduces new functionality, particularly if it uses new platform features, that is a valid reason to submit again. Seasonal moments are also valid, an app relevant to the summer travel period can submit in April and again the following April. What is not worth doing is submitting the same product with the same brief and expecting a different outcome. Something should have changed.

Conclusion

Getting featured on the App Store or Google Play is a long game, and the teams that tend to succeed at it are the ones who built with that goal in mind from the start rather than treating it as a marketing activity to pursue post-launch. Platform choice, compliance architecture, onboarding quality, interaction craft, these are all decisions made during the build, and they are all visible to editorial teams when they test your product.

The football platform we worked on is a useful illustration of how early decisions compound. A platform choice made under budget pressure led to a smaller launch audience, which led to a failed subscription model, which led to a product in a weaker position than it needed to be. None of that was inevitable. It was the result of decisions, some of them ours, some of the client's, that could have gone differently with more planning and more honest conversations about trade-offs before the build began.

Featuring is not something that happens to good apps by accident. It happens to apps where enough things have been done right, early enough, for an editorial team to confidently put their name behind the recommendation. The practical steps, submitting through the right channels, timing against the editorial calendar, keeping your store listing accurate, matter. But they sit on top of a product that was designed and built with genuine care. That part comes first.

If you are planning a launch and want to think through what a featuring-ready build actually looks like, let's talk about your product.

Frequently Asked Questions