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/rileytestut/Delta 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 — Single-maintainer risk — review before adopting

• Last commit 8w ago
• 2 active contributors
• AGPL-3.0 licensed
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 88% of recent commits
• ⚠ AGPL-3.0 is copyleft — check downstream compatibility
• ⚠ No CI workflows detected
• ⚠ 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 rileytestut/Delta repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/rileytestut/Delta.

What it runs against: a local clone of rileytestut/Delta — 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 rileytestut/Delta | Confirms the artifact applies here, not a fork | | 2 | License is still AGPL-3.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 ≤ 83 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of rileytestut/Delta. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/rileytestut/Delta.git
#   cd Delta
#
# 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 rileytestut/Delta and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(AGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"AGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is AGPL-3.0" \\
  || miss "license drift — was AGPL-3.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 "Delta/AppDelegate.swift" \\
  && ok "Delta/AppDelegate.swift" \\
  || miss "missing critical file: Delta/AppDelegate.swift"
test -f "Delta/Database/DatabaseManager.swift" \\
  && ok "Delta/Database/DatabaseManager.swift" \\
  || miss "missing critical file: Delta/Database/DatabaseManager.swift"
test -f "Delta/Database/Model/Human/Game.swift" \\
  && ok "Delta/Database/Model/Human/Game.swift" \\
  || miss "missing critical file: Delta/Database/Model/Human/Game.swift"
test -f "Delta/Database/Model/Delta.xcdatamodeld/Delta.xcdatamodel/contents" \\
  && ok "Delta/Database/Model/Delta.xcdatamodeld/Delta.xcdatamodel/contents" \\
  || miss "missing critical file: Delta/Database/Model/Delta.xcdatamodeld/Delta.xcdatamodel/contents"
test -f "Delta.xcworkspace/contents.xcworkspacedata" \\
  && ok "Delta.xcworkspace/contents.xcworkspacedata" \\
  || miss "missing critical file: Delta.xcworkspace/contents.xcworkspacedata"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 83 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~53d)"
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/rileytestut/Delta"
  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).

Delta is a native iOS emulator application that runs classic video games (NES, SNES, N64, GBC, GBA, DS, Genesis) on non-jailbroken iPhones and iPads by wrapping mature C-based emulator cores (Nestopia, Snes9x, mupen64plus, Gambatte, visualboyadvance-m, melonDS, Genesis Plus GX) in a modern Swift UI. It provides save states, controller skin customization, MFi/PS4/Xbox controller support, and automatic box art detection for imported ROM files. Monolithic iOS app structured as a single Xcode workspace (Delta.xcworkspace) with the main app in Delta/ directory. UI is organized by feature: Database/ (Core Data game library), Components/ (reusable UI widgets like GridCollectionViewLayout, PopoverMenuController, BadgedTableViewCell), and Storyboard-driven screens (Main.storyboard, Settings.storyboard, PauseMenu.storyboard). Emulator cores are vendored in Cores/ as C submodules. Build schemes exist for DeltaFeatures, DeltaPreviews, and Systems testing.

iOS gamers and retro enthusiasts who want to play classic games on their iPhones without jailbreaking; iOS developers interested in game controller integration, Core Data database design, or wrapping C emulation libraries in Swift; and controller skin designers who want to create and distribute custom UI overlays.

Actively developed and production-ready. The codebase is substantial (1.2M+ lines of Swift), uses modern iOS patterns (Storyboards, XIB layouts, Core Data), and supports 7 game systems with beta Genesis support. The project has clear AGPL licensing, established contribution guidelines (CONTRIBUTING.md), and demonstrates mature architecture decisions (separate Cores directory for emulator integration, Components directory for reusable UI). However, commit recency and CI/CD setup are not visible in the provided metadata.

