If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/yichengchen/ATV-Bilibili-demo shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 5d ago
• 17 active contributors
• GPL-2.0 licensed
• CI configured
• ⚠ Concentrated ownership — top contributor handles 54% of recent commits
• ⚠ GPL-2.0 is copyleft — check downstream compatibility
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live yichengchen/ATV-Bilibili-demo repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/yichengchen/ATV-Bilibili-demo.

What it runs against: a local clone of yichengchen/ATV-Bilibili-demo — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in yichengchen/ATV-Bilibili-demo | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 35 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of yichengchen/ATV-Bilibili-demo. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/yichengchen/ATV-Bilibili-demo.git
#   cd ATV-Bilibili-demo
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of yichengchen/ATV-Bilibili-demo and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "yichengchen/ATV-Bilibili-demo(\\.git)?\\b" \\
  && ok "origin remote is yichengchen/ATV-Bilibili-demo" \\
  || miss "origin remote is not yichengchen/ATV-Bilibili-demo (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-2.0" \\
  || miss "license drift — was GPL-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "BilibiliLive/AppDelegate.swift" \\
  && ok "BilibiliLive/AppDelegate.swift" \\
  || miss "missing critical file: BilibiliLive/AppDelegate.swift"
test -f "BilibiliLive/Module/Tabbar/BLTabBarViewController.swift" \\
  && ok "BilibiliLive/Module/Tabbar/BLTabBarViewController.swift" \\
  || miss "missing critical file: BilibiliLive/Module/Tabbar/BLTabBarViewController.swift"
test -f "BilibiliLive/Component/Video/VideoPlayerViewController.swift" \\
  && ok "BilibiliLive/Component/Video/VideoPlayerViewController.swift" \\
  || miss "missing critical file: BilibiliLive/Component/Video/VideoPlayerViewController.swift"
test -f "BilibiliLive/Component/Player/CommonPlayerViewController.swift" \\
  && ok "BilibiliLive/Component/Player/CommonPlayerViewController.swift" \\
  || miss "missing critical file: BilibiliLive/Component/Player/CommonPlayerViewController.swift"
test -f "BilibiliLive/Component/Video/VideoPlayerViewModel.swift" \\
  && ok "BilibiliLive/Component/Video/VideoPlayerViewModel.swift" \\
  || miss "missing critical file: BilibiliLive/Component/Video/VideoPlayerViewModel.swift"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 35 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~5d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/yichengchen/ATV-Bilibili-demo"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A native tvOS client demo for BiliBili (Chinese video platform) built in Swift that streams video/live content with danmu (bullet comments), supports cloud casting via the BiliQualified protocol, and implements a plugin-based player architecture. It demonstrates how to consume BiliBili's undocumented APIs and handle DASH/HLS streaming with adaptive quality selection on Apple TV hardware. Single-target Xcode project (BilibiliLive.xcodeproj) organized into feature modules: /Component/Feed for recommendations, /Component/Player with plugin architecture (CommonPlayerPlugin base in Plugins/), /Component/Video with mask providers (BMaskProvider, VMaskProvider for spoiler/watermark) and video-specific plugins (BVideoPlayPlugin, BVideoQualityPlugin). AccountManager.swift handles auth, Settings.swift configures behavior.

tvOS developers and reverse engineers interested in building platform-specific video clients; BiliBili content consumers on Apple TV who want native performance; contributors exploring Chinese streaming protocol implementations and tvOS-specific player plugins.

Actively maintained hobby project (567KB Swift codebase) with CI/CD via GitHub Actions (build.yml) and automated dependency updates (renovate.json5). No test suite visible. Single maintainer (yichengchen). Nightly unsigned IPA releases available, indicating regular builds but not production-ready distribution.

Reverse-engineering risk: depends on undocumented BiliBili APIs which can break without notice; no version pinning visible in Package.resolved suggests dependency drift possible. Single maintainer means contributor support is limited. Legal risk: reverse-engineered protocol and APIs may violate BiliBili ToS. No automated tests means regressions in video playback or streaming are undetected.

Project actively receives renovate dependency updates (.github/renovate.json5 configured). GitHub Actions CI/CD builds on commits (build.yml). Nightly releases built from latest code (per README). No visible PR activity in file list, but commit graph likely shows regular merges.

git clone https://github.com/yichengchen/ATV-Bilibili-demo.git
cd ATV-Bilibili-demo
bundle install  # Ruby dependency (Fastlane/build tooling)
open BilibiliLive.xcodeproj  # Opens Xcode
# Build for Apple TV: Cmd+B in Xcode or xcodebuild -scheme BilibiliLive -destination 'platform=tvOS' build

