Platform-policy and target-SDK assumptions were last rechecked on 21 August 2026. Recheck the live Apple and Google requirements against the exact release, storefronts, audience, and commercial model before submission.

Release verdict

Band Licence is not ready for App Store or Google Play submission.

The shared web service and unsigned native foundations are useful preparation. They do not yet establish:

• final organisation-owned store accounts and signing;
• a production-trusted host with verified app links;
• complete native teacher workflows;
• release-signed physical-device testing;
• approved target-audience and child-safety treatment;
• final privacy policy and terms;
• reconciled Apple App Privacy and Google Data safety answers;
• production account recovery, support and deletion completion;
• a decided subscription/purchasing model; or
• store reviewer evidence.

Run during development:

pnpm native:foundation-check
pnpm mobile:check

Run the blocking gate only against the final protected environment:

pnpm mobile:release-check

Implemented store foundation

Decisions required before store setup

Record each decision with owner, date, evidence and change impact.

Product and distribution

• Is the first release public, unlisted/custom, managed school distribution or a limited teacher beta?
• Which legal entity owns the product, domain, Apple Developer account, Play Console account and signing recovery?
• Is the intended user an adult teacher/administrator, a future Student-role user (shown as a Player Account), a future Parent/Carer-role user or more than one audience?
• Will students use a store-installed app directly, or only teacher-controlled browser/QR workflows in the first release?
• Which countries/regions and school systems are in scope?

Accounts and sign-in

• Keep registration invite-only or introduce approved account creation?
• Which roles are enabled in the binary?
• Is the existing first-party account system the only sign-in method?
• If a third-party/social login is added, does Apple Guideline 4.8 require an equivalent privacy-preserving login option?
• What minimum app version and server compatibility period applies?

Band Licence currently uses its own account system. Do not claim Sign in with Apple support. Reassess Apple’s current login rule before adding any third-party identity provider.

Commercial model

• School invoice, teacher subscription, organisation agreement, consumer subscription or a combination?
• Which party is the purchaser and which account receives entitlement?
• Does either store require its in-app purchasing system for the selected digital access?
• What are trial, renewal, cancellation, refund, grace, transfer and failed payment rules?

Until approved, the binary and listing must contain no purchase control, pricing promise, free-trial promise or subscription product.

Child and education audience

• Is the store listing targeted to children, adults, or mixed ages?
• Is Apple’s Kids Category intended?
• Which Google Play target age groups are accurate?
• What school authority, consent and safeguarding basis applies?
• Is any child-facing account or communication enabled?

Do not choose an adult-only store audience merely to avoid child-policy work if the app or listing is actually designed for students. Likewise, do not select a child audience casually: it changes content, data, link, SDK, advertising and commercial requirements.

Apple App Store workstream

Account and identity

• Use an Apple Developer organisation account where that matches the approved legal entity.
• Confirm Account Holder, Admin, App Manager, Developer, Finance and support access use least privilege.
• Record at least two-person recovery arrangements.
• Reserve the final bundle identifier and app record.
• Protect distribution certificates, API keys and recovery material outside source control.
• Record the final Team ID, bundle ID and Associated Domains entitlement.

Build and binary

• Use the currently required Xcode and platform SDK at submission time.
• Set production origin and associated domain in protected Release configuration.
• Ensure the archive contains the intended camera purpose text and no microphone, tracking or other unused purpose string.
• Add a valid PrivacyInfo.xcprivacy for the app and reconcile every included third-party SDK and required-reason API.
• Inspect the archived entitlements, Info.plist, symbols, signing and dependencies.
• Validate and upload the exact candidate.
• Test install and update through TestFlight on a real iPhone and iPad.

App Review Guidelines

Review at least:

• 1.3 Kids Category, if applicable;
• 2.1 completeness and functional review access;
• 2.3 accurate metadata;
• 3.1 payments and subscriptions, if applicable;
• 4.2 minimum functionality—do not submit a repackaged website;
• 4.8 login services if third-party login exists;
• 5.1 privacy, data minimisation, consent and account deletion; and
• current education/business exceptions and requirements.

