Fix iOS simulator linking and close iOS setup doc gaps#290
Open
gmarull wants to merge 5 commits into
Open
Conversation
The framework linker options hardcoded the device Swift toolchain
library directory (usr/lib/swift/iphoneos) for all Apple targets,
instead of using the already-computed per-target osName (as done for
the LibPebbleSwift framework directory a few lines above).
When linking for the iOS simulator with a deployment target below
iOS 15, the Swift driver autolinks libswiftCompatibility56.a, and the
hardcoded search path made ld pick the device build of that archive,
failing the link with:
ld: building for 'iOS-simulator', but linking in object file
(.../usr/lib/swift/iphoneos/libswiftCompatibility56.a[arm64][6]
(Overrides.cpp.o)) built for 'iOS'
This went unnoticed because CI only compiles/links device (iosArm64)
binaries.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The iOS prerequisites told contributors to put GitHub credentials in local.properties for the speex module, but speex now resolves from Maven Central and no build script reads GitHub credentials from local.properties anymore. What a fresh iOS setup actually fails on is the missing Android SDK: the Gradle build applies the Android Gradle plugin in several modules, so even an iOS-only build aborts with "SDK location not found". Document installing Android Studio (which provides the SDK) and pointing sdk.dir at it, which is the real reason local.properties is needed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Recent Xcode versions ship without the iOS platform; on a fresh install, building for any iOS destination (device or simulator) fails with "iOS X.Y is not installed. Please download and install the platform". Document downloading it via xcodebuild -downloadPlatform iOS, and renumber the following steps. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Building the iOS app currently requires creating a Firebase account just to obtain a GoogleService-Info.plist, even for contributors who don't use any Firebase-dependent feature. Provide a dummy config with placeholder values — the iOS counterpart of the existing google-services-dummy.json on Android — and document copying it into place. The app builds and runs fine with it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The io.github.coredevices.speex simulator artifacts on Maven Central embed a device-built libspeex.a in the iosSimulatorArm64 cinterop klib (all published versions: the 31 objects are tagged LC_BUILD_VERSION platform 2/iOS instead of 7/iOS-Simulator), so simulator links fail even with the Swift library search path fixed. This needs a republish of the speex library; document the failure signature and the physical device workaround until then. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Went through the iOS setup on a fresh machine (macOS, Xcode 26.6) following the README, and hit a few issues along the way. This PR fixes what can be fixed in this repo and updates the docs for the rest.
Code fix
composeApp/build.gradle.ktshardcoded the device Swift toolchain library path (usr/lib/swift/iphoneos) in the framework linker options for all Apple targets, while the per-targetosNamecomputed right above is only used for the LibPebbleSwift directory. On simulator links (deployment target < iOS 15) the Swift driver autolinkslibswiftCompatibility56.a, and the hardcoded path madeldpick the device build of it, hard-failing the link. Went unnoticed because CI only buildsiosArm64.Doc fixes
local.properties. What a fresh setup actually needs there issdk.dir— the Gradle build requires an Android SDK even for iOS-only builds ("SDK location not found" otherwise). Replaced the step with Android Studio +local.propertiesinstructions.xcodebuild -downloadPlatform iOS.GoogleService-Info-dummy.plist(iOS counterpart ofgoogle-services-dummy.json) and documented copying it into place. The app builds and runs fine with it.Known issue (needs a fix outside this repo)
Even with the linker path fix, simulator builds still fail: every published version of
io.github.coredevices.speexon Maven Central ships a device-builtlibspeex.ainside the iosSimulatorArm64 cinterop klib — all 31 objects are taggedLC_BUILD_VERSIONplatform 2 (iOS) instead of 7 (iOS-Simulator). The library needs to be rebuilt/republished with a proper simulator slice; I added a known-issue note to the README pointing at the failure signature. (I verified the rest of the chain works by patching the platform tags in the cached klib locally — with that plus the linker path fix, the app builds, installs and runs on the iOS 26.5 simulator.)🤖 Generated with Claude Code