React Native application

React Native application

Application overview and supported platforms

The PlayHub mobile application connects to the same PlayHub installation as the website through the versioned /api/v1 API. It combines video and Shorts playback, creator profiles, discovery, libraries, community posts, messages, notifications and creator tools. Available screens depend on the installed website, account permissions and the capabilities returned by the server.

Use the website documentation to install the backend and the API reference for endpoint methods, parameters, schemas and authentication. Live services have their own installation and capability guide.

Requirements and deployment prerequisites

A working PlayHub backend

• Deploy the current website code and database migrations, including native sessions, version policies and the capabilities required by the features you enable.
• Use PHP 8.3 or newer supported by the website package. The native API baseline was exercised on PHP 8.3.33; check the website guide for the complete PHP extension and service requirements.
• Provide an API origin that the target device can resolve and reach over trusted HTTPS. Production endpoints must use public DNS and a valid trusted certificate.
• Set independent, strong backend APP_KEY and PLAYHUB_NATIVE_HASH_KEY values. Keep these values on the server.
• Configure exact social-login callback allowlists, permitted CORS origins and the platform version policies for each client you intend to support.
• Run healthy background queue workers and FFmpeg/FFprobe for upload processing. Verify media storage, protected delivery, CDN signatures and byte-range requests.
• Configure SMTP, SMS and social providers only for the login or registration methods you enable. Live viewing and publishing also require the configured LiveKit services.
• If enabling native push, configure the appropriate FCM/APNs credentials and required tables, and supervise a worker for the configured push queue, which defaults to push. A worker listening only to videos,default does not deliver push jobs.

The application project and build tools

Work from the supplied react-native-app project, including its lockfile, local native modules, Expo plugins, configuration files and package scripts. You need npm and a Node.js version compatible with that package, an Android SDK/build environment for Android, and an Apple build environment or EAS Build for iOS. Signing credentials, native identifiers and store configuration belong to your deployment.

The documentation archive does not contain the application package itself or specify a universal Node, JDK or Android SDK version. Use the requirements pinned by the actual application package rather than upgrading native dependencies independently. The iOS guide lists the evidenced iOS profiles and commands.

Install and prepare the application

Google IMA SDK and advertising terms

1. Install the supplied package

Open a terminal in the supplied react-native-app directory and install the dependencies from its lockfile:

cd react-native-app
npm ci

Keep the package's postinstall step enabled. The recorded project uses guarded, version-specific native and LiveKit patches; a dependency-only install that skips those steps may omit required fixes. If installation reports unsupported versions or changed source anchors, resolve the package mismatch before building.

2. Configure the target environment

Review app.settings.json, app.config.ts, eas.json and the package's environment configuration. Set EXPO_PUBLIC_API_BASE_URL to the real HTTPS API endpoint for the selected deployment, ending in /api/v1. Configure the appropriate native application identifier, branding, provider player IDs and EAS project before producing an artifact. See configuration.

3. Produce a native development build

Use the supplied project's native build scripts and Expo configuration. The recorded Android workflow uses tools/build-android-windows.ps1; its optional -ManifestOnly mode checks the merged release manifest without producing a signed release. Generate native projects from the persistent configuration and plugins so camera, microphone, MediaProjection and network security settings survive the next prebuild.

The documented application includes native playback, advertising, Cast, AirPlay and real-time media modules. Use a compatible native development build for those integrations. A development client requires Metro; a standalone artifact has a different build profile. For iOS, follow the exact profile and command guide.

Standard Expo CLI workflow for local Android development

After installing the locked package and configuring its native plugins, Android Studio/SDK and device, Expo CLI can compile and install a debug build. Connect a phone with USB debugging enabled, or start an emulator:

npx expo run:android --device

This starts Metro after installation and generates native directories if absent. For subsequent JavaScript-only work, start Metro with the command below. Native/configuration changes require regeneration through the package's persistent plugins and a rebuild. These are the standard Expo local-build steps; prefer the supplied Windows helper when it handles project-specific preparation.

npx expo start --dev-client

PlayHub includes custom native video, LiveKit and provider modules, so use its own native development build. See Expo development builds for device/emulator setup.

4. Verify the installed app

• Confirm the app reaches its intended /api/v1/bootstrap using normal certificate verification.
• Check branding, enabled features, minimum-version handling and maintenance messages before signing in.
• Sign in, restart the app and confirm secure session restoration. Test logout and account changes without retaining another account's private data.
• Play a known compatible native video, seek, pause, leave playback and verify media stops when closed. Test each enabled external provider separately.
• Test permission denial and permission grants, then upload or use Live only when those features and their backend dependencies are enabled.
• Validate the final signed artifact on the supported devices. A successful JavaScript export or debug manifest check does not replace native build and device testing.

For an existing installed development app, the recorded Android workflow used adb install -r with the corrected APK and retained the signed-in session. Use the APK generated for your own build and compatible signing identity; this is not a store release procedure.

5. Prepare Android distribution

Select the Android release profile supplied in eas.json, configure your approved application ID and public API, and complete the package's release checks. Use your publisher's signing keystore, preserve it for upgrades, and increase the Android version code for each distributed update. Build a signed AAB for Google Play or an APK profile for authorized direct installation; a debug APK is not a store artifact. The recorded Android development identity used com.playhub.mobile.dev, version name 1.0.0 and version code 1.

Follow the supplied package's Android build command/profile and EAS signing/build setup. Validate the actual signed artifact on target devices, with bundled JavaScript and no Metro, before distributing. Verify upgrade/session persistence, camera/microphone denial and recovery, playback, background cleanup, deep links, privacy declarations, and configured push delivery. Store submission is separate from successful compilation.

Configure connections, identity and services

Runtime configuration and version policies

At cold start the app calls GET /bootstrap. Enforce maintenance and unsupported/required-update states before normal navigation. Build sign-in options from authentication, registration from the returned policy, and screens from features, playback, uploads and advertising. Refresh this private, 60-second-cacheable document after sign-in, app upgrades and foregrounding when stale.

The server supports version policies for ios, android, android-tv, tvos, tizen and webos. The administrator version-policy routes require server-side authorization; the consumer app does not gain administration privileges from capability discovery.

Permissions and network security

Request camera and microphone access when the user enters a feature that needs them. The Android capture-permission correction keeps the image-picker and WebRTC plugin descriptions consistent so prebuild does not remove required permissions. After a new permission grant, Go Live requires a fresh Test action before capture starts.

Production network security uses system certificate authorities and denies cleartext transport. The existing Android development certificate trust is confined to debug configuration. Configure an actual development certificate and device trust where required; never bypass TLS or hostname verification to connect the application.

Features and how to use them

Home, Explore, More, Library, profiles, Creator Studio and Settings provide entry points appropriate to the signed-in account. Server-side feature flags, ownership, publishing policy and quotas determine which controls are shown and which requests are permitted.

Discover and watch

Library, creators and communities

