20
26
2026
Native App 設計工具選型與協作指南
Web-first 工具為什麼不適用 Native App，iOS SwiftUI 和 Android Compose 的正確工具鏈， 以及每個開發階段設計師應該用什麼、交什麼。
這是設計師和工程師最常踩的坑。Claude Design、html.to.design、Anima Agent、Figma Make—— 這些工具生成的都是 HTML / CSS / React。 Native App 需要的是完全不同的東西。
最常見的錯誤路徑
設計師用 html.to.design 或 Figma Make 把 App 設計稿「轉成程式碼」，然後工程師試圖在 iOS/Android 上使用這些 HTML/React 程式碼。這條路行不通。App Store 也會因為「重新包裝的網站」拒絕這類提交。
React ≠ React Native，CSS ≠ StyleSheet。這些是不同的語言體系，不是同一個技術的變體。 Native App 需要的是 SwiftUI（iOS）和 Kotlin Compose（Android）—— 這些語言體系的生成，需要完全不同的工具路徑。
| 工具 | 輸出格式 | Web 可用 | iOS 可用 | Android 可用 |
|---|---|---|---|---|
| Claude Design | HTML / React / Handoff Bundle | ✓ 完整 | ✕ 不適用 | ✕ 不適用 |
| html.to.design / Anima | HTML / React | ✓ 參考用 | ✕ 不適用 | ✕ 不適用 |
| Figma Make | Web App prototype（瀏覽器） | ✓ UX 驗證 | ✕ 不適用 | ✕ 不適用 |
| Google Stitch | HTML / CSS / Tailwind / Vue / Flutter / SwiftUI | ✓ 完整 | △ 參考用（不穩定） | △ Flutter 參考 |
| Visual Copilot | SwiftUI / Kotlin Compose | ✕ 不涵蓋 | ✓ 完整 | ✓ 完整 |
| Figma Dev Mode + Code Connect | React / SwiftUI / Compose（視設定） | ✓ 完整 | ✓ Code Connect 設定後 | ✓ Code Connect 設定後 |
「Web 工具做不到 Native——不是功能不夠，是語言根本不同。理解這個邊界，是 Native App 設計工程協作最重要的第一步。」
iOS 設計的核心挑戰在於：設計稿必須從一開始就以 pt（點）為單位， 而不是 px，並且 Variables 命名必須遵循 iOS 語意色彩體系（label / systemBackground / fill）， 因為這是 Code Connect 輸出正確 SwiftUI 程式碼的前提條件。
FIG.01 · iOS 設計工具鏈概覽
↓ Dev Mode + Code Connect 確保工程師看到真實 SwiftUI 元件，而非通用 CSS
Claude Cowork
Research · 競品分析
建立 Research Project，彙整競品截圖、HIG 規範、用戶洞察。輸出：設計 Brief。
Claude Design
設計探索 · 視覺發散
讀取 DESIGN.md（含 iOS pt 規格），生成 3–5 個互動方向。輸出：Prototype URL 供三方評選。
Anima Agent / html.to.design
Figma 移植工具
把 Claude Design artifact 移植進 Figma。移植後立即替換所有 hardcode → Variables。輸出：Figma 初稿。
Figma Design
iOS 精修 · 設計系統套用
4pt 格線建立、44×44pt touch target、Safe area frame（上 59pt / 下 34pt）、Variables 以 iOS 語意命名、Dark Mode Variables、iOS 26 Liquid Glass 考量。輸出：Handoff Bundle。
Claude Cowork
Spec 交付文件
生成手勢說明（swipe / long press / pinch）、Haptic Feedback 觸發時機、頁面轉場動畫規格（push / modal / sheet）、QA Checklist。輸出：iOS Spec 文件。
Visual Copilot（iOS）
Builder.io · SwiftUI 生成
工程師在 Figma 選取 frame → 三階段 AI 管道（分析 → Mitosis 編譯 → 精調）→ CLI 一鍵插入 Xcode。輸出：SwiftUI 元件程式碼。
Figma Dev Mode + Code Connect
工程師主介面
Dev Mode 顯示真實 SwiftUI 元件使用範例（而非通用 CSS）。label 設定為 'SwiftUI'（注意大小寫）。輸出：真實元件程式碼 + 設計規格。
Figma + Cowork
真機 QA
Cowork QA Checklist 自查通過後進 final review。真機測試：SE / 15 / 15 Pro Max 三種尺寸。Dynamic Type、VoiceOver、Dark Mode 驗證。輸出：上線。
iOS 設計師必知的 Native 規格
SwiftUI Code Connect 設定步驟
Package.swift 加入 Code Connect 依賴：CodeConnect package from Figma。Button.figma.ts。設定 label 為 'SwiftUI'（大小寫完全匹配）——這決定 Dev Mode 顯示哪種語言的程式碼。size: Large）對應 SwiftUI 的 parameter（例如 .large）。Button("Label", action: {}) 形式的 SwiftUI 程式碼，不是 padding: 12px。Android 設計的特殊挑戰來自三個方向：dp 而不是 px（density-independent pixels 確保跨裝置一致性）、 sp 字型單位（支援使用者無障礙字型縮放）、以及 Foldable 裝置的佈局考量—— Galaxy Z Fold 等摺疊螢幕需要展開和折疊兩種完全不同的佈局設計。
FIG.02 · Android 設計工具鏈概覽
↓ Dev Mode + Code Connect label 設定為 'Jetpack Compose' 或 'Kotlin'
Claude Cowork
Research · 競品分析
彙整 Material Design 3 規範、Google Play 政策、Android 用戶習慣研究。輸出：設計 Brief。
Claude Design
設計探索 · 視覺發散
讀取 DESIGN.md（含 Android dp 規格），生成 3–5 個互動方向。輸出：Prototype URL 供三方評選。
Anima Agent / html.to.design
Figma 移植工具
把 Claude Design artifact 移植進 Figma。移植後替換 hardcode → Variables（Material 3 語意命名）。輸出：Figma 初稿。
Figma Design
Android 精修 · 設計系統套用
8dp 格線、48×48dp touch target、WindowInsets 標注（狀態列 24dp / 導航列 48dp）、Material 3 語意 Variables、Dark Mode Variables、Foldable 兩種佈局。輸出：Handoff Bundle。
Claude Cowork
Spec 交付文件
生成 Ripple Effect 觸控反饋說明、Back button / Edge gesture 行為、Navigation 結構說明、QA Checklist。輸出：Android Spec 文件。
Visual Copilot（Android）
Builder.io · Compose 生成
工程師在 Figma 選取 frame → 生成 Kotlin Composable 函數，自動對應 MaterialTheme token，支援不同螢幕密度換算。輸出：Kotlin Composable 程式碼。
Figma Dev Mode + Code Connect
工程師主介面
Dev Mode 顯示真實 Composable 元件使用範例。label 設定為 'Jetpack Compose' 或 'Kotlin'（需確認匹配）。輸出：真實元件程式碼 + 設計規格。
Figma + Cowork
真機 QA
Cowork QA Checklist 自查通過後進 final review。多裝置測試：小/中/大螢幕 + Foldable（展開/折疊兩種狀態）。TalkBack、sp 字型縮放、Dark Mode 驗證。輸出：上線。
Android 設計師必知的 Native 規格
理解兩個平台的規格差異，不只是為了避免錯誤，更是為了理解「同一個設計修改在兩個平台上的影響可能完全不同」。 iOS 的最小格線單位是 4pt，Android 是 8dp——改了一個 spacing 值，對兩個平台的合規性判斷標準是不同的。
| 規格項目 | iOS | Android | 共同點 |
|---|---|---|---|
| 設計單位 | pt（點） | dp（density-independent px） | 都不是 px |
| 格線基準 | 4pt（4/8/12/16/24/32pt） | 8dp（4/8/16/24/32dp） | 都基於 4/8 的倍數 |
| 最小 Touch target | 44×44pt | 48×48dp | 視覺可小，padding 延伸 |
| 系統 UI 保留區 | Safe area（Dynamic Island 59pt / 下 34pt） | WindowInsets（狀態列 24dp / 導航列 48dp） | 都需要 Figma frame 標注 |
| 色彩系統命名 | label / systemBackground / fill |
primary / surface / onPrimary |
都是語意命名，非 hex |
| 字型系統 | SF Pro · Dynamic Type（pt） | Roboto 或品牌字型 · sp 無障礙縮放 | 都不能 hardcode px |
| Code Connect label | 'SwiftUI'（大小寫完全匹配） |
'Jetpack Compose' 或 'Kotlin' |
label 錯誤 = Dev Mode 顯示錯語言 |
| Native 程式碼生成 | Visual Copilot → SwiftUI | Visual Copilot → Kotlin Composable | 同一工具，不同輸出 |
| 多裝置考量 | SE / 15 / 15 Pro Max | 小/中/大 + Foldable（展開/折疊） | 真機測試都必要 |
| 無障礙驗證 | VoiceOver · accessibilityLabel | TalkBack · contentDescription | 都在 Phase H QA 驗證 |
同一個設計修改，兩平台影響不同
iOS 格線是 4pt，Android 是 8dp。如果設計師改了一個 spacing 值，對 iOS 的影響是「這個間距是否還是 4pt 的倍數」，對 Android 的影響是「這個間距是否還是 8dp 的倍數」。這就是為什麼設計修改時對 iOS 和 Android 工程師必須分別通知並確認影響範圍，不能統一一條訊息打發兩個平台。
工具鏈共用的前段流程
FIG.03 · 三平台共用的前段工作流程
↓ Kickoff 後，Web / iOS / Android 進入各自的 Native 開發分支
「Figma 建檔品質是工程效率的天花板。Dev Mode 的輸出品質 100% 取決於設計師的建檔品質——AI 工具無法修補建檔問題，這個問題只存在於設計師的工作紀律中。」
Figma Make 生成的是在 Figma 瀏覽器環境中運行的 Web App prototype。 它不是 native iOS app，也不是 native Android app。 你可以用它來驗證 UX 流程和視覺方向，但不能把它的輸出直接交給 iOS 或 Android 工程師使用。
| 任務 | Figma Make 能做 | 需要另外工具 |
|---|---|---|
| UX 流程驗證 | ✓ 完整支援 | — |
| 視覺方向確認（Web 概念） | ✓ 完整支援 | — |
| 三方 Prototype 評選 | ✓ 分享 Make 連結 | — |
| 移植進 Figma 設計稿 | △ 三條路徑，需精修 | 精修後才能交付 |
| iOS Native 開發 | ✕ 無法直接使用 | Visual Copilot → SwiftUI |
| Android Native 開發 | ✕ 無法直接使用 | Visual Copilot → Kotlin Compose |
| iOS 規格驗證（4pt / safe area） | ✕ Web prototype 無法驗證 | Figma Design + 真機測試 |
| Android Foldable 佈局 | ✕ Web prototype 無法驗證 | Figma Design + 真機測試 |
| SwiftUI / Compose 程式碼輸出 | ✕ 輸出 HTML/React | Visual Copilot 專用路徑 |
Figma Make 在 Native App 流程中的正確位置
Figma Make 在 Native App 開發中的角色是「設計探索的前段工具」——在進入 Figma 精修之前，用來快速生成 UX 流程的視覺概念稿，讓 PM 和工程師有東西可以反應。一旦方向確認，後面的 iOS/Android 精修、規格驗證、程式碼生成都需要完全離開 Figma Make，進入 Figma Design 的精修流程。
最有效的 Figma Make → iOS/Android 工作流程
Figma Make 探索 → Copy design 移植 → Figma 精修（iOS/Android 規格套用）→ Cowork Spec → Kickoff → Visual Copilot 程式碼生成 → Dev Mode + Code Connect → 真機 QA。Figma Make 只在最前面的探索和評選節點。其餘全部是標準的 Native App 開發流程。
這週就可以開始的三件事
更新 DESIGN.md：加入 iOS pt 和 Android dp 規格區塊
把現有 Web CSS token 對照表擴充，加入 iOS 4pt 格線規格和 Android 8dp 格線規格，以及兩平台的語意色彩命名對照。30 分鐘完成。Claude Design 每次啟動時讀取它，確保生成結果在移植進 Figma 後的清理工作最小化。誰做：設計師
與工程師確認 Code Connect 評估計畫
iOS：SwiftUI Code Connect 評估（需 Org/Enterprise 方案，Full seat）。Android：Jetpack Compose Code Connect 評估。估算設定時間成本（約 1–2 週/平台），這是一次性投資但效益永久——設定後每次 Dev Mode 自動顯示真實元件程式碼。誰做：工程師
選一個小功能，走完 iOS 或 Android Checklist 一輪
不要一次導入所有工具。選一個 1–2 個畫面的小功能，從 Phase A 走到 Phase H 的完整流程，感受每個步驟的工作節奏。特別留意 Phase D（Figma 精修）的規格套用——這一步的品質決定 Phase F（Visual Copilot）的輸出品質。誰做：設計師 + 工程師
「Native App 設計不是 Web 設計的延伸，是不同語言、不同規格、不同工具鏈的獨立體系。理解這個邊界，設計師才能在正確的節點選擇正確的工具。」