iOS Engineer_Native Biomathematical Engine Integration

Role summary

Existing production iOS app with a prepared calculation protocol boundary. Integrate a licensed third-party native biomathematical library behind that boundary, map SDK I/O to app DTOs, dual-run against an in-house baseline, feature-flag cutover, and ship without rewriting product UI.

Technical context

• Platform: iOS 17+, Swift 5.9+, SwiftUI
• Architecture: MVVM-ish + service layer (singletons + @EnvironmentObject)
• Persistence: Core Data; Keychain for sensitive params
• Integrations: HealthKit, UserNotifications, BackgroundTasks, haptics
• Tests: XCTest unit/integration + UITests
• Scale: ~80 Swift files / ~18k LOC incl. tests
• Process: Conventional commits; PR to main; concurrency hygiene in progress (@MainActor, Swift 6–oriented)

Architecture seam (already prepared)

• SwiftUI Views → Services (data, HealthKit, notifications, personalization, monitor) → AlertnessEngine protocol (integration point) → Domain models + Core Data
• Boundary already in place:
  • Protocol: current state, forecast, optimize caffeine/dosing schedule, circulating level, related outputs
  • Inputs/outputs use absolute Dates only at the boundary
  • Single builder path: sleep + dose events + resolved subject profile → engine input
• Temporary in-house adapter implements the same protocol (dual-run baseline)
• DI provider swaps implementations without UI rewrites
• Planned doses are a real flag on events (not free-text parsing)
• Personalization traits resolved app-side and passed in; integrator does not own trait fitting unless contract expands
• On-device only: no backend; computation and storage stay on device

Responsibilities

• Package licensed lab library (SPM and/or XCFramework); pin versions; document upgrade path
• Implement protocol-conforming adapter; map lab SDK I/O → app DTOs
• Lock unit/timebase/dose policy (see existing unit-policy docs); touchscreen vs hardware RT policy where relevant
• Build dual-run / golden regression harness vs in-house baseline; no silent behavior drift
• Feature-flag provider swap; document failure modes (missing sleep, bad inputs, SDK errors)
• Own release risk for incorrect predictions at the engine boundary; science/product sign-off on parity

Must-have

• Strong Swift and iOS (async/await, actors / @MainActor, working inside an existing SwiftUI codebase)
• Wrapping third-party native libraries (XCFramework / SPM), binary vs source integration, module/linker issues
• Defining and locking I/O contracts (timebases, units, dose schedules, absolute timestamps)
• Test discipline: dual-run, golden/regression tests, CI-friendly harnesses; no silent drift
• Clear async written communication; Mac development environment

Nice-to-have

• Sleep / circadian / caffeine PK-PD or biomathematical modeling exposure
• HealthKit, BackgroundTasks, local notification scheduling
• Scientific, clinical, or safety-critical app experience
• On-device performance profiling; numerical stability awareness
• Prior closed-source / licensed SDK integration under NDA