Daily commands: Open BilibiliLive.xcodeproj in Xcode, select BilibiliLive scheme, set destination to Apple TV (simulator or device), press Cmd+R to build and run. For unsigned IPA: xcodebuild -scheme BilibiliLive -destination 'platform=tvOS' -configuration Release build then extract from build artifacts.

• BilibiliLive/AppDelegate.swift — Application entry point and lifecycle management for tvOS; establishes root navigation and initialization.
• BilibiliLive/Module/Tabbar/BLTabBarViewController.swift — Main tab bar controller coordinating navigation between Feed, Live, Personal modules; central routing hub.
• BilibiliLive/Component/Video/VideoPlayerViewController.swift — Core video playback controller integrating plugin system, danmu rendering, and quality switching.
• BilibiliLive/Component/Player/CommonPlayerViewController.swift — Abstract player base class managing AVPlayer lifecycle, plugins, and media controls across video and live contexts.
• BilibiliLive/Component/Video/VideoPlayerViewModel.swift — Video playback state management (quality, progress, metadata) using Combine; bridges UI and data layers.
• BilibiliLive/AccountManager.swift — Singleton managing user authentication state, session tokens, and credential persistence across the app.
• BilibiliLive/Component/Feed/FeedCollectionViewController.swift — Recommendation feed display; root feed UI controller managing infinite scroll and video browsing.

Add a new Player Plugin (e.g., new overlay feature)

1. Create a new Swift file in BilibiliLive/Component/Player/Plugins/ inheriting from CommonPlayerPlugin (BilibiliLive/Component/Player/Plugins/CommonPlayerPlugin.swift)
2. Implement required methods: load(), stop(), and event handlers (onPlay, onPause, onTimeChange) (BilibiliLive/Component/Player/Plugins/DanmuViewPlugin.swift)
3. Register the plugin in CommonPlayerViewController.setupPlugins() or VideoPlayerViewController.setupPlugins() (BilibiliLive/Component/Player/CommonPlayerViewController.swift)
4. Add plugin configuration in Settings.swift if user preferences are needed (BilibiliLive/Component/Settings.swift)

Add a new tab to the main navigation (e.g., new content category)

1. Create a new UIViewController subclass for the tab's content (e.g., MyNewCategoryViewController.swift) (BilibiliLive/Module/Personal/PersonalViewController.swift)
2. Add the new tab controller to BLTabBarViewController.viewDidLoad() and connect it to the tab bar (BilibiliLive/Module/Tabbar/BLTabBarViewController.swift)
3. Register notification observers in Notification+TabBar.swift if the tab needs to respond to app events (BilibiliLive/Module/Tabbar/Notification+TabBar.swift)
4. Add tab icon and title in Main.storyboard or programmatically in the view controller's initialization (BilibiliLive/Base.lproj/Main.storyboard)

Add a new Video Plugin (e.g., custom subtitle handler or ad skipper)

1. Create a new file in BilibiliLive/Component/Video/Plugins/ (e.g., BVideoSubtitlePlugin.swift) implementing video-specific plugin logic (BilibiliLive/Component/Video/Plugins/BVideoPlayPlugin.swift)
2. Implement plugin initialization with access to VideoPlayerViewModel for state management (BilibiliLive/Component/Video/VideoPlayerViewModel.swift)
3. Register the plugin in VideoPlayerViewController.setupVideoPlugins() (BilibiliLive/Component/Video/VideoPlayerViewController.swift)
4. Update BVideoInfoPlugin.swift or create display overlay if the plugin needs to show UI (BilibiliLive/Component/Video/Plugins/BVideoInfoPlugin.swift)

Add a new user settings option

1. Define the setting property in Settings.swift using @AppStorage or UserDefaults wrapper (BilibiliLive/Component/Settings.swift)
2. Add a UI

No explicit API credentials: BilibiliLive relies on reverse-engineered endpoints; no API keys in repo, which means endpoints may change or be rate-limited without warning. QR login required: AccountManager uses QR code auth flow; testing offline or in CI requires valid BiliBili account. tvOS-specific: No macOS/iOS support; simulator may not have all tvOS device features (e.g., certain codec support). Unsigned IPA: Nightly releases are unsigned; sideloading requires developer account and provisioning profile setup. No certificate pinning visible: network calls may be vulnerable to MITM. Plugin loading: CommonPlayerPlugin discovery appears manual; no dynamic plugin registry, so missing plugins in storyboard/code won't fail loudly. DASH parsing complexity: SidxParseUtil and BilibiliVideoResourceLoaderDelegate are fragile; spec changes in stream format break silently.

