Release RuView NLOS iOS beta through TestFlight

Objective

Publish the RuView NLOS native iOS client to a controlled TestFlight beta so an initial group of 5 to 20 LiDAR equipped iPhone testers can install it without Xcode.

Related implementation: PR 1687

Tester protocol and feedback: Issue 1690

Explainer: https://ruview-nlos.ruv.chatgpt.site

Expected effort

1. First Apple account and app setup: 30 to 60 minutes.
2. Archive and upload: 10 to 20 minutes.
3. Apple build processing: variable and not guaranteed.
4. Internal validation: about 10 minutes per tester.
5. External TestFlight review: variable and not guaranteed.

Inputs

1. A Mac with Xcode 26 or newer.
2. Membership in the Apple Developer Program.
3. Account Holder, Admin, App Manager, or Developer access for build upload.
4. Account Holder, Admin, or App Manager access for external tester groups.
5. Access to branch feat/consumer-nlos-ruview.
6. A LiDAR equipped iPhone Pro or iPad Pro running iOS 16 or newer.
7. A monitored feedback email address.
8. A privacy policy URL owned by RuView.
9. A support contact name, phone number, and email address for Apple review.

Output

1. A signed RuView NLOS build in App Store Connect.
2. A verified internal TestFlight group.
3. An approved external TestFlight group.
4. A controlled invitation link for qualified LiDAR testers.
5. A recorded release decision with build number, test results, known limitations, and rollback owner.

Release invariants

1. Display name is RuView NLOS.
2. Bundle identifier is org.ruvnet.RuViewNLOS.
3. Marketing version starts at 1.0.
4. Build number starts at 1 and must increase for every upload.
5. Minimum deployment target is iOS 16.
6. The camera purpose text must remain present.
7. The app must never claim that public ARKit scene depth is physical NLOS evidence.
8. Every local result must remain labeled direct_depth.
9. Physical NLOS status must remain blocked_raw_transients_unavailable.
10. No signing certificate, provisioning profile, private key, App Store Connect key, or tester email list may be committed to GitHub.
11. Diagnostics must remain local until explicit consent and must remain below 65,536 bytes.
12. The external invitation link must not be published until the internal hardware acceptance test passes.

Step 1: Confirm the source and CI state

1. Open PR 1687.
2. Confirm the latest commit is 4a8c8ea734b09ac5b0e6d4a47705b63f05b41fa1 or a later reviewed commit.
3. Confirm the Consumer NLOS workflow is green.
4. Confirm the native job passed Swift tests, simulator build, and unsigned generic device archive.
5. Confirm the web job passed tests, type checking, lint, browser export, and Expo iOS export.
6. Record the exact commit in a release comment on this issue.

Exit criterion: the release commit is immutable, reviewed, and all required feature checks are green.

Step 2: Prepare the Apple account

1. Sign in to Apple Developer and App Store Connect with the RuView organization account.
2. Confirm all current Apple agreements are accepted.
3. Confirm the person uploading has the required role.
4. In Certificates, Identifiers and Profiles, create or confirm an App ID for org.ruvnet.RuViewNLOS.
5. Keep automatic signing enabled for the first beta unless RuView already operates a governed manual signing process.
6. Confirm that no personal Apple team is selected by mistake.

Exit criterion: the App ID belongs to the intended RuView legal entity and the release operator can sign an archive.

Step 3: Create the App Store Connect record

1. Open App Store Connect.
2. Select Apps.
3. Select the add control and choose New App.
4. Choose iOS.
5. Enter RuView NLOS as the name.
6. Select the primary language.
7. Select the bundle identifier for org.ruvnet.RuViewNLOS.
8. Enter a unique SKU such as ruview.nlos.ios.001.
9. Restrict user access if the organization uses scoped App Store Connect access.
10. Save the record.

Exit criterion: the app record exists and its bundle identifier exactly matches the Xcode project.

Step 4: Prepare TestFlight metadata

1. Open the app record.
2. Select TestFlight.
3. Open Test Information.
4. Enter this beta description:

RuView NLOS validates the public LiDAR and ARKit capabilities available on supported Apple devices. It measures visible scene depth, motion stability, tracking quality, and thermal state. This beta does not claim around the corner reconstruction from Apple LiDAR because public Apple APIs do not expose the raw photon timing samples required by the research pipeline.

5. Enter this feedback focus:

Complete the 15 second calibration and 30 second visible wall scan. Report device model, iOS version, completion status, average frame rate, depth coverage, tracking warnings, thermal warnings, and whether the diagnostic share flow worked. Do not include photographs, raw depth, credentials, or private location information.

