Rebranding an App You Bought: Ten Things to Change Before You Ship

The transfer completes and the app is yours — still wearing somebody else's name, pointing at somebody else's privacy policy, and in at least one case quietly authorising somebody else to sell ads against your traffic. Most of that is twenty minutes of form-filling. Some of it cannot be undone later, and one item on the list is a revenue leak hiding inside a metadata field nobody reads. Here is the whole list, in the order you should do it.

TL;DR:

  • Three things never change: the bundle ID, the SKU and the numeric App Store ID. Make peace with inheriting them.
  • You get 30 characters of name, 30 of subtitle and 100 of keywords. That is your entire searchable surface — do not spend it on a brand nobody searches for.
  • The Marketing URL is what ad networks crawl for app-ads.txt. Leave the seller's in place and you are authorising their ad publisher from your listing.
  • Rotate the receipt-validation shared secret the day you accept. Until you do, the previous owner can still read your subscribers' state.
  • Do not change the name, the icon and the category in one submission. Reviewers read that as a different app.

Table of Contents

First, Sort the Work Into Three Buckets

Rebranding feels like one job and is three, with different tools and different risks:

  • Immutable. Identifiers Apple fixes for the life of the app. Nothing to do but know what they are.
  • Store metadata. Edited in App Store Connect and Play Console. Some fields are live immediately, some need a new version, and that distinction decides your release plan.
  • Inside the app. Strings, assets, keys and endpoints. Needs a build, a submission and a review.

People reliably underestimate the second bucket and overestimate the third.

1. What You Cannot Change, Ever

Identifier Why it is fixed Where you will keep seeing it
Bundle ID Cannot be changed once a build has been uploaded — and a transferred app has builds Crash reports, analytics, keychain access groups, App Store Connect API, provisioning profiles
SKU Cannot be changed after the app was added to an account Sales and finance reports
Numeric App Store ID Generated once, not editable The product page URL, every existing link and review of the app

The bundle ID is the one that bothers people, because it usually contains the seller's company name in reverse-DNS form and it will say that forever. It is worth being blunt about the trade: the alternative is submitting a fresh app under your own identifier, which abandons the reviews, the ratings, the ranking history and every install — the entire reason a transfer costs more than a code dump. Keep the identifier. Nobody browsing the store will ever see it.

Pro Tip: Add a line to your internal documentation on day one explaining why the bundle ID says someone else's name. The engineer who joins in eighteen months and finds it will otherwise assume it is a mistake and try to "fix" it.

2. The URLs You Are Asked For at the Moment You Accept

This is first in the running order because the opportunity happens once. When you accept an app transfer, Apple asks you to supply the new metadata there and then — a support URL, a marketing URL if the app previously had one, a privacy policy URL if it previously had one, plus App Review and App Store contact information.

Which means: have all three URLs live on your own domain before you click accept. Not planned, live. A privacy policy URL is required for iOS and macOS apps, so if yours 404s you have a store listing pointing at nothing in a field Apple treats as mandatory.

There is a design consequence here worth stealing. Because the privacy and terms URLs are registered inside a store listing that outlives the sale, they should never live under a path that describes the seller — a URL like /portfolio/our-apps/thing/privacy dies the moment the app changes hands or the seller reorganises their site. A stable per-app path, owned by whoever holds the listing and serving nothing but that app's documents, is the shape that survives. We serve them from a dedicated per-app path for exactly this reason: it is the URL registered with Apple, and it has to keep resolving after the app is no longer ours.

3. The Three Names Apple Holds Separately

An app has more than one name, and conflating them is the usual source of "why does the store say one thing and my phone another".

Field Limit Lives in Changing it
App Store name 2–30 characters App Store Connect Editable until the version is submitted to App Review; after that a change requires creating a new version
Subtitle Up to 30 characters App Store Connect Tied to a version, same as the name
Home-screen name Practically ~12 characters before truncation The app binary Needs a build and a review
Promotional text Up to 170 characters App Store Connect Any time, without a new version — and it does not affect search ranking

The practical sequence: set the store name and subtitle as part of the release that also changes the binary's display name, so the two never disagree in public. Use promotional text for anything you expect to change often, precisely because it is the one field you can edit without shipping.

And spend the subtitle properly. It sits under the name everywhere in the store, and Apple's own guidance is to use it to explain the value of the app rather than to restate the name — "Calm & Focus" tells a browser nothing that the name did not.

4. The Keyword Field, Which Is Not a Keyword List

You get 100 characters total, comma-separated, no spaces after the commas — spaces cost you characters you do not have. The field is invisible to users and is a ranking input, which makes it the highest-leverage 100 characters in the listing.

Apple's guidance is specific about what wastes it:

  • Do not repeat words already in the name or subtitle. Those are already indexed. This alone usually frees twenty characters.
  • Do not include plurals of words you have already used.
  • Do not include category names or the word "app".
  • Do not duplicate words, and avoid special characters unless they are part of your brand.
  • Do not use trademarked terms, celebrity names or competing app names. This is a rejection, not an inefficiency.

