Kotlin/Native generates distinct Swift types for a class depending on
whether it's imported directly from its owning module or transitively
re-exported through another framework, so files consuming these DTOs
via FluxaShared's re-export of core no longer matched the FluxaCore
type Loader/ResourceLoader now return directly. Route Bootstrap and
HomeEffectHandler through FluxaCore consistently, and add an explicit
FluxaCore->FluxaShared stream conversion where DetailStartup crosses
back into FluxaApple.shared's Shared-typed API.
Xcode's embedAndSignAppleFrameworkForXcode task for :shared: is
intermittently disabled by the Kotlin Gradle Plugin's own IDE/index-build
detection (onlyIf 'Task is enabled' is false), silently skipping the
framework embed and leaving these types unavailable to Swift. core's
framework already embeds reliably for iOS (matching tvOS), so these plain
DTOs move there instead; the Compose-dependent DataSource wrappers stay in
shared, which already re-exports core.
FluxaApplePluginRepositoryManager.swift only has iOS callers and
references the iOS-only FluxaApplePluginsEffectHandler, so it fails to
compile for tvOS the same way the addon-store files already excluded
above do. Add it to the same exclude list.
Also set cache-on-failure on both Swatinem/rust-cache steps: since every
Apple CI run this session failed at a later step, the Rust build cache
was never saved, so each retry recompiled the whole dependency tree
(~15-25 min) from scratch instead of reusing what already built fine.
It imports FluxaShared, which the shared Gradle module never builds
for tvOS (tvOS stays native SwiftUI per the project's CMP/KMP
migration plan). The other four AppleCore files with the same
dependency are already excluded here; this one was added by the
recent Addon Store wiring work and missed the same exclusion.
Kotlin default parameter values aren't exposed through the generated
Swift bindings, so every PlayerContentUiModel field is required from
Swift regardless of its Kotlin-side default. This call site predates
the seasonsCount field and never got updated, which only surfaced now
that Apple CI's build actually reaches Swift compilation for this file.
The Xcode "Build Fluxa Rust Core" run-script phase runs this script
with SDKROOT already exported for whichever platform Xcode is currently
building (e.g. iphonesimulator for the FluxaIos scheme). That ambient
value leaks into cc's default sysroot for every target this script
loops over, including unrelated ones, so linking the aarch64-apple-tvos
build picked up an iphonesimulator libiconv and failed with "building
for tvOS, but linking in dylib built for iOS-simulator". Override
SDKROOT per target using the same SDK path already resolved for
bindgen, so each cargo build gets a sysroot matching its own target.
build_rust_core never set IPHONEOS_DEPLOYMENT_TARGET/TVOS_DEPLOYMENT_TARGET,
so rustc fell back to its ancient default (iOS 10.0) when linking for
aarch64-apple-ios etc. That's too old for the rquickjs-sys objects, which
need ___chkstk_darwin support only available at a modern deployment
target, so linking fluxa_core failed with an undefined symbol.
build_streaming_engine already sets IPHONEOS_DEPLOYMENT_TARGET (default
18.5) for exactly this reason — mirror it here for both iOS and tvOS.
The \${arr[@]:-} default-value form avoids bash 3.2's unbound-variable
error on an empty array, but on macOS's stock bash it still expands to
a single empty-string word, so `env "" cargo build ...` tried to exec
an empty command name and failed with exit 127. Build the cargo
invocation as an array and only wrap it with `env` when bindgen_env
actually has entries, avoiding any [@] expansion of an empty array.
macOS's stock /bin/bash is 3.2, which raises "unbound variable" under
set -u when expanding an empty array via \${arr[@]} even with the [@]
syntax. build_rust_core hits this on the host-only build call (no
--target flag), where bindgen_env stays empty. Use the \${arr[@]:-}
default-value form, the standard bash 3.2-safe workaround.
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.
FluxaAppleAddonConfigurationStore gains a disabled-addon set and
enabledAddonUrls(); Home/Search/Discover/Detail now fetch from
enabledAddonUrls() instead of the raw configured list, so disabling an
addon in the store actually stops it from being queried.
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.
Mirrors Android's PluginRepositoryManager: owns its own headless
runtime instance, dispatches repo/scraper actions, persists state via
UserDefaults, and exposes scraper settings layout and execution.
Fetches plugin repository manifests over URLSession and parses them
via coreInvoke, matching Android's FluxaAndroidHeadlessEnvironment
fetchPluginManifest behavior.
Implements the generated PluginHttpClient callback interface
synchronously via URLSession, with an SSRF guard (scheme allow-list
plus resolved-address blocklist) mirroring Android's PluginNetGuard.
Replaces the checked-in 6-function stub with actual uniffi-bindgen
output, exposing PluginHttpClient, PluginHttpRequest/Response,
executePluginScraper, getPluginScraperSettingsLayout, and coreInvoke
to Swift for the first time.
rquickjs-sys has no prebuilt FFI bindings for iOS/tvOS targets, so
bindgen needs the matching SDK sysroot (iphoneos/iphonesimulator/
appletvos/appletvsimulator) and clang target triple per cross-compiled
target, or it silently uses the host's own headers and fails. Unverified
here — no Xcode/macOS available in this environment; needs confirming
on a real Mac before relying on it.
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.