6. Enter the monitored feedback email.
7. Enter the review contact information.
8. Add the explainer URL.
9. Add reviewer notes explaining that camera permission is required by ARKit, images are not displayed or stored, diagnostics are aggregate and local, and the NLOS server connection is optional.
10. If Apple requests credentials for an optional server, create a revocable review account with minimum permissions. Never place production credentials in reviewer notes.

Exit criterion: all required beta metadata is complete and a reviewer can understand the camera and LiDAR behavior without guessing.

Step 5: Decide export compliance accurately

1. Review the app encryption behavior before answering App Store Connect.
2. The current client uses Apple platform security services and encrypted network transport.
3. Confirm whether any custom or nonstandard cryptography has been added since PR 1687.
4. Answer the App Store Connect encryption questions based on the released binary and the organization legal determination.
5. Record the decision and owner in this issue.
6. Do not copy a previous answer without comparing the current binary.

Exit criterion: export compliance is answered by an accountable release owner and matches the binary.

Step 6: Configure signing in Xcode

1. Clone or update the RuView repository on the Mac.
2. Check out the approved release commit.
3. Open ui/ios-nlos/RuViewNLOS.xcodeproj.
4. Select the RuViewNLOS target.
5. Open Signing and Capabilities.
6. Select the RuView development team.
7. Confirm the bundle identifier is org.ruvnet.RuViewNLOS.
8. Confirm automatic signing resolves without errors.
9. Confirm version is 1.0.
10. Set the build number to a value greater than every prior upload.
11. Select a connected LiDAR equipped iPhone.
12. Build and run once on that device.
13. Grant camera permission and confirm the setup screen loads.

Exit criterion: Xcode reports no signing error and the app launches on a physical LiDAR device.

Step 7: Run the physical device gate before upload

1. Start the 45 second validation.
2. Point the phone at a well lit textured surface for the 15 second calibration.
3. Keep a matte visible wall between 0.5 and 4 metres away during the 30 second scan.
4. Move the phone slowly, roughly 5 to 15 centimetres per second.
5. Confirm frames per second is visible and stable.
6. Confirm depth coverage remains above zero.
7. Confirm tracking reaches normal for part of the run.
8. Confirm the result says direct_depth.
9. Confirm the physical NLOS status says blocked_raw_transients_unavailable.
10. Enable export consent only after completion.
11. Prepare the JSON.
12. Confirm the file is smaller than 65,536 bytes.
13. Inspect it and confirm there is no image, raw depth map, camera transform, endpoint, token, location, or stable analytics identifier.
14. Cancel a second run and confirm sensor activity stops.
15. Deny camera permission once and confirm the app fails safely with understandable recovery instructions.

Exit criterion: all 15 checks pass on at least one supported physical device.

Step 8: Archive and validate

1. In Xcode, select Any iOS Device as the destination.
2. Select Product, then Archive.
3. Wait for Organizer to open.
4. Select the new archive.
5. Select Validate App.
6. Choose the RuView distribution identity and automatic signing.
7. Resolve every error.
8. Review warnings individually. Do not ignore privacy, entitlement, architecture, or signing warnings.
9. Record the version, build number, commit, Xcode version, macOS version, and operator in this issue.

Exit criterion: Xcode validation succeeds with no unexplained release warning.

Step 9: Upload to App Store Connect

1. In Organizer, select Distribute App.
2. Choose App Store Connect.
3. Choose Upload.
4. Keep symbol upload enabled.
5. Confirm automatic signing.
6. Review the final bundle identifier, version, build number, entitlements, and destination.
7. Select Upload.
8. Wait for Xcode to confirm upload.
9. Open App Store Connect and wait for processing to finish.
10. Review any processing email or warning.
11. Do not upload the same build number again. Increase the build number for every retry.

Apple documents Xcode, Transporter, and the App Store Connect API as supported upload paths. Use Xcode for this first controlled release: Apple upload guidance.

Exit criterion: the build status is ready for internal testing.

Step 10: Run an internal TestFlight pilot

1. Create an internal group named RuView NLOS Release Gate.
2. Add 2 to 5 trusted App Store Connect users.
3. Add the uploaded build.
4. Enter the feedback focus from Step 4.
5. Ask each tester to install TestFlight from the App Store.
6. Ask each tester to accept the invitation and install RuView NLOS.
7. Require at least one LiDAR equipped device.
8. Have every tester complete the physical device gate from Step 7.
9. Collect crashes, sessions, screenshots of failures, and consented diagnostic JSON.
10. Record results by device model and iOS version.

Apple supports up to 100 internal testers: Apple internal tester guidance.

Exit criterion: at least 3 internal runs pass, including 1 LiDAR device, with zero crash and zero privacy boundary violation.

Step 11: Create the external beta

