本篇文章在介紹從 Apple 的 App Store Connect 中為 iOS App 建立 TestFlight 外部測試群組；並且將 App 加入測試建置版本、填寫 Beta App 審查資訊、建立公開連結，並在版本通過審查後讓外部測試人員安裝測試的完整流程。
透過先建立 testflight 專用的外部測試連結後，再等待 Apple 將送至 Beta 審查的 App 審查完成後，就能把已核准的建置版本正式提供給外部測試人員開始進行外部測試。
本篇文章主要是要介紹在 AppStore Connect 中為 iOS App 建立 TestFlight 內部測試流程的幾個關鍵點。
從建立內部測試群組、指定內部測試人員，到綁定建置版本並填寫測試內容。
整體流程就像替 App 啟動一條路，並先把測試團隊放到正確位置，再把可測試的 App 版本送到 AppStore Connect 後，標示一些測試訊息，也能替參與的測試者理解到此版本的測試方向。透過這些指引畫面，可以清楚掌握 TestFlight 內部測試的準備步驟。
讓 App 在正式上架前可以先進行一輪有秩序、可追蹤、也更安心的 TestFlight 的內部測試。
這次要操練的對象是 Apple 的 App Store Connect，並且在其中建立一個 App 可供上傳：
也就是讓 App Store Connect 則成為 App 正式亮相前的後台舞台，從 App 名稱、語言、Bundle ID 到 SKU，都必須與前面建立好的資料互相呼應。整個流程的核心不是單純填表，而是替 App 建立一條可信任、可追蹤、可發佈的路徑。
如果在 前篇 沒啥意外，應該要順利的能透過 Visual Studio 發佈經過簽署的 iOS 應用程式到 App Store Connect 當中。
不出意外的話…馬上就會出意外
，這是通則。
如果無法順利直接透過 Visual Studio 發佈經過簽署的 iOS 應用程式到 App Store Connect 當中的話，那該怎辦？
其實也別擔心，只要確定 Visual Studio 有產出經過簽署的 iOS 應用程式(*.ipa)，那就可以透過 Xcode 或是 Transporter 來發佈到 App Store 當中。
.NET MAUI 撰寫好 iOS 應用程式後，不外乎就是要發佈該 iOS 應用程式到 App Store Connect 當中，除非所寫的是專屬給企業內部使用的 iOS 應用程式。
而在 Xamarin 的時代就已經可以透過 Visual Studio 的介面操作，直接發佈 iOS 應用程式的 *.ipa 到 App Store Connect，詳情請看：
透過 Visual Studio 串接 App Store Connect 發佈 iOS App
https://dotblogs.com.tw/jamestsai/2020/06/05/Using-Visual-Studio-publish-iOS-App-to-App-Store-Connect
而微軟官方文件也有相關的撰寫：
在 前篇 中已經順利在 Visual Studio 登入 Apple Developer Account 並且透過 API Key 存取 Apple Developer 的相關資訊。
可是這時候注意到一件事情：
Status 顯示 Not In Keychain
若想要透過 Visual Studio 開發 .NET MAUI 並進行 iOS 應用程式的開發，勢必要在 Visual Studio 當中登入 Apple Developer Account，以利取得憑證等資訊。
取得相關資訊後，在進行 iOS 應用程式部署的時候(安裝到測試實機上) 或是打包發版(發佈到 AppStore Connect)的時候，都會相對簡便。
不過，現在不再支援直接使用登入帳號密碼的方式使用。
請改用 Apple Developer 的 API Key 來存取囉！
本篇介紹是要替一個即將登上 App Store 的 iOS App 進行實機開發、測試、與發佈的設定準備
App 不是只要寫好程式就能出發，它還需要在 Apple Developer 裡擁有清楚的身分，也就是正確的 Bundle Identifier；需要能證明開發者身分的 Certificates；也需要讓開發、測試與發佈流程順利通行的 Provisioning Profiles。
當這些資料都整理好後，macOS 的 Xcode 也就可以像是一個本機端的檢查站，負責確認 Apple Account、Team、憑證與 Profiles 是否都能被正確使用。
在這當中就是要確保 Identifier、Certificate、Profile 與 App Store Connect 的 App 紀錄彼此對得上。
開始吧~~~
如果根據 前篇 操作後有發現 macOS 所建立的憑證不受信任的話，請參考此篇處理。
這篇有提到：
在 macOS 上最主要就是要安裝 Xcode，而如果要安裝 Xcode 的管道，基本上有兩種：
- 透過 macOS 上的 App Store 安裝。(登入 Apple 帳號後即能免費下載使用)
- 透過 Apple Developers 網站來下載 .xip 安裝。(需要先有訂閱 Apple 開發者帳號才能下載使用)
本篇就來談談如何透過 .xip 來安裝 Xcode。
如果要順利在 Visual Studio 來連接 macOS 透由 .NET MAUI 開發 iOS 的話，對於要連接的 macOS 上是需要事先安裝好 Xcode 等 Apple 所設計的 iOS 開發工具的。
不然，就算有開啟遠端登入等功能讓 Visual Studio 能夠連線並自動安裝 mono 等軟體元件，那也沒有 iOS 的相關 SDK 供使用。
在 macOS 上最主要就是要安裝 Xcode，而如果要安裝 Xcode 的管道，基本上有兩種：
本篇介紹是使用第一種方式來完成唷~~~
在使用 .NET MAUI 的時候可以透過 Google 推出的 Android Emulator 來建立 Android Virtual Device (AVD)，以便進行基本的 Android App 開發與前期的測試。
雖然在 App 的開發到後期通常會直接使用 實際的裝置 進行測試會比較恰當，但不可質疑的 AVD 在 Android App 很多開發情境當中仍是扮演著測試環節中很重要的部分。
而 Google 所推出的 Android Emulator 可以透過 Visual Studio 當中的 "Android 裝置管理員" 來使用，並且建立所需的 AVD 環境。
續接前篇，趕緊來看看怎達成下圖效果吧！
在 Visual Studio 要透由 .NET MAUI 來開發 iOS 應用，連接 macOS 的環境並且使用 iOS Simualtor 進行開發上的處理，應該會是最輕鬆的方式。
由於 Visual Studio 在安裝 .NET MAUI 的工作負載時，只會安裝 "基本" 的 Android 所需的開發與執行環境。如果有遇到一些狀況需要其他的進階使用時，那對於 Android SDK 的元件安裝就必須再進一步的調整。
例如在 前篇 的介紹當中，要啟動所建立的 Android Emulator 時就 "可能" 會有看到類似的提示畫面：
可以怎樣進一步嘗試調整呢？
可以看看本篇介紹。
而由於 .NET MAUI 是一套建置跨平台應用的開發技術，所以如果要在 上回 所建構出的 .NET MAUI 專案，直接切換建置 Android 出應用程式並不是什麼難事：
使用 .NET MAUI 開發 Windows 應用不是什麼難事：
看看如何透過 Visual Studio 的安裝來設定相關的開發環境囉~~
在 .NET MAUI 的專案當中若使用 Onion.Maui.GoogleMaps 這個 Nuget 套件(前身為 Xamarin.Forms.GoogleMaps) 後，在 iOS 平台上就能順利呈現 Google Maps 的效果：
接下來就看看如何在專案中開始使用此 "Onion.Maui.GoogleMaps" 套件囉~~~
根據前一篇的說明，針對目標套件 API 31 的規範問題，若沒有調整 App 所使用的目標套件 SDK 就無法上架。
若有使用 Xamarin(.Forms) 技術開發 Android App 的話，該如何修正這個問題以利符合 Google Play 的目標 API 規範呢?
文章標題，來翻譯翻譯後的意思就是:
請按照 Google Play 要求 "準則" 上傳 Android 的 .apk or .aab，否則就不能上架。
那為什麼要這樣規定呢? Google Play 官方給出了這樣的解釋:
指定使用最新 API 級別也有助於讓應用程式充分發揮平台的最新功能，讓使用者用得更加愉快…(?
上述解釋可參見下列網址:
https://developer.android.com/google/play/requirements/target-sdk?hl=zh-tw#why-target