Xamarin iOS Library can't get location - xamarin

Question

I have a vendor provided .framework file that I created an iOS binding project for using Objective Sharpie. I can call into the library, get callbacks, pull data, mostly everything works except the library being able to access the current location. The public headers for that project are here StripeTerminal
In my C# code, I used the Xamarin.Essentials to pull the current location.
var location = await Geolocation.GetLastKnownLocationAsync();
This returns with my location both in the simulator and on a real iPhone. I can see the access is granted to my app in the Privacy-> Location Services menu.
I have the below in my info.plist file, which I have tried targeting 9.0 SDK and 12.0 SDK.
<key>NSLocationWhenInUseUsageDescription</key>
<string>Location required for accepting payments.</string>
In an example XCode project provided by the vendor, that is able to pull the location by inspecting their verbose logs. In the Xamarin app, their logs get stuck on a requestLocation and never continue past it. I even tried setting the Link option to Don't Link and the result is the same.
What is wrong with my binding project that would prevent a native framework library from being able to access the location?

Answer 1

The issue was a mix of how Xamarin works and iOS. I created a CLLocationManager object in my C# code and setup a listener for location changes, except it never worked. So I tried the Xamarin.Essentials package to get the current location using GetLastKnownLocationAsync and that worked every time, so it wasn't a permission issue or a simulator issue. Digging into the Xamarin.Essentials code I found the below.
NSRunLoop.Main.InvokeOnMainThread(() => manager = new CLLocationManager());
Reading more documentation, I found that the CLLocationManager can only be successfully created from an active run loop. Wrapping calls into the Stripe Terminal iOS SDK in the NSRunLoop.Main.InvokeOnMainThread allowed things to work as they were creating a CLLocationManager expecting the call to be in an active run loop without checking first, or documenting that behavior. Stripe's internal code waited on a callback, which never happened, thus hanging the SDK in a weird state.