The first store candidate must provide enduring native value. Secure sign-in and a scanner foundation alone are not an adequate claim that teacher workflows are complete.

Privacy and deletion

• Publish an easily accessible privacy policy in App Store Connect and in the app.
• Describe all app, backend and third-party SDK data, purposes and sharing.
• Explain retention, deletion, consent withdrawal and correction.
• Complete App Privacy for the most inclusive behaviour across the submitted Apple platforms.
• If account creation is available, let the user initiate complete account deletion inside the app; simple deactivation is insufficient.
• Make any legally required retention clear without using it as a blanket reason to retain all school data.

The existing request/review scaffold needs a release test from request through identity confirmation, scope decision, completion, notification and audit.

Accessibility

Before publishing Apple Accessibility Nutrition Labels:

• identify all common tasks, including first launch, login, settings, permission recovery and any purchase;
• test VoiceOver, Voice Control, Larger Text, sufficient contrast, differentiate-without-colour and Reduced Motion on iPhone and iPad;
• use Xcode accessibility audits plus manual assistive-technology testing; and
• claim only features that allow every common task on that device type.

Accessibility metadata must remain accurate after updates.

Review package

• fictional reviewer school and account;
• exact step-by-step sign-in instructions;
• explanation of account invitation and verification;
• camera scan steps and a fictional QR/Code 128 sample;
• explanation that camera images are decoded locally and not retained;
• server availability throughout review;
• contact person able to respond;
• notes for any hardware, school-role or subscription dependency; and
• screenshots containing no real student or school data.

Google Play workstream

Account, identity and signing

• Use the approved legal entity’s Play Console account and complete developer verification.
• Use least-privilege users and documented recovery.
• Reserve the final application ID.
• Enable Play App Signing and distinguish the app-signing key from the upload key.
• Put the Play App Signing certificate SHA-256 fingerprint in the production association configuration.
• Protect upload and API credentials outside the repository.

Build and target API

The project currently compiles and targets API level 36. Google’s published schedule says that from 31 August 2026, new mobile apps and updates must target Android 16/API level 36 or higher, subject to Google’s current exceptions and any later change. Existing availability has a separate API 35 rule.

Before every submission:

• recheck the current target API policy;
• generate the release Android App Bundle;
• inspect the merged manifest and dependency list;
• confirm only CAMERA and ordinary network access are present;
• confirm android:allowBackup remains false and cleartext remains disabled;
• verify final application ID, origin and host;
• upload to internal testing;
• test the Play-delivered build and signing identity; and
• review the pre-launch report.

Data safety and SDK review

Google requires complete Data safety information for the app and third-party SDKs. Record:

• account identifiers and school-role data;
• student and attendance data handled by the shared service;
• device session token storage;
• camera access and local frame processing;
• whether any crash, diagnostic or device data is sent;
• encryption in transit and deletion mechanisms;
• every dependency/SDK, including CameraX and ML Kit;
• whether data is collected, shared, optional or required; and
• the precise purpose for each declared data type.

An SDK’s marketing description is not enough. Review its current developer documentation, compiled behaviour and data-safety guidance for the exact version.

All apps published beyond internal-only testing need a Data safety form as required by current policy, and even a no-data app still needs the appropriate form and privacy-policy link.

Account deletion

If users can create accounts in the app, Google requires:

• an in-app path to request deletion of the account and associated data; and
• a public web resource for the same purpose.

The listing answers, public /account-deletion page, in-app request and actual operations process must agree.

Target audience and Families policy

• Complete target audience and content accurately.
• Complete content rating and ads declarations.
• If any selected audience includes children, apply the current Families requirements to content, SDKs, data, links and commercial features.
• Disclose collection of personal/sensitive child data, including authentication and camera sensor data where policy requires.
• Keep advertising and advertising identifiers absent.
• Keep social/freeform communication absent.
• Require appropriate adult/school control before any future child-facing exchange of personal information.

Device quality and accessibility