• Library: Watch Later, Liked Videos, purchased videos, subscriptions, watch history and Continue Watching are scoped to the current account.
• Playlists: create and edit playlists, manage privacy and metadata, add or remove permitted videos, and open visible public or owned private lists.
• Favorites: save creator channels and browse their latest public content. Favorites remain separate from channel subscriptions.
• Creator profiles: Videos, Shorts, Live/replays, playlists, About and community content; permitted subscribe, favorite, message, report and share actions.
• Communities: creator channel posts with search, latest/relevant discovery, suggested channels, hashtags, upcoming events, following and type filters. Joining means subscribing to the creator channel.
• Community creation: text, link, image, poll, video and event posts, safe link previews, supported media validation, owner editing/deletion, polls and permitted voter lists.
• Community interaction: likes, replies, bookmarks, share counts, image galleries and context-aware comment navigation. Locked paid photos reveal only media the account is allowed to access.
• Comment moderation: an owner-scoped video/community comment inbox with permitted pin, delete, mute and thread-navigation actions.
• Messages: native private conversations, recipient lookup, message lists, sending and read state when the current backend enables messaging and permits the recipient relationship.
• Notifications: in-app inbox, unread count, preferences, read/delete actions and authorized destinations. Remote push delivery has separate availability; see notifications and push.

Communities use creator channel posts; standalone groups, separate membership directories and community rules are not part of the documented backend model. Owner profile layout/pinning, advanced preferences and some provider workflows use the existing website.

Creator Studio and publishing

• Dashboard: current account/channel capabilities and shortcuts to publishing, content, analytics, growth and earnings.
• Upload and import: resumable video/Short uploads with metadata, thumbnail, captions, chapters and asynchronous processing; configured provider URL import using existing server validation.
• Content management: actual status/type/monetization filters, metadata search, server counts and sorting, multi-select visibility/deletion with confirmation and partial-failure recovery, series assignment and playlist shortcuts.
• Video editing: supported metadata, visibility, scheduling, artwork, captions, chapters and monetization settings. Paid pricing and unsupported advanced per-video controls remain website workflows.
• Channel settings: name, slug, biography, About, website/social links and artwork, with unsaved-change handling.
• Analytics: supported period/date/comparison controls, cumulative content views, signed-in identities represented in saved progress, saved-progress totals/averages, engagements, subscribers, daily returned series, top content and content/visibility mixes.
• CSV export: share the actual returned daily metrics; unavailable per-video subscriber values remain blank.
• Growth Hub: current advisory information and shortcuts to upload, Shorts, content, analytics, profile and community tools.
• Go Live: configured metadata, schedule, device/network preflight, host controls and moderation. See the current Live capability and acceptance guide.

Account, storage and financial information

Language, help, TV and optional extensions

Settings provides the installation's available interface languages, translated authored labels, cached language packs, a device-scoped language preference and RTL direction support. Video titles and user content are retained as authored. Light, Dark and System appearance use the existing native accessibility and reduced-motion behavior.

About/Help exposes the enabled managed About, Contact, Developers, FAQ, Support, Refund, Privacy, Terms and Cookie pages at their canonical website addresses. Connect TV previews an existing device code and requires explicit account/device/code confirmation before approval; expired and reused codes fail safely.

Plugins require installation, enablement, healthy boot state, explicit mobile support and account permission, plus a compatible native implementation. Unknown or unavailable plugin links return safely to More. Campaigns is an optional add-on and was not installed in the audited core source. Core video boosts are a separate feature. Platform administration remains on the permission-protected website; browser advertising slots do not become native card scripts.

Video playback and provider configuration

Fetch the video details, then request a fresh playback session immediately before starting or resuming. Use the explicit provider, source_type, provider_id and provider_url fields rather than guessing from an arbitrary URL. Existing imported records are normalized by the server.

Protected media, captions and seeking

• Use the returned source URL and mime_type directly. Never construct upload or storage paths in the application.
• For creator avatars and banners, use the API's complete avatar_url and cover_url. Current private-cloud display assets can use signed application image routes; stripping a signature or rebuilding an unsigned uploads URL breaks access.
• Protected video and caption URLs contain expiring query signatures. Do not append bearer tokens to them. Refresh the playback session before expires_at.
• Local delivery supports MIME types, content length, byte ranges, 206 responses, suffix ranges and 416 for unsatisfiable ranges. S3/CDN delivery must retain range behavior, CORS headers and query signatures.
• Sidecar WebVTT uses text/vtt; SRT uses application/x-subrip when reported client support permits it. Generated MP4 may also contain embedded mov_text. Legacy TXT captions are not native sidecar tracks.
• Remote direct media must use HTTPS and a compatible container. External origin codecs, MIME, TLS, CORS and range support remain deployment/provider dependencies.

Progress, player ads and receiver handoff

Start at resume_position_seconds. Send PUT /videos/{video}/progress with one UUID event_id per logical event and reuse it only when retrying that event. Follow the returned minimum interval, currently ten seconds, and send pause, completion and background transitions when possible.

PlayHub player advertising applies to native sessions. Resolve an enabled ad break shortly before playback of the ad instead of delaying video-session creation on an ad server. Payout-bearing completion is tied to the authenticated native session; anonymous playback does not create creator earnings. External embedded providers control their own advertising.

Before configuring Google IMA advertising, review the Google IMA SDK and advertising terms in the installation guide.

The API exposes receiver-playback endpoints for native video/Short Cast handoff. The server rechecks access and permitted public HTTPS receiver origins, returns bearer-free media, and rejects unsafe external URLs. The default receiver advertises no PlayHub ad integration. Device discovery, routing and native Cast/AirPlay/PiP behavior still require platform acceptance; see iOS media limitations.

Sign-in, secure sessions and TV pairing

Registration and login

Use POST /auth/login with the configured login identifier, password and native device context. Registration follows bootstrap policy through availability, CAPTCHA and email/phone challenge endpoints where enabled; /auth/register may sign the user in immediately or require /auth/confirm-registration. Present server-provided CAPTCHA or two-factor requirements rather than substituting a browser session.

Mobile sign-in accepts ios and android. Successful authentication returns access_token, refresh_token, expires_in, refresh_expires_in, the device session and the current user. Store both credentials in Keychain or Keystore-backed encrypted storage. Never store tokens in AsyncStorage, URLs, analytics, crash metadata or logs.

Token refresh

Default access-token lifetime is 30 days; refresh credentials have a 180-day sliding lifetime. Refresh does not need a valid bearer token or browser cookie. It requires the current refresh credential and the same stable device ID and platform.

1. Refresh before access expiry or once after a protected request returns 401 unauthenticated.
2. Allow one refresh request per installation at a time; queue other authenticated requests behind it.
3. After success, atomically replace both stored credentials before releasing queued calls. The server preserves the session ID and rotates both credentials.
4. Retry the original protected request once with the new token.
5. Clear local credentials for an invalid, expired or reused refresh credential, or an unavailable account, and show the appropriate sign-in/account message.

A consumed refresh credential is retained only for replay detection. Reuse revokes the device session family, newest access token, refresh credentials and matching push registration. A platform/device mismatch is rejected without consuming the credential. An ambiguous lost refresh response must not trigger a blind retry with the old credential.

Sessions and account changes

Use GET /auth/me to restore the account while its token remains valid. Manage Devices uses GET /auth/sessions, account-scoped rename/revoke and current/other/all-device logout. The default active-session limit is ten, subject to server policy. Password resets and session revocation invalidate matching credentials; suspended/banned accounts cannot continue refreshing.

Mobile token abilities include account and creator mutation, uploads and Live publishing where the account is authorized. TV tokens omit those abilities. Clear account-bound queries, private caches and session state on sign-out or account changes.

Social login