Primary risk is tight coupling to Apple's iOS SDK — breaking iOS API changes could require significant refactoring. The project appears to be maintained by a small team (single prominent maintainer evident from GBA4iOS history), creating continuity risk. Dependency risk is moderately low since core emulation logic is vendored in the Cores/ directory rather than pulled from package managers, but Swift Package Manager integration (Delta.xcworkspace/xcshareddata/swiftpm/Package.resolved) introduces transitive dependency risk. No visible test directory structure suggests limited automated test coverage for UI integration.

No specific PR or commit data provided in metadata, but the file structure indicates active work on: (1) Sega Genesis support marked as beta, (2) pause menu system (PauseMenu.storyboard, PausePresentationControllerContentView.xib), (3) controller skin loading (LoadControllerSkinImageOperation.swift), and (4) cheat database integration (Database/Cheats directory). The multiple build schemes (DeltaFeatures.xcscheme, DeltaPreviews.xcscheme) suggest ongoing feature branching and UI preview work.

git clone https://github.com/rileytestut/Delta.git
cd Delta
git submodule update --init --recursive
open Delta.xcworkspace

Then in Xcode: select the Delta scheme and build for your target iOS version. Note: The .xcworkspace file (not .xcodeproj) must be opened to properly link the vendored emulator cores.

Daily commands: Open Delta.xcworkspace in Xcode (not Delta.xcodeproj), ensure the Delta scheme is selected, connect an iOS device or simulator, then ⌘R to build and run. The app will initialize its Core Data database on first launch. To test a specific feature set: Xcode > Product > Scheme and select DeltaFeatures, DeltaPreviews, or Systems.

• Delta/AppDelegate.swift — Application entry point and lifecycle management; every contributor must understand how the app initializes, manages the database context, and handles background tasks.
• Delta/Database/DatabaseManager.swift — Core abstraction for CoreData access; all database operations funnel through this manager, making it critical for understanding data persistence patterns.
• Delta/Database/Model/Human/Game.swift — Primary domain model representing a playable game; understanding this entity is essential for features across UI, emulation, and persistence layers.
• Delta/Database/Model/Delta.xcdatamodeld/Delta.xcdatamodel/contents — CoreData schema definition; all database migrations and entity relationships are defined here, requiring review for any data model changes.
• Delta.xcworkspace/contents.xcworkspacedata — Workspace configuration managing project organization and inter-project dependencies; essential for understanding the modular structure and subproject relationships.
• Delta/Components/Collection View/GridCollectionViewLayout.swift — Custom layout engine for the primary game grid UI; layout bugs or performance issues here directly impact the main user interface.
• Cores — Submodule directory containing emulator cores (likely Git submodules); critical for understanding how emulation engines are integrated into the app.

Add Support for a New Game System/Core

1. Add the emulator core as a Git submodule in the Cores/ directory and reference it in .gitmodules (.gitmodules)
2. Create a new system entity in the CoreData model by editing the current xcdatamodel and adding a new version if needed (Delta/Database/Model/Delta.xcdatamodeld/Delta.xcdatamodel/contents)
3. Generate or manually create human-readable CoreData entity classes following the pattern of Game.swift (Delta/Database/Model/Human/Game.swift)
4. Create a new migration mapping if the schema changed (Delta/Database/Model/Migrations/Delta10ToDelta11.xcmappingmodel/xcmapping.xml)
5. Register the core with DatabaseManager and ensure it loads properly during app initialization (Delta/Database/DatabaseManager.swift)

Add a New UI Screen or Feature Tab

1. Create a new storyboard file in Delta/Base.lproj following the naming convention (e.g., NewFeature.storyboard) (Delta/Base.lproj/Main.storyboard)
2. Design the UI layout and define view controllers in the storyboard (Delta/Base.lproj/Settings.storyboard)
3. Create custom view controller Swift classes that conform to typical iOS patterns and inject DatabaseManager for data access (Delta/AppDelegate.swift)
4. If the feature displays games or collections, create a custom collection/table cell following GridCollectionViewCell or GameTableViewCell patterns (Delta/Components/Collection View/GridCollectionViewCell.swift)
5. Wire the storyboard scenes to your view controllers and ensure navigation from Main.storyboard or tab bar (Delta/Base.lproj/Main.storyboard)

