First, establish if the device is capable of accepting Touch ID input.

if (context.CanEvaluatePolicy(LAPolicy.DeviceOwnerAuthenticationWithBiometrics, out AuthError))

If it does then we can display the Touch ID UI by using:

context.EvaluatePolicy(LAPolicy.DeviceOwnerAuthenticationWithBiometrics, myReason, replyHandler);

There are three pieces of information we have to pass into EvaluatePolicy – the policy itself, a string explaining why authentication is necessary, and a reply handler. The reply handler tells the application what it should do in the case of a successful, or unsuccessful, authentication.

One of the caveats of Local Authentication is that it must be run on the foreground, so make sure to use InvokeOnMainThread for the reply handler:

var replyHandler = new LAContextReplyHandler((success, error) =>
    {

        this.InvokeOnMainThread(() =>
        {
            if (success)
            {
                Console.WriteLine("You logged in!");
                PerformSegue("AuthenticationSegue", this);
            }
            else {
                //Show fallback mechanism here
            }
        });

    });

To determine whether the database of authorized fingerprints has been modified you can check the opaque structure (NSData) returned by context.EvaluatedPolicyDomainState. Your app will need to store and compare the policy state to detect changes. One thing to note which Apple states:

However, the nature of the change cannot be determined from this data.

if (context.CanEvaluatePolicy(LAPolicy.DeviceOwnerAuthenticationWithBiometrics, out AuthError))
{
    var policyState = context.EvaluatedPolicyDomainState;

    var replyHandler = new LAContextReplyHandler((success, error) =>
    {

        this.InvokeOnMainThread(() =>
        {
            if (success)
            {
                Console.WriteLine("You logged in!");
                PerformSegue("AuthenticationSegue", this);
            }
            else {
                //Show fallback mechanism here
            }
        });

    });
    context.EvaluatePolicy(LAPolicy.DeviceOwnerAuthenticationWithBiometrics, myReason, replyHandler);
};

1. When building a library in Xcode it has an option to include the swift libraries. Don’t! They will be included in your final app as NAME.app/Frameworks/LIBRARY.framework/Frameworks/libswift*.dylib but they must be included as NAME.app/Frameworks/libswift*.dylib

2. You can find this information elsewhere, but it’s worth mention: Don’t include Bitcode in the library. As of right now Xamarin don’t include Bitcode for iOS and Apple requires all libraries to support the same architectures.

Asset catalogs are way to manage multiple resolutions of iOS image assets. In order to display optimal images, iOS uses 1x, 2x, and 3x versions of each image according to the device's screen density. The 1x version is only for very old, non-retina devices so it isn't necessary for apps only supporting iOS 9.

Asset catalogs will help support app thinning and slicing, optimizing the resources users have to download to install an app from the App Store.

The UIImageView has to be within a scrollview in order for this to work.

The DoubleTap method will toggle between the minScale and the doubleTapScale.

Calculating row heights might be expensive and scrolling performance can suffer if you have larger amounts of data. In that scenario, override UITableViewSource.EstimatedHeight(UITableView, NSIndexPath) to quickly provide a number sufficient for rapid scrolling, e.g.,:

public override nfloat EstimatedHeight(UITableView tableView, NSIndexPath indexPath) 
{ 
    return 44.0f; 
}