• test a Play-delivered release on phone and tablet;
• test adaptive layouts, rotation, resize and split-screen;
• test TalkBack, Switch Access, font/display scaling, contrast and touch targets;
• run Accessibility Scanner/Compose checks and manual user testing;
• verify permission denial and settings recovery; and
• record differences across supported Android versions.

Cross-store privacy inventory

Complete this from the exact release, not intention:

Store metadata package

Prepare:

• app name and unique proposition;
• Apple subtitle and Google short description;
• full description focused on actual current features;
• keywords/category where applicable;
• accurate target audience and school context;
• version release notes;
• icon and platform-specific screenshots;
• support URL and staffed contact;
• privacy-policy URL;
• account-deletion URL;
• optional accessibility URL with tested limitations;
• copyright/rights evidence; and
• review notes and fictional credentials.

Every screenshot must:

• use fictional demonstration data;
• show the visible prototype label if the build remains a prototype;
• avoid real names, schools, attendance, QR credentials and notifications;
• match the submitted platform and current UI; and
• avoid unimplemented feature or pricing claims.

Subscription and payment gate

Do not create store products until:

1. purchaser and entitlement owner are decided;
2. school invoice versus consumer digital purchase is reviewed against both stores’ current rules;
3. backend entitlement states exist independently of one device;
4. purchase verification is server-side;
5. restore-purchases and cross-device access are defined;
6. trial, renewal, grace, failure, cancellation, refund and transfer states are tested;
7. family/student purchase controls are approved;
8. terms and support processes are final; and
9. Apple/Google disclosure text has been legally and commercially reviewed.

Do not steer users around store purchasing rules or claim an exception without recorded current-policy advice.

Rejection-prevention review

Stop submission if:

• reviewer cannot reach the host or sign in;
• app offers only a thin web wrapper or incomplete foundation;
• screenshots/listing promise future features;
• camera purpose or privacy declaration differs from runtime;
• account deletion cannot be initiated and completed as declared;
• a student/child audience is misclassified;
• real student data appears in review material;
• accessibility claims have not been tested across common tasks;
• subscription access cannot be restored or reconciled;
• a third-party SDK is absent from privacy/data-safety review;
• Android link fingerprint uses the upload key instead of installed signing identity;
• Apple association entitlement or host file is wrong;
• production support is not staffed; or
• rollback and session kill switches have not been rehearsed.

Submission sequence

1. Approve audience, distribution, account and commercial decisions.
2. Finish useful native workflows.
3. Complete trusted host and signed links.
4. Freeze the exact release candidate.
5. Run static, unit, build, security and privacy checks.
6. Test signed candidates on all real form factors.
7. Complete accessibility audits.
8. Reconcile policy, privacy and deletion records.
9. Upload to TestFlight internal and Play internal testing.
10. Correct findings and retest the exact candidate.
11. Complete store listing/reviewer material.
12. Run pnpm store:evidence:check and pnpm mobile:release-check.
13. Obtain named release/governance approval.
14. Submit with a monitored server and support contact.
15. Use phased/staged rollout and an observation window.

Post-release and rollback

• Monitor sign-in failures, revoked sessions, HTTP errors, crashes, support requests and deletion requests without adding behavioural tracking.
• Pause staged rollout for authentication, privacy, school-boundary or child-safety failures.
• Disable native links/sign-in server-side if callback safety is affected.
• Revoke affected sessions.
• Keep the previous compatible backend and mobile release artefacts.
• Publish correction notes and update store privacy/audience answers when behaviour changes.

Unpublishing does not remove installed apps. An app update cannot be assumed to reach every device immediately.

Related guides

• Mobile Client Architecture
• Store Release Evidence
• Store Submission Worksheet
• Store Privacy Declaration Worksheet
• Account and Data Deletion
• Subscription Model Readiness

Official sources

Checked 12 August 2026. Recheck on the submission date:

• Apple App Review Guidelines
• Apple App Privacy details
• Apple privacy manifests
• Apple account deletion
• Apple Accessibility Nutrition Labels
• Google Play Data safety
• Google Play account deletion
• Google Play target API requirements
• Google Play target audience and app content
• Google Play Developer Program Policies
• Android accessibility testing
• Android large-screen guidance