Google, Facebook and Apple buttons follow the effective website provider flags on sign-in and registration. Use the system authentication browser with an exact allowlisted callback URI and PKCE S256. Generate a 43–128-character verifier, send its SHA-256 base64url challenge to /auth/social/{provider}/redirect, then exchange the single-use returned handoff code plus the original verifier at /auth/social/exchange. Discard both after completion.

The default documented callback is playhub://auth/callback; configure your actual scheme or approved claimed HTTPS links consistently in both the app and server allowlist. Provider credentials and enabled web OAuth configuration are still required.

Connect a TV

A television starts /auth/tv/device-authorizations and displays its user code, expiry and verification/QR link. Keep the separate device code secret. The signed-in website or mobile Connect TV screen previews the waiting TV and approves only after explicit confirmation. Poll the token endpoint no faster than the returned interval; honor authorization_pending, slow_down, Retry-After, denial and expiry.

Codes expire after ten minutes by default, bounded by policy to 2–30 minutes, and approval can be consumed only once. Connect TV approval in the phone app does not itself establish that a packaged television client has shipped.

API integration reference

All paths in this application guide are relative to your installed /api/v1 base. The versionless website API is not the native contract. The provided OpenAPI 3.1 contract has 191 paths, 230 HTTP operations and 232 component schemas. Its info.version: 1.0.0 describes the API document, independently of the installed application's version.

Open the full endpoint and contract reference for operation parameters, request bodies, response schemas, security and downloadable OpenAPI.

Client headers

The API replies with X-Request-ID, X-PlayHub-API-Version: 1 and X-Content-Type-Options: nosniff. Canonical client headers take precedence over equivalent device/platform values in authentication bodies.

Responses, pagination and retries

{
  "data": { "message": "Request completed." },
  "meta": { "request_id": "a UUID for this request" }
}

{
  "error": {
    "code": "validation_failed",
    "message": "The submitted data is invalid.",
    "status": 422,
    "request_id": "a UUID for this request",
    "validation": { "email": ["Enter a valid email address."] }
  }
}

Every non-204 JSON success uses the data/meta envelope. Field validation belongs to error.validation; branch on error.code and retain request_id for support. Empty plugin and translation dictionaries remain JSON objects, while list results remain arrays.

Length-aware lists return meta.pagination with page, per-page, total, last-page and has-more values. Cursor lists return opaque next/previous cursors, per-page and has-more values. Links, when provided, live under meta.links.next and meta.links.previous. Keep filters and sorting stable between pages; replace the list for a fresh search and append only after a successful next-page request.

The common outer limit is 240 requests per minute per authenticated user or source IP; sensitive operations have tighter limits. Login/social exchange is 8/minute and 40/hour, refresh is 15/minute and 120/hour, progress is 30/minute and upload session/chunk calls are 120/minute. Read the operation-specific policy and returned rate-limit headers.

Likes, Watch Later, subscriptions, playlist membership and progress use retry-safe set/update semantics. Guard record-creating comments, reports, live messages, votes, upload completion and refresh against duplicate or ambiguous submissions. Some newer financial/live operations require their documented immutable idempotency keys.

Upload, import and processing

Native uploads require a mobile token with uploads:write plus actual account publishing and storage eligibility. Refresh GET /uploads/capabilities before beginning; the returned limits, MIME types, chunk sizes, moderation policy, renditions and storage state are authoritative.

1. Create POST /uploads/sessions with a safe filename, exact file size, MIME type, selected chunk size and total_chunks = ceil(file_size / chunk_size).
2. Send zero-based multipart chunks in the chunk field to POST /uploads/sessions/{uploadSession}/chunks. A retry at the same index replaces or confirms that chunk.
3. After interruption, read GET /uploads/sessions/{uploadSession} and reconcile the server's received chunks before resuming.
4. Complete the upload with metadata and optional supported thumbnail/captions after every chunk is present.
5. Show the returned processing state while background jobs probe/transcode the video. Cancel abandoned sessions through their DELETE endpoint.

Shorts classification and provider import

Ordinary local uploads measured at 1–60 seconds are classified as Shorts, including forms that send the default content_type: video and older local records with stale standard-video flags. Processing checks duration again. Shorts disable video ads and chapters. Sale-enabled records explicitly classified as standard videos keep that classification to preserve purchase access; provider imports keep their provider classification and live replays remain replays. Navigate using the returned content type.

Provider imports use POST /creator/imports and the providers advertised by /creator/options. Imported items begin private and remain subject to the existing provider, visibility and publishing validation. Provider imports do not authorize hidden-stream extraction or guarantee external media availability.

Notifications and push registration

In-app notifications

The server-backed in-app inbox provides paginated notifications, authoritative unread counts, read/read-all, deletion and preferences. Comment/reply, mention and new-subscriber notifications honor the saved preferences; account and creator status notices remain available. Saved newsletter/live-reminder preferences and subscription-upload preferences do not establish producers for those notifications.

Route notification actions by their constrained type and identifiers. Reauthorize the destination through its API before displaying it. Video and community comment-context endpoints return the comment ID and root-to-parent ancestor IDs so the app can load and expand the correct reply chain; unavailable or broken chains return 404.

Device registration and delivery status

The API can store encrypted FCM registrations for Android production and APNs registrations for iOS sandbox/production. Registration requires the current native session's same installation ID and platform. The server returns metadata without exposing the raw provider token, and a replacement installation token retires older registrations, including a previous account's registration on a shared device.

The current shared backend includes FCM and APNs senders, a durable delivery outbox, queue dispatch, bounded retries, recovery, and registration/preference checks. This supersedes the older API/readiness notes that described sending as absent.

Configure and operate delivery

1. Configure the intended FCM or APNs credentials on the backend and apply the required registration/outbox migrations.
2. Review the backend push configuration, enable only the intended platform and confirm its bootstrap delivery capability.
3. Supervise a worker for the configured queue, which defaults to push. The ordinary videos,default worker alone does not consume that queue.
4. Verify queue dispatch, bounded retry and recovery behavior, then test actual delivery, preferences and revocation on a correctly signed device build before declaring the channel ready.

When delivery is configured and enabled, register only after OS permission and provider registration, refresh on provider-token rotation, and select the actual signed APNs environment. Revoke on logout; server session revocation and refresh replay also revoke matching registrations. If logout happens offline, suppress local notification presentation immediately and retry remote cleanup after reconnection. Delivery must continue to honor current registration, native-session and saved preference state.

Broadcast, watch, interact, and replay

The React Native application uses PlayHub's existing Live authorization, stream records, chat, moderation, polls, wallet ledger, and recording pipeline. Active media uses LiveKit and native WebRTC. Completed replays use the existing PlayHubPlayer with react-native-video v7.

Current Android acceptance: 9 October 2026

Physical Android connected acceptance and Web-to-mobile Live parity passed on a Samsung SM-G998B running Android 15 against the local acceptance installation. The checks covered Android host to Web viewer, Web host to Android viewer, sustained video and human audio checks, chat, test-wallet gifts/tips, guests, moderation, polls, scheduling, network restoration, recording, and native replay. Older 3–4 October blocked results are historical.

Discovery and viewer controls

