App store optimization moved out of its "keyword stuffing and icon color" phase a few years ago. What is working in 2026 is more specific and more connected to actual install and retention metrics than the old playbook suggested. This post covers the levers that move installs, the ones that used to matter but no longer do, and the measurement approach that lets you tell the difference.
What actually moves install volume in 2026?
The short list of levers producing measurable results this year, in rough order of impact:
1. Conversion rate optimization on the product page
Install rate from browse and from search has diverged significantly. From browse (featuring, category charts, related apps), the product page is doing heavy lifting, the first two screenshots, the icon, and the short description are the only things most users evaluate before the install button. From search, the query-to-install path is shorter and keyword relevance matters more. Treating these as one optimization problem produces mediocre results on both.
The practical implication: run separate A/B tests for browse and search traffic. Apple's Product Page Optimization lets you run up to three treatment variants against the default page in a single test (Apple). Use browse sessions to test screenshot narrative and icon variants. Use custom product pages (CPPs) for search-driven campaigns where you can tighten the message to the specific query.
2. Rating velocity and recency, not rating aggregate
Neither Apple nor Google publishes its ranking formula, but both platforms build their tools around time windows rather than lifetime averages: App Store Connect and Play Console both report rating trends over rolling periods, and the practitioner consensus, mine included, is that a newer run of strong ratings outweighs an older run of weak ones more than a simple lifetime average would suggest. Treat that as an informed working assumption, not a disclosed formula, since neither company states the exact weighting.
The practical implication: implement in-app review prompts at high-satisfaction moments rather than at arbitrary intervals. Session length and feature completion are better triggers than time-since-install. For iOS, this is worth getting the API name right, since a lot of ASO advice still references a class that no longer exists in current form: the review prompt is triggered through StoreKit, and the class most guides cite, SKStoreReviewController, was deprecated in iOS 18 in favor of AppStore.requestReview(in:) (Apple). Both the old and current APIs share the same built-in limit worth designing around: the system shows the prompt at most three times in a rolling 365-day period regardless of how often your code calls it, and calling the method never guarantees a prompt actually appears (Apple). That is Apple's decision, not yours, which is exactly why the timing of the call matters more than the frequency of the call.
3. Metadata optimization with search intent alignment
Keyword stuffing is still prevalent and still produces the same result it always did: you rank for terms nobody is searching and miss the terms that convert. The shift in the past couple of years is toward explicit intent modeling: what is the user trying to accomplish when they search this term, and does the app deliver that outcome.
For App Store, the title field (30 characters) and subtitle (30 characters) carry the most ranking weight. The keywords field (100 characters) is secondary. Google Play metadata works differently, the long description is indexed, so keyword density in the full description matters more than on iOS.
The practical implication: use Sensor Tower to identify the terms that drive installs, not just impressions, for competitors in your category, and build your title and subtitle around the two or three terms with the highest install intent. One correction worth making if you learned ASO before 2024: data.ai, formerly App Annie, is not a separate tool to check alongside Sensor Tower anymore. Sensor Tower acquired it in March 2024 and retired the brand, folding its data into Sensor Tower's own platform (Sensor Tower). If a client's team or an old workflow still references data.ai, it is the same company under a different, now-discontinued name. Rotate the keywords field quarterly based on trending terms in your category.
4. Feature graphic and first screenshot
On Google Play, the feature graphic (the banner at the top of the store listing) is the primary visual asset for browse and search results. Most developers treat it as an afterthought. On iOS, the first screenshot or app preview video is what appears in search results before a user taps into the product page. Both are the most consequential single creative assets in the ASO stack, because any gain in browse-to-page click-through compounds across every traffic source that reaches the listing.
The practical implication: test the feature graphic and first screenshot with the same rigor you would apply to a paid creative. It is the one asset nearly every competitor treats as a formality, which is precisely why it is underpriced attention relative to the effort it takes to fix.
5. In-app events and LiveActivities
Apple's in-app events surface in App Store search, the Today tab, and on the product page for installed users. For apps with recurring engagement loops, fitness, gaming, productivity, events, in-app event cards are a re-engagement tool that most competitors in the sub-100K download range are still not using, which means the surfaces they appear on are less crowded than the main product page.
The practical implication: run in-app events around major feature launches, seasonal campaigns, and any content-driven engagement moment. The setup cost is low, an event card, a short description, a start and end date, relative to the additional surfaces it gives a smaller app a chance to appear on.
What used to work but does not anymore
- Keyword stuffing the app name. Both stores penalize keyword-heavy names in ranking and in featured placement consideration. "Fitness Tracker - Workout Log App" is a worse name than "StrongLog" from a brand standpoint and from a ranking standpoint in 2026.
- Review-gating. Showing a satisfaction prompt first and only directing satisfied users to the store is an explicit violation of both Apple's and Google's developer policies, and it is one of the more actively enforced ones. If you inherit an app that does this, remove it before you do anything else with the review flow.
- All-time rating average optimization. As noted above, the platforms' own tooling points toward recency mattering. Chasing the all-time average by resetting it (changing bundle ID) or by soliciting reviews without intent context is expensive and works against the same recency dynamic you are trying to exploit.
How do you measure ASO correctly?
The measurement failure I see most often is conflating organic browse installs with organic search installs. These have different optimization levers and different conversion characteristics. Mixing them produces averages that do not tell you which intervention produced which result.
The measurement setup I recommend:
| Signal | What it tells you | Where to find it |
|---|---|---|
| Impressions by source (browse vs search) | Which traffic source is growing or declining | App Store Connect Analytics / Play Console |
| Conversion rate by source | Where the product page is converting well or poorly | App Store Connect / Play Console |
| Keyword ranking (organic) | Which terms drive impressions and installs | Sensor Tower, AppFollow |
| Rating velocity (30-day) | Momentum signal for store algorithms | AppFollow, direct store reporting |
| D1/D7/D30 retention | Whether installs are converting to retained users | Amplitude, Mixpanel, built-in app analytics |
The last metric, retention, is the one ASO practitioners most often skip. An install that churns in 24 hours is a negative signal for both Apple's and Google's ranking algorithms. Retention is an ASO metric, not just a product metric, and improving D1 retention, through better onboarding, faster time-to-value, or more accurate pre-install messaging, feeds back into organic ranking rather than sitting apart from it.
Common questions
How long does ASO take to show results?
Neither Apple nor Google publishes a fixed timeline for any of this, and I would treat any source that gives you one in exact hours or days with suspicion. What Apple does publish is a hard ceiling, not a minimum, on how long you have to run a Product Page Optimization test: a test runs for a maximum of 90 days or until you stop it, and Apple provides an estimate based on your app's own daily impressions and downloads rather than a fixed rule tied to your impression volume, with an explicit warning that lower-traffic apps may not reach a conclusive result inside that window at all (Apple). Metadata edits typically reflect in your own store listing once the review clears, but neither store commits to a timeline for when that shift then moves your ranking, and rating-driven ranking effects behave the same way: directionally real, gradual rather than a light switch, and not something either platform will hand you a day-count for.
Does paid UA affect organic rankings?
Yes, indirectly. Install velocity is a ranking signal, and paid campaigns that drive installs (and low churn) improve organic position. The effect is more pronounced for newer apps or apps in competitive categories where organic install velocity is otherwise low. The key is that paid installs need to produce retained users, installs that churn quickly generate a negative signal that can offset the volume benefit.
What is the minimum viable ASO investment?
For an app with under 10,000 monthly active users: metadata optimization, a review prompt implementation, and one screenshot test per quarter is the minimum viable set. For apps above that threshold, adding Sensor Tower competitor monitoring and a quarterly in-app event cadence is worth the added cost relative to what you are already spending on the app itself.
