① xcode為什麼能編譯成功但不能運行顯示出結果。顯示如下圖片。什麼問題。急急急!在線等
輸出框右下角，而且貌似你的還沒執行到nslog吧
② 【Android開發學Flutter】Xcode編譯問題匯總
Xcode編譯經常遇到各種問題，處理起來費時費力，挺打擊學習積極性的。記錄下這些問題，方便自己也幫助後來人。
編譯的時候遇到：
網上有很多解決方法，我是用這個方法解決的：
編譯的時候遇到：
解決辦法：
Project -> User-Defined -> FLUTTER_ROOT 改成本地 flutter SDK路徑
感謝 issues 上的小哥，給你個🚀
在項目目錄下執行 flutter run 可以正常運行到手機，但是在Xcode build 還是有問題。
這時需要手動添加 FLUTTER_ROOT 到 User-Defined ：
添加之後：
就可以正常在Xcode build 安裝到手機了。
flutter build ios 後出現：
pod install 後出現：
解決辦法：
這是因為terminal沒有走代理的流量，
使用 git config --global http.proxy "localhost:port" ，設置代理。
port是埠號，根據不同的vpn不一樣，我的埠是10080。
執行 git config --global http.proxy "localhost:10080"
Xcode build 的時候出現：
解決辦法：打開 ios/Podflie 文件：
關於 bitcode 的問題，我檢查了下用到的第三方SDK，應該是網路地圖的問題，我引入了個第三方插件（吐槽下沒官方插件），網路地圖有支持和不支持 bitcode 的兩個SDK，我取消這個插件就沒有報這個錯了，奇怪的是，再次引入同一個插件，也可以正常打包，所以說這個問題還沒有完全解決。
大家可以試下這個處理方法：
TARGETS -> Build Seettings 搜 arm ，試一下把其他刪除，只留下armv7跟armv7s或者只留下armv7
解決辦法：
https://www.jianshu.com/p/201df7e9a52f
我是clean Xcode之後就可以了
解決辦法：
用的是P12證書，改成手動簽名：
③ Mac下Xcode編程寫OpenGL遇到問題，編譯成功但無法生成窗口，內有詳細錯誤。
最好用斷點查一下具體錯誤代碼在哪裡。
④ M1 設備的 Xcode 編譯問題深究
在Apple發布M1晶元之前，一直使用Intel的晶元，沒有出現什麼問題。發布M1晶元後，由於兩者架構的不同（M1是arm64架構，Intel是x86_64的架構），導致很多軟體運行出現了問題。我們在M1機型中使用Xcode編譯模擬器時，可能會碰到如下報錯：
或
這些報錯，都是是由於項目中存在.a或.framework靜態庫導致的。以前，我們創建靜態庫時，會分別打包出一份針對真機（arm64）和模擬器的（x86_64），然後將這兩份合並成一個包後引入項目中進行使用。在Intel機型上，真機上使用arm64指令，模擬器（x86_64）中使用x86_64指令，所以不存在問題。但是在M1機型上，模擬器是以arm64運行的，顯然再以x86_64運行就會出現問題。
對於這類架構報錯問題，網上的資料一般會告訴你兩個解決方案：
以Rosetta模式運行Xcode。
修改Build Settings -> Excluded Architectures選項，添加Any iOS Simulator SDK選項，並設置值為arm64。圖示如下：
這兩種方案都能解決編譯問題，但是也都存在問題。
以Rosetta模式運行是M1機器上x86軟體無法運行的解決方案，它會將x86指令轉譯成ARM指令運行，這種轉譯顯然是存在性能損耗的，損耗大概在20%～30%，不到萬不得已，不推薦使用這種方案。
Excluded Architectures方案說明
修改Excluded Architectures選項也有它的問題。字面意思是排除架構的意思，我們設置在模擬器中排除arm64就能解決模擬器無法編譯arm64的問題。
這樣的設置能生效會讓人有點費解，我們知道，在intel機型上，模擬器本來就是以x86方式運行的，排除arm64毫無影響。但是在M1機型上，模擬器是以arm64方式運行的，排除了arm64反而能跑，這不是把我的智商摁在地上摩擦么？，但是蘋果就是這樣乾的，當在M1機型上，排除了模擬器的arm64架構後，模擬器還是會以arm64的方式運行，但是模擬器中的app是以x86的方式運行的，對蘋果的這個騷操作我們不得不服。圖示如下：
有時候在Excluded Architectures選項中排除了模擬器的arm64指令，依然無法編譯通過，那麼一般是項目設置和cocoapods的設置不一致導致，設置為一致後一般可以解決問題。可以通過在Podfile中添加如下內容來解決：
通過上述內容，我們知道了問題的由來，它是由於項目中存在.a或.framework，它們提供的指令集不完整導致的。Apple對於這類問題，也提供了解決方案，請由我細細道來。
以Xcode13為例，在我們創建靜態庫時，選擇真機編譯出來的包只包含arm64指令，選擇模擬器編譯出來的會同時包含arm64和x86_64指令。我看一些網上的教程，教別人將模擬器部分的arm64移除，其實大可不必。因為要支持M1機器正常跑模擬器，模擬器必須同時包含arm64和x86_64指令。
2019年的WWDC，apple提供了一種新的框架封裝格式XCFramework。簡單理解就是以前使用lipo合並不同指令集的包，現在則使用新的指令合並成XCFramework格式
打包成framework，格式如下：
打包成XCFramework後，格式如下：
從上述可以看出，XCFramework就是把兩個不同指令集的framework放入了同一個文件夾(.xcframework)，並生成了一個配置文件Info.plist。這樣生成的XCFramework就可以完美的解決M1機器無法編譯模擬器的問題。
XCFramework的創建指令也很簡單：
以現在的情況，很多第三方框架，並沒有使用XCFramework，而項目中只要有一個框架沒有支持模擬器的arm64指令，那麼在M1機器上，模擬器只能以Rosetta模式運行應用，對這一塊的普遍支持估計要等M1普及以後了。
蘋果換芯，成了開發者們的噩夢？
armv6、armv7、armv7s、armv8、armv64及其i386、x86_64區別
細說iOS靜態庫和動態庫
關於Xcode11的XCFrameworks框架