• Live, Upcoming, and Replay: browse authorized streams and ready recordings, with search, categories, following, sort, and date filters. Counts, topics, popular creators, and server time come from the backend.
• Featured carousel: up to three Live, Upcoming, then Replay items, preserving API order within each status. Autoplay advances every 6.5 seconds and pauses during interaction, reduced motion, background, hidden screens, or navigation away from Discover.
• Silent previews: video-only subscriptions use exclusive preview ownership. They do not capture media, play audio, create guest requests, or increase the watching count.
• Native stage: receive host and guest tracks, use grid/focus/split/spotlight layouts, mute/volume/output controls, fullscreen, connection state, and reconnect feedback. Layout changes retain the room owner.
• Identity and counts: see title, tags, thumbnail, creator, verification, duration, and current audience. Publishing hosts/guests are excluded from ordinary watching counts; ordinary and anonymous viewers count.
• Share and subscribe: share the canonical /live/{slug} URL and reuse the existing creator channel subscription workflow. Share links never contain connection grants or stream keys.
• Access: everyone, signed-in, subscriber, invited, and private rules are checked server-side for viewers, guests, and previews. Global availability, account eligibility, stream settings, and actual service readiness gate controls.

Configure and start a phone broadcast

1. Open Creator Studio / Go Live. Set title, description, category, tags, thumbnail, visibility, audience, and invited usernames where supported. Configure appearance, accent, layout, engagement, and recording options.
2. Choose phone camera hosting. Grant camera and microphone permission when requested. Previewing does not activate the stream; denied permission has contextual recovery/settings guidance.
3. Select available quality, FPS, and bitrate settings. Camera switching and camera/microphone controls work before and during publishing. Changing source, quality, or FPS releases the old preview and requires a new successful preflight.
4. Run Test connection and resolve each displayed latency, upload, camera, or permission failure. Use Retry connection test after correcting the issue.
5. Start once the matching saved preflight is ready. The app starts the stream, obtains its owner grant, connects and publishes, then activates only after actual source publication.
6. Manage chat, activity, participants, guests, moderation, polls, recording state, and read-only SDK diagnostics from the host screen.
7. Use End broadcast and its confirmation to stop the stream, remove publications/guests, release the owned camera/microphone/room, and transition viewers to the ended or replay state.

A scheduled time is entered locally and stored as ISO UTC. Upcoming displays the appropriate timezone. Starting a due saved stream preserves its original scheduled timestamp. Scheduling does not automatically turn on a phone or publish a camera. New or changed schedule values still receive normal validation.

A phone camera broadcast ends when the host application backgrounds; indefinite background hosting is unsupported. Viewers close their media room in background and rejoin once on return. Android host screen sharing uses OS-consented projection. The iOS ReplayKit broadcast extension remains separate implementation work; see iOS limitations.

Connection testing and quality targets

Web and native use the same backend gate. The test measures one authenticated 1 KiB multipart HTTP probe and one configured upload sample. Camera acquisition, draft saving, and payload preparation are outside the HTTP timing boundary. The result is application/server round-trip and finite-sample throughput, rather than an isolated network-interface or WebRTC packet benchmark.

Chat, emoji reactions, and polls

Chat provides bounded history, avatars, role/verified badges, timestamps, emoji input, held/pinned messages, and authorized deletion. The native feed uses bounded 3.5-second foreground polling, matching the actual web transport. Messages sharing a timestamp sort by ID for stable ordering. Quick reactions are ordinary emoji chat messages.

Server-enforced chat settings include slow mode, followers-only, unique-message, and blocked-term rules. Private blocked terms/restrictions remain authorized. Completed contribution history stays independently visible when chat is disabled.

Hosts can create, edit, schedule, launch, close, and delete polls. Viewers vote, inspect results, and view paginated voters when permitted. Duplicate and expired votes are rejected. Scheduled activation/expiry requires the Laravel scheduler and a currently live stream.

Guests, cohosts, and moderation

• Viewers request audio or audio-and-video access, cancel requests, and leave the stage. Duplicate pending requests are prevented; the host accepts or declines.
• An accepted guest explicitly chooses Join stage before publishing camera/microphone. Guest media modes are audio and audio_video; guest screen sharing is absent.
• Owners/moderators can invite eligible guests/cohosts through the existing role flow. There is no separate invented invitation-acceptance endpoint or fixed guest-seat quota; participant ceilings come from server settings.
• Owners and assigned moderators can delete authorized messages, restrict/restore chat, mute/remove current participant tracks, manage all microphones/cameras, and ban/restore stream access within assigned privileges.
• Kick disconnects the participant and permits a fresh ordinary viewer grant. Ban prevents re-entry until restored. Removing a guest stops publishing and supplies a distinct permitted viewer connection.
• Current-policy signaling admission invalidates cached grants after guest removal, kick, ban, and End. Connected removal and new-token rejection are separate parts of enforcement.

Gifts, tips, Super Chat, wallet, and earnings

Enabled gift and Super Sticker catalogues supply IDs, prices in cents, images, currency, and categories/pages. Tips and Super Chat enforce administrator/creator limits and messages. Quick tip presets come from supported server settings. The server resolves recipient, price, fee, and net earnings; the client cannot set a trusted price or credit its balance.

Wallet balance, transaction history, and creator earnings reuse the existing ledger. Native wallet purchase remains disabled; funding/management uses the existing protected web handoff. Receipts distinguish gross, fees, and actual creator net amounts. Goals use a monetary title, target, and net total.

Pending-action guards prevent rapid duplicate submissions. A sender-bound UUID idempotency key retains immutable stream/product/amount/message intent. Financial requests do not automatically replay after authentication failure. If the outcome is ambiguous, explicitly retry the same intent to recover its receipt without another debit. A changed sender, stream, or intent cannot reuse that receipt; exact completed recovery remains valid after repricing, disable, or End.

Pinned messages, contribution/subscription/goal alerts, and sound use actual stream settings. Alert queues are bounded and deduplicated: up to 8 pending alerts and 200 tracked IDs, with old receipts seeded without replay. Enabled Live ads use the existing inventory, impression, and completion security while preserving RTC volume; VOD IMA remains separate.

The physical financial check used isolated test credit and reconciled three gifts plus one tip with viewer balance and creator net earnings. Actual card charges and payouts were not tested. Implemented notification producers include creator_tip, live_moderator, and live_replay_ready; external email/push delivery depends on configured services.

RTMP and external encoders

Enable Ingress, select the external-encoder source, then prepare/reveal/copy the owner-only ingest URL and key. Publish from OBS or another encoder and wait for real ingress publishing state before Start. Native RTMP monitoring does not use camera activation. Leaving the monitor preserves the running encoder; explicit End stops the stream. Credentials clear on blur, background, or unmount. The final physical camera-host pass did not retest this optional workflow.

Recording, retention, and replay

Recording needs Egress, a reachable trusted recording template, writable output, FFmpeg/ffprobe, queue workers, and the scheduler. It begins after real publication. End queues finalization of a stable MP4, then existing video processing produces the ready replay. Privacy, approval, access, and retention continue to govern playback/discovery.

Replay uses the existing PlayHubPlayer and normal video route, with a bounded read-only archive of messages, contributions, moments, and manual timestamp/checkpoint seeking. It does not automatically synchronize rolling chat with the current playhead; checkpoints are separate from authored video chapters. Denied/expired/processing/unrecorded replays stay out of directory counts and topics, and denied/disabled cached chat is hidden.

Physical acceptance produced and played a real H.264/AAC 1280 × 720 replay of approximately 32 minutes 25 seconds. Playback, pause, timeline seek, fullscreen, portrait return, and close passed. Active replay used one player and released it on close. Test media was removed after validation.

Feature and performance boundaries