Add a New Cheat Format or Cheat Management Feature

1. Extend CheatDevice.swift to handle the new cheat format code parsing and validation (Delta/Database/Cheats/CheatDevice.swift)
2. Add new properties to the Cheat CoreData entity if needed to store additional format-specific metadata (Delta/Database/Model/Human/Cheat.swift)
3. Create a new UI component or view controller (e.g., CheatSearchViewController) following the pattern of LegacySearchBar.swift (Delta/Database/Cheats/LegacySearchBar.swift)
4. Update DatabaseManager to handle cheat fetching, filtering, and persistence for the new format (Delta/Database/DatabaseManager.swift)

Customize Controller Skins or Input Mapping

1. Define a new ControllerSkin entity instance or modify the ControllerSkin.swift model to support new properties (Delta/Database/Model/Human/ControllerSkin.swift)
2. Create or edit GameControllerInputMapping to define button-to-emulator-input mappings (Delta/Database/Model/Human/GameControllerInputMapping.swift)
3. Create a UI component for skin selection or customization (e.g., ControllerSkinViewController) and integrate with the pause menu storyboard (Delta/Base.lproj/PauseMenu.storyboard)
4. Update DatabaseManager to load, cache, and apply controller skins during emulation startup (Delta/Database/DatabaseManager.swift)

Submodule initialization: git submodule update --init --recursive is required after clone; omitting this will cause linker failures for emulator cores. Xcode workspace vs. project: Opening Delta.xcodeproj instead of Delta.xcworkspace will lose reference to vendored cores. iOS deployment target: Emulator cores are C89/C99; ensure your iOS target version matches the minimum supported by vendored cores (likely iOS 11+). Core Data migrations: The GamesDatabase.storyboard contains the data model; modifying it without creating migration files will cause crashes on upgrades. Simulator limitations: Some emulator cores (particularly N64 and DS) may be too compute-intensive for simulator; test on real devices. Controller skin format: Custom controller skins require a specific image/JSON pair format not documented in provided files; reverse-engineer from bundled skins.

• Game Controller Framework (GameController.framework) — Delta's entire external controller input system (PS4, Xbox, MFi) is built on GameController.framework; understanding GCController, GCGamepad, and button mapping is essential for modifying input handling.
• Core Data with Model Relationships — The entire game library, save state metadata, cheat database, and controller skin catalog are persisted via Core Data (GamesDatabase.storyboard); you must understand entities, relationships, and fetch requests to modify persistence.
• iOS Storyboard Segues and Unwind Actions — The UI flow (Main.storyboard, Settings.storyboard, PauseMenu.storyboard) is entirely storyboard-driven; adding new screens requires understanding segues, view controller lifecycle, and unwind segues for dismissal.
• Custom UICollectionViewLayout — GridCollectionViewLayout.swift is a custom layout engine controlling how game boxes appear in the library grid; understanding layout attributes, invalidation, and supplementary views is needed to tweak spacing or responsive behavior.
• Operation Queues for Asynchronous Image Loading — LoadControllerSkinImageOperation.swift and LoadImageURLOperation.swift use Foundation's Operation class to prevent blocking the main thread during I/O; understanding dependencies, cancellation, and KVO is needed to optimize performance.
• C-to-Swift Interoperability via Bridging Headers — The emulator cores in Cores/ are pure C89/C99; Delta must bridge them to Swift through Objective-C or C imports; understanding module maps, bridging headers, and unsafe pointer conversions is essential for emulation.
• Save State Serialization and File I/O — Delta's save state feature requires serializing emulator memory snapshots to disk and deserializing them on load; understanding file system sandboxing, Codable, and binary formats is key to implementing robust save/load.

