Archery Apprentice Documentation

iOS Development Roadmap

10 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 28):

  • ✅ iOS app framework established
  • ✅ Firebase Firestore integration working
  • ✅ Tournament list and detail views implemented
  • ✅ Join/leave tournament functionality

Shared Code Availability:

  • Tournament: 100% shared (models, DAOs, presenters)
  • Round Scoring: 90% shared (presenter, DAOs exist)
  • 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)

Estimated Total Effort: 12-16 weeks (remaining phases)

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 3: Tournament Creation & Authentication (Future)

Status: NOT STARTED

Estimated Duration: 2-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-18 Status: Active roadmap following iOS Phase 2 completion Next Review: After Phase 3 completion

Graph View

Backlinks