Screening App V1

Executive Summary

The MicroMaker Screening App is a native iPhone app that allows Peacock executives to review MicroMaker vertical cuts in the right viewing context: on a phone, in portrait, with full-screen playback and immediate progression from one episode to the next.

v1 is intentionally narrow. A user enters a personal invite code, opens a private catalog, chooses a series, and watches episodes in sequence. The product is meant for internal screening first, not public release or consumer growth — but v1 is being built with clear line of sight toward a consumer-facing app (Bananas), so architecture decisions now should not paint us into a corner.

My recommendation is to engage a "Consulting Engineer" to advise on iOS/Swift/SwiftUI architecture, ensure best practices for video playback and app structure, and help build v1 with intentional foundations for the eventual consumer product. I have 2 candidates in mind.

We can use AI coding tools to execute on the code base, with oversight and testing at each phase. Note that cost considerations should include a retainer fee for the Consulting Engineer, AI tokens, and robust video hosting on a service like Cloudflare.

Primary User and Use Cases

• Watch multiple episodes in sequence to judge story arc, pacing, and cliffhanger strength.
• Review newly delivered episodes as they are uploaded week to week.
• Resume quickly on the same device without needing an account or new setup.

Design Principles

• Portrait-first. The app should feel native to vertical viewing, not like a TV app reduced to phone size.
• Binge-first. Watching 12 or more episodes in a row is central to the product.
• Minimal interface. Content should dominate the screen, with controls only when needed.
• Simple navigation. Users should move from code entry to playback in just a few taps.
• Secure by default. Unreleased cuts must stay protected behind server validation.

MVP Scope

Out of scope for v1: accounts, search, recommendations, My List, deep links, feedback tools, downloads, Android, and a CMS admin panel.

Core User Flows

First Launch

Open app -> enter invite code -> code is validated -> catalog appears

Start Watching

Catalog -> choose series -> choose episode or resume -> full-screen playback -> next episode starts automatically

Return Visit

Open app -> session still valid -> continue from same series and episode on the same device

Screen-by-Screen Experience

Playback Behavior

Content and Navigation Model

Content is organized very simply: Series -> Episodes. The catalog remains small, so there is no need for search or recommendation logic in v1.

For launch, content is managed manually through a JSON catalog and private Cloudflare R2 uploads. This is acceptable for a small slate and keeps delivery lightweight.

Catalog -> Series Detail -> Full-Screen Player -> Auto-advance within the same series

Video Format

Peacock delivers editorial cuts as high-quality production masters. We convert these to a mobile-optimized format before uploading them to the app.

The conversion reduces file size by roughly 90% with no visible quality loss on a phone screen. H.264 is used because it plays natively on every device — iOS and Android — so the same files work if the app expands to other platforms later. Captions are converted from SCC (a broadcast format) to VTT (the format iOS uses), so users can toggle captions on and off in the app.

For v1, this conversion is done manually using a simple script before uploading episodes. An automated pipeline is planned for a later phase.

v1 Telemetry

v1 only needs the minimum instrumentation required to prove that the app works and that reviewers are actually completing episode runs.

Content Upload

A simple, password-protected upload page where an assistant editor or producer can add new episodes to the app without any technical knowledge.

The uploader submits:

• Video file — the mobile-optimized MP4 (transcoded from the Peacock master)
• Thumbnail — a still image representing the episode
• Episode number
• Title
• Description — a short summary (1–2 lines)
• Caption file — the VTT sidecar (optional)

The page handles uploading the files to storage and updating the catalog automatically. No command line, no code, no developer involvement. The episode appears in the app on the next refresh.

This upload page is a lightweight precursor to the full CMS planned for Phase 4. It covers the immediate need — getting episodes into the app quickly — without overbuilding.

Deferred Features

• Feedback tools: lightweight thumbs-up style reaction or flagging, to be explored later.
• Offline downloads: intentionally deferred because secure local storage adds complexity.
• CMS: later phase for content management, metadata, and publishing workflows.
• Full analytics: more detailed reporting can come after v1 proves the viewing behavior.

Technical Assumptions

• Native iPhone app built in Swift and SwiftUI.
• Distributed via TestFlight to a small internal group.
• Video stored in a private Cloudflare R2 bucket.
• Cloudflare Workers validate invite codes and generate signed video access.
• Workers KV stores invite codes, session data, and basic viewing logs.

Timeline and Phased Delivery

Milestones and Deliverables

Verification and Acceptance Criteria

• Valid invite codes unlock the app cleanly; invalid codes fail cleanly.
• Videos are not publicly exposed and require valid access.
• Users can watch 12 consecutive episodes without a critical playback failure.
• The app remembers where a user left off on the same device.
• Captions work on all episodes intended for exec review.
• Telemetry records starts and completions with invite-code association.

Testing Plan

Open Questions

1. Which iPhone models and iOS versions need to be supported for Peacock executives?
2. Should each invite code allow one device only, or one backup device too?
3. Are episode-level thumbnails required for every title by April 2?
4. Should captions be on by default?

How Executives Get the App

TestFlight is Apple's official system for sharing apps privately before they go live on the App Store. Think of it like a private screening link — but for an app instead of a video.

Here's how it works for the people using it:

1. An exec receives an email invitation from us.
2. They tap the link, which opens a free Apple app called "TestFlight" (one-time install, takes 30 seconds).
3. Inside TestFlight, they tap "Install" and the Screening App appears on their home screen like any other app.
4. From that point on, they just open it and use it — it looks and feels like a normal app. TestFlight stays in the background.

When we push updates or fixes, TestFlight automatically notifies them and the app updates with one tap. No App Store review process, no public listing, no waiting. We control exactly who has access and can revoke it at any time.

For v1, TestFlight is the right distribution method because the app is for a small, known group (~10–30 people), not the general public. It's how virtually every iOS app is tested before launch — it's the industry standard, not a workaround.

Recommended Next Artifacts

• Annotated wireframes for the core screens
• API contract for invite validation and signed video delivery
• JSON catalog template for manual content operations
• QA checklist for binge-viewing and TestFlight release