iOS 系統自帶 UITabBar 的五大局限性，為何常需自定義？

官方 UITabBar 的硬性限制

常見自定義方案對比

1. 繼承 UITabBarController + 完全自定義 View：隱藏系統 tabBar (self.tabBar.hidden = YES)，在底部添加自定義 UIView 管理按鈕、指示器、動畫。控制力最強，但需手動處理選中狀態、轉場協調、安全區適配。
2. 使用第三方庫（如 ESTabBarController, CYLTabBarController, RAMAnimatedTabBarController）：封裝好動畫、紅點、L 形、彈出菜單等豐富效果，接入成本低，維護活躍。
3. iOS 13+ UITabBarAppearance 微調：可修改背景圖、陰鬱、選中/未選圖標顏色、字體，**但無法突破結構性限制（高度、項目數、凸起按鈕）**。

決策建議

• 功能入口 ≤ 5 個、無特殊交互、接受系統風格 → 直接用系統 UITabBarController + UITabBarAppearance 美化，最省力。
• 需彩色圖標、自定義高度、中間凸起按鈕、複雜動畫、不等寬佈局 → **必須自定義**，推薦成熟第三方庫或參考其源碼實現核心邏輯。
• App 遷移 SwiftUI：使用 TabView 配合 .tabItem、.toolbar、.background 等修飾符，靈活度大幅提升，但跨平台一致性需測試。

總結

系統 UITabBar 設計初衷是「統一、簡潔、低開發成本」，其局限性正是為了保證 iOS 生態的一致性體驗。當產品設計超出這套規範（尤其是「中間核心入口」模式成為主流後），自定義 TabBar 成為剛需。選擇成熟開源庫可平衡開發效率與維護成本。