What changes when I put Grounded on the App Store?

So far I have been installing development builds on iPhones and explaining Grounded to people myself. For an App Store release someone needs to understand it from the listing, install it without me and know what the app can tell them during a journey. I looked at Apple’s submission process alongside the parts of Grounded that I would need to check again for a public release. I would recheck Apple’s requirements on the day I submit because they can change. Apple’s submission guidance

Setting up my developer account and build

I need to enrol in the Apple Developer Program and make sure the relevant agreements are active. Before enrolling, I would check the current membership fee and decide whether I am enrolling as an individual or through an eligible organisation. That affects which seller name appears publicly. In App Store Connect I would create an iOS app record with the same bundle ID as the Xcode target. Then I would check the signing team, capabilities, version and build numbers before archiving a release build in Xcode and uploading it from Organizer. Apple Developer Program enrolment · Upload builds

Apple’s minimum requirement in November 2026 is Xcode 26 or later and an iOS 26 SDK or later for the iPhone upload. The SDK I build with and the oldest iOS version I support are separate settings. I would check the deployment target against the oldest iPhone and iOS version I can realistically test. Apple’s SDK requirements

Using TestFlight before the public release

I would install the uploaded build through TestFlight and try it on an iPhone that has never had Grounded installed. I would give external testers a short set of tasks and ask for the build number and steps when something goes wrong. Apple may review external beta builds and a TestFlight build is available for up to 90 days. I would leave time for fixes and retest the build I intend to submit, since a working development build can behave differently from the one an App Store user installs. TestFlight overview

• Flight search. Try UK and international departures, a search across December and January, and an empty result. Compare the selected date with the date returned. Check time zones, scheduled versus live information, stale data and the wording when the gate is unverified.
• Family View. Open a shared link from Messages on another phone. Try it with location declined, an older phone update and a link that has expired or been stopped, if those controls are in the release. Check what a recipient can see if the link is forwarded. Use test data when recording or sharing screenshots.
• Wearable and support. Try the journey with a connected monitor, after disconnecting it and with no monitor paired. Check whether the app explains a missing reading and whether the exercises can still be opened by hand. Try starting and stopping the spoken guidance and returning to directions.
• Accessibility and settings. Check large text, VoiceOver reading order, labels, touch targets, contrast and light and dark appearance on the release build. Turn the character off and follow every route that normally shows it, then turn it back on and reopen the app. Check that the gate and next action remain easy to find.

<aside>

My release check is whether someone can install Grounded, follow the core journey and understand what is confirmed even if they skip the wearable, decline location or never use Family View.

</aside>

Checking what Grounded collects and shares

Apple requires a public privacy policy linked in the listing and accessible inside the app. App Store Connect also asks for privacy disclosures based on what the app and its third-party partners actually collect. I would trace the data from the phone through the flight service, map and hosting services, and Family View before answering. For each item I would record what leaves the device, where it goes, who can see it, how long it is kept and how it can be deleted. For Family View, this includes the location and its timestamp, flight and stage details, and what access someone has if they receive the link. I would check whether the release supports stopping or expiring links and make sure that the wording matches the behaviour. If I add account creation, Apple also requires account deletion within the app. App Privacy Details · App Review Guidelines, section 5.1

I would check location and wearable permission prompts against the features that actually ask for them. The location wording should tell the traveller what it is for and when their position can be shared. For the monitor, I would check which integration the release uses. If it uses HealthKit, I need to check the capability, the purpose strings for the access I request, and Apple’s health-data rules. I would describe heart rate as a reading that can trigger an optional support prompt. The listing and permission copy should match that behaviour. I would also review the archive’s privacy manifest, any required-reason API declarations, third-party SDK requirements, and the encryption or export compliance questions in App Store Connect. Location permissions · HealthKit authorisation · Privacy manifests · Export compliance

Preparing the App Store page

I would prepare the app name, subtitle, description, keywords, category, icon, screenshots, support URL and privacy policy URL. I would answer the age rating questions, choose the countries where I can support the app and check any compliance questions for those storefronts. Apple asks developers to declare EU trader status in App Store Connect. I would also check whether my flight and map providers allow the intended public use, including presentation of flight data in the shared view and any required attribution. App Store Connect app information · EU trader requirements

I would take screenshots from the actual release build with sample data and export them in Apple’s accepted sizes. I want the first images to show the journey, the gate alert and the option to carry on. Features in the listing should be available in the submitted build. I would label scheduled flight information clearly and describe any illustrative route accordingly. If I disclose support for accessibility features on the product page, I would base those claims on checks of the main tasks. Screenshot specifications · Accessibility Nutrition Labels

Giving App Review a journey they can try

I would provide a contact and concise review notes for the exact build. I would explain how to open a sample journey, see the gate-change flow, use the app without a wearable and test Family View with example data. If any feature requires an account, hardware or a particular setup, I would provide usable demo access or explain what the reviewer needs. I would check that the backend and any demonstration links work during review. Finally I would select the build, choose Add for Review, and then Submit for Review. Once approved, I would check the chosen release timing and test the public listing, privacy and support links. App Review Guidelines · Submit an app