Prepare App Store Connect fields before upload day in five groups: app identity, localized product-page metadata, version details, App Review Information, and compliance declarations. Some values are public, some are private to Apple, and some become difficult or impossible to change after the app record is created.
Do not wait for every red warning to discover what you need. Collect approved copy, public URLs, screenshots, contact details, demo credentials, privacy answers, and release settings while the build is still being tested.
The short version
- Decide the bundle ID, SKU, primary language, and app name before creating the record.
- Prepare public metadata and URLs for every launch localization.
- Keep Review Notes and demo credentials separate from customer-facing copy.
- Answer privacy, age-rating, encryption, and content-rights questions from the actual build.
Start with the app record fields
The app record is the container for builds, versions, product-page information, and review submissions. Apple’s new app instructions currently ask for platforms, app name, primary language, bundle ID, SKU, and user access.
Prepare these values deliberately:
| Field | What to decide | Why it deserves care |
|---|---|---|
| Platforms | The Apple platforms belonging to this record | Affects the record and platform versions |
| App name | Launch name for the primary language | Must be available and match your product |
| Primary language | Default metadata language | Used when localized information is unavailable |
| Bundle ID | Registered identifier matching the binary | Connects uploads to the record |
| SKU | Your internal identifier | Not shown to customers |
| User access | Full or limited team access | Controls who can manage the app |
Apple limits record creation to users with an appropriate role and requires the latest agreement to be accepted. The bundle ID should match the production target before the first upload. Treat it as identity, not marketing copy.
The full first-submission walkthrough explains where record creation belongs in the wider release sequence.
Prepare the app-level information
App-level information applies across versions or appears in the app’s general record. The exact editable fields vary by platform and state, but the usual preparation set includes category choices, content rights, age rating, privacy policy URL, and other general information.
Apple’s app information reference distinguishes required, localizable, and editable properties. For iOS apps, it states that the Privacy Policy URL is required. The same reference currently limits the app name and subtitle to 30 characters.
Before entering anything, create a source document with:
- the approved app name and subtitle per locale;
- primary and secondary categories;
- a public privacy policy URL;
- content-rights ownership or authorization details;
- age-rating questionnaire answers;
- any custom licence agreement decision;
- the support owner who can maintain these values.
The age rating is not a copywriting choice. Answer from the app’s content, capabilities, and controls. The dedicated App Store age-rating guide shows how to inspect each question without guessing.
Prepare each platform version page
A platform version page describes a specific release. It connects customer-facing metadata, screenshots, the selected build, release behavior, and App Review Information.
For the public product page, prepare:
- description;
- keywords;
- support URL;
- marketing URL, if you use one;
- promotional text, if you use it;
- screenshots and optional app previews;
- What’s New text for an update;
- copyright information where requested.
Descriptions should match the selected build. Keywords are metadata, not a place to list unrelated competitors or claims. Support and marketing URLs must resolve publicly. Screenshots need to meet Apple’s current file and display specifications and represent the running app accurately.
Apple’s platform version information reference is the best field-by-field check because it identifies which properties are required, localizable, or editable. Use the live reference when preparing a release; the interface and platform requirements can change.
Separate public metadata from App Review Information
App Review Information is private operational metadata for Apple. It should help a reviewer reach you and test the submission, not sell the product.
Apple currently requires contact information for the review and provides fields for sign-in details and notes. Prepare:
- contact first and last name;
- a monitored phone number;
- a monitored email address;
- demo username and password when sign-in is required;
- concise Review Notes;
- any additional account or resource the reviewer needs, with access instructions in Notes.
The platform reference states that the demo account must not expire. If you use a single sign-on service, include working access for it. Put additional accounts and role explanations in Notes.
A reviewer should be able to follow this format:
- Starting state: clean install, region, device, or seeded account.
- Access: credentials and any authentication exception.
- Route: exact tabs, labels, and taps.
- Action: the feature or purchase to test.
- Expected result: what confirms the path worked.
Do not put private credentials in the public description or support page. Conversely, do not hide required customer disclosures only in Review Notes.
Collect build and release controls
The version page is incomplete until you select a processed build and configure release controls. Record the marketing version and build number you have actually tested, then select that exact build.
Depending on the release, prepare decisions for:
- manual, automatic, or scheduled release after approval;
- phased release for an update;
- availability by country or region;
- pricing and tax category;
- in-app purchases, subscriptions, or other related items included in review;
- export compliance information attached to the build.
These are not all free-text “fields,” but they determine what App Review receives and what happens after approval. A correct description cannot compensate for a missing build or unavailable subscription product.
Reconcile privacy and compliance answers
Complete compliance forms last enough that they reflect the release, but early enough to investigate unknowns. Review the production binary, SDK inventory, backend data flows, permission prompts, and account behavior.
Prepare evidence for:
- App Privacy data collection and use purposes;
- tracking and linked-data decisions;
- privacy manifests and required-reason API work where applicable;
- encryption/export compliance;
- advertising identifier use;
- content rights;
- age-rating descriptors and capabilities;
- account deletion if users can create accounts.
Never copy these answers from a previous app without checking the code and SDK configuration. If a question has legal or regulatory consequences, obtain suitable professional advice. AppRejectKit is not a law firm, and Apple’s current forms remain the source of truth.
Use an upload-day field pack
A compact handoff prevents upload day from becoming a scavenger hunt. Keep one release folder or ticket containing:
- version and build identifiers;
- final copy by locale;
- screenshots by device family and locale;
- public URL checks;
- review contact and demo account;
- Review Notes and any reviewer resources;
- privacy and compliance evidence;
- purchase-product status;
- release and availability choices.
Assign an owner to each item. “Engineering has it” is not a value you can paste into App Store Connect.
FAQ about App Store Connect required fields
Can I create the app record before the build is ready?
Yes. In fact, Apple requires the record before the first build upload. Finalize the bundle ID and core identity fields first.
Is the SKU visible on the App Store?
No. It is an internal identifier for your own tracking in App Store Connect.
Are Review Notes shown to customers?
No. App Review Information is provided to Apple for the review process. Keep public product copy in the localized version fields.
Do all fields lock after submission?
No. Editability depends on the field and the app’s status. Use Apple’s current field references before relying on a late edit, and remove the submission from review if the required change demands it.
Do I need a privacy policy URL for an iOS app?
Yes. Apple’s current app information reference marks the Privacy Policy URL as required for iOS apps.
Conclusion
The safest way to prepare App Store Connect is by field group and owner. Lock identity, approve localized copy, build a reviewer access path, gather compliance evidence, and select release controls against one tested build.
Start with the values that are hardest to change: bundle ID, record structure, primary language, and production identity. Then build the upload-day pack around them.