Archery Apprentice Documentation

iOS Development Roadmap

16 min read

Home > Developer Guide > iOS > iOS Development Roadmap

iOS Development Roadmap

Purpose: Define the path to iOS feature parity with Android app, leveraging existing KMP shared code

Context: iOS Phase 2 (tournament features) completed in Week 28. This roadmap covers all remaining features.

Impact: Provides clear scope, dependencies, and effort estimates for each development phase

Executive Summary

Current State (Week 31):

  • ✅ iOS app framework established
  • ✅ Firebase Firestore integration working
  • ✅ Tournament list and detail views implemented
  • ✅ Join/leave tournament functionality
  • ✅ Round Scoring MVP complete (Phase 2, PR #298)
  • ✅ iOS tab navigation architecture complete (Phase 3B pivot)
  • ✅ Equipment Hub complete (Phase 3a, PR #301) - TDD approach
  • ✅ Visual Scoring complete (Phase 4a-4c, PRs #307, #308, #309) - Android parity achieved
  • ✅ Shot Placement Persistence complete (Phase 4c) - Coordinates persisted with SOLID refactoring
  • ✅ Analytics Dashboard complete (Phase 5a, PR #312) - TDD approach with 28 tests

Plan Reordering (Week 29): Authentication moved from Phase 2 to Phase 5 after discovering missing Kotlin iosMain infrastructure. Phases reordered to prioritize features with 90-95% shared KMP code (Round Scoring, Equipment, Tournaments) before tackling complex infrastructure work.

Shared Code Availability:

  • Tournament: 100% shared (models, DAOs, presenters)
  • Round Scoring: 90-95% shared (presenter, DAOs exist) ← Current Focus
  • Equipment: 95% shared (10 presenters, 11 DAOs exist)
  • Statistics: 50% shared (DAOs exist, analytics logic Android-specific)
  • Authentication: 40% shared (models exist, platform-specific implementation) - Deferred to Phase 5

Estimated Remaining Effort: 10-14 weeks (Phases 2b-6)

  • Phase 2 (Round Scoring): 4-5 weeks remaining (2a complete)
  • Phase 3 (Equipment): 3 weeks
  • Phase 4 (Tournaments): 4 weeks
  • Phase 5 (Authentication): 2 weeks
  • Phase 6 (Polish): 3 weeks

Phase Breakdown

Phase 1: Framework & Tournament List (Week 28) ✅ COMPLETE

Status: COMPLETED 2025-11-18

What Was Built:

  • iOS app framework (Xcode project, KMP integration)
  • TournamentListView (SwiftUI)
  • TournamentListViewModel (Firebase integration)
  • Navigation infrastructure

Key Achievements:

  • Established Swift-Kotlin interop patterns
  • Firebase setup and initialization
  • KMP-NativeCoroutines integration

PRs:

  • #272: Initial iOS app framework
  • #273: TournamentListView

Lessons Learned:

  • Swift Int → Kotlin Int32 conversion required
  • KotlinLong uses .int64Value, not .longValue
  • Firebase availability checks prevent crashes
  • Graceful error handling essential

Phase 2: Tournament Detail & Participation (Week 28) ✅ COMPLETE

Status: COMPLETED 2025-11-18

What Was Built:

  • TournamentDetailView (SwiftUI)
  • TournamentDetailViewModel (Firebase integration)
  • Join/leave tournament operations (transaction-based)
  • Integration with TournamentListView navigation

Key Achievements:

  • Transaction-based participant management (prevents race conditions)
  • Proper type conversions for all Kotlin types
  • Swift-Kotlin property name mapping patterns documented

PRs:

  • #275: TournamentDetailViewModel implementation
  • #276: TournamentDetailView implementation
  • #278: Build error fixes (KMP plugin, type conversions, Firebase)

Lessons Learned:

  • guard/return pattern doesn’t work in WindowGroup body
  • Copilot enforcement of zero attribution
  • Integration reviews critical for multi-agent work

Documentation:

Phase 2 (Reordered): Round Scoring MVP ⏳ IN PROGRESS

Status: IN PROGRESS (Week 29+) Started: 2025-11-20 Estimated Duration: 4-5 weeks (part-time)

What’s Being Built:

  • Round creation, persistence, list display, active scoring, and details
  • Leveraging 90-95% shared KMP code from Android
  • 6 subphases (2a-2f)

Current Progress:

  • ✅ Phase 2a: Round Creation (PR #284) - Complete
  • ✅ Phase 2b: Round Persistence - Complete
  • ✅ Phase 2c: Round History List - Complete
  • ✅ Phase 2d: Active Scoring - Complete
  • ✅ Phase 2e: Round Details - Complete
  • ✅ Phase 2f: Flow Bridging & Database Fixes (PR #298) - Complete

Key Achievements (Phase 2a):

  • Comprehensive round creation form (407 lines SwiftUI)
  • Quick Start templates (18m Indoor, 70m Outdoor)
  • Real-time validation with Combine publishers
  • Auto-selection of scoring systems
  • Summary card with total arrows and max score
  • Mock repository (ready for Phase 2b integration)

Key Achievements (Phase 2f - PR #298):

  • FK constraint removal (database v36) - Prevents “UNIQUE constraint” errors
  • Flow bridging simplified to suspend functions - Cleaner KMP-NativeCoroutines integration
  • kotlin.time.Clock import pattern established
  • CI runner selection fixes (merge commit vs PR head, JSON array format)

PRs:

  • #284: Round Creation implementation
  • #298: Phase 2f Flow bridging, FK removal, CI fixes

Shared Code Leveraged:

  • Round entity (shared/database)
  • ScoringSystem, Distance, TargetSize enums
  • Form validation logic

CI/CD Lessons (PR #298):

Detailed Documentation:

Phase 3 (Reordered): Equipment Management ⏳ IN PROGRESS

Status: Phase 3a COMPLETE, Phases 3b-3d NOT STARTED

Estimated Duration: 3 weeks total (Phase 3a complete in 1 day)

Dependencies:

  • Phase 2 complete ✅

Shared Code Available: 95% (10 presenters, 11 DAOs)

Phase 3a: Equipment Hub ✅ COMPLETE

Status: COMPLETED 2025-11-28 PR: #301

What Was Built:

  • EquipmentHubView with 3 category groups and equipment counts
  • EquipmentListView with swipe-to-delete and confirmation dialogs
  • EquipmentListViewModel (unified for all 10 equipment types)
  • EquipmentRepositoryBridge (adapts 10 KMP DAOs to Swift)
  • Type-erased EquipmentItem protocol for generic list display
  • 20+ unit tests (TDD approach)

Key Achievements:

  • async let concurrent fetching for 10 parallel DAO calls
  • FlowUtils.first() pattern for Flow → single value conversion
  • KMP enum comparison via .name property (not ==)
  • Force cast pattern for guaranteed KMP Flow types

Categories Implemented:

  • Bow Components: Riser, Limbs, Sight, Rest, Plunger
  • String & Stabilization: BowString, Stabilizer, Weight
  • Arrows & Accessories: Arrow, Accessory

Documentation:

Phase 3b: Equipment Add/Edit (Future)

Features to Implement:

  • Equipment creation forms for all 10 types
  • Equipment editing screens
  • Form validation with Combine

Phase 3c: Equipment Details (Future)

Features to Implement:

  • Detailed view for each equipment type
  • Equipment-specific fields display
  • Equipment performance tracking

Phase 3d: Bow Setup Management (Future)

Features to Implement:

  • Bow setup creation (assemble from components)
  • Bow setup editing
  • Integration with round scoring

Phase 4: Active Scoring Enhancements

Phase 4b: Visual Scoring Integration ✅ COMPLETE

Status: COMPLETED 2025-11-28 PR: #308

What Was Built:

  • Visual target tap-to-score integration
  • Score button layouts for all 4 scoring systems (Olympic, Compound, Indoor, Field)
  • X-ring vs 10 distinction (matching Android behavior exactly)
  • Unified ArrowScoreCircle component for consistent display
  • Resume scoring for incomplete rounds (UPSERT pattern)

Bugs Fixed (6 total):

  1. KMP Coroutine Crash - Added @MainActor to Task closures calling KMP suspend functions
  2. Missing X Button - Created DynamicScoreButtons matching Android’s ScoreInputSection.kt
  3. SQLite UNIQUE Constraint Crash - Implemented UPSERT pattern for arrow scores
  4. X Shows as 10 - Changed to explicit isX flag (default false, matching Android)
  5. Inconsistent Score Display - Created unified ArrowScoreCircle component

Key Patterns Established:

  • @MainActor for Task closures calling KMP code
  • UPSERT pattern for database operations on resume
  • Explicit parameter pattern (don’t auto-detect user intent)
  • Resume state pattern (load existing data on view appear)
  • KMP enum comparison via .name property

Color Scheme (Android Parity):

ScoreColor
XRed
10Green
8-9Blue
6-7Orange
1-5Gray
MGray

New Component:

  • Components/ArrowScoreCircle.swift - Unified arrow score display (two sizes: small/medium)

Documentation:

Phase 4c: Shot Placement Persistence & SOLID Refactoring ✅ COMPLETE

Status: COMPLETED 2025-11-29 PR: #309

What Was Built:

  • Shot placement coordinate persistence (-1 to 1 normalized range)
  • Resume scoring with arrow coordinate restoration
  • ArrowEntry struct replacing parallel arrays (Single Source of Truth)
  • ScoringOperations shared helper (eliminates duplicate scoring logic)
  • Protocol extraction to DI/Protocols.swift (Interface Segregation)
  • Consolidated PreviewEquipmentRepository (was 4 duplicates)
  • Safe guard-based unwrapping (replaces force casts)
  • Accessibility support for TargetFaceView

Key Refactoring:

  • Replaced 3 parallel arrays with single currentEndArrows: [ArrowEntry] array
  • Extracted ScoringOperations enum for shared save/complete logic
  • Moved all repository protocols to centralized Protocols.swift
  • Net reduction of ~366 lines while improving maintainability

Test Coverage:

  • ScoreColorTests: 25 tests
  • ArrowScoreCircleTests: 17 tests
  • ActiveScoringViewModelTests: +47 new tests (resume, X-ring edge cases, coordinates)
  • Total: 501+ tests passing

Documentation:

Phase 5: Analytics Dashboard

Phase 5a: Analytics Hub ✅ COMPLETE

Status: COMPLETED 2025-11-30 PR: #312

What Was Built:

iOS:

  • AnalyticsHubViewModel with TDD approach (28 tests)
  • AnalyticsTabView with summary cards and recent rounds list
  • AnalyticsRepositoryBridge for KMP integration
  • AnalyticsRepositoryProtocol added to Protocols.swift
  • StatCard and RecentRoundRow components

Android:

  • loadPerformanceStats() implementation in RoundAnalyticsViewModel
  • EquipmentDriftStats data class and SQL query in RoundDao
  • Fixed hardcoded max score bug (was 10, now uses scoringSystem.maxScore)
  • Time-range filtering fixes in EquipmentComparisonScreen

Key Features:

  • Total rounds count
  • Total arrows shot
  • Average score per arrow
  • Recent rounds list (limit 10)
  • Pull-to-refresh with data preservation on error
  • Empty state handling

Test Coverage:

  • iOS: 28 new tests (AnalyticsHubViewModelTests)
  • Android: 9 new tests (RoundDaoTimeRangeFilteringTest)
  • Total: 37 new tests

Known Issues (Documented for Future):

  • AnalyticsTabView not yet wired into MainTabView
  • N+1 query problem in statistics loop (acceptable for MVP)

Documentation:

Phase 4 (Reordered): Tournaments & Analytics (Future)

Status: Partially Complete (Tournament viewing done in original Phase 1-2)

Estimated Duration: 4 weeks

Dependencies:

  • Phase 2-3 complete

What’s Complete:

  • ✅ Tournament list view
  • ✅ Tournament details view
  • ✅ Join/leave functionality

What’s Remaining:

  • Tournament creation
  • Tournament management
  • Advanced analytics

Phase 6 (Reordered): Authentication & Settings (Future)

Status: Deferred (was originally Phase 2)

Estimated Duration: 2 weeks

Why Moved to Phase 5:

  • Discovered missing Kotlin iosMain infrastructure (Phase 3B pivot)
  • Authentication not required for core features
  • Allows shipping features faster

See: Phase 3B: iOS Navigation Foundation for deferral rationale

Phase 6 (Original Phase 3): Polish & Release (Future)

Status: NOT STARTED

Estimated Duration: 3 weeks

Dependencies:

  • Phase 2 complete ✅

Features to Implement:

3.1 Authentication (Google/Apple Sign-In)

  • Shared Code Available: SecurityModels.kt (domain models)
  • iOS Work Needed:
    • Implement GoogleSignInProvider (Swift wrapper for Google SDK)
    • Implement AppleSignInProvider (native AuthenticationServices)
    • Create IOSAuthProvider (conforms to shared auth interface)
    • AuthenticationView (SwiftUI login screen)
    • AuthenticationViewModel (Firebase Auth integration)

Effort: 1 week

  • Google Sign-In SDK integration (2 days)
  • Apple Sign-In integration (1 day)
  • AuthenticationView UI (1 day)
  • Firebase Auth ViewModel (2 days)

3.2 Tournament Creation

  • Shared Code Available: Tournament model, TournamentRepository interfaces
  • iOS Work Needed:
    • TournamentCreationView (multi-step form)
    • TournamentCreationViewModel (validation, Firebase write)
    • Form components (date picker, location selector, rules editor)
    • Integration with TournamentListView (refresh after creation)

Effort: 1-2 weeks

  • TournamentCreationView UI (4 days)
  • Form validation logic (2 days)
  • Firebase create operation (1 day)
  • Integration and testing (2 days)

Shared Code Audit:

  • ✅ Tournament model exists (shared/domain/models/tournament/)
  • ✅ Firebase integration pattern established (from Phase 2)
  • ❌ No shared tournament creation presenter (Android ViewModel is app-specific)
  • Action: Create TournamentCreationViewModel in iOS (similar to Android pattern)

Success Criteria:

  • User can sign in with Google or Apple ID
  • User can create new tournaments
  • Created tournaments appear in TournamentListView
  • Authentication state persists across app launches

Phase 4: Active Scoring (Offline-First) (Future)

Status: NOT STARTED

Estimated Duration: 4-5 weeks

Dependencies:

  • Phase 3 complete (authentication required for user-owned rounds)

Features to Implement:

4.1 Round Creation

  • Shared Code Available:
    • RoundDisplayPresenter (shared/presentation/round/)
    • RoundDao (shared/database/)
    • RoundFormat model (shared/domain/models/tournament/)
  • iOS Work Needed:
    • RoundCreationView (round setup form)
    • RoundCreationViewModel (validation, local DB write)
    • Integration with scoring session

Effort: 1 week

4.2 Active Scoring Interface

  • Shared Code Available:
    • RoundDisplayPresenter (shared/presentation/round/)
    • RoundDao (shared/database/)
    • ScoringSystem models (shared/domain/models/)
  • iOS Work Needed:
    • ActiveScoringView (end-by-end score entry)
    • LiveScoringViewModel (local state management)
    • Target face rendering (custom SwiftUI drawing)
    • Arrow score input components

Effort: 2-3 weeks

  • ActiveScoringView UI (5 days)
  • Target face drawing (3 days)
  • Score entry logic (3 days)
  • LiveScoringViewModel (2 days)

Key Challenge: Offline-first architecture

  • Local Room database writes
  • Sync when online
  • Conflict resolution

4.3 Round History & Details

  • Shared Code Available:
    • RoundDao (query operations)
    • RoundDisplayPresenter
  • iOS Work Needed:
    • HistoricalRoundsView (list of completed rounds)
    • RoundDetailsView (view past round scores)
    • RoundAnalyticsView (basic stats: total, average, best end)

Effort: 1 week

Shared Code Audit:

  • ✅ RoundDisplayPresenter exists (shared/presentation/round/RoundDisplayPresenter.kt)
  • ✅ RoundDao exists (shared/database/dao/RoundDao.kt)
  • ✅ ScoringSystem models exist (shared/domain/models/ScoringSystem.kt)
  • ✅ TournamentScoreCacheDao exists (shared/database/dao/TournamentScoreCacheDao.kt)
  • ❌ LiveScoringViewModel is Android-specific (app/ui/roundScoring/LiveScoringViewModel.kt)
  • Action: Port LiveScoringViewModel logic to iOS (or create shared presenter)

Success Criteria:

  • User can create new round with format/distance
  • User can score arrows end-by-end
  • Scores persist locally (offline mode)
  • User can view historical rounds
  • Scores sync to Firebase when online

Phase 5: Gear Management (Future)

Status: NOT STARTED

Estimated Duration: 3-4 weeks

Dependencies:

  • Phase 3 complete (authentication required for user-owned equipment)

Features to Implement:

5.1 Equipment Profiles

  • Shared Code Available: (⭐ HIGHEST KMP COVERAGE ⭐)
    • 10 Equipment Presenters (shared/presentation/equipment/):
      • AccessoryPresenter
      • ArrowPresenter
      • BowStringPresenter
      • LimbsPresenter
      • PlungerPresenter
      • RestPresenter
      • RiserPresenter
      • SightPresenter
      • StabilizerPresenter
      • WeightPresenter
    • 11 Equipment DAOs (shared/database/dao/):
      • All equipment types (Riser, Limbs, BowString, Arrow, Sight, Rest, Plunger, Stabilizer, Weight, Accessory, BowSetup)
    • BowSetup model (shared/domain/models/equipment/)

iOS Work Needed:

  • EquipmentListView (list all equipment by type)
  • EquipmentDetailView (view/edit equipment specs)
  • EquipmentCreationView (add new equipment)
  • EquipmentSelectionView (pick equipment for round)
  • ViewModels wrapping existing presenters

Effort: 2-3 weeks

  • Equipment list UI (3 days)
  • Equipment detail/edit UI (4 days)
  • Equipment creation UI (3 days)
  • Integration with 10 presenters (3 days)
  • Testing and refinement (2 days)

5.2 Bow Setup Management

  • Shared Code Available:
    • BowSetupDao (shared/database/)
    • BowSetup model (shared/domain/models/equipment/)
  • iOS Work Needed:
    • BowSetupView (assemble bow from components)
    • BowSetupViewModel (validation, save setup)

Effort: 1 week

Shared Code Audit:

  • ✅ ALL 10 equipment presenters exist (shared/presentation/equipment/)
  • ✅ ALL 11 equipment DAOs exist (shared/database/dao/)
  • ✅ BowSetup model exists (shared/domain/models/equipment/BowSetup.kt)
  • ✅ EquipmentStatsDao exists (shared/database/dao/EquipmentStatsDao.kt)
  • KMP Readiness: 95% - Nearly all business logic is shared!
  • Action: Create thin SwiftUI wrappers around existing presenters

Success Criteria:

  • User can view all equipment by type
  • User can add/edit equipment specifications
  • User can create bow setups from components
  • User can select equipment for rounds
  • Equipment persists locally and syncs to Firebase

Phase 6: Statistics & Analytics (Future)

Status: NOT STARTED

Estimated Duration: 2-3 weeks

Dependencies:

  • Phase 4 complete (needs round scoring data)
  • Phase 5 complete (needs equipment data for correlations)

Features to Implement:

6.1 Personal Statistics

  • Shared Code Available:
    • EquipmentStatsDao (shared/database/dao/)
    • Some analytics models (need audit)
  • iOS Work Needed:
    • PersonalStatsView (overview dashboard)
    • StatsViewModel (aggregation queries)
    • Charts/graphs (Swift Charts)
    • Filters (date range, equipment, distance)

Effort: 1-2 weeks

6.2 Shot Grouping Analysis

  • Shared Code Available:
    • DomainCoordinate model (shared/domain/models/)
  • iOS Work Needed:
    • GroupingAnalysisView (visual shot pattern)
    • GroupingViewModel (calculate grouping metrics)
    • Custom drawing for shot dispersion

Effort: 1 week

Shared Code Audit:

  • ✅ EquipmentStatsDao exists (shared/database/dao/EquipmentStatsDao.kt)
  • ✅ DomainCoordinate exists (shared/domain/models/DomainCoordinate.kt)
  • ⚠️ RoundAnalyticsViewModel is Android-specific (app/ui/roundScoring/RoundAnalyticsViewModel.kt)
  • ⚠️ Analytics logic NOT in shared code (needs investigation)
  • KMP Readiness: 50% - DAOs exist, but analytics calculations are Android-specific
  • Action: Audit analytics algorithms, consider moving to shared presenter

Success Criteria:

  • User sees personal bests and averages
  • User sees progress over time (charts)
  • User sees shot grouping analysis
  • User can filter stats by equipment/date

Phase 7: iOS-Specific Features (Future)

Status: NOT STARTED

Estimated Duration: 2-3 weeks (optional enhancements)

Dependencies:

  • Phases 1-6 complete (feature parity achieved)

Features to Implement (iOS Enhancements):

7.1 Widgets

  • Home screen widget (today’s best score, upcoming tournaments)
  • Lock screen widget (quick score entry)
  • Effort: 1 week

7.2 Apple Watch App

  • Round scoring on watch
  • Tournament countdown
  • Quick stats view
  • Effort: 2-3 weeks

7.3 Live Activities

  • Real-time tournament scoring updates
  • Active round progress
  • Effort: 3-5 days

Shared Code Audit:

  • ❌ No shared code for widgets/watch (iOS-specific UI)
  • ✅ Can reuse presenters/DAOs for data access
  • KMP Readiness: N/A (platform features)

Success Criteria:

  • Widget displays accurate data
  • Watch app syncs with phone
  • Live Activities work during tournaments

Shared Code Summary

High KMP Coverage (90%+)

  1. Equipment Management - 95% shared

    • 10 presenters ready to use
    • 11 DAOs ready to use
    • Minimal iOS UI work needed

  2. Round Scoring - 90% shared

    • RoundDisplayPresenter exists
    • RoundDao exists
    • LiveScoringViewModel needs porting

  3. Tournament Management - 100% shared

    • Already implemented in iOS (Phase 2)

Medium KMP Coverage (40-60%)

  1. Statistics & Analytics - 50% shared

    • DAOs exist
    • Analytics calculations in Android ViewModels
    • Needs shared presenter or iOS reimplementation

  2. Authentication - 40% shared

    • SecurityModels exist
    • Platform-specific SDKs (Google, Apple)
    • Firebase Auth integration per platform

Phase 4 & 5 (High Priority):

  • Leverage existing shared presenters (equipment, round scoring)
  • Focus iOS effort on SwiftUI UI layer
  • Minimal business logic reimplementation

Phase 6 (Medium Priority):

  • Audit Android analytics algorithms
  • Consider moving calculations to shared presenter
  • Alternative: Reimplement in iOS (if algorithms simple)

Phase 3 & 7 (Low Shared Code):

  • Implement platform-specific code as needed
  • Authentication: Use Firebase SDKs per platform
  • Widgets/Watch: iOS-specific (no shared code)

Dependencies Between Phases

Phase 1 (Framework) ✅
    ↓
Phase 2 (Tournament Detail) ✅
    ↓
Phase 3 (Auth + Tournament Creation)
    ↓
Phase 4 (Active Scoring)
    ↓
Phase 5 (Equipment) ← Can parallelize with Phase 4
    ↓
Phase 6 (Analytics)
    ↓
Phase 7 (iOS-Specific Features)

Critical Path:

  • Phases 1-2 (complete)
  • Phase 3 (blocks everything - auth required)
  • Phase 4 or 5 (can parallelize)
  • Phase 6 (needs data from 4 & 5)
  • Phase 7 (optional enhancements)

Parallelization Opportunities:

  • After Phase 3: Phase 4 and Phase 5 can be built in parallel
  • Phase 7 features are independent and can be prioritized separately

Effort Estimates

PhaseDurationComplexityKMP Leverage
Phase 1: Framework ✅2 weeksMedium60%
Phase 2: Tournament Detail ✅1-2 weeksMedium80%
Phase 3: Auth + Creation2-3 weeksMedium40%
Phase 4: Active Scoring4-5 weeksHigh90%
Phase 5: Equipment3-4 weeksLow95%
Phase 6: Analytics2-3 weeksMedium50%
Phase 7: iOS Features2-3 weeksLow0%
Total Remaining12-16 weeks--

Notes:

  • KMP Leverage: Percentage of feature where shared code exists
  • Complexity: Based on Android implementation size and algorithm complexity
  • Duration: Assumes 1 full-time developer working on iOS

Risk Assessment

Technical Risks

Risk 1: Swift-Kotlin Type Conversion Edge Cases

  • Likelihood: Medium
  • Impact: Low (slows development, but not blocking)
  • Mitigation: Continue documenting patterns in kotlin-swift-interop

Risk 2: Firebase Offline Sync Differences

  • Likelihood: High
  • Impact: Medium (affects Phase 4 scoring)
  • Mitigation: Test offline behavior early, document differences

Risk 3: KMP-NativeCoroutines Plugin Updates

  • Likelihood: Medium
  • Impact: Medium (build breaks when upgrading Kotlin)
  • Mitigation: Pin plugin versions, test upgrades in isolation

Risk 4: Room Database iOS Performance

  • Likelihood: Low
  • Impact: High (if slow, affects user experience)
  • Mitigation: Profile query performance, add indexes as needed

Process Risks

Risk 5: Feature Scope Creep

  • Likelihood: Medium
  • Impact: High (delays feature parity)
  • Mitigation: Strict adherence to roadmap, defer iOS-specific features to Phase 7

Risk 6: Android-iOS Feature Drift

  • Likelihood: Medium
  • Impact: Medium (iOS falls behind as Android adds features)
  • Mitigation: Pause Android new features until iOS catches up, or budget iOS updates

Success Metrics

Phase Completion Metrics

  • ✅ All features from Android phase implemented on iOS
  • ✅ No build errors (Xcode compilation passes)
  • ✅ No runtime crashes (Firebase, Room, type conversions work)
  • ✅ Zero attribution in all commits/PRs
  • ✅ Documentation updated (session notes, patterns, guides)

Quality Metrics

  • Test coverage: 60%+ for ViewModels
  • Zero P0 bugs at phase completion
  • Performance: UI response < 100ms
  • Offline mode: All features work without network

User Experience Metrics

  • Feature parity: iOS has 100% of Android features
  • User satisfaction: App Store rating > 4.5
  • Retention: Users continue using both platforms

Next Steps

Immediate (Post-Phase 2):

  1. Merge PR #60 (iOS Phase 2 documentation)
  2. Celebrate Phase 2 completion 🎉
  3. Plan Phase 3 kickoff

Phase 3 Planning (Next Session):

  1. Design authentication flow (Google + Apple Sign-In)
  2. Create Agent assignments for Auth + Tournament Creation
  3. Set up Firebase Auth configuration
  4. Define acceptance criteria

Long-Term:

  1. Reassess roadmap after Phase 3 (adjust estimates)
  2. Consider hiring iOS specialist if timeline critical
  3. Evaluate Phase 7 features based on user feedback

Architecture:

Session Documentation:

KMP Architecture:

  • shared/MODULE_ARCHITECTURE.md - KMP module structure
  • shared/presentation/ - Shared presenters for equipment, rounds, tournaments

Android Implementation:

  • app/src/main/java/com/archeryapprentice/ui/ - Reference for iOS UI
  • app/src/main/java/com/archeryapprentice/ui/roundScoring/ - Active scoring reference
  • app/src/main/java/com/archeryapprentice/ui/equipment/ - Equipment UI reference

Last Updated: 2025-11-30 Status: Active roadmap following iOS Phase 5a completion Next Review: After Phase 5b (Advanced Analytics) completion

Graph View

Backlinks