Repository navigation
No iOS build of liblbug — neither the prebuilt nor the source path currently works on iOS #14
Description
Summary: Since LBUG_USE_PREBUILT is now the default, iOS consumption is broken both ways — no iOS archive exists for the prebuilt path (confirmed against the v0.21.2 release assets: only macOS/Linux/Windows), and the source path still hits the Sources/cxx-ladybug/ladybug/ gap from the earlier #9/#11 thread.
Already raised once: quotes the maintainer's May reply on #6 about looking into an .xcframework, noting the gap matters more now that prebuilt isn't opt-in anymore.
What we tried: resolves and compiles fine, fails at link with library 'lbug' not found; ran download-liblbug.sh anyway to see what it'd fetch — a macOS-platform dylib, confirmed via vtool, since the script only reads the host OS, not the build target.
Suggested fix: an iOS .xcframework alongside the existing macOS/Linux archives, plus script/manifest logic that picks it when the build target is iOS rather than relying on host uname.
Activity
adsharma commentedon Oct 8, 2026
https://github.com/LadybugDB/swift-ladybug/actions/runs/37650242817
CI runs on iOS and passes.
tomastiminskas commentedon Oct 8, 2026
Thanks for the pointer — I checked that run, and I think it's testing something different from what's reported here. It's the iOS Simulator job from PR #13, which explicitly sets LBUG_USE_PREBUILT=0 and runs collect-ladybug-src.py as an explicit CI step after a full checkout with submodules initialized. That's the "full clone" path your own README describes, which I don't think anyone disputed works. The issue here is specifically about the package checkout path — adding this via .package(url:) in Xcode, which is how every downstream consumer (including us) would actually pull this in. With LBUG_USE_PREBUILT now defaulting to on and no iOS archive published, and the source path requiring the gitignored Sources/cxx-ladybug/ladybug/ directory that a package checkout never generates, that path is still broken for iOS as far as I can tell.
Separately — the README mentions an iOS XCFramework is planned. Is that something you're actively working on or planning to pick up soon? We're trying to decide whether to wait on that or build one ourselves in the meantime, so a rough sense of timeline (even "not anytime soon") would help us plan. Happy to contribute if it'd be useful — just want to avoid duplicating effort if you're already partway through it.
adsharma commentedon Oct 8, 2026
Thanks for explaining. That part of README is probably from the kuzu era. No activity planned here.
Adding an extra package is not very hard in terms of the amount of CI glue, the real cost is the CI infra and the fragility of the build pipeline. If there is demand for it (as in lots of people want this), we can revisit. For now recommend building from source.