Unable to bind native iOS framework that uses Async/Await in iOS 14 #1423
Comments
|
From @jslew on Sun, 19 Feb 2023 02:23:42 GMT I think it may be because of this line from |
|
From @jslew on Sun, 19 Feb 2023 02:35:54 GMT Yep, that seems to be the problem. Changed to: |
|
Update: I changed |
|
Hi @rolfbjarne, it looks like #1431 was merged several months ago... Do you have any updates on when a fixed version of SwiftRuntimeSupport will be made available on NuGet? |
No, unfortunately I do not :/ |
|
@rolfbjarne thanks, and please feel free to point me somewhere else if there's a more appropriate place/person to ask, but do you think it's likely that a fix will be released at some point before the sunset date? My team maintains a set of packages that includes bindings to a mixed swift/obj-c native library, and we've had reports from customers that are running into this issue. I'm not entirely clear on what the sunset means for this repo and the packages contained, but it would be unfortunate indeed, for folks who are still working on migrating to MAUI, if a fix isn't released with Xamarin compatibility. |
|
Hi there, |
|
@jyaganeh I believe you can just remove the reference to
That's a question for our PM: https://github.com/davidortinau |
|
@rolfbjarne we don't reference SwiftRuntimeSupport in our bindings, because it's only needed in certain cases, so unfortunately it seems like we're a bit stuck until a working version makes it to NuGet. I'm certainly no expert when it comes to MSBuild targets, but I did have some success getting build+run to iOS 14 working with this workaround that overrides the after targets to <PropertyGroup>
<!-- Override target for SwiftRuntimeSupport to BeforeCodesign -->
<_SRSMasterAfterTargets>BeforeCodesign</_SRSMasterAfterTargets>
<!-- Override depends on target to use the workaround _SRSCopySwiftDependencies -->
<_SRSMasterDependsOnTargets>_SRSCopySwiftDependenciesWorkaround</_SRSMasterDependsOnTargets>
</PropertyGroup>
<!-- Workaround version of the copy dependencies target -->
<!-- Borrowed from: https://github.com/xamarin/XamarinComponents/commit/7ed461124d396e13ce3581a59914fed771989aef -->
<Target Name="_SRSCopySwiftDependenciesWorkaround" Condition="!Exists('$(_AppBundlePath)Frameworks/libswiftCore.dylib')">
<PropertyGroup>
<_SRSRemoteMirror Condition=" '$(Configuration)' != 'Debug' "></_SRSRemoteMirror>
<_SRSRemoteMirror Condition=" '$(Configuration)' == 'Debug' ">--resource-destination '$(_AppBundlePath)' --resource-library libswiftRemoteMirror.dylib</_SRSRemoteMirror>
</PropertyGroup>
<Message Text="Copying Swift Frameworks dependencies for $(_NativeExecutable) to the $(_AppBundlePath)Frameworks folder." />
<Exec Condition="'$(_CodeSigningKey)' != ''" SessionId="$(BuildSessionId)" Command="$(_SdkRoot)$(_XcodeToolChainRelativeToSdkRoot)usr/bin/swift-stdlib-tool --copy --verbose --sign '$(_CodeSigningKey)' --scan-executable '$(_NativeExecutable)' --scan-folder '$(_AppBundlePath)Frameworks/' --scan-folder '$(_AppBundlePath)PlugIns/' --platform '$(_TargetPlatform)' --destination '$(_AppBundlePath)Frameworks/' $(_SRSRemoteMirror) --unsigned-destination '$(DeviceSpecificIntermediateOutputPath)SwiftSupport' --strip-bitcode --source-libraries '$(_SdkRoot)$(_XcodeToolChainRelativeToSdkRoot)usr/lib/swift-5.5/$(_TargetPlatform)'" />
<Exec Condition="'$(_CodeSigningKey)' == ''" SessionId="$(BuildSessionId)" Command="$(_SdkRoot)$(_XcodeToolChainRelativeToSdkRoot)usr/bin/swift-stdlib-tool --copy --verbose --scan-executable '$(_NativeExecutable)' --scan-folder '$(_AppBundlePath)Frameworks/' --scan-folder '$(_AppBundlePath)PlugIns/' --platform '$(_TargetPlatform)' --destination '$(_AppBundlePath)Frameworks/' $(_SRSRemoteMirror) --unsigned-destination '$(DeviceSpecificIntermediateOutputPath)SwiftSupport' --strip-bitcode --source-libraries '$(_SdkRoot)$(_XcodeToolChainRelativeToSdkRoot)usr/lib/swift-5.5/$(_TargetPlatform)'" />
</Target>That seems somewhat undesirable / fragile to me, though, especially knowing that the bug fix has already been merged. |
I think that if your minimum deployment target is iOS 12.2 or later, you don't need to call |
|
If you are using Swift Concurrency in the native code, `libswift_concurrency.dylib` will not be present without something like this package, up through iOS 14.
From: Rolf Bjarne Kvinge ***@***.***>
Date: Wednesday, February 21, 2024 at 6:54 AM
To: xamarin/XamarinComponents ***@***.***>
Cc: Jeremy Lew ***@***.***>, Comment ***@***.***>
Subject: [EXTERNAL] Re: [xamarin/XamarinComponents] Unable to bind native iOS framework that uses Async/Await in iOS 14 (Issue #1423)
@rolfbjarne we don't reference SwiftRuntimeSupport in our bindings, because it's only needed in certain cases, so unfortunately it seems like we're a bit stuck until a working version makes it to NuGet.I'm certainly no expert when it comes to MSBuild targets, but I did have some
[Image removed by sender.]<https://protect-us.mimecast.com/s/64hfCM8gyECL4gP6Uw8osm?domain=us.report.cybergraph.mimecast.com>
@rolfbjarne<https://protect-us.mimecast.com/s/q3MWCNkjzEiQmALMt4VQcS?domain=github.com> we don't reference SwiftRuntimeSupport in our bindings, because it's only needed in certain cases, so unfortunately it seems like we're a bit stuck until a working version makes it to NuGet.
I'm certainly no expert when it comes to MSBuild targets, but I did have some success getting build+run to iOS 14 working with this workaround that overrides the after targets to BeforeCodesign, and uses a custom copy target with the updated swift-stdlib-tool arguments:
<PropertyGroup>
<!-- Override target for SwiftRuntimeSupport to BeforeCodesign -->
<_SRSMasterAfterTargets>BeforeCodesign</_SRSMasterAfterTargets>
<!-- Override depends on target to use the workaround _SRSCopySwiftDependencies -->
<_SRSMasterDependsOnTargets>_SRSCopySwiftDependenciesWorkaround</_SRSMasterDependsOnTargets>
</PropertyGroup>
<!-- Workaround version of the copy dependencies target -->
<!-- Borrowed from: https://github.com/xamarin/XamarinComponents/commit/7ed461124d396e13ce3581a59914fed771989aef<https://protect-us.mimecast.com/s/VRdcCOYkAEHgmJY2CkOU0X?domain=github.com> -->
<Target Name="_SRSCopySwiftDependenciesWorkaround" Condition="!Exists('$(_AppBundlePath)Frameworks/libswiftCore.dylib')">
<PropertyGroup>
<_SRSRemoteMirror Condition=" '$(Configuration)' != 'Debug' "></_SRSRemoteMirror>
<_SRSRemoteMirror Condition=" '$(Configuration)' == 'Debug' ">--resource-destination '$(_AppBundlePath)' --resource-library libswiftRemoteMirror.dylib</_SRSRemoteMirror>
</PropertyGroup>
<Message Text="Copying Swift Frameworks dependencies for $(_NativeExecutable) to the $(_AppBundlePath)Frameworks folder." />
<Exec Condition="'$(_CodeSigningKey)' != ''" SessionId="$(BuildSessionId)" Command="$(_SdkRoot)$(_XcodeToolChainRelativeToSdkRoot)usr/bin/swift-stdlib-tool --copy --verbose --sign '$(_CodeSigningKey)' --scan-executable '$(_NativeExecutable)' --scan-folder '$(_AppBundlePath)Frameworks/' --scan-folder '$(_AppBundlePath)PlugIns/' --platform '$(_TargetPlatform)' --destination '$(_AppBundlePath)Frameworks/' $(_SRSRemoteMirror) --unsigned-destination '$(DeviceSpecificIntermediateOutputPath)SwiftSupport' --strip-bitcode --source-libraries '$(_SdkRoot)$(_XcodeToolChainRelativeToSdkRoot)usr/lib/swift-5.5/$(_TargetPlatform)'" />
<Exec Condition="'$(_CodeSigningKey)' == ''" SessionId="$(BuildSessionId)" Command="$(_SdkRoot)$(_XcodeToolChainRelativeToSdkRoot)usr/bin/swift-stdlib-tool --copy --verbose --scan-executable '$(_NativeExecutable)' --scan-folder '$(_AppBundlePath)Frameworks/' --scan-folder '$(_AppBundlePath)PlugIns/' --platform '$(_TargetPlatform)' --destination '$(_AppBundlePath)Frameworks/' $(_SRSRemoteMirror) --unsigned-destination '$(DeviceSpecificIntermediateOutputPath)SwiftSupport' --strip-bitcode --source-libraries '$(_SdkRoot)$(_XcodeToolChainRelativeToSdkRoot)usr/lib/swift-5.5/$(_TargetPlatform)'" />
</Target>
That seems somewhat undesirable / fragile to me, though, especially knowing that the bug fix has already been merged.
I think that if your minimum deployment target is iOS 12.2 or later, you don't need to call swift-stdlib-tool in the first place.
—
Reply to this email directly, view it on GitHub<https://protect-us.mimecast.com/s/Yfh9CPNlBMH2EOg5Cjeghc?domain=github.com>, or unsubscribe<https://protect-us.mimecast.com/s/EXUkCQWmDNhKj8VNHrmZZ2?domain=github.com>.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
@jyaganeh we did the same thing (custom MSBuild target, rather than relying on the "official" MS support for this). This is slightly specific to some other MSBuild variables set during our builds, but here it is, FWIW: |
|
We have also the same problem, we use the Xamarin.Swift package to solve this. |
From @jslew on Sat, 18 Feb 2023 16:09:54 GMT
Having exactly the same problem as xamarin/xamarin-macios#13605, except now trying to back-deploy to iOS 14 (not 13, which was originaly reported). Adding a reference to
Xamarin.iOS.SwiftRuntimeSupportdoes not fix this with the current toollchain. Perhaps the package needs to be updated again?@chamons or @rolfbjarne, any idea?
Thanks.
Expected Behavior
Xamarin.iOS app which references a native framework that (internally) uses swift concurrency should run without issue.
Actual Behavior
App crashes as soon as native code using swift concurrency is run.
Environment
Version information
Build Logs
Example Project (If Possible)
will add a minimal repro project shortly.
Copied from original issue xamarin/xamarin-macios#17572
The text was updated successfully, but these errors were encountered: