Which App Store Metadata Changes Require Re-Submission?

Most app teams think about metadata as a one-time job. You write the description, pick the screenshots, set the keywords, and move on. Then, three months later, someone wants to change the subtitle, or the marketing team decides the screenshots need refreshing, and suddenly nobody can agree on whether that means going back into review or not. The answer, frustratingly, depends on what you're changing and where.

The rules around App Store metadata re-submission are genuinely confusing, partly because Apple and Google handle things differently, and partly because the documentation is scattered across multiple support pages that don't always agree with each other. Teams end up making conservative assumptions, submitting binary updates they didn't need to, or accidentally holding up a release cycle because they bundled a metadata change with a code change without thinking through the implications.

This guide pulls together the core rules in one place. We'll walk through what triggers a re-review, what you can change freely, and where the genuine grey areas sit. Whether you're managing a retail app, a travel product, or a health and wellbeing platform, the same principles apply, and understanding them properly saves real time.

Metadata rules are scattered and confusing, but getting them right protects your release cycle.

Think of this as a working reference, not a one-read article. The specifics matter here, so we've been precise about which changes fall into which category.

The Core Rule: What Triggers a Re-Review

The simplest way to think about re-submission is that anything affecting what users see before they download, or anything that changes what the app claims to do, goes through review. Anything that Apple or Google can update on the store's own infrastructure, without touching the binary, generally does not.

For Apple's App Store, a re-review is triggered any time you submit a new binary, but also when you make certain metadata changes that Apple's review team considers substantive. These include changes to the app name, subtitle, keywords, and primary category. They also include privacy information updates, age rating changes, and anything that affects how the app is classified or found.

Google Play operates on a slightly different model, where metadata changes are more often handled independently of binary updates. But the general principle is the same: if a change affects how the app is represented to users or how it ranks, it goes through some form of review before it goes live.

The practical consequence is that not all metadata changes are equal. Some changes go live within minutes. Others wait in a review queue that can take 24 hours or several days. And some changes can only be made alongside a new app version. Knowing which is which is what keeps your release planning sensible.

Changes You Can Make Without Re-Submission

Several metadata fields can be updated freely, and the changes go live without triggering a review queue. These are mostly fields that live on the store's own infrastructure rather than inside the app binary itself.

On the App Store, you can update your promotional text at any time without re-submitting. This is the 170-character field that sits above the description on your store listing. Because it's designed for short-term messaging around events, promotions, or announcements, Apple lets you change it whenever you like, and updates appear quickly. This makes it a useful field for time-sensitive communications that don't need to go through a full review cycle.

Use the promotional text field for seasonal messaging, event announcements, or short-term offers. It's the one metadata field that can flex in real time without touching your review queue.

You can also update your app's description without re-submitting, as long as you're not changing the app's core functionality claims in a way that would mislead users. In practice, this means rewriting the description for clarity, improving the copy, or updating it to reflect features that were already approved in a previous version.

Developer responses to user reviews, the support URL, and the marketing URL are all fields you can update freely. These are operational rather than representational, so they sit outside the review process entirely.

Metadata Changes That Always Require Re-Submission

Several fields cannot be changed without submitting a new binary for review. These are the fields that most directly shape how users discover and evaluate your app, so both Apple and Google treat changes to them as substantive.

The app name is the most protected field. On the App Store, the name is locked once it's been approved. You cannot change it without submitting a new version of the app. The same is true for the subtitle, the primary category, and the keywords field. All of these are part of Apple's search and discovery infrastructure, and changes to them require a full re-review.

Fields that shape how users find your app are always treated as substantive changes by both platforms.

Privacy nutrition labels are another area where re-submission is required. If the data practices of your app change, you need to update the privacy information in App Store Connect, and that update goes through review. This matters more than teams often realise. App Store Connect will ask you to confirm your privacy details are accurate every time you submit a new version, and inconsistencies between what you declare and what the app actually does create compliance risk.

Age rating information also requires re-submission. If your app introduces new content types that push it into a different rating category, or if a previous rating was inaccurate, you'll need to submit a new version with updated rating information.

