Five years after SwiftUI shipped, the question every iOS team still asks is: do we go all-in on SwiftUI, stay on UIKit, or mix? In 2026, the answer is clearer than it was — but it’s not a universal "use SwiftUI everywhere". This post is the production decision framework we apply at Schedars.

TL;DR

SwiftUI is the default for new projects targeting iOS 17+. UIKit is the right choice for legacy maintenance, complex camera/AR/Metal code, intricate gesture systems, and multi-window iPad workflows. Most production apps in 2026 are mixed: SwiftUI as the primary layer with UIKit islands where SwiftUI’s gaps still hurt.

SwiftUI strengths in 2026

SwiftUI matured significantly between iOS 16 and iOS 18. The reactive data model is now genuinely productive for typical product UI: lists, forms, navigation, modals, animations. Live previews in Xcode have stopped being a beta feature and become a real iteration accelerator.

What works well

  • Standard UI patterns: lists with diffable updates, forms, navigation stacks, sheets, popovers
  • Animation: implicit animations and transitions are concise and predictable
  • Cross-Apple-platform code: same SwiftUI runs on iPad, Mac, watchOS, visionOS with platform-specific tweaks
  • Accessibility: built-in semantics that VoiceOver respects without extra wiring
  • Dark mode and Dynamic Type: free if you stick to system colours and font styles

SwiftUI weaknesses (still real in 2026)

SwiftUI is not a complete replacement for UIKit. Some real gaps remain — knowing them matters more than pretending they’re solved.

Where SwiftUI struggles

  • Camera and AVFoundation flows: still cleaner in UIKit, especially capture preview overlays
  • Custom complex gestures: SwiftUI gestures conflict with each other in ways UIKit pan/pinch composition doesn’t
  • Performance on long lists with heterogeneous cells: List can hitch where UICollectionView with diffable data sources stays smooth
  • Pull-to-refresh customization beyond default: clunky
  • Deep keyboard handling on iPad with hardware keyboards: requires UIKit fallback

When UIKit makes sense

UIKit isn’t deprecated — Apple still ships UIKit-only APIs in some areas, and the framework has 15 years of accumulated patterns for hard problems. New projects can use UIKit if any of these apply.

Pick UIKit when

  • You’re extending a large existing UIKit codebase — porting just to port is rarely worth it
  • The product is media-heavy: complex camera capture, video editing, AR with custom Metal shaders
  • You have a designer-engineer pair where the engineer is a UIKit expert — speed matters more than future-proofing
  • You’re shipping an iOS-only product where Mac/iPad portability isn’t a goal

Mixing them right

The most common production pattern in 2026 is SwiftUI as the primary layer with UIKit hosted via UIViewRepresentable / UIViewControllerRepresentable for specific screens. The trick is to keep the boundary clean: pass simple value types in, get callbacks out, treat UIKit views as black boxes from the SwiftUI side.

Avoid the inverse pattern (UIKit hosting SwiftUI) unless you have to — UIKit-first apps that bolt on SwiftUI islands tend to accumulate boundary leaks. Hosting SwiftUI inside UIKit is fine for tactical migration, but the long-term architecture should flow the other way.

What we ship at Schedars

Our default for new iOS projects in 2026 is SwiftUI 5+ on iOS 17+ with TCA (The Composable Architecture) for state management on apps over ~15 screens, and plain @Observable for smaller apps. We use UIKit representables for: camera (AVCaptureSession + custom preview), Apple Pay button (PKPaymentButton), and any third-party SDK that ships UIKit views.

On the legacy side, we maintain two UIKit codebases — one is too large to migrate without business case, the other is intentionally UIKit because it’s a video-editing tool with custom Metal pipelines.

Bottom line

Go SwiftUI-first for new product work. Reach for UIKit when you hit a real gap, not because of nostalgia. And accept that mixed codebases are normal — every senior iOS team in 2026 manages a SwiftUI/UIKit boundary, and the discipline is in keeping that boundary intentional.

Planning an iOS app or auditing an existing one? Drop us a line — we’ll be honest about what we’d build in SwiftUI vs where UIKit is still the right call.