working in Swift/SwiftUI and .NET in the same project is on our radar to be being further investigated, primarily for WidgetKit and App Clips. The same concepts could be applied to watchOS.
The Embeddinator experiment is one idea, but as you note it's not actively in development and is a complex solution. Another solution is to initially offer the build/bundling of the Swift artifact (the watch app for example) with the .NET app for iOS, and provide a communication solution for passing messages between them.
@chamons sounds like a clean workaround, but since my main Xamarin platform is WatchOS, I personally would need support there too ... from what you are saying would I be right in assuming that the extension and the main app could run at the same time, and you'd use a IPC mechanism to communicate?
I've been all-in on Xamarin since 2012, but I'm looking seriously to moving to Swift/SwiftUI on Apple platforms because I can't do some things such as SwiftUI/complications on WatchOS. I was recently taken aback when I found I could not use RealityKit with Xamarin at one of my consulting clients (I'd created a scene in Reality Composer and wanted to export it as a .reality file and use it from Xamarin). I know I am not typical because WatchOS is where 90% of my app sales are (Android, Tizen, WearOS, UWP, xBox and MacOS are the other platforms I support, using Xamarin and a NetStandard library to share almost all my code https://www.youtube.com/watch?v=TOaJ1R4eLSw
There are other factors - when I started, C# was so far ahead of Objective C that it was a no-brainer. Swift is definitely behind C# (IMO - e.g async/await), but not too far behind. I'm also worried that Microsoft won't be able to track new APIs/technologies that are exposed purely in Swift/SwiftUI - I can't rely on doing everything from C# that can be done natively - I used to push that when selling Xamarin a few years back.
I'm not saying Microsoft would be wrong to stop updating support for WatchOS, I'm just an unintended casualty, and I can live with that. Swift/SwiftUI would be "as well as" .NET/C# not "instead of"
hi all - ive used xam before across mobile devices extensively but this is my first foray into macOS and im usually a win user... im looking for a little advice on debugging binding issues.
Im trying to leverage embedded chrome/ CEF.framework using CefGlue via xam.mac or .net core but im having very little luck getting examples to work always for the same reason - cant find the native cef library at runtime.
ive traweled docs and i feel like i am doing everything correctly. i then came across this - https://stackoverflow.com/questions/47538368/how-to-properly-map-an-expected-dll-name-to-a-native-mac-framework-for-mono
i found this person who was having similiar issues and they mentioned a "lib" appending issue. so i experimented and was finally able to get past the .dll load by renaming "chromeinium embedded framework.framework/chromeinium embedded framework" to "../liblibcef", but fails soon after because it cant find other expected framework/bundle files that are located in "chromeinium embedded framework.framework/Resources". im assuming there is a proper way to achieve this linking that i just cant work out is. is there a config i need to update to provide the mapping? (<dll import= ?).
cefglue binds using this approach:
[DllImport("libcef", EntryPoint = "cef_initialize", CallingConvention = libcef.CEF_CALL)]
public static extern int initialize(cef_main_args_t args, cef_settings_t settings, cef_app_t* application);
looking for suggestions / links that will help me down the right path on setting up these native ".framework" references? i would like to generate my own in future using sharpie so i want to fully understand the mechanics here.
is using something like dtrace/opensnoop the right approach to debugging these load failures (wasnt highlighting the probing paths for me :| )?