62 lines
9.2 KiB
Markdown
62 lines
9.2 KiB
Markdown
# Release checklist
|
|
|
|
Status: planning baseline, not submission-ready. Owner: integration/release engineer, with product owner sign-off. Official sources checked 2026-09-16; recheck before submission. A checked list cannot guarantee App Review approval.
|
|
|
|
## 1. Prototype without paid enrollment
|
|
|
|
Xcode development and personal-device testing can begin using a free Apple Account. Apple documents Personal Team limits of 10 App IDs, three test devices per platform, and seven-day provisioning; its account help also lists three installed apps per device. Expect to rebuild/reinstall periodically. Multiple app targets consume signing resources: verify this project's actual iPhone/watch installation on the intended devices before allocating more identifiers. [Membership comparison](https://developer.apple.com/support/compare-memberships/), [account help](https://developer.apple.com/help/account/basics/about-your-developer-account).
|
|
|
|
- [ ] Install a compatible Xcode release and its iOS/watchOS simulator runtimes on a Mac.
|
|
- [ ] Keep signing team and bundle prefix configurable; do not commit a developer's account, certificate, private key, or provisioning profile.
|
|
- [ ] Run shared-package tests and simulator UI checks before device installation.
|
|
- [ ] Install on a paired physical iPhone and Apple Watch; real wrist motion, lifecycle transitions, WatchConnectivity delivery, and local TV access need hardware evidence.
|
|
- [ ] Verify every requested capability is available to the Personal Team; remove nonessential capabilities rather than making a paid feature a prototype dependency.
|
|
- [ ] Keep this stage as personal development. Plan paid enrollment before TestFlight or App Store distribution. Apple's published annual fee is USD 99 or local equivalent where offered. Decide whether the seller should be the individual or a qualifying legal organization before enrollment. [Membership comparison](https://developer.apple.com/support/compare-memberships/).
|
|
|
|
## 2. Hardware feasibility gate
|
|
|
|
These are project acceptance criteria, not claims that the prototype already passes:
|
|
|
|
- [ ] Record tested iPhone model, Watch model, OS versions, TV model/year, Tizen/firmware version, and network conditions.
|
|
- [ ] Demonstrate left/right/up/down wrist gestures reaching the intended TV commands, including left/right wrist configuration and calibration.
|
|
- [ ] Demonstrate neutral motion, return-to-neutral, refractory interval, deliberate arming, visible armed state, and immediate disarm. Ordinary arm motion must not produce repeated commands.
|
|
- [ ] Demonstrate manual button alternatives on both devices. Do not require wrist mobility for essential operation.
|
|
- [ ] Demonstrate pairing approval on the TV under the name **Wristivo**, rejection, token revocation, reconnection, and forgetting a TV. Never simulate successful pairing in live mode.
|
|
- [ ] Measure command latency, false positives, duplicate suppression, battery usage, and thermal behavior against the targets in the test plan; attach the actual results.
|
|
- [ ] Prove behavior when the phone locks, app backgrounds, watch display sleeps, Wi-Fi changes, or TV powers off. Stop gesture capture and clearly report unavailable control when the supported session ends.
|
|
- [ ] No fake workout, audio, location, or other unrelated background activity to keep a remote session alive. Do not promise all-day gesture listening.
|
|
- [ ] Distinguish app-level send success from TV acknowledgement and actual screen response; show honest status.
|
|
- [ ] Publish only tested compatibility claims. A protocol observed on one TV is not proof that every Tizen TV supports it.
|
|
|
|
Apple requires intended use of public APIs and background modes. Its review rules also address power use and accurate metadata. Check sections 2.4, 2.5, and 2.3 when implementing the above project controls. [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/).
|
|
|
|
## 3. Privacy and security gate
|
|
|
|
The intended baseline is local processing, no account, no advertising SDK, and no developer-operated telemetry backend. Treat this as a design target until verified from the shipping build.
|
|
|
|
- [ ] Inventory raw motion samples, calibrated thresholds, gesture events, TV names/IPs, pairing tokens, command history, error logs, diagnostics, support messages, and every SDK/network destination.
|
|
- [ ] For each item, document purpose, location, recipients, retention, deletion, and whether it leaves a device. Review Watch-to-phone and phone-to-TV transfers explicitly.
|
|
- [ ] Keep raw motion ephemeral by default. Any development recording requires deliberate opt-in, visible recording state, bounded retention, and a delete/export control; exclude recordings from release bundles.
|
|
- [ ] Keep pairing credentials in appropriate secure storage, redact logs, scope trust decisions to the selected TV, and test reset/revocation. Do not introduce a global TLS certificate bypass.
|
|
- [ ] Verify actual permission usage and localized purpose strings; request local-network/motion permissions only where the chosen API and platform require them. Test denial, later revocation, and recovery.
|
|
- [ ] Produce the privacy policy from the implemented data inventory, identifying operator/contact, uses, sharing, retention/deletion, consent withdrawal, and support-data handling. Host it at a stable public URL and expose it inside the app and App Store Connect. [App Review preparation](https://developer.apple.com/app-store/review/), [guideline 5.1.1](https://developer.apple.com/app-store/review/guidelines/#privacy).
|
|
- [ ] Reconcile App Store privacy answers with the actual behavior of the app and its partners. Apple's collection definition concerns off-device transmission with developer/partner access beyond servicing the request; local storage alone is not automatically collection under that definition. Do not select “Data Not Collected” without auditing diagnostics, support uploads, and dependencies. [App privacy details](https://developer.apple.com/app-store/app-privacy-details/).
|
|
- [ ] Audit each executable target and dependency for required-reason APIs. Common persistence choices, such as UserDefaults, can introduce required declarations; choose approved reasons matching actual usage rather than copying a generic code.
|
|
- [ ] Add accurate `PrivacyInfo.xcprivacy` files to applicable target resources, verify SDK manifests/signatures where required, generate Xcode's privacy report, and inspect the archive. An empty manifest or `tracking=false` is not evidence of compliance. watchOS is included in required-reason API reporting. [Privacy manifests](https://developer.apple.com/documentation/bundleresources/privacy-manifest-files), [data-use declarations](https://developer.apple.com/documentation/bundleresources/describing-data-use-in-privacy-manifests).
|
|
|
|
## 4. Review package and finished product
|
|
|
|
- [ ] Paid program enrollment, final identifiers/signing, distribution build, archive validation, current SDK submission requirements, age-rating answers, export-compliance answers, support contact/URL, and territory-specific business disclosures are complete. Resolve these from current App Store Connect requirements at release.
|
|
- [ ] Complete the brand/IP gate in [BRAND-AND-IP.md](BRAND-AND-IP.md).
|
|
- [ ] Verify VoiceOver labels, readable text, non-color status cues, comfortable gesture instructions, haptics alternatives, and manual fallback.
|
|
- [ ] Remove placeholders and debug controls; verify clean installation, upgrades, permission-denied paths, network errors, and both supported minimum/current OS versions.
|
|
- [ ] Provide review notes listing tested TV models/firmware, setup steps, on-TV approval, network prerequisites, gesture calibration/arming, lifecycle limits, and known unsupported behavior.
|
|
- [ ] Supply an unedited demonstration video showing the real phone, worn Watch, wrist motions, and TV response. Arrange hardware access if Apple requests it. A difficult hardware setup may require a video or hardware during review. [App Review preparation](https://developer.apple.com/app-store/review/).
|
|
- [ ] Include a clearly labelled **Demo TV — simulated** mode to let users/reviewers inspect pairing guidance and command feedback without a TV. It must never claim real TV connectivity. Explain it in review notes and preserve the same behavior for reviewers and customers. This does not substitute for a complete working app or requested hardware evidence.
|
|
- [ ] Ensure screenshots and descriptions match measured functionality. Keep hardware demonstration footage for review separate from public App Store preview-format requirements.
|
|
- [ ] Keep monetization out of the prototype. Before adding it, review current payment rules and guideline 4.10: built-in sensor access itself must not be the paid product. Review any later remote-app paid feature proposal separately. [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/).
|
|
|
|
## 5. Integration sign-off record
|
|
|
|
For each release candidate, create a dated record containing commit SHA, build numbers, test artifacts, compatibility matrix, privacy report, dependency/license audit, brand clearance decision, open defects, review notes, and responsible sign-offs. No unchecked hardware, privacy, IP, or signing gate should be disguised by a demo or mocked result. The owner chooses submission timing after the integration engineer reports the evidence and remaining limitations.
|