A buyer rebranding an app has an advantage here that the original developer did not: you can see which queries the app already ranks for, because you inherit its App Analytics history going back to launch. Read it before you rewrite the field, or you will unknowingly drop the term that was bringing in installs.

Pro Tip: Write the keyword field last, after the name and subtitle are final, and write it as one string with no spaces. Then count it. Almost everyone's first draft is over 100 and half of it is duplicated from the name.

5. Icon, Screenshots and Previews

The counts are generous and most listings underuse them: up to 10 screenshots and up to 3 app previews of up to 30 seconds each.

Two facts change how you prioritise the work:

  • The first one to three screenshots appear in search results when there is no app preview. They are doing the job of an advert, not of documentation, so they carry the proposition — not your settings screen.
  • Previews autoplay muted. The first few seconds must work with no sound and no context.

If the app supports dark mode, include at least one screenshot that shows it. And if the bought app's screenshots were good, change them anyway — they carry the old name in their captions, which is the single most visible leftover of a rebrand.

6. Where the Old Brand Hides in the Code

Searching the repository for the old name finds most of it. These are the places it survives that search:

  • Localisation files for every language, not just English.
  • Push notification payloads, which are often built server-side and so are not in the app repository at all.
  • Transactional email templates — welcome, password reset, receipt — wherever they live.
  • OAuth consent screens. The name shown when a user signs in with Google or Apple comes from a provider console, not from your code.
  • Deep link schemes and universal link domains, which are also a compatibility decision: changing a scheme breaks every link already in the wild.
  • In-app purchase display names and subscription group names, which users see on the App Store subscription screen and in their receipts.
  • App Store Connect contact details, still the seller's until you change them.
  • Legal text inside the app — the terms screen, the about box, copyright strings.
  • Store assets' alt text and captions, and the support site the app links to.

7. Keys and Accounts to Rotate

Ownership of an app includes ownership of its secrets, and until you rotate them the previous owner has read access to your business. In priority order:

What Why it matters When
App-specific shared secret (receipt validation) Until rotated, the seller's servers can still validate and read your subscribers' state The day you accept
Backend and database keys Service-role keys in a handed-over repository are full database access Day one
Subscription platform keys Revenue data and entitlement control Day one
OAuth client secrets Sign-in impersonation risk Day one
APNs key or certificate Inherited certificates keep working until they expire, then push silently stops Before expiry — but do not wait for it
Crash-reporting DSN and analytics keys Otherwise your telemetry flows into the seller's dashboards First release
AdMob app ID and ad unit IDs Otherwise the ad revenue is not yours. See the next section First release
Apple Pay merchant ID, Wallet pass identifiers Neither transfers; both need recreating Before the feature ships again

Two inherited behaviours to know about rather than fix. Keychain sharing continues only until the app is updated — so the first build you ship under your own Team ID makes anything stored under the old access group unreachable. If the app keeps credentials there, users will be logged out by your rebrand unless you migrate them deliberately. And inherited APNs certificates work right up to their expiry date, which makes this the most pleasant possible failure mode: everything is fine, and then one morning push notifications stop.

8. The app-ads.txt Trap

This one deserves its own section because the mechanism is invisible and the cost is direct.

If the app shows ads, ad networks verify who is authorised to sell its inventory by fetching an app-ads.txt file from the root of the developer website listed in the app's store listing. On the App Store, that is the marketing URL field. On Google Play it is the store listing contact website. The file names the publisher IDs permitted to monetise the app.

Now recall section 2: the marketing URL is one of the fields Apple asks the recipient to re-enter at the moment they accept a transfer. So there are two ways to get this wrong, and both are easy:

  1. You leave the seller's marketing URL in place. Their app-ads.txt is crawled, naming their publisher ID, and your listing is authorising their account against your app's inventory.
  2. You set your own marketing URL and forget the file. The crawler finds no app-ads.txt at your domain, the app shows as unverified, and bidders that require verified inventory stop buying — so your ad revenue falls without any error appearing anywhere.

The fix is three lines of work: point the marketing URL at your domain, publish app-ads.txt at its root naming your own publisher ID, and check the verification state in your ad network console. Google documents up to 24 hours for the crawl.

Pro Tip: Do this before you ship the rebranded build, not after. The crawl is tied to the store listing, so the file needs to be live at the URL the listing names while the old build is still the one earning.

9. Privacy Declarations and Manifests

Privacy paperwork describes what the app does, which means it is a function of the SDKs inside it — and a rebrand that swaps an analytics or ad provider changes the answers.