Active RTC Picture in Picture and genuine active Live DVR seeking are not exposed. Completed replay retains ordinary VOD behavior. Peak/unique viewers and average/total watch time are not persisted Live analytics; current audience must not be called peak audience. Clip creation, actual reminder subscriptions, coin/combo/quantity gifts, gift leaderboards, timed timeout actions, chat reply/mention entities, pinned products/links, mature-age controls, and guest screen media are absent from the current web inventory.

The accepted network outage recovered after owner-restored connectivity; it does not establish a 12-second recovery guarantee. Debug hot reload during active capture can leave an old idle helper after its JavaScript runtime is destroyed; end/leave before reload and restart the development app if needed. Normal End/leave/background cleanup passed separately. Debug multi-session memory did not immediately return to baseline, and temperature reached 40.7°C. These measurements do not certify release-build memory efficiency, leak freedom, sustained CPU use, every audio route, or every Android GPU.

Install and configure the Live backend

The mobile app uses the same streaming backend as the website. Follow the website LiveKit guide and configure Live through the authenticated Admin settings. The mobile bundle receives public API/signaling configuration and short-lived authorized grants; LiveKit keys, Redis passwords, and recording credentials stay on the server.

Prerequisites and pinned services

Generate the runtime and start services

Save actual engine/Redis/ports/recording settings in Admin and regenerate livekit/runtime/docker-compose.yml. The committed livekit/docker-compose.yml provides the definition. Runtime files are private and excluded from source control. Containers use the livekit bridge network with explicit port publishing; Docker Desktop host networking is not part of this workflow.

On Linux, use the supplied installer from the website guide, adapting the project path and PHP-FPM account:

sudo /var/www/playhub/livekit/install.sh www-data

The installer/systemd manager is a Linux workflow. Windows uses the generated Compose project directly. From the PlayHub project root, the generated runtime can be validated and core started on either supported Docker host:

docker compose -f livekit/runtime/docker-compose.yml config --quiet
docker compose -f livekit/runtime/docker-compose.yml up -d livekit

Start only configured optional services that your workflow needs, particularly on a constrained development machine:

docker compose -f livekit/runtime/docker-compose.yml up -d egress
docker compose -f livekit/runtime/docker-compose.yml up -d ingress

Confirm containers remain running with stable restart counts, readable private mounts, writable output, and reachable media transports. Ingress/Egress use ws://livekit:<signal_port> within the bridge. Private host Redis can use host.docker.internal with host-gateway; listener/ACL/firewall must allow that authenticated connection. A host-loopback-only Redis listener may be unreachable from Docker.

Public configuration and ports

Set the mobile EXPO_PUBLIC_API_BASE_URL to your public trusted HTTPS API ending in /api/v1. Set the LiveKit public URL in Admin to the matching trusted WSS gateway, such as wss://video.example.com/livekit. The local acceptance domain and debug CA are development-only; release uses system trust and cleartext remains disabled.

Inspect generated effective settings rather than copying development port ranges. Basic settings and advanced JSON are merged; explicit UDP mux/extra listeners and relay sockets must have matching published mappings. Keep rtc.node_ip / use_external_ip reachable by intended participants. Ordinary nginx HTTP proxying does not forward RTC UDP, and opening only the TURN listener does not publish relay allocation sockets.

Redis 5 supports password-only AUTH: the generator omits the canonical default username while preserving the password/database. A custom username remains configured and requires Redis with named ACL support. Authentication/protected mode must remain enabled.

Guard nginx signaling and protect credentials

Adapt livekit/nginx-app-test-location.conf into the intended nginx virtual host, using that installation's actual upstream, PHP path, and document root. It provides the existing LiveKit routes, HTTP/1.1 Upgrade/Connection and forwarded headers. Validate nginx before reload and avoid competing locations.

Verify nginx includes http_auth_request_module. The private /__playhub_livekit_admission FastCGI subrequest calls Laravel /api/livekit/admission for join/validate variants under the LiveKit prefix. Admission verifies signed JWTs, current stream/account/audience/stage policy, and server-held identity versions. Query and Bearer credentials must match; upstream receives the exact admitted token. Keep direct core signaling host-private.

Removing a participant in self-hosted LiveKit alone does not cryptographically revoke an existing JWT. Policy/version admission blocks cached joins after kick, ban, guest demotion, and End while server APIs remove/update currently connected participants. Initial viewer/guest grants are 90 seconds and host grants 300 seconds, but refreshed credentials mean initial expiry alone is insufficient. Final physical acceptance rejected still-unexpired revoked grants.

Queue and scheduler: Linux and Windows

Supervise a project worker handling videos,default. On Windows development, the supplied helpers verify the executable, absolute project Artisan path, and command before accepting a stored process ID:

powershell -NoProfile -ExecutionPolicy Bypass -File tools/start-queue-worker.ps1
powershell -NoProfile -ExecutionPolicy Bypass -File tools/start-scheduler.ps1

Both accept -PhpBinary and -Foreground, and write process IDs/logs under storage/app and storage/logs. These are development processes, not automatic startup services. Production needs an appropriate project-specific supervisor/service or Windows Task Scheduler task. Do not kill a reused PID or start a duplicate unverified worker.

Run php <absolute-project-artisan> schedule:run every minute, or supervise one schedule:work process. The Linux cron convention is:

* * * * * cd /absolute/playhub/project && /absolute/php artisan schedule:run >> /dev/null 2>&1

Keep queue retry intervals greater than the longest job timeout. The documented local worker uses 21,600 seconds with DB_QUEUE_RETRY_AFTER=21660. The Redis connection repository fallback is only 90 seconds unless overridden. Confirm the active connection's value to avoid concurrent duplicate reservations of long media jobs.

A running process or registered task is not completed work. Verify job completion, actual schedule run history, poll/lifecycle effects, and replay availability. Scheduled Live appears in Upcoming but does not automatically start a creator's phone. A running external encoder survives leaving its monitor.

Recording storage and real replay verification

Egress uses Room Composite recording, /livekit-recording-template, and mounted uploads/live-streams output. It must reach the template/signaling origin with trusted TLS, connect to configured Redis, and have sufficient CPU/memory/disk. Give the original Egress account write access and the actual queue worker read access with deliberate ownership/ACLs. Avoid recursive world-write permissions.

The recording template sends Cache-Control: private, no-store and Referrer-Policy: no-referrer; suppress token-bearing URL logs. The ignored local development Egress CA overlay is acceptance tooling, not a required production image. Production should use trusted public DNS/TLS.

1. Confirm real source publication and recording start.
2. End the stream and confirm a stable finalized MP4 exists.
3. Allow finalization/video processing to produce a ready replay with valid duration/media.
4. Play, seek, enter/exit fullscreen, and close on the intended device.
5. Verify access/retention policy and artifact handling using owned test data.

Read-only health checks

node tools/live-health.cjs --json

For the supplied local debug CA only, retain normal certificate validation and provide its certificate:

node tools/live-health.cjs --ca-file react-native-app/assets/certificates/playhub-local-acceptance-ca.cer --json

Supported options include --ca-file (PEM/DER X.509), --docker-binary, --root, and --admin-base. Optional administrator diagnostics use an ephemeral process environment variable PLAYHUB_LIVE_HEALTH_ADMIN_TOKEN to call existing admin-only /api/admin/livekit-status and /api/admin/livekit-test. Do not put the value in command arguments or committed files, and clear it afterward.