• rileytestut/Provenance — Another iOS multi-system emulator with similar architecture; useful reference for controller mapping patterns and save state management.
• rileytestut/GBA4iOS — The spiritual predecessor to Delta (mentioned in README); shows the evolution from GBA-only to multi-system emulation.
• rileytestut/AltStore — Companion project by the same author; the distribution mechanism for Delta on non-jailbroken iOS devices via MDM workarounds.
• snes9xgit/snes9x — One of the core emulation engines vendored in Cores/; understanding its API is critical for SNES emulation integration.
• mupen64plus/mupen64plus-core — The N64 emulation core vendored in Cores/; N64 is the most computationally intensive system supported, making this core's optimization crucial.

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.

Add unit tests for Database/DatabaseManager.swift and Core Data migration logic

The repo has 11 versions of the Core Data model (Delta.xcdatamodeld/Delta 1-11.xcdatamodel) indicating significant schema evolution, but no visible test coverage for DatabaseManager or migration validation. New contributors could add tests to prevent data loss during migrations and validate the DatabaseManager's CRUD operations across model versions.

• [ ] Create Delta/Tests/Database/DatabaseManagerTests.swift
• [ ] Add unit tests for Core Data migration from Delta 10 → Delta 11 model versions
• [ ] Test DatabaseManager initialization, fetch, create, update, and delete operations
• [ ] Add tests for CheatMetadata and CheatDevice persistence
• [ ] Reference existing model files: Delta/Database/Model/Delta.xcdatamodeld/

Add GitHub Actions workflow for Swift linting and build validation

The repo uses Swift 5.0+ (per badge) and has multiple Xcode schemes (Delta, DeltaFeatures, DeltaPreviews, Systems) but no visible CI workflow file. A Swift linting + build validation workflow would catch syntax errors and scheme incompatibilities before merge.

• [ ] Create .github/workflows/swift-lint-and-build.yml
• [ ] Add SwiftLint linting step targeting Delta/ and Components/ directories
• [ ] Add xcodebuild validation for all schemes in Delta.xcodeproj/xcshareddata/xcschemes/
• [ ] Test against iOS deployment target from Delta.xcodeproj/project.pbxproj
• [ ] Include build step for Delta.xcworkspace (not just .xcodeproj)

Extract and document the emulator core integration pattern in Cores/ subdirectory

The file structure shows a Cores/ directory (mentioned in .gitmodules as submodules) but no documentation on how to add new emulator cores or integrate existing ones. A guide with code examples would unlock contributions from developers wanting to add NES, SNES, or other system support.

• [ ] Create CORE_INTEGRATION.md documenting the Cores/ submodule structure and expectations
• [ ] Document the interface/protocol that emulator cores must implement (reference Delta/AppDelegate.swift for initialization)
• [ ] Add example: 'How to add a new Game Boy core' with step-by-step submodule integration
• [ ] Reference .gitmodules to explain existing core dependencies
• [ ] Include build instructions for systems using the Systems.xcscheme

• Add unit tests for GridCollectionViewLayout.swift — currently no visible test directory exists. Create XCTest targets in Delta.xcodeproj to verify grid sizing, cell spacing, and responsiveness across device sizes.: Tests are absent for a critical UI component affecting the game library display on the main screen.
• Document the controller skin JSON schema in a CONTROLLER_SKINS.md file — users trying to create custom skins have no canonical format reference. Include example skin bundle structure and field descriptions.: The custom controller skin feature (LoadControllerSkinImageOperation.swift) is mentioned but has no user-facing documentation for skin creators.
• Add accessibility labels and VoiceOver support to GameTableViewCell.swift and GridCollectionViewCell.swift — currently no a11y hints visible. Implement accessibilityLabel, accessibilityValue, and accessibilityHint for screen readers.: Game library browsing is inaccessible to visually impaired users; low-hanging fruit for inclusive design.

