Ignite 的 iOS 原生工程ios 文件夾的生成時機、結構與 Xcode 調試指南【免費下載鏈接】igniteInfinite Reds battle-tested React Native project boilerplate, along with a CLI, component/model generators, and more! 9 years of continuous development and counting.項目地址: https://gitcode.com/GitHub_Trending/ig/ignite導讀本文圍繞 Ignite 項目模板中的ios文件夾展開講清楚它在什么條件下生成、內部包含哪些原生工程內容、與 Expo CNG連續原生生成工作流的關系以及如何用 Xcode 打開并運行、如何通過 EAS 構建 iOS 包。讀完本文你將掌握手動管理 iOS 原生代碼的完整路徑并理解 Ignite 團隊為何默認推薦 CNG 工作流。ios 文件夾從哪來兩條生成路徑在 docs/boilerplate/ios.md 中明確說明ios文件夾以及通常同時出現的android文件夾出現在項目根目錄只有兩種來源使用ignite new創建新應用時選擇manual手動工作流在項目根目錄運行pnpm run prebuild:clean。無論哪條路徑其背后都是同一個機制Expo Prebuild 根據app.json/app.config.ts中的配置一次性生成完整的原生 iOS / Xcode 工程并已預先配置好與 React Native 的集成。源碼視角new 命令中的工作流選擇從 src/commands/new.ts 可以看到ignite new會在未顯式傳入--workflow參數時向用戶詢問是采用expo還是manual工作流確認后會打印workflow: ${workflow}日志。當依賴安裝成功后new.ts 會通過packager.run(prebuild:clean, ...)執行原生模板生成——也就是 boilerplate/package.json 中定義的npx expo prebuild --clean。一個值得注意的細節在 new.ts 中當工作流為manual時CLI 會從生成的.gitignore中移除/android與/ios兩行。這意味著manual 工作流下原生目錄被視作需要提交到版本庫的一等公民而在默認的 CNG 工作流下它們被忽略、可隨時重新生成。文件夾內部是什么預配置好的 Xcode 工程ios文件夾是一個標準的 iOS 原生工程包含.xcworkspace/.xcodeproj、PodfileCocoaPods 依賴管理、Info.plist以及由 Expo Prebuild 生成的各類原生源文件。它開箱即可與 React Native 協同工作你可以像對待任何 React Native 項目一樣用 Xcode 打開并運行到模擬器或真機上。工程名與包名的來源工程的身份信息并非手寫而是來自 boilerplate/app.json 中的ios配置段ios: { icon: ./assets/images/app-icon-ios.png, supportsTablet: true, bundleIdentifier: com.helloworld }bundleIdentifieriOS 包名Bundle IDPrebuild 會將其寫入 Xcode 工程的簽名與產品標識supportsTablet是否聲明支持 iPadiconApp 圖標資源會被寫入工程的 AppIcon 資產目錄。需要修改包名或圖標時直接修改app.json并重新執行pnpm run prebuild:clean即可讓原生工程同步更新。iOS 隱私清單app.config.ts 中的原生級配置生成的原生工程還會帶入 boilerplate/app.config.ts 中通過動態配置注入的 iOS 設置。該文件使用 TypeScript 編寫并借助tsx/cjs加載其中默認加入了一份Apple 隱私清單Privacy Manifestios: { ...config.ios, privacyManifests: { NSPrivacyAccessedAPITypes: [ { NSPrivacyAccessedAPIType: NSPrivacyAccessedAPICategoryUserDefaults, NSPrivacyAccessedAPITypeReasons: [CA92.1], // CA92.1 Access info from same app, per documentation }, ], }, },這份配置聲明了應用會訪問UserDefaults這一“需說明理由的 API”類別原因代碼為CA92.1。如果你在原生的ios文件夾中直接修改了涉及這些 API 的邏輯需要在此處補充對應的隱私聲明條目。這也是“直接維護原生代碼”時最容易遺漏、卻可能影響 App Store 審核的環節。manual 工作流 vs Expo CNG為什么不推薦直接改原生Ignite 團隊在 docs/expo/CNG.md 中給出的建議是絕大多數應用都應優先使用 Expo CNG 工作流。它的優勢包括無需直接與 Gradle 和 CocoaPods 打交道升級 React Native 或 Expo SDK 時極為省力因為你不需要繞開自己的原生定制大量流行庫都有現成的 Config Plugin也支持編寫自定義插件來注入原生配置。而 manual 工作流的定位在 docs/expo/DIY.md 中描述得很直白它主要為不想使用 Expo Prebuild、希望自行維護原生代碼的開發者保留。文檔同時揭示了一個實現細節manual 工作流底層仍然是CNG流程——CLI 只是幫你把ios/android文件夾生成出來之后你就不再運行 Prebuild而是直接定制這兩個原生工程所以稱為手動部分。這意味著一旦選擇了 manual 工作流你就承擔起了 CocoaPods 管理、Xcode 工程配置、SDK 升級時的原生適配等全部責任。如果你的應用需要深度原生定制如接入自研原生 SDK、修改原生啟動流程ios文件夾正是你施展的舞臺否則保持 CNG 工作流、讓ios文件夾保持在.gitignore中隨用隨生是更省心的選擇。用 Xcode 運行與調試拿到ios文件夾后運行方式與任意 React Native 項目一致安裝依賴并安裝 Pods在項目根目錄執行pnpm install隨后cd ios pod install或直接使用npx pod-install用 Xcode 打開ios/HelloWorld.xcworkspace注意是 workspace 而非 project因為工程依賴 CocoaPods選擇目標模擬器或已連接的真機真機需配置好開發者簽名與 Bundle ID點擊 Run 構建并啟動應用。針對原生代碼的調試官方文檔建議參考 React Native 原生調試章節使用 LLDB 斷點、查看原生日志等。ios文件夾中的 Swift/Objective-C 文件均可在 Xcode 中直接打斷點調試這與純 JS 層的調試器是互補的兩套工具鏈。通過 EAS 云構建 iOS 包無需本機 Xcode如果你不想在本機折騰 XcodeIgnite 的默認方案是 EASExpo Application Services云構建相關說明見 docs/expo/EAS.md。boilerplate/eas.json 已為 iOS 預置了多檔構建配置development: { extends: production, distribution: internal, ios: { buildConfiguration: Debug, simulator: true } }, development:device: { extends: development, distribution: internal, ios: { buildConfiguration: Debug, simulator: false } }, preview: { extends: production, distribution: internal, ios: { simulator: true } }, preview:device: { extends: preview, ios: { simulator: false } }, production: {}配置要點buildConfiguration: Debug指定 Xcode 構建配置為 Debug便于攜帶開發調試能力simulator: true / false控制構建產物面向模擬器還是真機真機構建需要簽名證書與 Provisioning Profiledistribution: internal產物通過 EAS 內部渠道分發。boilerplate/package.json 中提供了對應的快捷腳本全部通過--local在本機構建pnpm run build:ios:sim # 開發版iOS 模擬器 pnpm run build:ios:device # 開發版iOS 真機 pnpm run build:ios:preview # 預覽版模擬器 pnpm run build:ios:prod # 生產版真機日常本地開發啟動模擬器應用則使用pnpm run ios # 等價于 expo run:ios注意在 CNG 工作流下expo run:ios會在構建前按需執行 Prebuild重新生成ios文件夾而在 manual 工作流下它直接編譯你已維護的ios文件夾。實踐建議與注意事項確認你所在的工作流運行pnpm run prebuild:clean會覆蓋你手工修改的原生代碼因此在 manual 工作流下請謹慎執行該命令提交策略manual 工作流應把ios目錄提交進 GitCLI 已自動從.gitignore中移除/iosCNG 工作流則保持忽略隱私合規無論哪種工作流只要 iOS 原生代碼訪問了 Apple 的“需說明理由 API”都應同步維護 boilerplate/app.config.ts 中的privacyManifests升級路徑CNG 工作流可通過升級 Expo SDK 后重新 Prebuild 獲得最新原生模板manual 工作流則需要手動比對并移植原生改動這也是其維護成本最高的環節。總之ios文件夾是 Ignite 在需要直接掌控原生層時的出口平時安心使用 CNG 讓原生工程隨配置再生真正需要深度定制時再通過 manual 工作流或prebuild:clean把它落地并用 Xcode 或 EAS 完成構建與調試。【免費下載鏈接】igniteInfinite Reds battle-tested React Native project boilerplate, along with a CLI, component/model generators, and more! 9 years of continuous development and counting.項目地址: https://gitcode.com/GitHub_Trending/ig/ignite創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 Ignite 的 iOS 原生工程：ios 文件夾的生成時機、結構與 Xcode 調試指南
Ignite 的 iOS 原生工程ios 文件夾的生成時機、結構與 Xcode 調試指南【免費下載鏈接】igniteInfinite Reds battle-tested React Native project boilerplate, along with a CLI, component/model generators, and more! 9 years of continuous development and counting.項目地址: https://gitcode.com/GitHub_Trending/ig/ignite導讀本文圍繞 Ignite 項目模板中的ios文件夾展開講清楚它在什么條件下生成、內部包含哪些原生工程內容、與 Expo CNG連續原生生成工作流的關系以及如何用 Xcode 打開并運行、如何通過 EAS 構建 iOS 包。讀完本文你將掌握手動管理 iOS 原生代碼的完整路徑并理解 Ignite 團隊為何默認推薦 CNG 工作流。ios 文件夾從哪來兩條生成路徑在 docs/boilerplate/ios.md 中明確說明ios文件夾以及通常同時出現的android文件夾出現在項目根目錄只有兩種來源使用ignite new創建新應用時選擇manual手動工作流在項目根目錄運行pnpm run prebuild:clean。無論哪條路徑其背后都是同一個機制Expo Prebuild 根據app.json/app.config.ts中的配置一次性生成完整的原生 iOS / Xcode 工程并已預先配置好與 React Native 的集成。源碼視角new 命令中的工作流選擇從 src/commands/new.ts 可以看到ignite new會在未顯式傳入--workflow參數時向用戶詢問是采用expo還是manual工作流確認后會打印workflow: ${workflow}日志。當依賴安裝成功后new.ts 會通過packager.run(prebuild:clean, ...)執行原生模板生成——也就是 boilerplate/package.json 中定義的npx expo prebuild --clean。一個值得注意的細節在 new.ts 中當工作流為manual時CLI 會從生成的.gitignore中移除/android與/ios兩行。這意味著manual 工作流下原生目錄被視作需要提交到版本庫的一等公民而在默認的 CNG 工作流下它們被忽略、可隨時重新生成。文件夾內部是什么預配置好的 Xcode 工程ios文件夾是一個標準的 iOS 原生工程包含.xcworkspace/.xcodeproj、PodfileCocoaPods 依賴管理、Info.plist以及由 Expo Prebuild 生成的各類原生源文件。它開箱即可與 React Native 協同工作你可以像對待任何 React Native 項目一樣用 Xcode 打開并運行到模擬器或真機上。工程名與包名的來源工程的身份信息并非手寫而是來自 boilerplate/app.json 中的ios配置段ios: { icon: ./assets/images/app-icon-ios.png, supportsTablet: true, bundleIdentifier: com.helloworld }bundleIdentifieriOS 包名Bundle IDPrebuild 會將其寫入 Xcode 工程的簽名與產品標識supportsTablet是否聲明支持 iPadiconApp 圖標資源會被寫入工程的 AppIcon 資產目錄。需要修改包名或圖標時直接修改app.json并重新執行pnpm run prebuild:clean即可讓原生工程同步更新。iOS 隱私清單app.config.ts 中的原生級配置生成的原生工程還會帶入 boilerplate/app.config.ts 中通過動態配置注入的 iOS 設置。該文件使用 TypeScript 編寫并借助tsx/cjs加載其中默認加入了一份Apple 隱私清單Privacy Manifestios: { ...config.ios, privacyManifests: { NSPrivacyAccessedAPITypes: [ { NSPrivacyAccessedAPIType: NSPrivacyAccessedAPICategoryUserDefaults, NSPrivacyAccessedAPITypeReasons: [CA92.1], // CA92.1 Access info from same app, per documentation }, ], }, },這份配置聲明了應用會訪問UserDefaults這一“需說明理由的 API”類別原因代碼為CA92.1。如果你在原生的ios文件夾中直接修改了涉及這些 API 的邏輯需要在此處補充對應的隱私聲明條目。這也是“直接維護原生代碼”時最容易遺漏、卻可能影響 App Store 審核的環節。manual 工作流 vs Expo CNG為什么不推薦直接改原生Ignite 團隊在 docs/expo/CNG.md 中給出的建議是絕大多數應用都應優先使用 Expo CNG 工作流。它的優勢包括無需直接與 Gradle 和 CocoaPods 打交道升級 React Native 或 Expo SDK 時極為省力因為你不需要繞開自己的原生定制大量流行庫都有現成的 Config Plugin也支持編寫自定義插件來注入原生配置。而 manual 工作流的定位在 docs/expo/DIY.md 中描述得很直白它主要為不想使用 Expo Prebuild、希望自行維護原生代碼的開發者保留。文檔同時揭示了一個實現細節manual 工作流底層仍然是CNG流程——CLI 只是幫你把ios/android文件夾生成出來之后你就不再運行 Prebuild而是直接定制這兩個原生工程所以稱為手動部分。這意味著一旦選擇了 manual 工作流你就承擔起了 CocoaPods 管理、Xcode 工程配置、SDK 升級時的原生適配等全部責任。如果你的應用需要深度原生定制如接入自研原生 SDK、修改原生啟動流程ios文件夾正是你施展的舞臺否則保持 CNG 工作流、讓ios文件夾保持在.gitignore中隨用隨生是更省心的選擇。用 Xcode 運行與調試拿到ios文件夾后運行方式與任意 React Native 項目一致安裝依賴并安裝 Pods在項目根目錄執行pnpm install隨后cd ios pod install或直接使用npx pod-install用 Xcode 打開ios/HelloWorld.xcworkspace注意是 workspace 而非 project因為工程依賴 CocoaPods選擇目標模擬器或已連接的真機真機需配置好開發者簽名與 Bundle ID點擊 Run 構建并啟動應用。針對原生代碼的調試官方文檔建議參考 React Native 原生調試章節使用 LLDB 斷點、查看原生日志等。ios文件夾中的 Swift/Objective-C 文件均可在 Xcode 中直接打斷點調試這與純 JS 層的調試器是互補的兩套工具鏈。通過 EAS 云構建 iOS 包無需本機 Xcode如果你不想在本機折騰 XcodeIgnite 的默認方案是 EASExpo Application Services云構建相關說明見 docs/expo/EAS.md。boilerplate/eas.json 已為 iOS 預置了多檔構建配置development: { extends: production, distribution: internal, ios: { buildConfiguration: Debug, simulator: true } }, development:device: { extends: development, distribution: internal, ios: { buildConfiguration: Debug, simulator: false } }, preview: { extends: production, distribution: internal, ios: { simulator: true } }, preview:device: { extends: preview, ios: { simulator: false } }, production: {}配置要點buildConfiguration: Debug指定 Xcode 構建配置為 Debug便于攜帶開發調試能力simulator: true / false控制構建產物面向模擬器還是真機真機構建需要簽名證書與 Provisioning Profiledistribution: internal產物通過 EAS 內部渠道分發。boilerplate/package.json 中提供了對應的快捷腳本全部通過--local在本機構建pnpm run build:ios:sim # 開發版iOS 模擬器 pnpm run build:ios:device # 開發版iOS 真機 pnpm run build:ios:preview # 預覽版模擬器 pnpm run build:ios:prod # 生產版真機日常本地開發啟動模擬器應用則使用pnpm run ios # 等價于 expo run:ios注意在 CNG 工作流下expo run:ios會在構建前按需執行 Prebuild重新生成ios文件夾而在 manual 工作流下它直接編譯你已維護的ios文件夾。實踐建議與注意事項確認你所在的工作流運行pnpm run prebuild:clean會覆蓋你手工修改的原生代碼因此在 manual 工作流下請謹慎執行該命令提交策略manual 工作流應把ios目錄提交進 GitCLI 已自動從.gitignore中移除/iosCNG 工作流則保持忽略隱私合規無論哪種工作流只要 iOS 原生代碼訪問了 Apple 的“需說明理由 API”都應同步維護 boilerplate/app.config.ts 中的privacyManifests升級路徑CNG 工作流可通過升級 Expo SDK 后重新 Prebuild 獲得最新原生模板manual 工作流則需要手動比對并移植原生改動這也是其維護成本最高的環節。總之ios文件夾是 Ignite 在需要直接掌控原生層時的出口平時安心使用 CNG 讓原生工程隨配置再生真正需要深度定制時再通過 manual 工作流或prebuild:clean把它落地并用 Xcode 或 EAS 完成構建與調試。【免費下載鏈接】igniteInfinite Reds battle-tested React Native project boilerplate, along with a CLI, component/model generators, and more! 9 years of continuous development and counting.項目地址: https://gitcode.com/GitHub_Trending/ig/ignite創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考