2020年3月開始，上傳ipa檔到App Store，立刻收到上傳成功信，不過有點不太一樣的是，信中提醒有個問題未來必須解決⋯⋯目前可以暫時略過，直到2020年12月後若還沒解決，上傳ipa檔到App Store就會被拒絕！
哇～真是驚為天人，原本已經完美無瑕的功能，現在要被迫更新使用新的API。其實軟體就是如此，會隨著時間演化出更好的效能，與時俱進是較佳的做法，就像公司的產品，若一直是舊有的狀態，極有可能會被時代給遺棄。例如：Feature phone已被Smart phone取代啦～
原本在想只要搜尋本專案中有無關鍵字「UIWebView」，然而查到的解法，是連同所使用的第三方套件都必須一併移除，這可是大工程呢！於是要研究怎麼轉移到「WKWebView」。
某天老闆心血來潮，要推播促銷活動，發現奇怪的問題⋯⋯查詢後原來是iOS 13 Apple推播通知回傳的Device Token改變了規則～
我立馬測試我們家App取得的Device Token，結果如下：
Printing description of deviceToken:
<a9df8591 f9be281b 45b7fd30 c452c298 05d04532 1c8e5e93 83079040 2efd1b83>
Printing description of deviceTokebStr:
{length=32,bytes=0xa9df8591f9be281b45b7fd30c452c298…830790402efd1b83}
Printing description of deviceToken:
<f144b48d 96957ab9 16717a2e e36d56a3 e91c0f7f 48623985 021173dd c4097c0e>
Printing description of deviceTokebStr:
f144b48d96957ab916717a2ee36d56a3e91c0f7f48623985021173ddc4097c0e
可以看到原本該是64字元的字串，變成有length和bytes，於是乎要再另外處理。
在iOS中有兩種常用的容器Object，就是Dictionary和Array，而現在資料傳輸到伺服器幾乎都在使用JSON，於是就有很多機會要將Object 轉換成 JSON。
註：
JSON（JavaScript Object Notation，JavaScript物件表示法，讀作/ˈdʒeɪsən/）是一種由道格拉斯·克羅克福特構想和設計、輕量級的資料交換語言，該語言以易於讓人閱讀的文字為基礎，用來傳輸由屬性值或者序列性的值組成的資料物件。儘管JSON是JavaScript的一個子集，但JSON是獨立於語言的文字格式，並且採用了類似於C語言家族的一些習慣。
JSON 資料格式與語言無關，脫胎自JavaScript，但目前很多程式語言都支援 JSON 格式資料的生成和解析。JSON 的官方 MIME 類型是 application/json，副檔名是 .json。
為了避免上架時把開發的東西誤上傳，那麼一開始最好就定義好Debug和Release，其實Debug和Release在Xcode中已有定義，包版本釋出預設就是Release，而開發的時候透過Xcode編譯到手機，預設則是Debug，不過其實可以改成Release來測試，如此方便！
透過Xcode可以讓專案自定義變數 (Project User Defined Variable)，這樣一來就算忘了有什麼是測試還是正式，都不用擔心會上錯啦～
現在申請或註冊任何服務，非常多都需要透過收發簡訊驗證碼，來確認是否為真實的使用者！過去一直都能在Android收到驗證碼後自動填入畫面欄位，而iOS終於在WWDC 2018開始支援呀ＸＤ～它建造一個叫做一次性驗證碼欄位 (One Time Code Textfield)。
最近需要得知第一響應者 (First Responder)是哪個元件，可惜iOS SDK並沒有直接取得的Method，網路上有的是Private API解法，若使用的話很大可能送審會「悲劇」，於是乎就有其他替代方法出現⋯⋯
若想體驗看看悲劇的話，可以使用這Private API：Ｐ～
UIWindow *keyWindow = [[UIApplication sharedApplication] keyWindow];
UIView *firstResponder = [keyWindow performSelector:@selector(firstResponder)];
審核人表明：
The non-public API that is included in your application is firstResponder.
專案已經開發超過一年半，累積的檔案數量已將近2500個（可見文章：專案檔案數遞增），想必日後編譯速度將會越來越慢，會深刻地影響我們開發的效率，尤其是在要了解前人所寫的程式碼，我們總是會稍微修改一下變數/參數來嘗試是否為增修的關鍵目標，所編譯頻率相當大，三不五時就要按Command+R。
我嘗試過許多改善開發效率的方法，其中有三個可以嘗試：
1和3在我們的專案早已設定完畢，只剩下2可以嘗試，沒想到效果超好，提升幾乎10倍快的編譯速度！
我們一定使用過通訊App，輸入框會隨著字數多換行而高度變大。四年前我寫過文章：動態框架 (Dynamic Frame)，這次我要來講進階用法，就是邊打字邊算輸入框的高度：TextView 動態高度 (TextView Dynamic Height)。
如上圖，我要打三元合一的緣由，從第一行開始，到「兩千年」的下一個字，就會計算兩行高度，此時需要實作TextView的Delegate，每打一字就會觸發：
-(BOOL)textView:(UITextView *)textView shouldChangeTextInRange:(NSRange)range replacementText:(NSString *)text
就在裡頭就能即時運算高度。
去年11月底，剛熟悉公司專案，想知道整個專案的至今的狀況如何，其中一個方式就是了解程式碼相依程度，我找到一個相當不錯的視覺化專案相依關係的工具，會透過網頁以互動的方式呈現。
我在GitHub上找個開源專案，透過模擬器編譯成功後，成功開啟網頁來玩泡泡～
從main開始進入AppDelegate。
最近要送審未來高達10000人使用的App，過程我要非常小心不能出差錯，先前都是由前輩同事送審，因為他連續請假3天，只好由我代替來送審，儘管過去已送審不下10個App，然而一想到是公司自己的產品，神經稍微緊繃了一下，是在看到IDFA，我還是愣了一下⋯⋯因為幾個選項描述得好似官方式文言文，深怕一選錯，被拒絕後，會被主管關切ＸＤ～
逍遙文工作室 
HappyMan・迴響