軟體主廚的程式料理廚房

以前聽過有個笑話是這樣說的：

某A：聽說 iOS 在瀏覽網頁的時候很省電
某B：對，因為它什麼事都沒做。

原來這件事是真的，根據 RFC 7234 5.2.1.4 的定義，如果我們在發送 Request 的時候，加上 cache-control: no-cache，在沒有從伺服器成功取得內容之前，不得使用已儲存的快取來滿足目前的 Request，但是 iOS 它連 Request 都沒送，自然就不需要理會這個定義。

開發 iOS 的 App 想上架到 App Store 送審被拒絕個幾次可說是稀鬆平常的，即使我們把 App Store Review Guidelines 讀得滾瓜爛熟，還是有被拒絕的可能，而且被拒絕的理由百百種，有跟 Apple 審核團隊交手過的朋友應該就有 fu，我就我這次 App 送審被 Apple 退件拒絕的經驗做個記錄。

Apple 在審查我們的 App 的時候會在 IPv4 跟 IPv6 環境底下去測試，我們的 App 應該要能在 IPv6 的網路環境執行，如果我們手邊有 macOS 就可以建立一個 NAT64 的網路環境來測試看看我們的 App 在 IPv6 的環境底下 work 不 work？

用 Xamarin 開發好 iOS App 後，如果我們的開發環境是 Visual Studio 照著官方的步驟一步一步做，用 Application Loader 上傳完畢想說應該 OK 了，但是在 iTunes Connect 遲遲不見剛剛建置版本上傳，檢查信箱收到了一封信：

Apple 在審核我們的 App 的時候會看一個東西，那就是我們的 App 內提供的對外連結是否具有引導消費的功能，消費的項目如果被認定踩中了 App 內購買的類型，比如說我在我的 App 放了一個按鈕，按下去之後用瀏覽器開啟我準備好的網頁，使用者在網頁中可以付費升級專業版，這樣的話有極大的機率會被 Apple Reject，然後叫我們用他們家的 In-App Purchases，不過實作上也不算太難。

Firebase Clound Messaging（FCM）的 Notification Payload 裡面有一個 click_action，顧名思義就是當推播訊息被使用者點擊之後，App 跟隨著要做什麼樣的反應動作，最常見的就是 App 依據 click_action 跳至與通知相關的頁面，我們就來看看如何透過 click_action 來控制顯示不同頁面。

上一篇 Xamarin.Forms（Android）接收來自 Firebase Cloud Messaging 的推播通知，當然也要來個 iOS 版本，但是在這個過程當中走了相當多的坎坷路，才知道原來 iOS 模擬器不能模擬東西還不少，為了開發 iOS App 除了買 Mac 用來建置之外，還得買 iPhone 來測試模擬器不能測試的東西，還要為我們的開發者帳號繳至少一年 $99 鎂的費用，著實花了不少錢，說這些都是淚水啊。