When planning a new version release, check whether any of your protected metadata fields need updating. Bundling those changes into a scheduled binary submission is far more efficient than discovering you need a separate submission later.

What Counts as a New Binary

A new binary means a new build uploaded through Xcode or the equivalent submission tool. Even a build with no functional changes still constitutes a new binary submission and goes through review. Teams sometimes use this deliberately, submitting a version bump with no code changes specifically to get metadata updates through review. It works, but it adds review time, so it's worth doing intentionally rather than by accident.

App Name and Subtitle Changes

The app name and subtitle sit at the top of your store listing and carry significant weight in App Store search. Apple indexes both fields for keywords, and the words you use there have a direct effect on discoverability. That's precisely why changes to them go through review, and why they're worth thinking about carefully before you lock them in.

Your app name on the App Store can be up to 30 characters. The subtitle, which sits just below the name in search results and on the product page, can also be up to 30 characters. Together, they give you 60 characters of prime keyword real estate that Apple's algorithm actively reads.

Because both fields require re-submission to change, teams that iterate on their store listing copy need to plan those changes around binary releases. If you want to test different name or subtitle variations to see which performs better in search, you'll need to run those tests across separate app versions, each going through its own review cycle.

Name Changes and Brand Consistency

There's a behavioural dimension worth considering here. Users who already have your app installed will see the updated name, and if the change is significant, it can create momentary disorientation. The brain's first reaction to something unfamiliar is a quick check: is this the same thing I trusted before? A name change that feels discontinuous with the brand can briefly shake that confidence, even among loyal users. Incremental refinements tend to land more smoothly than wholesale rebrandings.

Google Play is slightly more permissive here, allowing name changes to go live more quickly after review, but the same strategic logic applies. A name is one of the most persistent signals you send to users, and changing it carries real implications beyond the technical review process.

Keywords and Search Metadata

Keywords are one of the more misunderstood parts of App Store metadata, partly because the two major platforms handle them in fundamentally different ways. Getting this right has a direct effect on organic discovery, which for many apps is the primary driver of new installs.

On the App Store, you get a dedicated keywords field of 100 characters. These keywords are not visible to users. They exist purely for Apple's search algorithm, and the words you put there are indexed alongside the words in your app name and subtitle. Because Apple already reads your name and subtitle, there's no point repeating those words in the keyword field. Every character in that 100-character limit should be doing new work.

Changes to the keyword field require re-submission. You cannot update your keywords independently of a binary release, which means keyword testing and iteration is tied to your release cycle. Teams that want to respond quickly to search trends or seasonal search behaviour need to either plan those keyword changes into upcoming releases or accept that they'll be working a version or two behind.

Google Play and Keywords

Google Play doesn't have a dedicated keywords field. Instead, Google's algorithm reads your app title, short description, and long description, and indexes the language it finds there. This makes keyword optimisation on Google Play an exercise in copy rather than a discrete metadata field, and it means changes to your description can have search implications even when they feel like straightforward copy edits.

On Google Play, short description and long description changes go live more quickly after review than on the App Store, giving teams a bit more flexibility to iterate on language. But the principle of thoughtful, intentional keyword choices applies equally on both platforms.

Screenshots, Previews, and Promotional Artwork

Screenshots and app preview videos are the most visually prominent part of your store listing, and they carry more weight in a user's decision to download than most teams appreciate. The first two or three seconds of looking at a store listing involve rapid, largely unconscious judgements about whether the app looks professional and whether the design suggests competence. Screenshots are doing the heavy lifting in those seconds.

On the App Store, screenshots and preview videos require re-submission to update. They're part of your app's metadata bundle and go through review alongside any binary changes. This surprises teams who assume visual assets might be easier to update than text fields, but from Apple's perspective, screenshots are a representation of what the app does, and misrepresentative screenshots are a common reason for rejection.

The practical implication is that if your screenshots show features that no longer exist in the current version, or if they make claims the app doesn't deliver on, you're carrying review risk. Keeping screenshots current with your actual product is important, and the review requirement is a useful forcing function to do that work deliberately rather than letting the listing drift out of sync with the app.