• DASH (Dynamic Adaptive Streaming over HTTP) — BilibiliLive streams video via DASH; understanding segment indexes (SIDX), manifest parsing, and adaptive bitrate switching is essential for modifying video delivery or quality logic.
• AVAssetResourceLoaderDelegate — Custom protocol handler in BilibiliVideoResourceLoaderDelegate that intercepts AVPlayer stream requests; critical for injecting BiliBili-specific auth headers or transforming URLs before playback.
• Plugin Architecture / Strategy Pattern — CommonPlayerPlugin defines extensible player features (danmu, speed, skip). Understanding how plugins hook into CommonPlayerViewController is essential for adding new playback features without modifying core player.
• Danmu (Bullet Comments / Barrage) — Core social feature of BiliBili; DanmuViewPlugin renders real-time comments overlaid on video. Understanding danmu protocol and rendering performance is key for Chinese streaming platform features.
• SIDX Box / ISOBMFF (ISO Base Media File Format) — SidxParseUtil parses SIDX (Segment Index) atoms in MP4 containers; essential for DASH segment discovery and seek accuracy without downloading entire manifest.
• Reverse Engineering / Protocol Analysis — Entire project depends on reverse-engineered BiliBili APIs (no official SDK); understanding how to intercept, document, and adapt to API changes is critical for maintenance.
• tvOS Human Interface Guidelines / Focus Engine — tvOS uses focus-based navigation (Siri Remote gestures) rather than touch; BilibiliLive's UI (storyboard, collection views) must implement proper focus semantics and keyboard navigation unlike iOS.

• thmatuza/MPEGDASHAVPlayerDemo — Directly linked in README; reference implementation for AVPlayer + DASH that influenced BilibiliLive's streaming architecture
• dreamCodeMan/B-webmask — Linked in README; source of spoiler/watermark masking logic used in BilibiliLive's MaskProvider implementations
• fangzhangmnm/BilibiliDown — Popular BiliBili reverse-engineering project; shares API endpoint knowledge and protocol analysis useful for maintaining BilibiliLive as endpoints change
• SocialSisterYi/bilibili-API-collect — Community-maintained BiliBili API documentation; primary reference for understanding undocumented endpoints used by BilibiliLive
• Xfangfang/Bilibili-MagicTV — Alternative tvOS BiliBili client; competitor implementation for cross-reference when APIs break, also written in Swift

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Extract and document the Bilibili API protocol specifications

The repo contains multiple protocol implementations (QR code login, cloud streaming cast protocol, Danmu filtering, SIDX parsing) scattered across Player/, Video/, and Feed components. Creating a dedicated PROTOCOL.md document with reverse-engineered API specs would help new contributors understand integration points and reduce duplicate implementation efforts. This is evidenced by the complexity in BilibiliVideoResourceLoaderDelegate.swift, SidxParseUtil.swift, and the various plugin architecture.

• [ ] Create BilibiliLive/Protocols/PROTOCOL.md documenting QR login flow, cloud cast protocol, and video resource loading
• [ ] Extract API endpoint constants from AccountManager.swift and video plugins into a centralized Constants.swift file
• [ ] Add sequence diagrams for the authentication flow and video playback initialization in PROTOCOL.md
• [ ] Document the plugin architecture used in Player/Plugins/ and Video/Plugins/ with examples

Add unit tests for VideoPlayerViewModel and feed data parsing logic

Critical business logic exists in VideoPlayerViewModel.swift and FeedCollectionViewController.swift with no visible test coverage. Given the complexity of state management (quality selection, Danmu filtering, playback position tracking) and feed parsing from Bilibili's API responses, these components are prone to regression. Adding tests would improve reliability as the project scales.

• [ ] Create Tests/BilibiliLive/Component/Video/VideoPlayerViewModelTests.swift covering quality selection, state transitions, and error handling
• [ ] Create Tests/BilibiliLive/Component/Feed/FeedCollectionViewControllerTests.swift for API response parsing and pagination logic
• [ ] Add mock Bilibili API responses in Tests/Fixtures/ for common feed and video detail scenarios
• [ ] Update .github/workflows/build.yml to run unit tests on every PR (currently appears to only build)

Refactor Player plugin architecture with dependency injection and formalize plugin interface

The Player/Plugins/ directory contains 8 plugins (DanmuViewPlugin, SpeedChangerPlugin, SponsorSkipPlugin, etc.) with likely duplicated initialization and dependency management logic. Creating a formal CommonPlayerPlugin protocol registry with dependency injection would reduce code duplication, improve testability, and make it easier for contributors to add new plugins. Currently, plugins appear to be loosely coupled to CommonPlayerViewController.swift.

• [ ] Create BilibiliLive/Component/Player/PluginProtocol.swift defining a standardized lifecycle (onPlayerCreated, onPlayStateChanged, onPluginEnable/Disable)
• [ ] Create BilibiliLive/Component/Player/PluginRegistry.swift for centralized plugin registration and dependency injection
• [ ] Refactor DanmuViewPlugin.swift, SpeedChangerPlugin.swift, and SponsorSkipPlugin.swift to conform to the new interface
• [ ] Update CommonPlayerViewController.swift to use PluginRegistry instead of direct plugin instantiation
• [ ] Add documentation in ARCHITECTURE.md explaining the plugin system for new contributors