The verifier reads generated settings and reports PASS, FAIL, WARN, NOT_CONFIGURED, or UNVERIFIED; required operational failure exits 1. It never starts/stops services, runs jobs, or prints configuration/credential bodies. A STUN reply proves a UDP listener, not authenticated TURN relay media; a healthy process/listener does not prove recording, queue completion, or device acceptance. Prove relay-only media separately for UDP/TCP/TLS.

Live fixes and troubleshooting

These are implementation and validation milestones from the supplied documentation, not invented semantic app versions. The current Android connected result is PASS; earlier failed preflight results remain historical.

Schedules, chat, End state, and host-loss recovery

• Due saved schedules: an unchanged saved date was incorrectly treated as a new past date. Starting now preserves that schedule and omits unchanged scheduled_at from metadata saves; changed/new dates retain validation.
• Stable chat ordering: messages sharing a timestamp now use an ID tie-breaker in both shared feeds before reversing the newest-message window.
• Clean ended summary: a stale control-room query could show “not active” after a successful End. The summary suppresses stale active-session query errors while retaining actual action/cleanup errors.
• Abnormal host loss: when LiveKit had closed an empty room, participant listing could return 503 and leave a ghost live stream. A healthy uncached authenticated room listing can confirm absence for this operation. Outages, malformed responses, and existing rooms do not count as absence; grace and locked rechecks remain.
• Physical connected coverage: both hosting directions, owner-heard audio, 20 camera switches, 10 mic cycles, alternating chat/emoji, test-wallet receipts, guest lifecycle, moderation, polls, viewer count, scheduled start, network restoration, UDP relay, native End, recording, and replay seek/fullscreen/close passed.

Supplied validation evidence for this milestone reports 1,146 mobile tests across 130 files, 428 Laravel tests with 9,211 assertions, 34 operational tests, passing application/contract TypeScript, touched-file Pint, and Expo Doctor 21/21. ESLint reported 0 errors and 3 existing warnings. These are evidence from the supplied package, not new test execution performed by this documentation page.

Configured latency limit

The owner raised the maximum Live connection-test HTTP round trip from 300 to 2,000 ms through existing administrator settings, preserving other limits. Earlier physical tests at 300 ms failed latency despite passing upload. The later accepted run used 2,000 ms; customers should inspect their own configured gate rather than copy historical failures.

Preflight, capture profiles, and native ownership

• Configured upload samples: removed the unintended native 512 KiB cap so the 64–2,048 KiB backend-supported setting is honored.
• Quality selection and feedback: explicit selection resets bitrate like web; separate measured failure reasons and Retry connection test clarify the gate without automatic fallback.
• Supported camera profiles: bounded larger-format retry handles a camera returning dimensions below the selected profile minimum. Failed acquisition releases before retry; minimum/FPS/network rules are preserved.
• Native track ownership: obsolete owned tracks release after sender replacement/unpublish/disconnect, preserving shared microphones and remote tracks. Failed release remains retryable. Track registration before first publication blocks cancelled acquisitions from publishing and disconnects uncertain outcomes before disposal.
• Coherent SDK upgrade: LiveKit React Native 2.12.0 → 3.0.0, WebRTC bridge 144.1.2 → 144.2.0, Expo LiveKit plugin 1.0.2 → 1.0.3, and native WebRTC 144.7559.05 → 144.7559.15 include an upstream ordinary recorder shutdown fix. JavaScript LiveKit stays pinned at 2.22.3; the audited Expo 57.0.26 / React Native 0.86.3 application stack remained unchanged.
• Guarded postinstall corrections: handle failed restart/acquisition cleanup, redundant screen acquisition streams, sender identity, rejected/missing native track acknowledgements, and verified sender detachment before SDK ownership clears. The guarded patch must be reviewed when changing pinned packages.
• Local environment corrections: timestamp-validated OPcache and a corrected development emulator host entry reduced diagnosed local server delays. These are environment changes, not a mobile production DNS/authentication change.

Feature parity and server reliability

• Integrated native discovery/carousel/silent previews, viewer stages, camera hosting/settings, activity/diagnostics, chat, guests, moderation, polls, financial interactions, engagement/ads, protected RTMP controls, recording, and replay archive with shared backend behavior.
• Fixed directory following filters serializing false where Laravel expects 0/1, preventing 422 responses.
• Stopped cached RTC after terminal access denial, hidden cached replay chat after denial/disable, and cancelled pending native capture consent on background.
• Corrected actual browser Live media rendering, zero-valued participant text handling, and replay panel navigation-context crashes by using its owning screen's active state.
• Reset ended web draft/preflight state and rejected stale control-room responses after End.
• Moved thumbnail work from blocking Windows HTTP after-response execution to the normal videos queue after commit.
• Required core for camera hosting while independently gating optional ingress/egress; missing/stale Docker status preserves existing readiness probes.
• Added current-policy nginx admission and versioned grant enforcement for removed, kicked, banned, demoted, or ended participants.
• Fixed Windows bind-mounted key permissions with a private 0600 container copy, Redis 5 default-username AUTH compatibility, explicit bridge/TURN relay publishing, project worker/scheduler identity checks, and sanitized health/status reporting.
• Protected runtime and recording-template routes and grant-bearing URL logs; isolated local Egress CA support preserves trusted TLS and production trust boundaries.

Troubleshooting

For the documented Windows configuration bind-lock maintenance, run from the project root:

docker compose -f livekit/runtime/docker-compose.yml stop egress ingress livekit
# Save the intended configuration through authenticated PlayHub Admin settings.
docker compose -f livekit/runtime/docker-compose.yml up -d --force-recreate livekit

Restart optional Egress/Ingress separately if required. Stopping core interrupts active streams. Do not weaken key checks, disable TLS/authentication, or broadly reset/prune Docker to conceal a service failure.

iOS installation, configuration and distribution

The supplied React Native application includes an iOS implementation targeting iOS 16.4 and later. Complete the shared application installation and configuration steps first, then configure the Apple identity, build profile and services below.

Prerequisites and native dependencies

• An installed and configured react-native-app/ project connected to a compatible PlayHub V1 API.
• An Expo/EAS account linked to your approved project. Check the existing project link before creating another project.
• Apple Developer membership and authorized account access for signed device builds; an approved Apple bundle identifier, a real Apple Team ID, distribution signing and appropriate provisioning.
• A registered, accessible iPhone for internal ad hoc installation. Test iPad separately when distributing with tablet support.
• A public HTTPS API with a normally trusted certificate for cloud testing and store production. Local development requires working device DNS and operating-system trust for its development certificate.
• Real AirPlay/Cast receivers, APNs sender configuration and legitimate provider credentials or entitlements when accepting those features.

The supplied compatibility audit uses Expo 57.0.27, React Native 0.86.3, react-native-video 7.0.0-beta.11, Nitro 0.37.1, LiveKit React Native 3.0.0 and WebRTC 144.2.0. The local IMA/AirPlay pods target iOS 16.4 with Swift 5.9. Dailymotion iOS SDK 1.4.11 shares pinned Google IMA 3.33.0 and Google Cast 4.8.6.

Windows can run the shared checks and use EAS-hosted Apple infrastructure for native compilation. A JavaScript/Hermes export does not compile Swift or produce an IPA. A local Apple Simulator requires an Apple development environment; Windows host access to the API does not configure a Simulator or iPhone.

