SwiftUI First

As an indie developer, my first goal is not to build the most technically complete app.

It is to ship quickly, get it into users’ hands, and find out whether the idea is worth pursuing.

That is why I prefer a SwiftUI-first approach.

SwiftUI is my default for application structure, navigation, state, forms, lists, and shared interfaces across iPhone, iPad, and macOS. It lets me spend less time maintaining platform-specific UI and more time building the product itself.

UIKit and AppKit still matter, but I treat them as tools for specific problems, not as the foundation of every app.

My rule is simple:

Stay in SwiftUI until SwiftUI becomes the bottleneck.

If I need a specialized UIKit control, precise AppKit window behavior, or deeper platform integration, I drop down to the native framework and bridge it back into SwiftUI.

SwiftUI
   ↓
Platform-specific bridge
   ↓
UIKit / AppKit

For an indie product, premature platform complexity is usually a bad trade.

Ship with SwiftUI. Add UIKit or AppKit when the product proves that it needs them.