Review your screenshots alongside every major binary submission. It's the moment when updating them costs you no additional review time, since you're already going through the process.

Promotional Artwork and the App Store

Promotional artwork, including the app icon as displayed on the store page, also requires re-submission to change on iOS. The icon inside the binary itself can only change with a new build. Some elements of store-specific promotional imagery, like the promotional artwork used in featuring opportunities, have different workflows, but the core visual identity of your listing is locked to your binary submission cycle.

In-App Purchases and Pricing Metadata

In-app purchases have their own metadata layer, covering display names, descriptions, and pricing. The rules here are a bit more nuanced than for the main app listing, because Apple and Google have both built separate workflows for managing purchase products.

On the App Store, new in-app purchase products need to go through review before they can be offered to users. You create them in App Store Connect, set the display name, description, and price, and then either submit them alongside a binary update or, in some cases, submit them for independent review. Apple does allow certain in-app purchase updates to be reviewed separately from a full app submission, which gives teams more flexibility when adding or adjusting purchase options.

Pricing for existing in-app purchases can be changed without re-submission in most cases. Apple's pricing infrastructure lets you update the price of an existing product and have that change go live without a review cycle. This is genuinely useful for promotional pricing, introductory offers, or responding to currency fluctuations across different markets.

Subscription Metadata

Subscription products, including free trial lengths and introductory offer terms, follow similar rules. You can set up and modify introductory offers through App Store Connect, and some of those changes go live without a full binary submission. However, changes to subscription group names or the fundamental structure of your subscription tiers generally require more careful handling and may need to go through review. The App Store Connect documentation is the most reliable reference for the current state of these rules, as they've evolved over several platform versions.

Age Ratings and Content Descriptions

Age ratings on both platforms come from a questionnaire rather than being set manually. You answer a series of questions about the content your app contains, and the platform calculates the appropriate rating from your answers. This means the rating itself isn't something you directly edit, but your content descriptions absolutely are, and changes to them carry real consequences.

On the App Store, if you update your app in a way that introduces new content types, including things like user-generated content, gambling mechanics, or mature themes, you need to update your content description questionnaire. That update goes through review, and if the new rating is significantly higher than the previous one, it can affect your app's visibility in certain markets or for certain user groups.

Getting this wrong creates compliance risk. Apple has rejected updates where the declared content rating didn't match what the app actually contained, and in more serious cases, apps have been removed from the store entirely. The practical advice is to treat the content questionnaire as a living document that you revisit with every meaningful feature addition, not a one-time submission you complete at launch and forget about.

Google Play uses a similar questionnaire-based approach through its Rating Certificate system, and the same principle applies. Changes to what your app contains need to be reflected in the declared content information, and that information goes through review before it affects your listing.

Localisation and Metadata for Additional Regions

Localised metadata, meaning your app name, description, keywords, and screenshots in languages other than your default, follows the same rules as your primary listing but adds an extra layer of complexity around which locales are linked to which binary submissions.

On the App Store, each locale has its own metadata fields, and changes to those fields follow the same review rules as your primary locale. If you want to update your German-language keywords, that requires re-submission, just as an update to your English-language keywords would. This matters for teams that manage apps across many markets, because the coordination overhead of keeping localised metadata current is real.

One thing teams sometimes miss is that the App Store allows you to add new locales to an existing app without submitting a new binary, as long as you're adding metadata for a language rather than changing existing approved metadata. In practice, this means you can expand your app's market reach to new regions with localised copy and screenshots without going through a full re-review, provided the app binary itself was already approved for global distribution.

What Changes Across Locales

Search behaviour, keyword relevance, and even visual expectations for screenshots vary significantly across markets. A travel app targeting users in Japan and users in Brazil needs localised metadata that reflects genuinely different search habits, not just translated versions of English copy. Teams that treat localisation as a translation task rather than a market-specific optimisation exercise tend to underperform in non-English-speaking markets, even when the app itself is well-designed.