• Add unit tests for SidxParseUtil.swift: create Tests/ directory with tests for SIDX box parsing edge cases (missing boxes, malformed data, empty segments). Currently no test coverage for critical streaming logic.
• Document the plugin architecture with code examples: BilibiliLive/Component/Player/Plugins/ is powerful but undocumented. Add PLUGIN_DEVELOPMENT.md showing how to create a new plugin (e.g., SimpleLoggingPlugin), wire it in CommonPlayerViewController, and explain the lifecycle.
• Implement graceful fallback for dead BiliBili API endpoints: wrap API calls in retry logic with exponential backoff in AccountManager.swift and video plugins. Add a config file (Settings.swift) to toggle between primary/fallback endpoints when endpoints change.

• High · Unsigned IPA Distribution — README.md, GitHub releases/nightly. The project distributes unsigned IPA files from GitHub releases (nightly builds). This bypasses Apple's code signing requirements and security checks, making the application vulnerable to tampering, man-in-the-middle attacks, and malicious modifications. Users installing unsigned binaries face significant security risks. Fix: Only distribute through official channels (App Store, TestFlight) with proper code signing. If distribution outside App Store is necessary, implement code signing and integrity verification mechanisms. Use notarization where applicable.
• High · Potential Credential Exposure in AccountManager — BilibiliLive/AccountManager.swift. The presence of 'AccountManager.swift' without visibility into its implementation raises concerns about how authentication tokens, refresh tokens, and credentials are stored and managed. Credentials might be stored in UserDefaults or Keychain without proper encryption. Fix: Implement secure credential storage using Keychain (not UserDefaults). Never store sensitive credentials in plaintext. Implement token rotation and expiration mechanisms. Audit all credential handling code.
• High · Insecure QR Code Login Mechanism — BilibiliLive/LoginViewController.swift, BilibiliLive/AccountManager.swift. The QR code login feature ('二维码登录') could be vulnerable to MITM attacks if the underlying implementation doesn't use HTTPS/TLS properly, or if QR codes are transmitted or displayed insecurely. No visibility into the login flow implementation. Fix: Ensure all communication during QR code login uses HTTPS with certificate pinning. Validate all authentication endpoints. Implement CSRF tokens for state management. Audit the complete login flow for security.
• Medium · Lack of Dependency Manifest — BilibiliLive.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved. No 'Package.swift', 'Podfile', or clear dependency declaration file is visible in the provided structure. The 'Package.resolved' file exists but the actual dependency specifications are not provided, making it impossible to verify if outdated or vulnerable dependencies are used. Fix: Maintain an up-to-date dependency manifest. Regularly scan dependencies using tools like OWASP Dependency-Check or Swift package vulnerability databases. Pin dependency versions to known-good releases.
• Medium · Custom Protocol Handlers (DLNA/UPNP) — BilibiliLive/Module/DLNA/. The DLNA/UPNP implementation (BiliBiliUpnpDMR.swift, NVASocket.swift) involves custom network protocol handling which could introduce security vulnerabilities if not properly validated. XML parsing (AvTransportScpd.xml, DLNAInfo.xml, NirvanaControl.xml) without proper XXE (XML External Entity) protection is a risk. Fix: Implement proper XML parsing with XXE protection disabled. Validate all UPNP/DLNA messages thoroughly. Implement message signing/verification. Use secure defaults for DLNA/UPNP communication.
• Medium · Custom Video Resource Loading — BilibiliLive/Component/Player/BilibiliVideoResourceLoaderDelegate.swift. BilibiliVideoResourceLoaderDelegate.swift handles custom video resource loading, which could bypass security controls if not properly validating URLs and response data. Risk of URL spoofing, MITM attacks, or serving malicious content. Fix: Validate all video URLs against a whitelist. Implement certificate pinning for video CDN requests. Verify video content integrity using checksums/signatures. Log all resource loading activities.
• Medium · Dynamic Content Rendering with Danmu/Comments — BilibiliLive/Component/Video/VideoDanmuProvider.swift, BilibiliLive/Component/Video/Replys+AttritubedString.swift, BilibiliLive/Component/View/ReplyCell.swift. The danmu (barrage/comments) system and reply rendering (VideoDanmuProvider.swift, VideoDanmuFilter.swift, Replys+AttritubedString.swift) could be vulnerable to XSS attacks if user-generated content is rendered without proper sanitization. Fix: Implement strict input validation and sanitization for all user-generated content. Use safe text rendering APIs. Escape special characters. Consider Content Security

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.