Requirements: mixed iOS/Android households (iOS parent, and separately, iOS kid)

[jsconu]

Requested: what it would take to support a parent and kid on different platforms, not just Android+Android.

This splits cleanly into two independent projects with very different costs, because the pairing mechanism itself doesn't care what platform either side runs on - it's just Firestore reads/writes (see shared/repo/FamilyRepository.kt). What differs entirely between platforms is the kid-side enforcement mechanism, which has no Android equivalent on iOS at all.

1. iOS parent app (any parent + Android kid) - the cheap direction

The parent app never touches accessibility services, foreground services, or anything Android-specific - it only reads/writes Firestore and shows a dashboard. An iOS parent app is close to a straight port of the logic, with a new UI layer.

What's needed:

• SwiftUI (or Flutter/RN if a shared codebase is preferred) rewrite of: sign up/in, dashboard, add-child + pairing-code display, child detail (stats, limits, lock), passcode settings screen
• Firebase iOS SDK (Auth + Firestore) - same Firestore data model, same firebase/firestore.rules, no backend changes
• PasscodeHasher reimplemented in Swift (PBKDF2 is available via CryptoKit/CommonCrypto - straightforward)
• Apple Developer Program membership ($99/yr) and App Store submission
• A second google-services-equivalent (GoogleService-Info.plist) registered for the same Firebase project

What's NOT needed: any change to firebase/firestore.rules, the pairing-code mechanism, or the Android kid app. An iOS parent and an Android kid pairing with each other works today, architecturally, the moment this app exists - pairing has never assumed anything about the parent's platform.

Realistic scope: a few weeks of focused work for one person familiar with SwiftUI; the hard parts (data model, security rules, business logic) are already solved and don't need to be re-derived, only re-expressed in Swift.

2. iOS kid app (Android parent, or iOS parent, + iOS kid) - the expensive direction

This is not a port. Apple has no equivalent to AccessibilityService, UsageStatsManager, or a general-purpose foreground service that can watch foreground-app changes and show a blocking overlay. The only sanctioned mechanism is Apple's own Screen Time stack:

• FamilyControls - authorization and app/category selection, built around Apple's own Family Sharing group model (a "Family Organizer" Apple ID + child accounts), not a generic device-to-device pairing code
• ManagedSettings - applies restrictions (app blocking, shields) to a FamilyActivitySelection
• DeviceActivity - schedules and usage-threshold callbacks (this is how a "5 minutes left" warning or a limit-reached block would be implemented on iOS)

What's needed:

• Apply to Apple for the com.apple.developer.family-controls entitlement - restricted, requires justification, Apple can refuse or take a long time
• A child must be part of the parent's Apple Family Sharing group - this is an Apple-managed relationship that exists independent of this app; the app can't create its own equivalent
• Redesign the account/pairing model to fit that constraint - the current 6-digit pairing-code scheme doesn't map onto "join my Family Sharing group," which happens through Apple's own Settings app, not ours
• Reimplement limit enforcement using ManagedSettings shields instead of a custom AccessibilityService + block overlay - different visuals, different configuration surface, no direct equivalent to the current reason=daily_limit/app_limit/parent_lock overlay
• Reimplement usage tracking using DeviceActivityReport/DeviceActivityMonitor instead of the current screen-on/off broadcast + accessibility-event approach - the data Apple exposes here is shaped differently (app/category usage, not raw foreground-time deltas), so dailyStats's current shape may not map 1:1
• Decide whether firebase/firestore.rules and the pairingCodes mechanism still apply at all, or whether an iOS kid device's Firestore writes need a different trust model entirely, since "the device that claimed a pairing code" may no longer be the right authorization concept

Realistic scope: a genuinely separate engineering effort - new data model decisions, an entitlement application with uncertain timeline/outcome, and no code reuse from the Android kid app beyond the Firestore data layer (and even that may need reshaping). Not a "few weeks" estimate; closer to a second product.

Recommendation

Build (1) first if iOS support matters at all - it's cheap, high-value (any parent with an iPhone can use this even with an Android-only kid device today), and blocks nothing about (2) later. Treat (2) as a distinct, much larger decision to make deliberately if/when there's real demand for an iOS kid device specifically - don't let today's Android-only kid-side design carry an implicit tax for a platform commitment that hasn't actually been made.