JetPack Architecture Deep Dive

Research compiled: 2026-02-16 Sources: workspace summaries (created Oct 2025 by Joe Newbry), codebase analysis

System Architecture

[iPad App (Swift/SwiftUI)]
    -> [Azure APIM Gateway]
        -> [4.x REST API (ASP.NET Core 8.0)]
            -> [Azure SQL (geo-replicated)]
            -> [External: DAP APIs, JetStream, GDS, CrewSupport, Weather]
        -> [3.x OData API (.NET Framework 4.8)] (legacy, being phased out)
            -> [Azure SQL]
            -> [Azure Service Bus (event-driven)]
            -> [External: JetStream, Tibco]

Frontend Architecture (4.x iOS)

Pattern: MVVM + Repository + Service Layer

Views (SwiftUI)
  -> ViewModels (business logic, state management)
    -> Repositories (data access abstraction)
      -> Services (NetworkService, DatabaseManager)
        -> External (REST APIs, CoreData/SwiftData)

9 Architectural Patterns Used

1. MVVM (primary)
2. Repository Pattern
3. Service Layer
4. Adapter Pattern
5. Observer Pattern (Combine + NotificationCenter)
6. Singleton (NetworkService, AuthUserManager, DatabaseManager)
7. Factory Pattern
8. Strategy Pattern
9. Coordinator Pattern

Key Singletons

• NetworkService -- async/await networking with retry logic
• AuthUserManager -- OAuth 2.0, Keychain storage
• DatabaseManager -- CoreData/SwiftData persistence
• UrlConstructor -- API endpoint building

Persistence (Dual, In Transition)

• CoreData -- Legacy, being phased out
• SwiftData -- Modern replacement, migration in progress
• Offline-first pattern: Check network -> fetch API or cache

Dependencies (SPM)

Backend Architecture (4.x)

Pattern: Clean Architecture with Repository + Unit of Work

Controllers (10+ REST controllers)
  -> Services (business logic, aggregation)
    -> Repositories (Unit of Work pattern)
      -> Entity Framework Core 7.0
        -> Azure SQL (42 tables)
    -> External Adapters (DAP, JetStream, GDS, CrewSupport, Weather)

Key Services

• FlightDetailService -- Aggregates from DAP/GDS
• FlightPlanService -- Parallel DB queries via Task.WhenAll (70%+ speedup)
• PaxListAndCountsService -- SSR code categorization (8 categories: Armed, Deportee, Prisoner, Wheelchair, Infant, Medical, Animals, Other)
• WeatherDataService -- Weather API integration
• FitForDutyV2 -- Digital fitness signatures

Database: 42 SQL Tables

• Flight planning tables
• Aircraft/performance tables
• Crew/passenger tables
• Operations tables
• Maintenance tables
• Weather tables
• System tables

CI/CD Pipeline

1. Stage 1 - Prep (2-3 min): Version stamping, config
2. Stage 2 - Build/Test (10-15 min): Compile, unit tests, SonarQube
3. Stage 3 - Deploy (5-10 min per env): ARM template deployment

Backend Architecture (3.x Legacy)

Pattern: OData v4 + Event-Driven

OData V2 Controllers (15+ entity types)
  -> Entity Framework 6.5.1
    -> Azure SQL

Azure Service Bus
  -> FlightEventQueueMonitor (JetStream data)
  -> LoadCloseoutMonitor (weight/balance)
  -> ExternalQueueEventMonitor (Tibco messages)
    -> 13+ Specialized Parsers

Parser Library (13+ parsers)

FlightPacket, FlightPlan, Route, Fuel, Weight, TakeoffPerformance, ETOPS, Cabin, Crew, Notam, Pirep, Wind, DeferredMaintenance

Formats Handled

JetStream JSON, Tibco XML, Tibco JSON, FltOps XML

Migration Status

• Phase 1 (Complete): 4.x REST API built
• Phase 2 (In Progress): iOS app migrated to 4.x endpoints
• Phase 3 (Planned): Decommission 3.x

Data Flow: Flight Loading

1. Pilot opens app -> OAuth login -> Keychain token
2. App requests pilot schedule -> Backend queries crew systems
3. Pilot selects flight -> App requests flight details
4. Backend aggregates from DAP + GDS + JetStream in parallel
5. Response cached locally (CoreData/SwiftData)
6. Push notifications update data in real-time (Service Bus -> APNS)

Visualization Tool

~/dev/JetPack-Visualization/ -- D3.js force-directed graph mapping data flow across 7 layers: 1. External APIs 2. Backend Entities 3. Services 4. Endpoints 5. Response Models 6. ViewModels 7. Views

Includes CodeMirror JSON editor with test flight scenarios and an inconsistency checker with 8+ rules derived from actual codebase analysis.