[Bug]: App crashes on startup - SwiftUICore not loaded

[sulfura3]

Current Behavior

App crashes on startup on iOS 16-17, citing an issue that the SwiftUICore library could not be loaded. Bug disappears on iOS 18+ on both physical and simulated devices. Android is not affected.

XCode stops execution as soon as the app starts and shows the following error

Library not loaded: /System/Library/Frameworks/SwiftUICore.framework/SwiftUICore
  Referenced from: <426AAAB0-87BE-3433-8468-D88DF1465770> /Users/mike/Library/Developer/CoreSimulator/Devices/79351DC3-1468-497F-B170-9087B4A1CE30/data/Containers/Bundle/Application/42A04B3C-26C8-4686-BFB0-4E51C525F5F5/App.app/App.debug.dylib
  Reason: tried: '/Users/mike/Library/Developer/Xcode/DerivedData/App-cusjosgzwhwclohdocgksyxxfwbr/Build/Products/Debug-iphonesimulator/SwiftUICore.framework/SwiftUICore' (no such file), '/Users/mike/Library/Developer/Xcode/DerivedData/App-cusjosgzwhwclohdocgksyxxfwbr/Build/Products/Debug-iphonesimulator/PackageFrameworks/SwiftUICore.framework/SwiftUICore' (no such file), '/Library/Developer/CoreSimulator/Volumes/iOS_20E247/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 16.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/SwiftUICore.framework/SwiftUICore' (no such file), '/System/Library/Frameworks/SwiftUICore.framework/SwiftUICore' (no such file, not in dyld cac
dyld config: DYLD_SHARED_CACHE_DIR=/Library/Developer/CoreSimulator/Caches/dyld/24G720/com.apple.CoreSimulator.SimRuntime.iOS-16-4.20E247/ DYLD_ROOT_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_20E247/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 16.4.simruntime/Contents/Resources/RuntimeRoot DYLD_LIBRARY_PATH=/Users/mike/Library/Developer/Xcode/DerivedData/App-cusjosgzwhwclohdocgksyxxfwbr/Build/Products/Debug-iphonesimulator:/Library/Developer/CoreSimulator/Volumes/iOS_20E247/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 16.4.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/Library/Developer/CoreSimulator/Volumes/iOS_20E247/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 16.4.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libBacktraceRecording.dylib:/Library/Developer/CoreSimulator/Volumes/iOS_20E247/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 16.4.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/Library/Developer/CoreSimulator/Volumes/iOS_20E247/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 16.4.simruntime/Contents/Resources/RuntimeRoot/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib DYLD_FRAMEWORK_PATH=/Users/mike/Library/Developer/Xcode/DerivedData/App-cusjosgzwhwclohdocgksyxxfwbr/Build/Products/Debug-iphonesimulator:/Users/mike/Library/Developer/Xcode/DerivedData/App-cusjosgzwhwclohdocgksyxxfwbr/Build/Products/Debug-iphonesimulator/PackageFrameworks DYLD_FALLBACK_FRAMEWORK_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_20E247/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 16.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks DYLD_FALLBACK_LIBRARY_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_20E247/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 16.4.simruntime/Contents/Resources/RuntimeRoot/usr/lib

Plugin was working in a previous version using the following packages (only relevant packages listed)

  "dependencies": {
    "@capacitor/android": "^7.4.3",
    "@capacitor/barcode-scanner": "^2.2.0",
    "@capacitor/core": "^7.4.4",
    "@capacitor/ios": "^7.4.3",
    "@capacitor/splash-screen": "7.0.3",
  }

Additionally, we have switched from CocoaPods to SPM.

Expected Behavior

App should launch

Reproduction

https://github.com/sulfura3/capacitor-barcode-issue

Screenshots / Media

Environment Details

OS: macOs Sequoia 15.7.7 (Intel-CPU)
XCode: 26.3 (17C529)
@capacitor/android: 8.4.1
@capacitor/barcode-scanner@3.0.2
@capacitor/camera: 8.2.0
@capacitor/cli: 8.4.1
@capacitor/core: 8.4.1
@capacitor/ios: 8.4.1
@capacitor/splash-screen@8.0.1

Versions Affected

3.0.2

Platforms Affected

• iOS
• Android
• Web

Notes / Comments

This was originally found on a larger project. The linked project was provided as a minimal example of where the bug appears. Removing the barcode plugin makes the crash disappear and the app behave as expected (minus barcode functionality).

[SebastianoOlivo]

We hit this exact crash and traced the root cause. Sharing in case it helps move it forward.

Setup: same as OP: @capacitor/barcode-scanner 3.0.2, Capacitor 8.4.1, Xcode 26, SPM, app min iOS 15.5. Crashes on iOS 16.7/17, fine on 18+. It's actually two stages: the SwiftUICore launch crash reported here, and after adding -weak_framework SwiftUICore, a second EXC_BAD_ACCESS (0x20) deep in SwiftUI layout when the scanner opens (that second stage is #118).

Root cause : it's binary-vs-source, not deployment target. The same app on CocoaPods works on the same device and same Xcode; only the SPM build crashes. Why:

• CocoaPods pulls OSBarcodeLib as a prebuilt .xcframework (s.dependency 'OSBarcodeLib', '2.0.1'), compiled against an older SDK → no SwiftUICore reference:

  otool -L …/App.app/Frameworks/OSBarcodeLib.framework/OSBarcodeLib
    /System/Library/Frameworks/SwiftUI.framework/SwiftUI (current version 5.0.83)
    # no SwiftUICore
  

• SPM pulls OSBarcodeLib as source (.package(url: "…/OSBarcodeLib-iOS", from: "2.1.1") → a .target, not a .binaryTarget), which Xcode 26 recompiles → the SwiftUI/SwiftUICore split kicks in:

  otool -L …/App.app/App
    /System/Library/Frameworks/SwiftUICore.framework/SwiftUICore (current version 7.0.84, weak)
    /System/Library/Frameworks/SwiftUI.framework/SwiftUI (current version 7.0.84)
  

Both builds target iOS < 18 (~15.5 — the podspec even sets s.ios.deployment_target = '15.0'), so deployment target isn't the factor. The only difference is prebuilt binary vs source recompile under Xcode 16+, i.e. the known SwiftUICore back-deployment bug (ionic-team/capacitor#7667, #8229). -weak_framework SwiftUICore only moves the crash from launch to first render, because the scanner's SwiftUI genuinely calls a SwiftUICore-routed path at runtime on iOS < 18.

Proposed fix: distribute OSBarcodeLib to SPM as a binaryTarget (the prebuilt xcframework that's already shipped for CocoaPods), so its SwiftUI source isn't recompiled under Xcode 16+. Either OSBarcodeLib-iOS exposes a .binaryTarget product, or this plugin's Package.swift references the prebuilt xcframework via .binaryTarget(name:url:checksum:) instead of the source package.

Workaround for anyone stuck now: patch this plugin's Package.swift (e.g. via patch-package) to consume the prebuilt OSBarcodeLib.xcframework as a .binaryTarget, that reproduces the working CocoaPods behavior on iOS 16.7.

Happy to help test a fix.
Related: #118 (the runtime / scanner-open stage of the same bug).

[sulfura3]

Can confirm that the workaround offered in the linked issue ionic-team/capacitor#7667 (specifically the workaround described here: ionic-team/capacitor#7667 (comment)) does also avoid the crash. Big thanks to @SebastianoOlivo

[OS-pedrogustavobilro]

Hey everyone, thanks for opening this issue, we'll be further investigating this crash and #118 some time later this month.

In the mean time the workaround suggested by @SebastianoOlivo should work, either that or try adding OTHER_LDFLAGS = "$(inherited) -weak_framework SwiftUICore"; to your app's pbxproj file for Debug and Release. The work around offered in 7667 - don't think it will work, because it's tied to an overall different issue (even if the crash is similar)

Are you stating that #118 is the same exact crash related to SwiftUICore but happening at a different stage? Because it's originally reported to happen with CocoaPods.

[SebastianoOlivo]

Are you stating that #118 is the same exact crash related to SwiftUICore but happening at a different stage? Because it's originally reported to happen with CocoaPods.

Maybe not, you're right to separate them, I probably over-linked #118. Let me be precise about what I actually see:

Our crash is specifically the SwiftUICore one, and it only occurs on the SPM build. It shows up in two stages, both from the same cause (Xcode 26 recompiling OSBarcodeLib's SwiftUI source → a SwiftUICore reference):

1. Launch: SwiftUICore not loaded.
2. After adding -weak_framework SwiftUICore, the app launches but the scanner crashes the moment it opens, EXC_BAD_ACCESS (0x20) with a backtrace entirely inside SwiftUI view layout (the weak-nulled SwiftUICore symbol getting called at render time). So for us the weak-link just moves the crash from launch to first render.

Why I think it's SwiftUICore and not something else: the same app on CocoaPods, same device (iOS 16.7), same Xcode 26 , the scanner works fine. CocoaPods pulls OSBarcodeLib as a prebuilt .xcframework (SwiftUI 5.0.83, no SwiftUICore), whereas the SPM build recompiles the source (SwiftUI 7.0.84 + SwiftUICore, weak). Nothing to crash on in the binary.

Probably #118 is a different issue while symptoms are the same.

What we could verify is: -weak_framework SwiftUICore on its own does not fix the scanner for us , the app launches but the scanner still crashes at render on iOS < 18. The only workaround that actually makes scanning work on iOS < 18 is consuming the prebuilt OSBarcodeLib.xcframework via a binaryTarget (i.e. not recompiling the SwiftUI source under Xcode 16+).

Thanks for looking into it, happy to share the full backtrace / otool diff or test a fix whenever you get to it.