在我上一篇文章中，我強調了一些在iOS 10推出的開發者可以利用的新功能。將版本沖刺到最新和最好的是很有趣，然而你也需要確保你的應用程序是全線更新的。這意味著需要檢查任何過時的方法或類，并驗證仍在運行iOS現有版本的用戶被繼續維護。

在你翻看所有的更新記錄之前（如果今晚你無法入睡，這是我強烈建議的），有幾件事情你可以做，以確保你的應用程序準備好過渡到iOS 10。

小故事：很多年前，在一個遙遠的星系，我以在幾十萬的月活躍用戶附近的東西創建一個iOS應用程序。我建立、測試和部署最新iOS 5支持的更新。我和一些同事慶祝其發布，但幾小時內，我從Apteligent得到事故通知。原來，我用了一個只適用于iOS 5的方法，沒有妥善處理，于是，由于我的用戶群中30%的人使用iOS 4或更早版本，應用程序崩潰了。哎！不用說，我的測試變得更加嚴格，（注意：無恥的插在前面）我很高興我安裝的Apteligent快速提醒了我，但這是一個慘痛的教訓。不要讓這種事發生在你的身上！

API的可用性檢查

當在iOS 10中構建新的API時，你能夠確保你的應用程序仍然可以在舊版本上運行的最好的辦法就是做運行時API檢查。這將確保你將要在當前運行的設備上調用的類或方法。如果你想在iOS 9中調用iOS 10的方法，你會遇到麻煩（見以上我的傷心故事）。

對于類，這是一個簡單的檢查，看起來就像這樣：

if(NSClassFromString(@"MSMessage")) {
    // This class is available, go ahead and do something with it
} else {
    // This class is not available, handle it appropriately
}

或者，如果你更喜歡Swift：

if #available(iOS 10.0, *) {
  let message = MSMessage()
} else {
    // This class is not available, handle it appropriately
}

如果類（MSMessage）是弱聯系，block 外部的MSMessage引用在前iOS 10設備上不會導致你的應用程序立即崩潰。這使得錯誤更難找到，并會讓測試忽略更多的問題。即使你避免了崩潰，你的用戶體驗也會迅速降低，因為你的代碼不能識別MSMessage功能的缺失。這使得實施新的功能時，處理前、后iOS 10的情況變得非常重要。

對于現有的類的新方法，有另一個簡單的檢查：

// Check if new API is available
if ([existingClassObject respondsToSelector:@selector(newMethod:)]){
    // Yes, we can safely call this method
    [existingClassObject newMethod:@”something”];
} else {
    // The new method is not available, handle accordingly
}

在Swift中，你可以使用上述相同的#available方法，如果你知道你的方法需要的SDK，這會特別有用。否則，你可以使用以下所顯示的等效方法調用：

// Check if new API is available
if existingClassObject.respondsToSelector(Selector(“newMethod”)){
    // Yes, we can safely call this method
    existingClassObject.newMethod()
} else {
    // The new method is not available, handle accordingly
}

我們首先檢查看看如果我們調用它，該方法是否會響應，如果響應，我們就繼續并且安全地調用它。這個簡單的條件也在iOS 9中處理的事件，其中該方法將不響應，在iOS 10中，該方法可以被調用。

如果你試圖在iOS一個不受支持的版本中調用newMethod ，你的應用程序會由于NSInvalidArgumentException而崩潰。這是一個關于iOS最常見的事故，它可以用這種簡單的檢查來避免。

關于宏的一個注記

宏是由編譯器執行的代碼位。通過iOS系統，你可以使用這樣的東西：

#if __IPHONE_OS_VERSION_MIN_REQUIRED >= __IPHONE_10_0 
    // iOS 10+ code 
#endif

許多開發者看到了這一點，把它添加到他們的代碼卻沒有完全理解發生了什么，但這不應該被用來確保用戶在iOS 10。這就是為什么：

么，但這不應該被用來確保用戶在iOS 10。這就是為什么： 如果應用程序的部署目標（deployment target）是大于或等于iOS 10，block內的代碼只會被編譯。更有可能的是，你的應用程序的部署目標是低于目前的SDK。例如，你的部署目標可低至iOS 8，因為你仍然要支持現有的用戶。

如果你使用iOS 8以上支持的宏，由于宏在編譯時執行的所有用戶，block內的代碼將被省略。你不會看到任何警告或得到任何錯誤提示，你的代碼將不會被包含在你的應用程序中！

為了管理的棄用和新的API，最好在運行時做代碼檢查以容納你的應用程序支持的所有的操作系統版本和設備。

注意Deprecation警告

在一點或另一個上，每個開發者都沿著“別擔心，我后面會處理”的套路在走。你可能已經在Xcode看到deprecation警告，讓開發商知道方法或類找到了出路。在某個點上的代碼將被刪除；如果它試圖在一個新的操作系統上引用被刪除的方法，你的應用程序將崩潰。

一般來說，這不是一個短期的過程。蘋果通常會用“過時的”類或方法發布很多大的操作系統，在它實際上被刪除之前，這給了開發者時間來適當地更新他們的代碼。無論如何，時間終于來了，所以它是你的雷達上應保留的東西。

在iOS 10有極少數的類/方法移除，這意味著對大多數開發者而言這些都不是問題，但是要檢查更新記錄，以及關注你的編譯器警告以防萬一。

測試所有支持的iOS版本

在一天結束時，它將是適當的測試，以驗證你的應用程序可以在你支持的所有的設備和操作系統上運行。不要落入“它能在我的設備上運行，所以它是沒問題的”的陷阱中。不幸的是，即使是最好的測試也不能抓住一切，于是Apteligent來了。我們的SDK允許你在你的應用程序上監控崩潰和性能問題，快速追蹤測試忽略的錯誤。

完成

我強烈建議搶先安裝iOS的最新版本，這樣你的應用程序就可以利用蘋果所提供的最新的功能。只要確保你沒有忽視其余部分用戶群使用的應用程序的穩定性和性能。只需要一個失敗的發布就可能減少你辛辛苦苦賺來的五星評級，所以請徹底的測試、測試、測試。

遵循這些準則，你的應用程序都將在今年秋季iOS 10正式啟動時被設置完成。

本文翻譯自：

PS: 關于移動開發，這些產品你可以關注>>

關于移動開發的最新資訊和產品推薦，請<>!