• High · Keychain Component Security — Delta/Components/Keychain.swift. The presence of 'Delta/Components/Keychain.swift' suggests credential storage implementation. Without reviewing the actual code, common issues include: insecure keychain query construction, missing access control attributes, insufficient data protection, or improper error handling that could leak sensitive information. Fix: Ensure keychain queries use kSecAttrAccessibleWhenUnlockedThisDeviceOnly or stricter, implement proper error handling without logging sensitive data, use kSecAttrSynchronizable=false for sensitive credentials, and avoid storing credentials in UserDefaults or plain text.
• High · Potential SQL Injection in Core Data Implementation — Delta/Database/Model/Delta.xcdatamodeld/. The application uses Core Data with multiple database model versions (Delta 2 through Delta 11 xcdatamodels). Core Data typically mitigates SQL injection, but improper use of NSFetchRequest with dynamic predicates or raw SQL could introduce vulnerabilities. Fix: Always use NSFetchRequest with NSPredicate using parameterized queries; avoid string concatenation for predicate construction. Review DatabaseManager.swift for any raw SQL or unsafe predicate building.
• High · Insecure Game ROM Storage — Delta/Database/Model/Human/Game.swift. The application handles game ROM files, which may contain copyrighted material. Without proper access controls and encryption, stored game files could be accessed via file system exploitation or backup mechanisms. Fix: Implement file protection with NSFileProtectionComplete, disable iTunes file sharing if not required, encrypt sensitive game metadata, and implement strict file access controls using SecureEnclave if available.
• Medium · Storyboard and XIB File Security — Delta/Base.lproj/*.storyboard, Delta/Base.lproj/*.xib. Multiple XIB and Storyboard files present (Main.storyboard, Settings.storyboard, etc.). These XML-based files could contain hardcoded URLs, identifiers, or segue logic that might expose security-sensitive information or enable unauthorized navigation flows. Fix: Audit all storyboard segues for logic flaws, avoid hardcoding sensitive URLs or API endpoints in UI definitions, use view controller initialization methods for sensitive data passing, and consider programmatic UI construction for security-critical flows.
• Medium · Controller Skin Loading - Arbitrary Code/Resource Execution — Delta/Components/Loading/LoadControllerSkinImageOperation.swift. The LoadControllerSkinImageOperation.swift suggests loading external controller skin resources. If skin files are user-provided or downloaded without proper validation, this could enable arbitrary resource loading, including potentially malicious assets. Fix: Validate controller skin files before loading (signature verification, whitelist of trusted sources), sanitize file paths to prevent directory traversal, implement strict content-type validation, and sandbox resource loading operations.
• Medium · Network Request Security - LoadImageURLOperation — Delta/Components/Loading/LoadImageURLOperation.swift. LoadImageURLOperation.swift downloads images from URLs. Without HTTPS enforcement, certificate pinning, and proper SSL validation, the application is vulnerable to MITM attacks and data interception. Fix: Enforce HTTPS-only connections, implement certificate pinning for critical endpoints, validate SSL certificates properly, use URLSession with secure configuration, and implement timeout mechanisms.
• Medium · Cheats Database - Injection and Code Execution Risk — Delta/Database/Cheats/CheatBase.swift, CheatDevice.swift, CheatMetadata.swift. The cheats subsystem (Delta/Database/Cheats/) may process user-provided cheat codes. Improper parsing or execution of cheat codes could lead to format string attacks, buffer overflows, or code injection depending on the emulation backend. Fix: Validate and sanitize all cheat code inputs against strict whitelist patterns, avoid dynamic code execution from user-provided cheats, implement sandboxing for cheat processing, and log all cheat modifications for audit trails.
• Low · Missing Security Headers in Web Content — Delta/Components/FollowUsFooterView.swift, Delta/Components/FollowUsFoot. If the application displays web content or loads remote resources (FollowUsFooterView suggests external links), missing security headers could enable attacks. Fix: undefined

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.