Using backward deployment on iOS 12.1 will crash, iOS 12.2+ works fine

[djr]

Hello,

Thank you for bringing support for iOS 12. When testing on iOS 12.4 we have no issues. Testing on iOS 12.1 causes this crash:

dyld: Library not loaded: /usr/lib/swift/libswiftCore.dylib Referenced from: /Users/djrossi/Library/Developer/CoreSimulator/Devices/5D46194E-556D-477F-96BC-E3BDE9687113/data/Containers/Bundle/Application/A2C4C78B-6135-4409-92CF-D6D7CECEF853/Charge.app/Frameworks/SDWebImageSwiftUI.framework/SDWebImageSwiftUI Reason: no suitable image found.

I tested using the iOS 12.1 simulator and 1.0.0-beta2. Thank you for the help.

[dreampiggy]

Carthage ?

Seems the issue caused by the Swift when using Carthage and turn on Library Evolution ?

Swift have a smart check, when the min deployment target version is iOS 13.0+, it link the system framework ( /usr/lib/swift/libswiftCore.dylib)

When iOS 12.4-(which does not have Swift built in), it use the embed Swift dynamic framework (bundled in your App)

If you want to deploy both iOS 12.0(less than 12.4) && iOS 13, maybe the final ipa produce must keep the Swift dynamic framework. This can not been workaround without chaning the min deployment target version.

Could you please, using Carthage to pull the project with --no-build, changing the min deployment target version to iOS 12, and build it manually to add ?

[dreampiggy]

Why the backward deployment is hard, because the main idea: I don't want to change the min deployment target version to iOS 12 for this Package.

Because changing min deployment target, will have a bad effect on user, who only build their App for iOS 13+. It will cause performance dropdown and ipa size become bigger.

And it's really strange, why a SwiftUI only framework package allows to deploy on iOS 12...If they can deploy on iOS 12, which means they can also deploy on iOS 8, right ? (The min deployment target version will loss their meanings)

[dreampiggy]

I'll try to find other solution. The worst idea is to change the min deployment target version to iOS 12, or totally remove the min deployment target version.

[dreampiggy]

Can this ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES works for this case ? Turn this on to bundle the Swift runtime framework.

I remember when Submitting to App Store, App Store will strip the Swift Runtime when the end-user use iOS 12.4+.

---

This trick does not help. Swift compiler and Xcode, use a smart hack to determinate where the libSwiftCore.dylib to find. Even you use ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES, the final binary still reference to the system path /usr/lib/swift/libswiftCore.dylib, this cause runtime dyld error on iOS 12.1 and earlier.

[dreampiggy]

I think the final solution is to set the min deployment target version.

But I will not done this here, because as a framework author, I don't want to `Decrease my most users' (who use iOS 13+ only) performance because of that I want to backward support on iOS 12).

You can choose:

1. Set your minimum deployment target version to iOS 12.2, this is when the Swift runmtime built-in in Apple's system framework.
2. If you still want to support user who use iOS 12.1 or lower, you can use Carthage to download the project, then change the minimum deployment target to what you want, such as iOS 8, then build and link it to your App project.

See more: https://forums.swift.org/t/does-swift-5-runtime-support-swift-4-2/23240

[djr]

Thanks @dreampiggy! For testing purposes I tried forking the repo. I changed the deployment target to iOS 12.0 in the project and the target settings and it seems to be working.

[dreampiggy]

I think this is the idea. It's not so hard for most cases.

• Carthage: use carthage update --no-build, change the Xcodeproject's min deployment target and click Archive to produce binary
• CocoaPods: use Podfile's post_installer to modify the Pod's min deployment target version, those can works for all the pods everytime (for example, another Package called SDWebImageSwiftUI2 also want to support iOS 12.0), better thatn Carthage which you need to edit once again

Another idea it to maintain two different branches, which beyond the limitation to maintain of me...

[fermoya]

Hi, I found a similar issue in my framework. Recently, a user asked me to enable compatibility with iOS 12 or lower. I also refused to change the deployment target and was looking for another solution. I've been using this thread as a reference.

What I've managed to do is the following:

• I add the same @available wrappers to make it explicit it only works with iOS 13+
• In the project file I use to build Carthage frameworks, I've added a non-shared aggregate target and use it to generate a xcframework.
• I've made every shared target here _weaklink both SwiftUI and libswiftCore

So now, I'm able to use the xcframework on any platform version. No compiler error when importing the module and no issue when running.

I haven't been able to make it work with Cocoapods or SPM

[dreampiggy]

I've made every shared target here weak_link both SwiftUI and libswiftCore

You miss the Combine framework, which is imported by SwiftUI and iOS 13 only as well. However, pre to Xcode 11.4, there is a bug you can not use GUI to set the weak framework. You can use -weak_framework Combine the linker flags to do the same thing.

[dreampiggy]

Will not solve.

I will drop the iOS 13 support in the future. It's pain to maintain backward compatibility for SwiftUI. Because Apple does not provide any good workaround and changes behavior from version to version.