個人制作のアプリを作った経験を元にしためっちゃ使えるライブラリを紹介させてください。
ローカルDBのバージョン管理で破滅したり翻訳のResource.reswで頭を抱える人が一人でも減ったらいいなーと思います。
MITライセンスで公開されているもののみを紹介していますが、実際利用される際には各自で確認してやってください。
LiteDB
端末ローカルなDatabase。No SQL。
クラス＋メンバーアトリビュートでDBのレコードを定義して、Linqで問い合わせられる。C#の自然な構文でアプリケーションサイドDBを扱えるのでDB苦手な人でもいけそうな気にさせてくれる（実際めちゃくちゃ簡単便利）。
バージョン間の統合にも対応しているが、よくわからん場合はメンバー定義の削除or追加をしてしまってもとりあえず動いてくれるので、なおのことDB初心者でも取り扱いがしやすい印象。
MonkeyCache
キャッシュしたいデータは全部「タル」に突っ込め！ 猿でもわかる超シンプルなデータキャッシュライブラリ。
キャッシュしたいデータにIDと期限だけ設定してBarrel（タル）に追加して、次回アクセス時に対象IDが期限切れなら新しいの取る、切れてないならキャッシュを取得する、とシンプルに管理できるようになる。
データの型ごとにテーブルが勝手に分かれるため、IDの管理とデータの種類ごとにどれぐらいのキャッシュ期限とするかだけに集中できる。
データ型を指定してキャッシュする場合はJsonにシリアライズ・デシリアライズして管理されるが、HttpCacheを使えばレスポンスの文字列データのままでキャッシュ管理することも出来る。（URLとレスポンスで管理できるのでこっちのほうが楽かも）
ReactiveProperty
表示とデータを分離する設計パターンのお供。プロパティをReactive（反応的）に扱えるようにしてくれる。
UWPやWPF、Xamarin.FormsにおけるXamlでは、表示側とデータ側のプロパティをバインディングしますが、プロパティを持つクラスがINotifyPropertyChangedを実装していればプロパティ変更通知から表示更新を行えるようになっています。このデータ変更から変更通知までの流れをカスタマイズしやすくサポートしてくれるのがReactivePropertyです。
MVVM的に良い感じにやりたくなってきたら是非MVVM、Observable、ReactiveExtensionsも含めて勉強していきましょう。そしてHotだのColdだので苦しむのだ…（呪詛）（よくわからなくて大丈夫です）
I18NPortable
国際化対応（internationalization）の英単語が長ったらしいので略して i18nと表記することに由来。ポータブルとあるように多くの環境で動くように作られているようです。
Key Value PairまたはJsonで表現したシンプルなテキストファイルを元にローカライズデータを作成できるため、外部ツールで翻訳データを編集してエクスポートしてプロジェクトに配置、みたいな運用とも相性がいいです。
特に恨みはありませんが UWP標準の翻訳である Resources.resx のVisualStudio付属のエディターが使いづらいだとか、MS謹製のMultilingalToolkitはAzureサービスにロックインしていてなんかヤダだとか色々と黒いものが…、やめよっかこの話(´・ω・｀)
詳しくは以前に紹介記事を書いてますので、そちらで。
→ 【.Net/Xamarin】I18N-Portableで手軽に多言語対応
Bmbsqd.AsyncLock
非同期処理を如何にシンプルに同期的に処理できるかは、async/awaitが非常に手軽に使えるC#では超重要だと思います（個人の感想です）
非同期の同期ロック AsyncLock にもたくさん実装があるので信用・信頼できるものを探してみてほしいところですが、個人的にはめっちゃシンプルに書ける Bmbsqd.AsyncLock を推してます。
private readonly Bmbsqd.AsyncLock _lock = new Bmbsqd.AsyncLock();
using (await _lock)
{
// 非同期な処理
}
これだけで非同期ロックを表現できます。ただし、キャンセルは別途Lockの内側で各自対応、かつデッドロックは発生するのでロックを含むメソッドをネストして呼び出すと詰むため注意必要です。
await ほにゃららと書くとGetAwaiterメソッドが呼び出されるので、そこでロック処理やればメソッド呼び出し回数最小になるしええやんという感じです。たぶん。
お行儀よくやるならSemaphoreSlimや AsyncEx をどうぞ。
PropertyChanged.Fody
禁断の魔法、それがFodyWeavers。その中でもPropertyChangedの実装を（クラスやメンバーの）アトリビュート記述のみで自動で付与してくれるのが PropertyChanged.Fody です。
Fodyはコンパイル時にコードを変更して便利機能を作るためのライブラリです。そのPropertyChanged版ということですね。
PropertyChangedをちゃんと実装しようとすると、例えばMVVMライブラリのPrismにあるBindableBaseクラスを継承すれば SetPropertyメソッドを通じて少ない記述量でINotifyPropertyChangedのPropetyChangedイベントをトリガーするプロパティを書けます。
ところが PropertyChanged.Fody ではクラスに[PropertyChanged.AddINotifyPropertyChangedInterface] を付与するだけで、
コンパイル時に自動生成されるようになるため、もはやバッキングフィールド＋SetPropertyを書かなくて済みます。クラスの記述量を非常に減らせることがとても魅力的です。
ですが、その魅力は悪魔の果実。不用意に利用すると生成されるILコード量が爆発し、最終的にアプリのパッケージサイズが非使用時の数倍に膨れ上がります。またゲッターが他の通知プロパティを利用して実装されている場合に、ゲッターにもプロパティ変更通知が飛ぶようにする依存性解決がビルド時間をモリモリと伸ばします。
ご利用は計画的に。使うと割と大きめな代償（主にビルド時間やCPUとメモリのリソース）を求められるため覚悟の準備をしておいてください。
Windows Community Toolkit
UWPとWPF、WinFormにだけ限定されます。
標準のUIや機能では足りない部分をMicrosoftとコミュニティとで協力して開発しているのがWindows Community Toolkitです。
例えば、「WPFにあったLayoutTransformがUWPだと出来ない！」と言う場合もToolkitのLayoutTransformを利用することで対処できたり、
レイアウトで「寄せ＋残りを自動サイズ」としたい場合には「DockPanel」が有用だったり、といった具合。
また、UIに留まらず、扱いづらいApplicationDataはObjectStorageで補助したり、SystemInfomationではデバイスの種類、利用可能メモリ、アプリバージョンなどをまとめてアクセスできて便利（アプリの起動回数や使用時間の把握の補助機能もここにあったりする）。
標準にないけどもっと込み入ったことをやりたいときにWindows Community Toolkitを確認しておくと車輪の再開発をせずに済むかもしれないので、予めチェックしておくとどんな表現なら短時間でやれそうかなど読みやすくなるので要チェックです。
Uno Platform
C#/XamlでUWPアプリを作ったらAndroid/iOS/Web Assemblyなどに対応できることを目指して、既にUWPの電卓アプリをUno PlatformによってAndroid/iOS/Wasmに対応してリリースしているなど実用段階に入りつつあるライブラリ（？ プラットフォーム？）。
Xamarinベースなクロスプラットフォーム対応コードをUWPのXamlやAPIとして隠蔽してしまっているため、表面的な開発はUWPアプリを作るのとほぼ変わりありません。
クロスプラットフォーム対応の原理としては基本UWPがネイティブなんですが、AndroidやiOSで動かす場合には、UI表現に関してはXamlの描画機構を各プラットフォーム向けにエミュレートして表示する形になっているので、UWPアプリとして表示できたものはそのままAndroid/iOSでも表示できます。特にVisualStateやAdaptiveTriggerも対応しているのでレスポンシブデザインもデフォで対応可能。条件付きXamlを利用すればバージョンアダプティブなデザインも出来るし、UWPアプリの表現力をそのままAndroid/iOS等で使えます。
また、APIに関しては、例えばインターネット接続やセンサーなどのデバイスごとの機能を使いたい場合、XamarinであればXamarin.Essentialを使用するが、Uno PlatformにおいてはUWPのAPIを各プラットフォーム向けに実装を差し替えてくれるため、UWP向けのコードがそのままAndroid/iOSでも動作する形となってます。（MediaPlayerのような実装がハードなものに関しては対応が部分的になっているケースもあるので要検証）
UWPの開発UX（XAML Edit and Continue や C# Edit and Continue）などを使って高速な開発イテレートから、AndroidやiOSも行えるようになることが目標となっていて、個人的に、UWPでXboxOneやMobileを統合して「Once write, run everywehre」を実現していたものをさらにAndroidやiOSなども巻き込んで実現していくという理想に、とても期待してます。
おわりに
UWPが下火になっても私はUWPのファンを続けるよ！
というのは半分冗談ですが、UWPの開発UXはとてもいい環境なので今後も長く続いてくれた良いなと思います。また何か応援できるような記事を書いていきたいなと思います。
へばな！