SwiftUI vs UIKit: Counts From Eight of My iOS Apps

The SwiftUI vs UIKit question gets answered with opinions, and when I had to decide how to write a new screen I wanted to know what I had actually done, so I counted. In the eight iOS apps on my Mac, every one imports both SwiftUI and UIKit, and across the 1,266 Swift files outside test paths, 336 import SwiftUI and 109 import UIKit. The rest of this post is the tally, the UIKit-related types that keep appearing, and what the numbers cannot show.

Updated 2026-10-26. Counts run 2026-10-26. Apple docs quoted: UIViewRepresentable, UIViewControllerRepresentable and UIHostingController, read 2026-10-26.

What I counted

I searched eight iOS app repositories for Swift files, leaving out vendored code, build output, dependency checkouts and any path containing "test". Then I counted files containing the exact text import SwiftUI or import UIKit, and used a text search for type names and for class X: SomeUIKitType declarations. A file that imports a framework is not necessarily mostly written in it, so these are import counts, not a share of the UI code.

In my apps, files importing SwiftUI outnumber files importing UIKit by about three to one, and about half of the UIKit-importing files also import SwiftUI.

Per app, the SwiftUI-importing files ranged from 14 to 69 and the UIKit-importing files from 5 to 31, and no app had zero of either. The same count over the 721 Swift files in test paths gave 93 importing SwiftUI and 47 importing UIKit. I split test from non-test by path name only.

What Apple says connects them

Apple's one-line summaries of the bridging types are short. UIViewRepresentable is "A wrapper for a UIKit view that you use to integrate that view into your SwiftUI view hierarchy." UIViewControllerRepresentable is "A view that represents a UIKit view controller." In the other direction, UIHostingController is "A UIKit view controller that manages a SwiftUI view hierarchy", and its overview says to create one "when you want to integrate SwiftUI views into a UIKit view hierarchy."

So the docs describe mixing in both directions. My 46 files that mention one of the three types do not tell me which direction each one goes. I did not read Apple's guidance on when to prefer one, so I quote none.

Which UIKit-related types appear

Among the 109 non-test files that import UIKit, I counted how many mention each of these names; two are SwiftUI bridging types. Names were matched as plain text, so UIApplication also matches UIApplicationDelegate and UIImage also matches UIImageView. I did not count UIHostingController in this table, and the 46 above is not limited to these 109 files. A file can mention several.

Among the eight types I searched for, application and image types appear in the most UIKit-importing files, ahead of the two bridging types.

That list is a count of names in text. I did not open each UIViewRepresentable file to record what it wraps, so I cannot tell you which UIKit views my apps still need. The 26 files that declare a subclass of a UIKit view, control or view controller show that some UIKit subclasses exist in the code, but I did not check whether they are whole screens, cells or controls, or whether a user can still reach them.

How I use that

In new work I start with SwiftUI and reach for UIKit when the SwiftUI side does not give me what I need, for example the application object or an image renderer, which are the kinds of names in the second table, though that table does not show whether a SwiftUI alternative was available or tried. That is my habit, not a finding from the counts, and eight apps by one developer are not evidence about anyone else's project. If you are deciding for a team, the counts say only that all eight of my apps use both frameworks, and 52 of 1,266 files import both.

For the agent side of working on these apps, see The Agent Taps the Phone. Nothing Touches the Mac. and Xcode MCP: Setting It Up for Claude Code, and What I Saw.

What I did not measure

I did not measure lines of code, screens, build time, performance or crash rates in either framework, and I did not compare minimum iOS versions across the apps. The eight apps are the ones I happen to build, not a sample. Import counts treat a one-line helper and a large screen alike.

Related: Your iOS and Android Apps Are Supposed to Be the Same Product. One of Them Isn't. and Running Multiple Claude Code Agents.