Unable to bind native iOS framework that uses Async/Await in iOS 14
rolfbjarne opened this issue · comments
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.SwiftRuntimeSupport
does 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
Visual Studio Community 2022 for Mac Preview
Version 17.5 Preview (17.5 build 1766)
Installation UUID: 74672fca-f2f0-4664-b502-6ecf39ba23f4
Runtime
.NET 7.0.1 (64-bit)
Architecture: Arm64
Microsoft.macOS.Sdk 12.3.2372; git-rev-head:754abbf6a3563f6267e5717ae832b4ac25b1f2fb; git-branch:release/7.0.1xx-xcode13.3
Roslyn (Language Service)
4.5.0-3.23056.2+97881342e427ff5cdcba8f12b12ff8e6f3564431
NuGet
Version: 6.4.0.117
.NET SDK (Arm64)
SDK: /usr/local/share/dotnet/sdk/7.0.200-preview.22628.1/Sdks
SDK Versions:
7.0.200-preview.22628.1
7.0.100
6.0.405
6.0.403
6.0.402
6.0.401
6.0.400
6.0.301
6.0.300
6.0.202
6.0.201
MSBuild SDKs: /Applications/Visual Studio (Preview).app/Contents/MonoBundle/MSBuild/Current/bin/Sdks
.NET SDK (x64)
SDK Versions:
6.0.403
6.0.402
6.0.401
6.0.400
6.0.301
6.0.300
6.0.105
6.0.103
5.0.408
5.0.406
3.1.425
3.1.424
3.1.423
3.1.422
3.1.420
3.1.419
3.1.418
3.1.417
.NET Runtime (Arm64)
Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
7.0.0
6.0.13
6.0.11
6.0.10
6.0.9
6.0.8
6.0.6
6.0.5
6.0.4
6.0.3
3.1.32 (x64 – Unsupported)
.NET Runtime (x64)
Runtime: /usr/local/share/dotnet/x64/dotnet
Runtime Versions:
6.0.11
6.0.10
6.0.9
6.0.8
6.0.6
6.0.5
6.0.3
5.0.17
5.0.15
3.1.31
3.1.30
3.1.29
3.1.28
3.1.26
3.1.25
3.1.24
3.1.23
Xamarin.Profiler
Version: 1.8.0.49
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler
Updater
Version: 11
Xamarin.Android
Version: 13.2.0.0 (Visual Studio Community)
Commit: xamarin-android/d17-5/797e2e1
Android SDK: /Users/jlew/Library/Android/sdk
Supported Android versions:
12.1 (API level 32)
12.0 (API level 31)
11.0 (API level 30)
13.0 (API level 33)
SDK Command-line Tools Version: 7.0
SDK Platform Tools Version: 33.0.3
SDK Build Tools Version: 33.0.1
Build Information:
Mono: 6dd9def
Java.Interop: xamarin/java.interop/main@149d70fe
SQLite: xamarin/sqlite/3.40.0@fdc1e34
Xamarin.Android Tools: xamarin/xamarin-android-tools/main@9f02d77
Microsoft Build of OpenJDK
Java SDK: /Library/Java/JavaVirtualMachines/microsoft-11.jdk
11.0.16.1
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL
Eclipse Temurin JDK
Java SDK: /Library/Java/JavaVirtualMachines/temurin-8.jdk
1.8.0.302
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL
Android SDK Manager
Version: 17.5.0.33
Hash: f0c0c52
Branch: remotes/origin/d17-5~1
Build date: 2023-02-02 19:20:19 UTC
Android Device Manager
Version: 0.0.0.1245
Hash: 7f8a990
Branch: 7f8a990
Build date: 2023-02-02 19:20:19 UTC
Xamarin Designer
Version: 17.5.3.47
Hash: e8b5d371c3
Branch: remotes/origin/d17-5
Build date: 2023-02-02 19:20:14 UTC
Apple Developer Tools
Xcode: 14.2 21534
Build: 14C18
Xamarin.Mac
Version: 9.1.0.2 Visual Studio Community
Hash: 956a059ba
Branch: xcode14.2
Build date: 2022-12-15 06:15:43-0500
Xamarin.iOS
Version: 16.2.0.2 Visual Studio Community
Hash: 956a059ba
Branch: xcode14.2
Build date: 2022-12-15 06:15:44-0500
Build Information
Release ID: 1705001766
Git revision: 749808e99f0d0bf8a8eb45fe406840107ffb46b4
Build date: 2023-02-02 19:18:20+00
Build branch: release-17.5
Build lane: release-17.5
Operating System
Mac OS X 13.2.0
Darwin 22.3.0 Darwin Kernel Version 22.3.0
Thu Jan 5 20:48:54 PST 2023
root:xnu-8792.81.2~2/RELEASE_ARM64_T6000 arm64
Build Logs
Example Project (If Possible)
will add a minimal repro project shortly.
Copied from original issue xamarin/xamarin-macios#17572
From @jslew on Sun, 19 Feb 2023 02:23:42 GMT
I think it may be because of this line from Xamarin.iOS.SwiftRuntimeSupports.targets
:
<_SRSMasterAfterTargets>_CodesignNativeLibraries</_SRSMasterAfterTargets>
_CodesignNativeLibraries
does not seem to exist anymore, so the targets in this package which copy things are not actually running.
From @jslew on Sun, 19 Feb 2023 02:35:54 GMT
Yep, that seems to be the problem. Changed to:
<_SRSMasterAfterTargets>AfterCodesign</_SRSMasterAfterTargets>
and all seems well again.
Update: I changed AfterCodesign
to BeforeCodesign
after realizing that the copied support libraries had to be codesigned along with everything else...
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?
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,
We are also encountering the same issue as the OP.
It would be great if we could have an update to the SwiftRuntimeSupport for this please!
Thanks.
@jyaganeh I believe you can just remove the reference to Xamarin.iOS.SwiftRuntimeSupport
in your bindings if the minimum deployment target is iOS 12.2 or later.
@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?
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 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 -->
<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.
@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
BeforeCodesign
, and uses a custom copy target with the updatedswift-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 --> <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.
@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:
<?xml version="1.0" encoding="UTF-8" ?>
<Project>
<PropertyGroup>
<_SRSMasterAfterTargets>BeforeCodesign</_SRSMasterAfterTargets>
<_SRSMasterDependsOnTargets>_SRSCreateProps;_SRSCopySwiftDependencies</_SRSMasterDependsOnTargets>
</PropertyGroup>
<Target Name="_SRSCreateProps">
<PropertyGroup>
<_XcodeToolChainRelativeToSdkRoot>/../../../../../Toolchains/XcodeDefault.xctoolchain/</_XcodeToolChainRelativeToSdkRoot>
<_TargetPlatform Condition=" '$(Platform)' == 'iPhoneSimulator' ">iphonesimulator</_TargetPlatform>
<_TargetPlatform Condition=" '$(Platform)' == 'iPhone' ">iphoneos</_TargetPlatform>
<_SdkToolchainRoot>$(_SdkRoot)$(_XcodeToolChainRelativeToSdkRoot)</_SdkToolchainRoot>
<_SwiftStdLibTool>$(_SdkToolchainRoot)usr/bin/swift-stdlib-tool</_SwiftStdLibTool>
<_SwiftLibDir>$(_SdkToolchainRoot)usr/lib/swift-5.5/$(_TargetPlatform)</_SwiftLibDir>
</PropertyGroup>
</Target>
<!-- IpaPublishDestination is set by the azure_scripts/azure_ios_post_clone.sh script -->
<Target Name="_SRSMasterTarget"
Condition="'$(_SRSMasterDependsOnTargets)'!='' And '$(IpaPublishDestination)' == 'AppStore' And '$(BuildIpa)' == 'true'"
AfterTargets="$(_SRSMasterAfterTargets)"
DependsOnTargets="$(_SRSMasterDependsOnTargets);_DetectSigningIdentity" />
<Target Name="_SRSCopySwiftDependencies" Condition="!Exists('$(_AppBundlePath)Frameworks/libswift_Concurrency.dylib')">
<PropertyGroup>
<!-- Some arguments were removed in Xcode 14.3's tooling. Define them for 14.2 only -->
<_SwiftStdLibConditionalArgs Condition="$(_XcodeVersion.StartsWith('14.2'))">--toolchain '$(_SdkToolchainRoot)' --strip-bitcode-tool '$(_SdkToolchainRoot)usr/bin/bitcode_strip' --emit-dependency-info '$(DeviceSpecificIntermediateOutputPath)SwiftStdLibToolInputDependencies.dep'</_SwiftStdLibConditionalArgs>
</PropertyGroup>
<Message Text="Copying Swift Frameworks dependencies for $(_NativeExecutable) to the $(_AppBundlePath)Frameworks folder." />
<Exec Condition="'$(_CodeSigningKey)' != ''" SessionId="$(BuildSessionId)" Command="$(_SwiftStdLibTool) --copy --verbose --sign '$(_CodeSigningKey)' --scan-executable '$(_NativeExecutable)' --scan-folder '$(_AppBundlePath)Frameworks/' --scan-folder '$(_AppBundlePath)PlugIns/' --platform '$(_TargetPlatform)' $(_SwiftStdLibConditionalArgs) --destination '$(_AppBundlePath)Frameworks/' --unsigned-destination '$(DeviceSpecificIntermediateOutputPath)SwiftSupport' --strip-bitcode --source-libraries '$(_SwiftLibDir)'" />
<ItemGroup>
<!-- _IpaPackageSource is used to zip up the IPA contents, make sure it includes the SwiftSupport folder -->
<_IpaPackageSource Include="$(DeviceSpecificIntermediateOutputPath)SwiftSupport" />
</ItemGroup>
</Target>
</Project>
We have also the same problem, we use the Xamarin.Swift package to solve this.
https://github.com/Flash3001/Xamarin.Swift