Current verdict

Band Licence is not ready for TestFlight distribution, Google Play testing or public store submission.

In the current development configuration, the mobile readiness report identifies nine structural foundations and three external evidence groups still requiring real completion:

1. trusted production HTTPS and signed verified links;
2. release-signed physical-device and internal-store testing; and
3. store ownership, listings, privacy and governance approval.

The count is a report of repository and environment checks, not a percentage of the total release effort. Run the command again whenever code or protected configuration changes:

pnpm mobile:check

The blocking gate is:

pnpm mobile:release-check

Do not set an environment declaration to true merely to turn a report green.

Evidence principles

Evidence must be:

• specific — identifies the exact host, commit, build, device and policy version;
• repeatable — another authorised reviewer can reproduce the check;
• current — repeated after material code, infrastructure, SDK, permission or policy changes;
• private — keeps credentials, signing material and real student data out of the repository;
• attributable — includes owner, tester/reviewer and date;
• traceable — links a requirement to an artefact and any issue record; and
• truthful — records fail or not-applicable with rationale instead of changing the expected outcome.

Code, a passing static check and a screenshot are useful evidence, but none alone proves secure operation on the final signed release.

Private evidence workspace

Create the ignored evidence records:

pnpm store:evidence:init

Validate the script-enforced minimum:

pnpm store:evidence:check
pnpm store:evidence:check -- --verbose

The checker validates four private JSON records:

The expanded evidence below remains mandatory even where the script does not yet parse every field. Attach or reference it from the private records.

Keep out of the repository:

• passwords and reviewer credentials;
• session tokens and native handoff codes;
• Apple certificates, private keys and provisioning secrets;
• Android upload keys and Play recovery material;
• API keys, recovery codes and account-owner identity documents;
• real student, family, school or attendance data; and
• unrestricted production logs or database copies.

Evidence package identity

Every candidate needs one immutable release identity:

Do not mix evidence from different candidate builds. A code change after testing creates a new candidate unless the release owner documents why it cannot affect the tested boundary.

1. Trusted HTTPS and Verified Links

Required outcome

• One stable root BAND_LICENCE_APP_URL uses a normal-browser-trusted certificate.
• HTTP redirects to HTTPS without sending credentials.
• Secure cookies are enabled.
• The teacher application and public QR process remain route-isolated.
• Apple and Android signing identities are final and organisation-owned.
• Association endpoints serve valid JSON without a redirect.
• Only approved, non-destructive paths are associated.
• Universal Links and App Links open the exact release-signed apps.
• An unverified or unexpected path opens safely in the browser.

Automated and manual checks

Run from a separate trusted computer and network:

pnpm verified-links:check
pnpm shared-host:check
pnpm deployment:check

Then test on signed physical devices:

• fresh install;
• update from the previous production build;
• app running and app terminated;
• link opened from Safari/Chrome, Mail and a QR scan;
• association cache refresh;
• wrong path, wrong subdomain and lookalike hostname;
• Android verification state and installed signing fingerprint;
• Apple associated-domain entitlement in the archived app; and
• the browser fallback when the app is absent.

Evidence

• hostname, certificate issuer, validity and test date;
• browser trust results from a separate mobile network;
• sanitised HTTP response headers and association payload hashes;
• Apple Team ID, bundle ID and archived entitlement reference;
• Android application ID and installed Play App Signing SHA-256 reference;
• device, OS, app build and verification result;
• route-isolation evidence showing the public QR process cannot serve sign-in or teacher pages; and
• reviewer approval.

Stop conditions

Stop release if there is a certificate warning, redirecting association file, wrong fingerprint, link hijack, unexpected deep-linked privilege or teacher route available through the public profile process.

2. Native iOS and Android Projects

What exists

The repository contains genuine SwiftUI and Android projects. They use:

• external system-browser sign-in;
• S256 PKCE and exact state validation;
• fixed verified HTTPS callbacks;
• Keychain or Android Keystore-backed token protection;
• local QR and Code 128 decoding;
• no native school database;
• cleartext disabled on Android; and
• fail-closed placeholder hosts.

Run:

pnpm native:foundation-check

What this does not prove

• organisation signing ownership;
• release compiler settings;
• production host configuration;
• full mobile teacher workflows;
• permission recovery;
• protection from token leakage in device logs, backups or crash reports;
• accessibility;
• dependency and SDK privacy behaviour;
• physical-device functionality; or
• store acceptance.

Required security evidence

Map the signed apps to OWASP MASVS STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE and PRIVACY. At minimum retain:

• compiled entitlements and Android merged manifest;
• release-build debug and logging review;
• storage/backup inspection for the session token;
• proxy test confirming HTTPS-only traffic and no secrets in URLs;
• negative sign-in and verified-link results;
• exported component and intent-filter review;
• dependency inventory and vulnerability review;
• permission inventory with purpose and denial behaviour;
• screenshots/app-switcher/notification privacy review; and
• independent reviewer sign-off.

3. Physical-device and Store Testing

Physical-device functional matrix

The script-enforced device classes are:

• iPhone;
• iPad;
• Android phone;
• Android tablet;
• supported desktop browser; and
• supported mobile browser.

Use the exact release candidates. “Works in simulator” does not pass a physical device row.

Identity and account

Camera, links and documents

Reliability and compatibility

Accessibility

Complete common tasks with:

• VoiceOver, Voice Control and at least 200 percent text on iPhone and iPad;
• TalkBack, Switch Access, font scaling and display scaling on Android phone and tablet;
• external keyboard where supported;
• portrait, landscape and split-screen;
• colour-blind-safe statuses and sufficient contrast;
• Reduced Motion or equivalent; and
• temporary messages announced to assistive technology.

Record platform/device-specific limitations. Do not declare an Apple Accessibility Nutrition Label feature unless all common tasks meet the published criteria.

Child-safety and privacy

• only fictional test students and schools;
• first name plus surname initial wherever a student is displayed;
• no student photos;
• no public child-to-child communication;
• no retained or uploaded camera frames;
• no microphone permission in the first native candidate unless separately approved;
• no analytics, advertising, tracking or advertising identifier;
• no student data in lock-screen notifications, logs or screenshots; and
• QR profile access remains token-bound and narrow: progress and attendance are read-only, while unlocked QR profile sessions have only the documented practice-timer/tracking, sight-reading-result and friend-choice writes.

Internal store testing

Apple

Retain:

• successful signed archive validation;
• TestFlight internal group and exact build;
• tester invitation/access;
• install, update, expiry and crash results;
• export compliance and age rating responses;
• App Privacy draft reconciled to the binary and backend;
• privacy-manifest validation;
• reviewer test account and instructions; and
• final retest after every review-blocking correction.

Google Play

Retain:

• accepted Android App Bundle;
• Play App Signing ownership and certificate evidence;
• internal-test release and exact version code;
• install/update results from Play, not sideload only;
• pre-launch report and resolved findings;
• target API verification;
• Data safety, target audience, content rating and Families-policy decision;
• SDK inventory, including camera/barcode dependencies;
• reviewer test account and instructions; and
• final retest after every policy or functional correction.

Promote in order: Apple internal TestFlight and Play internal testing, then a small approved external/closed cohort, then staged production. Do not use public school data for store review.

4. Store and Governance Evidence

Store ownership and recovery

• Apple Developer and Google Play accounts are controlled by the approved organisation.
• At least two authorised people can recover operational access.
• Roles follow least privilege.
• Signing, API and recovery keys have named custodians and rotation/revocation procedures.
• Tax, banking and legal agreements are complete only if the chosen commercial model needs them.

Listing package

• final app name, subtitle/short description and full description;
• icons, screenshots and feature graphics with fictional data;
• support and accessibility URLs;
• public privacy-policy URL;
• public account-deletion URL;
• copyright and content ownership;
• target audience, age rating and education/school context;
• reviewer account, school and step-by-step instructions;
• explanation of camera scanning and why images are not retained; and
• subscription explanation only if entitlements and purchasing are approved.

Governance approvals

The evidence checker requires approvals for:

• product owner;
• school;
• privacy;
• child safety;
• retention and deletion;
• incident response;
• support and recovery; and
• role and school boundary.

Each approval needs status approved, owner, date and evidence reference. A verbal “looks good” does not pass.

Declaration reconciliation

Compare the exact candidate and backend against:

• Apple App Privacy;
• Apple privacy manifests and included SDK signatures;
• Google Play Data safety;
• target audience/Families answers;
• public privacy policy and terms;
• account deletion and correction process;
• retention and backup behaviour;
• permissions and just-in-time explanations; and
• subscription/billing disclosures.

If any two sources disagree, stop and correct the software or declaration before submission.

Release-candidate approval record

The final sign-off should answer:

Only after the evidence is complete may authorised operators consider these protected environment declarations:

BAND_LICENCE_NATIVE_FUNCTIONALITY_APPROVED=true
BAND_LICENCE_NATIVE_DEVICE_TESTS_PASSED=true
BAND_LICENCE_APPLE_STORE_READY=true
BAND_LICENCE_GOOGLE_PLAY_READY=true
BAND_LICENCE_STORE_LISTINGS_APPROVED=true
BAND_LICENCE_STORE_GOVERNANCE_APPROVED=true

These declarations do not substitute for App Store or Play approval.

Release sequencing and rollback

1. Freeze and identify the candidate.
2. Deploy a backward-compatible server contract.
3. Complete host and link verification.
4. Complete signed device and accessibility testing.
5. Reconcile privacy, audience and store records.
6. Complete TestFlight/Play internal testing.
7. Complete final candidate retest.
8. Approve the protected declarations.
9. Start a small staged release.
10. Monitor authentication failures, server errors, crashes, support contacts and deletion requests.
11. Expand only after the observation window passes.

Stop rollout when:

• sign-in or school boundaries fail;
• camera or link routing exposes unintended data/actions;
• declarations are inaccurate;
• a child-safety or privacy incident is suspected;
• crash/error rate exceeds the approved threshold;
• support cannot respond; or
• rollback cannot be performed safely.

Rollback actions:

• stop the store phased/staged rollout;
• disable native links/sign-in server-side if the boundary is unsafe;
• revoke affected sessions;
• restore the last compatible server runtime if needed;
• keep API compatibility for already installed clients; and
• issue a corrected build.

Unpublishing does not remove installed copies, and binary rollback does not revoke sessions.

Related guides

• Native Device Test Matrix
• Store Submission Worksheet
• Store Privacy Declaration Worksheet
• App Store and Play Store Readiness
• Governance Deployment Gate
• Account and Data Deletion

Official sources

Checked 12 August 2026; store policies change and must be checked again for the exact submission date:

• Apple App Review Guidelines
• Apple App Privacy
• 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 content
• OWASP MASVS