Hi Kurt,
Unfortunately, this scenario is unsupported for Xamarin.Forms -> Xamarin.iOS. For Mobile platforms, the best practice (as mentioned in this thread) is to create an intermediate service to then connect to your database. Connecting directly through a mobile platform is heavily discouraged, so you will not find many resources or much supportability for this scenario.
The Microsoft.Data.SqlClient.SNI.dll assembly is a Windows only assembly (Native networking implementation), which does not apply to the iOS platform. The DLL is used by Windows targeted SqlClient binaries (runtimes\win in NuGet package), so when implementation is on a non-Windows platform, the assembly is going to throw a DLLNotFound Exception when trying to use native Windows SNI.
The SNI runtime binary dependency from the SqlClient package is attempting to target the native SNI assembly. There is the possibility of using Managed Networking by setting this AppContext switch in app code, but testing this proved to not have any effect on the missing SNI assembly error.
Source: https://zcusa.951200.xyz/en-us/sql/connect/ado-net/appcontext-switches?view=sql-server-ver15#enabling-managed-networking-on-windows
Aside from the issues with SNI when on the emulator, the error message being received on the physical device build is due to a Xamarin.iOS limitation with NetStandard. Xamarin.iOS must use AOT compilation, due to the lack of support for dynamic code generation on the iOS platform. This is why we are seeing AOT mentioned in the error, but regardless, there is a dependency on "System.Configuration.dll" from the SQLServer package and its dependencies which is not supported in the Xamarin.iOS .NET API profile.
Source: https://zcusa.951200.xyz/en-us/xamarin/ios/internals/limitations#net-api-limitations
Lastly, there is an open GitHub issue on the scenario you are experiencing located here: https://github.com/dotnet/SqlClient/issues/861
While the scenario on iOS through Xamarin.Forms is deemed unsupported, the SQLClient side is investigating possible workarounds and further insight onto why the SNI assembly is being called on non-Windows platforms. Any updates from them on this scenario will likely be posted on that issue post - please feel free to interact with the post yourself as well to gather attention to it.
Thank you,
Anthony