Three separate obligations, often confused:

  • The App Privacy section in App Store Connect. You are prompted to review it when you accept the transfer. If the previous owner never disclosed data collection, or you delete their responses, you must complete it before submitting a new version.
  • Privacy manifests, and signatures, for third-party SDKs. Apple requires a privacy manifest for any SDK on its published list when you submit a new app containing it, or an update that adds one — and signatures too where those SDKs are binary dependencies. The list is long and includes things a bought React Native app very likely contains: the Firebase modules, FBSDKCoreKit and FBSDKLoginKit, GoogleSignIn, Alamofire, AFNetworking, Lottie, RealmSwift, SDWebImage, Kingfisher and React Native's own Hermes. Xcode merges the manifests into one report at distribution time, which is also how you find out something is missing.
  • Google Play's data safety form. The same exercise, independently maintained, and it must match real behaviour.

If you are swapping ad or analytics providers as part of the rebrand, do the SDK change and the declarations in the same release. Declarations that describe the previous release's SDKs are a rejection waiting for a reviewer to notice.

10. The Shipping Order

Everything above, sequenced. The ordering is not aesthetic — several steps are impossible or expensive out of order.

  1. Before accepting: get support, marketing and privacy URLs live on your own domain.
  2. Accept the transfer, entering those URLs and your contact details. Review the App Privacy section while you are there.
  3. Same day: rotate the shared secret, backend keys, subscription keys and OAuth secrets.
  4. Publish app-ads.txt at your domain root with your publisher ID, and confirm verification.
  5. Create provisioning profiles in your account and confirm you can build and archive the app unchanged.
  6. Ship one unchanged build from your own account before you change anything. This separates "can we release at all" from "did our rebrand break something", and it is the step everyone skips and regrets.
  7. Then rebrand the binary: display name, icon, strings, assets, SDK and key swaps.
  8. Update store metadata alongside that version: name, subtitle, keywords, screenshots, previews, in-app purchase display names.
  9. Submit, with the privacy declarations matching the SDKs in this build.
  10. After approval: migrate anything keychain-dependent, move push to your own APNs key, and keep the old analytics dashboard open for a fortnight to spot what changed.

One warning on step 7. Resist changing the name, the icon and the category in a single submission. Reviewers compare a submission to the app that exists, and an app that arrives looking entirely unlike the one that was approved is a conversation you do not want on your first release. Change the name and icon first, the category later, and let one approval land between them.

Everything here assumes the transfer itself has gone through. If you are not there yet, what actually transfers with an App Store listing covers that half — including the things, like Sign in with Apple user identifiers, that must be handled before the handover rather than after.

Sources

Apple and Google revise these pages and their character limits and SDK lists change. Everything above was checked against them in October 2026 — follow the links before you plan a release around a detail.

FAQ

Can you change an app's name after you buy it?

Yes. The App Store name is a 30-character field you edit in App Store Connect, and the subtitle beneath it is another 30. The catch is when rather than whether: a name can be edited freely until the version is submitted to App Review, after which changing it requires creating a new version — so a rename is part of a release, not a quick edit. The name on the home screen is a separate value inside the binary and changes with a build. They do not have to match, and letting them drift confuses users and reviewers alike.

Can you change the bundle identifier of an app you bought?

No. Apple's documentation is unambiguous: the bundle ID cannot be changed once a build has been uploaded, and a transferred app arrives with builds already uploaded. You inherit the previous owner's reverse-DNS identifier permanently. It is invisible on the store and visible in your crash reports, your analytics, your keychain access groups and your API calls. The only alternative is publishing a fresh app under your own identifier, which means abandoning the reviews, ratings, ranking history and every existing install — which is the asset you paid for.

What should you rotate after buying an app?

Everything that authenticates as the app rather than as a user. The app-specific shared secret for receipt validation, immediately after accepting the transfer. Backend and database keys. Subscription platform keys. The crash-reporting DSN. Analytics keys. Your AdMob app ID, and with it the app-ads.txt file on the domain your store listing points at. Push credentials, because inherited APNs certificates work only until they expire. Any OAuth client secrets. Do the shared secret first, because until you do, the previous owner's servers can still read your customers' subscription state.

Will renaming an app reset its App Store ranking or reviews?

No. Reviews, ratings, ranking history and the install base attach to the app record, not to the name, so they survive both a transfer and a rename. What a rename does change is search: the name, subtitle and keyword field are ranking inputs, so editing them changes which queries you appear for. The real risk is not losing history but spending characters badly — a 30-character field filled with a brand name nobody searches for earns less than one carrying a phrase people actually type.

Do you need to redo the App Store privacy declarations after a transfer?

Often, yes. At the moment you accept a transfer Apple asks you to review the App Privacy section, and if the previous owner never disclosed data collection — or you delete their responses — you must complete that section before you can submit a new version. The declarations describe the SDKs the app actually contains, so swapping an analytics or ad provider during a rebrand changes the answers. Google Play's data-safety form has to match real behaviour too. Treat both as part of the rebrand rather than as the seller's leftover paperwork.