Android's download engine turned out to be simpler than "full parity"
implied: enqueue, progress, cancel - no pause/resume, no WiFi-only
gating, no auto-delete (none of those exist on Android either, despite
a dead "paused" status branch). Mirror that scope on iOS:
- FluxaAppleDownloadManager: background URLSession-based download
engine, UserDefaults+JSON persisted (same pattern as other Apple*
managers in this codebase), pushes state into Kotlin via a new
updateDownloads bridge call.
- AppleLibraryDataSource now reuses the existing commonMain
OfflineDownloadItem model and OfflineDownloadGrouping/formatting
logic directly (same code Android uses) instead of reimplementing
grouping/status-label/size-label logic in Swift.
- FluxaAppleDetailStartup.downloadEpisode/downloadSeason resolve a
playable stream through the existing addon resource loader, then
hand off to the download manager.
Known gap: no application(_:handleEventsForBackgroundURLSession:)
AppDelegate hook, so downloads won't reliably resume/report after the
app is fully killed by the OS - only while backgrounded, not
terminated. Also unverified like the rest of the iOS work this
session: no Xcode/Swift toolchain in this environment to compile
against.
FluxaAppleDetailStartup now caches the meta response's videos/
seasonsCount per content id, exposes real availableSeasons/
selectedSeason/seasonEpisodes, and adds selectSeason/loadSources to
answer the new AppleDetailDataSource callbacks (season switch filters
the cached episode list locally; loadSources fetches per-episode
streams through the existing addon resource loader). Addon-filter and
download callbacks are wired but still no-ops on the Swift side -
downloads have no iOS engine yet.
Unverified: no Xcode/Swift toolchain available in this environment,
so this has not been compiled. Needs an xcodebuild pass to catch any
ObjC/Swift interop mistakes (numeric bridging, argument order) before
relying on it.
into the app shell and home
FluxaAppHost/FluxaHomeContent/HomeViewModel and friends now route to the
features landed in the preceding commits (local media, watch together,
external player, Nuvio plugin catalog, provider-adapter library sync),
plus the matching iOS platform data sources and i18n keys for all of it.
CorePolicyModels.kt/FluxaCoreNative.kt in this commit also carry the
NativeDeviceResourceBudget model and FluxaCoreNative.deviceResourceBudget
accessor added earlier this session for the unified memory-budget work;
they were sitting in the same files as pre-existing uncommitted changes
and weren't worth a separate hunk-level split.
FluxaAppleAddonStoreManager fetches manifests over URLSession and
persists the local addon list plus enabled/disabled state via
FluxaAppleAddonConfigurationStore. FluxaAppleAddonStoreStartup routes
AppleAddonStoreActionSnapshot actions from the shared UI to it and
pushes merged state back to Kotlin. FluxaIosApp constructs and
registers it, restoring/refreshing on launch. Users can now actually
add, toggle, reorder, and remove Stremio addons on iOS.
FluxaApplePluginsStartup routes ApplePluginsActionSnapshot actions
from the shared UI to FluxaApplePluginRepositoryManager and pushes
merged state back to Kotlin. FluxaIosApp constructs and registers it
alongside the other feature startups, restoring persisted repos on
launch.
Fixes AppleAuthDataSource: continueWithNuvio/continueWithStremio/
continueWithoutAccount were incorrectly routed through Swift
notifications - Android handles all three as pure local UI-state
transitions (no network), so this matches that instead of adding
unnecessary indirection.
submit() for the Credentials stage now posts a real request that
FluxaAppleAuthStartup.swift picks up: FluxaAppleStremioAuthClient
mirrors StremioService.kt's api.strem.io/api/login and /api/register
endpoints via URLSession, and the resulting session (id/email/authKey)
is persisted through FluxaAppleAuthStore using the Keychain generic-
password API (kSecClassGenericPassword, accessible-after-first-unlock),
not UserDefaults - this is the first credential-bearing data iOS
persists, unlike the existing UserDefaults-backed local stores.
Nuvio login/import is out of scope here: Android's version pulls
profile/addons/library/progress/history/collections through
NuvioAccountImportCoordinator, which needs library and addon-store
integration iOS doesn't have yet. The Nuvio stage transition works
(continueWithNuvio), but submitting Nuvio credentials currently has no
Swift listener - same "reachable but inert" scope already established
for AddonStore.
The error-state message on failed Stremio login is a hardcoded English
string rather than routed through AppStrings, since calling Kotlin's
AppStrings.t() from pure Swift needs framework-export verification I
can't perform without Xcode.
Caveat: this Swift code (Keychain access, URLSession networking) is
unverified - no Xcode/macOS toolchain available in this environment.
Only the Kotlin side (AppleAuthDataSource, all Gradle targets) is
compile-checked. Needs a real Xcode build and device/simulator test
before shipping.
