問題裡的“秒退”如果我沒理解錯，應該是指程式顯示完預設啟動圖片後，在初始化階段就崩潰了（也可以叫“閃退”，不過最近“閃退”這個詞已經被廣泛應用於各種程式崩潰情況了，所以可能還是“秒退”更準確？）。 這種情況應和所謂的記憶體不足關係不大，很少有程式會在初始化時載入大量內容導致崩潰，並且這類問題也很容易在開發階段被發現，所以記憶體不足造成秒退的可能性低（記憶體不足退，通常是程式用了一段時間，切換了幾個畫面以後發生的）。 而且秒退是發生在程式剛剛啟動的時候，在開發、蘋果稽核階段都沒有被發現的最大可能性就是，這個問題只會發生在老版系統、老版機型上。 對於很多開發者（尤其是個人開發者），進行所有 iOS 版本，所有 iOS 機型覆蓋測試是有難度的，蘋果稽核時也只是重點稽核該應用在新機器、新版本下的執行情況，並不關注老系統。所以這也就是為什麼會秒退的程式竟然也能透過蘋果的稽核。 在新 iOS 上正常的應用，到了老版本 iOS 上秒退最常見原因是系統動態連結庫或Framework無法找到。這種情況通常是由於 App 引用了一個新版作業系統裡的動態庫（或者某動態庫的新版本）或只有新 iOS 支援的 Framework，而又沒有對老系統進行測試，於是當 App 執行在老系統上時便由於找不到而秒退。解決辦法是等開發人員發現這個問題後升級程式，或由使用者自行升級其作業系統。 還有一種常見的秒退是程式在升級時，修改了本地儲存的資料結構，但是對使用者既存的舊資料沒有做好升級，結果導致初始化時因為無法正確讀取使用者資料而秒退。這類問題通常只需刪除程式後重新安裝一遍就能解決。但缺點是使用者的既存資料會丟失——就算有備份可能也無濟於事，因為備份下來的舊資料還是無法被正確升級。如果舊資料非常重要，那麼就需要聯絡開發人員要求其進行程式修正了。 另一種已經變得不那麼常見的秒退原因是 App 的設定不正確。例如在編譯時沒有編譯 ARMv6 的版本，但是設定裡卻允許該 App 執行在 ARMv6 處理器的機器上（如：iPhone 1代，iPhone 3G，iPod touch 1、2代和3代8G版）。這個問題除了等開發人員升級外使用者自己沒什麼辦法解決。當然願意換臺新機器是最好的 ；） 這個問題目前已經能夠在提交應用至 App Store 的時候被檢查出來了，因此今後應該不太常見了。 還有一類秒退或是用到 App 裡某個功能後必退的原因，是開發時用到了只有新版作業系統才支援的某個方法，而又沒有對該方法是否存在於老系統中做出判斷。例如程式啟動時用到了 Game Center，而沒有判斷使用者的機器是否支援 Game Center，於是就秒退了。 主要的秒退情況就是這麼幾個，這些都是以該 App 新版系統上能正常跑為前提的。 諸如記憶體不足、BAD_ACCESS 這類問題通常不管在新舊 iOS 上都會存在，如果是由於這類問題造成的秒退通常都能在測試和稽核階段被發現，因此並不常見。