KTP Life App Support and Releases

Current release status

Item	Status
Distribution	TestFlight beta
Status date	September 2, 2026
Intended audience	Approved KTP testers; exact chapters and roles not yet documented here
Current build/version	Needs confirmation from the release owner
Android beta	Not documented
Production/store launch	Not announced
Feedback route	Needs confirmation; use the Technology route in the National Organization Map until published

The supplied client documentation reports different application and package version values. The release team should choose one authoritative version workflow and prevent drift in continuous integration.

Submit useful beta feedback

Include:

• build number;
• device model and operating-system version;
• chapter and requester role;
• workflow affected;
• expected and actual behavior;
• time, frequency, and whether the issue is still happening;
• safe reproduction steps;
• impact and any deadline; and
• a redacted screenshot only when it contains no personal, restricted, credential, invitation, or recovery information.

Severity guide

Severity	Example impact	Initial action
Critical	Suspected data exposure, compromised elevated access, or organization-wide outage during a required deadline	Use the restricted urgent route immediately and begin the incident process
High	A chapter cannot complete an approved time-sensitive workflow and no safe workaround exists	Notify Technology with build, deadline, and scope; assign an owner promptly
Normal	A workflow is degraded or confusing for some testers and a safe workaround exists	Submit through the standard beta route with reproduction details
Improvement	Usability, accessibility, documentation, or feature request	Record the underlying member need for product review

Severity reflects impact, not frustration or fault.

Beta release flow

1. Product Council approves the intended outcome and scope.
2. The owning engineering team implements the change with IAM or data review when required.
3. Automated lint, type, and test checks pass.
4. Quality and Accessibility completes the applicable device and regression plan.
5. Product, privacy/data, support, and release owners review affected workflows.
6. Release Engineering creates the TestFlight candidate.
7. Approved testers validate acceptance criteria and known-risk areas.
8. The release owner promotes, pauses, or rolls back the build.
9. Documentation and release notes are updated with public-safe details.

Production-readiness gates

• [ ] Official product owner, technical owner, and release authority recorded
• [ ] Canonical client, backend, calendar-sync, and dashboard sources owned by the organization
• [ ] Versioned backend migrations and authorization policies reproducible and tested
• [ ] Privacy notice, data map, consent, visibility, retention, correction, and deletion approved
• [ ] Authentication, role changes, RSVP, attendance, uploads, and notifications tested on supported devices
• [ ] Accessibility review completed against adopted criteria
• [ ] Support, incident, rollback, monitoring, and recovery runbooks exercised
• [ ] App-store ownership, signing, recovery, and two-person continuity confirmed
• [ ] Beta exit criteria met across representative chapters
• [ ] Member-facing onboarding and known limitations published

Public release-note template

## [Version/build] — [YYYY-MM-DD]

- Status: [TestFlight beta / Released / Paused / Rolled back]
- Audience: [Approved public-safe description]
- Summary: [What changed and why]
- Chapter action: [Required action or “None”]
- Workflows affected: [List]
- Privacy or access change: [None or approved summary]
- Known limitations: [Public-safe list]
- Support route: [Approved role or public channel]

Current public release note

TestFlight beta — active September 2, 2026

• Status: Beta testing
• Summary: The documented client supports chapter selection and authentication, member profiles and network search, events and RSVP, QR attendance, notification registration, and offline-aware data refresh.
• Audience: Approved KTP testers.
• Known documentation gaps: Build number, participating chapters, tester eligibility, Android plan, feedback route, response targets, and production exit criteria.
• Chapter action: Do not distribute invitation links. Chapters interested in testing should use the National Technology routing guidance.

Maintenance calendar

Cadence	Review
Weekly during beta	New feedback, critical/high issues, build status, and tester communication
Per build	Scope, automated checks, regression evidence, access/data changes, and release note
Monthly	Support themes, adoption outcomes, ownership, accessibility, and risk
Each semester	Team assignments, access, roadmap, beta chapters, documentation, and handoff
Annually	Product purpose, cost, platform ownership, privacy, retention, security, and continued value