Apple identity and API settings

Set these values in the supplied configuration system. Environment overrides take effect when building the application; public API addresses and player IDs become part of public application configuration. Keep Apple authentication, certificates, provisioning material and service secrets in secure credential storage.

The shipped development bundle identifier is com.playhub.mobile.dev. Use your actual resolved identifier for device registration and testing fixtures. Changes to native identity, app name, icons, splash screens, permissions or entitlements require a new native build; website bootstrap branding controls the runtime name separately.

EXPO_PUBLIC_API_BASE_URL=https://app.test/api/v1

The local endpoint is a development setting. Do not use it as a public store deployment or assume that a cloud Simulator can reach it. The separate cloud value does not replace your Android/local development API. The build gates retain normal TLS and hostname verification.

Select an iOS build profile

A Simulator .app archive cannot be installed as a physical-device or App Store IPA. The documented successful ios-local-simulator artifact is a development client requiring Metro; it is not the standalone ios-e2e artifact.

Validate and build

Run commands from react-native-app/. The examples use Windows PowerShell executables; use npm in shells where the .cmd suffix is unnecessary.

npm.cmd run check:ios
npm.cmd run release:local-api:check:ios
npm.cmd run e2e:ios:check

check:ios validates shared code and exports JavaScript/assets. The local API check verifies the iOS bootstrap contract at the configured endpoint from the current host. Neither command installs or runs the application on an Apple device.

npm.cmd run ios:cloud:api:check
npm.cmd run e2e:ios:preflight
npm.cmd run eas:workflow:ios:validate
npm.cmd run eas:ios:e2e:build

Configure the same public API in the current environment and the EAS development environment before running cloud checks. Prepare the real fixtures described below. Workflow service validation also depends on your EAS account entitlement. The cloud pre-install hook checks the real bootstrap over verified TLS before native compilation.

npm.cmd run eas:ios:simulator
npm.cmd run eas:ios:simulator:local

The first command selects the cloud development-client profile; the second selects the local-network Simulator profile. Both require Metro. Building the local profile does not make a private local API remotely reachable.

Signing, internal installation and production

Set your approved bundle identifier and Apple Team ID before configuring signing. Expo authentication and Apple authentication are separate. The supported credential-inspection command is:

eas credentials --platform ios

The configuration inspection repair allows exact Expo JSON configuration reads when production settings are incomplete. Actual prebuild, export, native introspection and build workers still require valid production configuration. Inspecting credentials does not create a signed artifact or waive those gates.

1. Confirm your Apple membership, app registration, approved bundle identifier and Team ID.
2. Arrange matching distribution certificates and provisioning through EAS/Apple. For ios-preview, register the authorized test iPhone and use the prepared internal device profile.
3. Build the configured ios-preview internal profile, install its signed artifact on a registered device through the EAS internal-distribution installation link, and prove a cold launch with bundled JavaScript and no Metro.
4. For production, configure the approved public API and run the production commands below.
5. Inspect the actual signed IPA, then complete physical-device and store acceptance. Signing and compilation alone do not complete release verification.

npm.cmd run config:production:check -- --platform ios
npm.cmd run release:api:check:ios
npm.cmd run eas:ios:production

The supplied production configuration was blocked by missing approved public API, Apple bundle identifier/team and signing access. No signed production artifact metadata exists. Version 1.0.0 and build 1 are documented Simulator/configuration values; inspect the intended remote build number and final signed artifact before distribution. Android version codes remain independent.

Permissions, networking and platform behavior

Arbitrary network loads are disabled. Development configuration permits local networking and a scoped localhost exception for Metro; it does not add an arbitrary-load exception for app.test. A local device must independently resolve the API host and trust its CA. Inspect the final Release Info.plist and use trusted production TLS.

Push enrollment requires authenticated state, OS permission and the backend delivery capability. The supplied local bootstrap reports push_registration: true and push_delivery: false, so registration capability alone does not enable native enrollment. Refresh/token listeners recheck delivery capability, while Settings preserves revocation. No actual iPhone token registration or APNs delivery is verified.

iOS feature boundaries

• Native video: MP4/HLS playback and controls are implemented. iOS source selection excludes native DASH and chooses an available compatible MP4/HLS rendition. A DASH-only asset needs compatible server delivery.
• Dailymotion: the native iOS bridge uses the official SDK, fullscreen/ad presentation and setMute; arbitrary volume is unsupported (supportsVolume: false). Configure its separate iOS Player ID and accept actual playback, ads and lifecycle.
• Provider surfaces: YouTube, Vimeo and Twitch integrations preserve official provider interaction. Vimeo Direct requires legitimate server credentials/entitlement. Twitch clips lack the same interactive playback telemetry as the VOD test fixture.
• Live: camera/microphone host, guest and viewer flows, interactions and server recording/replay integration are implemented. Host screen sharing remains Android-only; no iOS ReplayKit broadcast extension is supplied. Recording requires configured server egress and the replay setting.
• Commerce and downloads: StoreKit purchases, DRM and authorized offline downloads are not implemented. Billing/management links use website payment flows; review the policy for enabled digital purchase flows before store distribution.

Privacy and publisher configuration

Prepare privacy answers from your actual API, storage, providers and advertising configuration. The app can transmit account/profile/contact fields, device/session metadata, media/messages/content, social and library interactions, viewing progress, searches, billing/withdrawal data, Live media/chat and conditional native push tokens. Live recording depends on configured egress and the selected replay setting.

Session credentials use device-only SecureStore; preferences and recent searches use AsyncStorage. Upload recovery retains account/API-scoped source copies and a metadata journal without serializing authentication credentials. Account deletion, session revocation, history clearing and content deletion are implemented, but deployed retention, backups, operational logs, financial records and third-party deletion practices require operator review.

No app-level ATT request, integrated UMP SDK or complete CMP flow was found in the supplied source. IMA can receive consent/ad-request configuration, and Dailymotion sets allowIDFA: false, but these do not prove an end-to-end consent flow or that every provider disables tracking. Review enabled ad suppliers, SDK purposes, regional consent and actual traffic. The app-owned analytics sink defaults to a no-op, which does not exclude backend statistics or provider advertising/analytics.

The supplied Dailymotion integration inventory records a publisher requirement to provide the relevant TCF2 CMP consent string before loading its player in GDPR countries. Configure and verify the required consent handoff before enabling that provider there; a complete CMP flow is not implemented in the documented application.

Confirm the public privacy-policy URL, account/data deletion practices, first-party collection, SDK declarations, encryption declaration and content disclosures. Inspect the actual signed archive and final Xcode privacy report. No App Store privacy answers or consent certification were submitted in the supplied evidence.

iOS testing, Windows workflow and TestFlight readiness

Record native compilation, JavaScript export, Simulator execution and physical-device acceptance separately. The supplied evidence dated 9 October 2026 confirms native Simulator compilation, while all ten defined Simulator cases and physical-device acceptance remain unexecuted.

Testing from Windows

Run the local checks and EAS build scripts from react-native-app/. Keep the local development endpoint for the local profiles and configure the separate public endpoint for hosted acceptance. An iPhone using the local endpoint must independently resolve app.test and trust the development CA; a successful Windows host check proves neither condition.

npm.cmd run eas:ios:availability

At the supplied evidence date, the tested account's interactive Simulator service was unavailable and hosted Maestro required a paid team plan. Check your own account availability and plan before scheduling hosted work. Workflow commands pin EAS CLI 24.12.1, which corrects earlier current-schema parsing and failure-exit behavior.

