Chapter 14 Releasing Our Application

Issues That Crop Up

As you can imagine, if the Linker is unable to detect that something is really used in your application and it is removed, things can go very wrong at runtime. Your application will most likely crash when it tries to use a type that isn’t included in your build.

This can quite often happen when only referring to types in XAML. As I covered in Chapter 5, the XAML compiler isn’t as powerful as the C# compiler and it can miss scenarios.

Reflection is another option to really avoid. Not only can it trick the compiler into not realizing APIs are used but it can also not perform well. It is worth considering that some third-party packages that you end

up using in your applications may not be Linker safe. For this reason, the default setting of Link SDK assemblies only is set. This means that only the assemblies provided by Microsoft will be linked because they are built to be Linker safe. In an ideal world, the third-party libraries would also be Linker safe, but I can safely say that the people building these fantastic packages are already spread thin building them, so if it is something that

you really require, I strongly urge you to investigate helping them provide it or sponsoring the people that build it to help them.

Crashes/Analytics

Given that I have covered how things can go wrong, I would like to cover a way in which you can gain insight to when that happens. Each of the platform providers do offer a way to collect crash information and report them it to you in order to make sure that you can prevent things like crashes from ruining the experience your applications provide.

422

Chapter 14 Releasing Our Application

There are frameworks/packages that aim to make this process easier by collecting and collating information from each platform into a centralized site. Further to this, you can enable the collection of analytic information to aid your understanding of how your users like to interact with your application and identify areas that you can improve upon.

In fact, a lot of the effort in my day job goes into finding ways to improve products. This only truly comes to light when you learn how your users interact with your applications. Capturing analytic information isn’t the sole route I recommend taking. End user engagement can also be a fantastic thing to do if you have the opportunity. I would also like

to highlight things like App Tracking Transparency by Apple and the Google equivalent as you want to make sure that when collecting analytic information you are not passing on information that can be used to track your users, or you at least make them aware of it. Further to this, it is considered good practice to allow users to opt in to enable the collection of analytical information rather than just capturing it or making them opt out.

There are some companies that provide solutions for this already. They are fee-based but do offer a free tier with fewer features.

Sentry

Sentry offers a .NET MAUI package that will make it easier to collect crash and analytical information. The website contains details on its usage and pricing: https://sentry.io/for/dot-net/.

Sentry also has the source code open sourced on GitHub and provides usage examples as well as assisting in understanding what the code does:

https://github.com/getsentry/sentry-dotnet/tree/main/src/ Sentry.Maui

423