How Platform Differences Affect the Rules (App Store vs Google Play)

The two platforms share the same broad logic but diverge meaningfully in the details, and those differences matter when you're planning metadata updates across both stores simultaneously.

Apple's App Store is the more restrictive of the two. Review timelines are generally longer, more metadata fields are locked to binary submissions, and the review criteria around content representations are applied more strictly. The upside is that the App Store review process provides a degree of quality assurance that users have come to associate with iOS apps, and passing review successfully carries a kind of implicit credibility.

Google Play operates a faster review cycle for most metadata changes. Many text-field updates go live within a few hours of submission rather than waiting in a multi-day queue. Google also allows more metadata changes to be made independently of binary updates, giving Android teams more flexibility to iterate on their store listing without timing everything around a release.

Managing Both Stores in Practice

Teams managing both platforms in parallel often find that the App Store cadence sets the pace for their metadata update cycles. Because iOS changes take longer to go live, it makes sense to plan metadata updates around iOS submission windows and then apply equivalent changes to Google Play alongside them, even if the Play changes could technically go live sooner. This keeps both listings consistent and prevents the kind of drift where your iOS and Android listings start diverging in ways users and search algorithms notice.

The two platforms also have different rules around promotional artwork, featuring opportunities, and the relationship between your app's store listing and any associated web presence. It's worth maintaining separate documentation for each platform rather than treating the rules as identical.

How to Plan Metadata Updates Without Disrupting Your Release Cycle

The most common mistake teams make with metadata is treating it as something to sort out right before a release rather than something to plan alongside one. When metadata decisions are made at the last minute, they either get rushed through without enough strategic thought, or they cause delays because something goes into review at the wrong moment.

A simple approach is to maintain a metadata backlog alongside your feature backlog. Any time someone on the team identifies a potential improvement to the listing, it goes into that backlog. When a new binary release is being planned, the metadata backlog gets reviewed, and relevant items get bundled into that release. This way, you're making maximum use of each review cycle rather than submitting binary updates with no accompanying metadata improvements.

For fields like promotional text that can be updated freely, create a simple content calendar. If your app has seasonal relevance, or if there are predictable moments in the year when you want to push specific messaging, writing that copy in advance means it's ready to go when the moment arrives rather than being written reactively.

• Keep a live metadata document that shows the current approved state of every field across every locale
• Add a metadata review step to your standard pre-release checklist
• Flag which fields are locked to binary submissions and which can be updated independently
• Plan keyword reviews and description updates quarterly, not just when something breaks
• Test promotional text variations at times that don't coincide with major binary submissions, so you can attribute any performance changes clearly

The review process is not the enemy here. It's a fixed constraint, and the teams that manage it best are the ones who treat it as a scheduling reality rather than an obstacle to work around at the last minute.

Document the current approved state of your metadata in a shared file that the whole team can see. When someone asks whether a particular field can be changed without re-submission, the answer should be in that document rather than in someone's head.

Conclusion

App Store metadata is a moving system, not a static form you fill in at launch. The fields that drive discovery, the visuals that shape first impressions, and the information that builds user trust all need regular attention, and the review rules that govern them shape how and when you can make changes.

The distinction between what requires re-submission and what doesn't is genuinely consequential for release planning. Treating every metadata change as something that needs a full binary update wastes time and slows your ability to iterate. Treating none of them that way risks compliance problems, review rejections, and inconsistencies between what you claim and what you deliver.

Getting this right is partly about knowing the rules and partly about building processes that make the rules easy to work with. A metadata backlog, a shared document showing the current approved state of your listing, and a habit of reviewing metadata alongside every release cycle are small investments that pay back consistently over time.

The deeper point is that your store listing is a user experience in its own right. The decisions users make about whether to download, whether to trust, and whether to continue are shaped by what they see before they ever open the app. Metadata governs what that experience looks like, and it deserves the same level of care and ongoing attention as the product itself.

If you're working through how to structure your app's store presence, or if your metadata strategy has drifted and needs a proper review, let's talk about your app store approach.

Frequently Asked Questions