A development client needs reachable Metro. Use the standalone ios-e2e artifact for hosted acceptance without Metro. Appetize requires a compatible Simulator application and authorized account access; BrowserStack real iPhone testing requires a compatible signed device IPA and account access. Neither alternative service was executed in the supplied evidence.

Prepare real acceptance fixtures

Use tools/ios-e2e-fixtures.json and a disposable account that supports noninteractive password login. The account needs a channel, an existing published creator video and playlist. Prepare deterministic public Home/Search/Shorts resources and all seven provider fixtures. Vimeo Direct must be legitimately entitled; a DASH fixture requires a real MP4/HLS fallback. CAPTCHA/MFA behavior needs its own acceptance.

• Store MAESTRO_TEST_LOGIN and MAESTRO_TEST_PASSWORD as secure EAS development variables.
• Set MAESTRO_TEST_DISPOSABLE_ACK=yes.
• Set MAESTRO_APP_ID to the actual resolved application identifier, including the development suffix when applicable.
• Use the same public API in the build and test environment. Do not replace real provider behavior with mocked production records.

npm.cmd run e2e:ios:check
npm.cmd run e2e:ios:preflight
npm.cmd run eas:ios:e2e

The manual-only workflow performs GET-only public preflight, builds ios-e2e, then runs Maestro 2.11.0 with one shard, zero retries and JUnit output. It has no push, pull-request or scheduled trigger. Actual flows can create disposable login sessions and watch history and sign out that device; they read existing profile, playlist and creator data without editing or deleting it.

Keep test artifacts private. Logger message bodies and recordings are disabled, and a sanitizer handles configured credential values in text/JSON/XML outputs. Screenshot/binary artifacts and hosted collection paths have not been certified secret-safe. Review outputs before sharing and rotate disposable credentials if exposed.

Ten core Simulator cases

Playback assertions require genuine provider load/first-frame/playing telemetry and advancing progress without an active ad, error or buffering state. Mounting a screen is not playback evidence. The ten cases do not contain a Dailymotion fixture/assertion; accept Dailymotion separately. Creator/profile cases read existing data and do not cover upload or settings mutations.

Physical-device acceptance checklist

1. Install and upgrade: verify signed standalone cold launch with no Metro; authenticate and visit Home, Search, Library, Creator, Notifications, Messages, Profile and Settings. Install signed baseline N followed by N+1 with the same approved bundle/signing identity without uninstalling; check login, theme and preferences.
2. Native media: play real MP4/HLS and compatible DASH fallback; verify seeking, mute, captions/audio tracks, replacement, buffering/error/retry, fullscreen/rotation, mini-player and cleanup.
3. Providers and ads: verify YouTube/Shorts official interactions, entitled Vimeo Direct URL expiry/restoration, Vimeo embed, Twitch live/VOD/offline states and Dailymotion playback/ads/fullscreen. Test IMA preroll/skip/content resume and applicable VMAP pre/mid/post transitions.
4. Routes and lifecycle: verify PiP/background/return/exit, user pause, Control Center, calls, headphones/Bluetooth, AirPlay/Cast discovery/handoff/seek/disconnect and single audio/player ownership.
5. Live: test actual camera/microphone grant/denial/recovery, front/rear publishing, received audio/video with a real remote viewer, chat/reactions/gifts, reconnect/background recovery and End Live camera/microphone release. If egress is enabled, verify host → recording → processing → replay playback.
6. Uploads and mutations: select/upload real files and artwork, verify progress/cancel/recovery, metadata/captions/chapters/scheduling, profile/privacy writes, library edits, comments/replies/moderation/subscriptions and appropriate validation errors.
7. Push and sessions: align real Apple/server APNs configuration; verify foreground/background/terminated delivery, badge/read counts, deep links, expiry/revocation and logout behavior.
8. Accessibility and layouts: test VoiceOver, Dynamic Type, keyboards, safe areas, notch/Dynamic Island, orientations, offline/empty/error states and supported iPhone/iPad sizes.
9. Stability: measure actual startup, long playback, Shorts/Live scrolling, repeated provider switching, memory and cleanup on Apple hardware.

Simulator mocks and source tests cannot establish real capture, native permission sheets, APNs delivery, hardware receiver routing or device performance. The supplied records contain no physical iPhone/iPad result and no iOS hardware performance measurement.

Before TestFlight or App Store distribution

1. Pass production configuration/API preflights and create the separate signed production IPA using your approved Apple identity and signing access.
2. Inspect its actual identity/version/build number, signature/provisioning, push and background entitlements, release get-task-allow behavior, Info.plist, trusted TLS policy, permissions, SDK inventory, privacy manifests and native notices.
3. Complete physical install/upgrade and functional acceptance, then review release logs and packaged data for secrets/development tooling.
4. Finalize store screenshots/assets, public privacy policy, data/consent/encryption/content disclosures and the policy for enabled web billing/digital purchase paths.
5. Complete TestFlight/App Store submission through your authorized Apple distribution workflow, install the processed TestFlight build, and repeat the signed-device acceptance checks before wider rollout. No completed distribution is recorded for the documented build.

Supplied validation record

The latest signing-configuration pass records 1,173 passing Vitest tests across 133 files and 81 passing Node tooling tests: 1,254 passing mobile tests. Application/API-contract TypeScript, configuration checks, Expo Doctor 21/21 and optimized local-API iOS export passed. ESLint had zero errors and three existing warnings.

The latest backend full run executed 428 tests and retained one timing-sensitive push retry-budget failure; its focused retry passed. The full run remains failed. Earlier all-green backend totals describe an earlier pass. Production export/readiness remained blocked by required production settings, and actual iOS executions remained zero. These are supplied historical results, not tests performed while updating this documentation.

iOS fixes and implementation history

9 October 2026 · version 1.0.0 implementation and validation updates. The archive records one Simulator version/build, 1.0.0 (1). The updates below are documented implementation changes within that baseline; they are not separate numbered App Store releases.

Keep native dependency pins and the version-checked postinstall patch when reinstalling dependencies. Rebuild after native configuration/module changes, rerun affected regressions and record actual device results before marking an iOS release accepted.

Application versions, updates and fixes

The supplied records provide development milestones rather than a complete published mobile release history. Version 1.0.0/build 1 is confirmed for the iOS development Simulator artifact; sample API header versions do not identify additional app releases.

Capability limits carried across these updates

• No native StoreKit/Google Play digital checkout or receipt-validation endpoint; existing authorized web purchases remain playable.
• No generated adaptive HLS/DASH, DRM, HDR signaling, authorized offline download or direct-to-cloud multipart upload. Native remote push is implemented but disabled until its platform configuration and readiness gates pass; device delivery still needs acceptance.
• No shipped TV build, complete iOS runtime acceptance, exhaustive Android/tablet accessibility acceptance or signed production release is established by the supplied reports.
• Live depends on reachable configured services; provider media, financial handoffs and signing require their actual external setup.

For website release versions and backend update instructions, use the website changelog and installation guide. Configure the app's real supported/latest/minimum version policies on the server when distributing your own validated build.

Application troubleshooting

For support, provide the app version/build, platform/OS, selected environment, timestamp, reproducible steps and the API request_id. Keep credentials, private URLs, signing files and server secrets out of screenshots and shared logs.