1. Create an external group named RuView NLOS LiDAR Pilot.
2. Add the approved internal build.
3. Enter What to Test using the feedback focus from Step 4.
4. Submit the build for TestFlight App Review.
5. Wait for approval before inviting external testers.
6. If rejected, read the exact rejection, correct metadata or code, increase the build number, upload again, and record the resolution here.
7. After approval, create a public invitation link or invite named testers by email.
8. Prefer a controlled public link limited to 20 testers for the first cohort.
9. Apply device and OS criteria when App Store Connect offers them.
10. Paste the approved invitation link into Issue 1690 and the explainer only after the internal gate passes.
11. Do not use the generic TestFlight App Store link as if it were the RuView invitation link.

Apple requires an internal group before an external group and permits up to 10,000 external testers: Apple external tester guidance.

Exit criterion: 5 to 20 qualified external testers can install the approved build through the real RuView invitation link.

Step 12: Monitor the pilot

1. Review TestFlight crashes, sessions, and feedback daily during the first 7 days.
2. Triage Issue 1690 daily.
3. Track these measures:

Measure	Release threshold
Installation success	at least 90 percent
Validation completion	at least 80 percent
Crash free runs	at least 99 percent
Diagnostic generation	at least 95 percent of completed runs
Diagnostic size	below 65,536 bytes in every run
Privacy boundary violations	zero
Incorrect NLOS claims	zero
Supported device depth coverage	above zero in at least 95 percent of completed runs

4. Segment failures by device model, iOS version, permission state, thermal state, and tracking state.
5. Do not combine unsupported devices with LiDAR devices when calculating depth success.
6. Stop expanding the cohort if crash free runs fall below 99 percent or any privacy invariant fails.

Exit criterion: all thresholds hold for at least 20 completed runs across at least 3 device configurations.

Rollback procedure

1. In App Store Connect, open TestFlight and select the affected build.
2. Stop testing the build.
3. Disable the public invitation link if exposure must stop immediately.
4. Remove the build from all testing groups.
5. Add a visible notice to Issue 1690.
6. Revoke any review or test server credentials involved.
7. Preserve crash reports and consented aggregate diagnostics.
8. Open a blocking defect linked to this issue.
9. Correct the problem and release a new build number.
10. Never attempt to replace an uploaded binary under the same build number.

Troubleshooting

Xcode cannot sign

1. Confirm the selected team is the RuView organization.
2. Confirm the App ID exists and exactly matches org.ruvnet.RuViewNLOS.
3. Confirm the operator has certificate access.
4. Refresh accounts in Xcode settings.
5. Remove only stale local derived build data. Do not delete organization certificates without approval.

App Store Connect does not show the upload

1. Confirm Xcode reported upload success.
2. Confirm the app record bundle identifier matches the binary.
3. Wait for Apple processing.
4. Check the email address associated with App Store Connect for processing errors.
5. Confirm the build number was unique.

External group cannot use the build

1. Confirm an internal group exists.
2. Confirm the build was not uploaded as TestFlight Internal Only.
3. Confirm beta metadata and review contact information are complete.
4. Confirm TestFlight App Review approved the build.
5. Confirm the device and OS criteria match the build.

Scene depth is unavailable

1. Confirm the device has LiDAR.
2. Confirm camera permission is enabled in Settings.
3. Use a matte, visible, textured surface.
4. Improve lighting.
5. Keep the surface between approximately 0.5 and 4 metres away.
6. Restart the validation with the app in the foreground.

Tracking remains limited

1. Slow movement to approximately 5 to 15 centimetres per second.
2. Add visible texture near the wall.
3. Avoid reflective glass and featureless white surfaces.
4. Keep the app active.
5. Let the device cool for 5 to 10 minutes if thermal state is serious or critical.

Biggest uncertainty

Public Apple APIs expose derived visible scene depth, not the raw photon timing histograms required for the MIT physical NLOS technique. TestFlight cannot remove that hardware API boundary.

Fix path: validate the public ARKit capture and diagnostic experience on iPhone now, then connect RuView to an external supported transient sensor for physical NLOS reproduction. Keep those evidence classes separate.

Final acceptance test

A new tester with no Xcode installation opens the real RuView TestFlight invitation, installs the app in under 5 minutes, reads the explainer, grants camera permission, completes the 45 second validation, sees direct_depth and blocked_raw_transients_unavailable, generates a diagnostic smaller than 65,536 bytes only after consent, and submits usable feedback to Issue 1690.

Start by opening PR 1687 and checking the approved commit and Consumer NLOS workflow, then open ui/ios-nlos/RuViewNLOS.xcodeproj in Xcode. Follow the physical device gate before archiving and uploading to App Store Connect. Done means the internal TestFlight gate passes and the approved external invitation is ready for qualified LiDAR testers, with results recorded in this issue and Issue 1690.