Coder Legion - Recent posts tagged uikit

I open-sourced 5 tiny SwiftUI utilities I use in every project

Mon, 23 Mar 2026 14:37:01 +0000

Sharing 5 lightweight SwiftUI packages I built — keyboard avoider, scroll offset tracker, shimmer effect, flow layout, and App Store review link

Hey everyone! I've been building iOS apps for a while and kept copying the same utilities across projects, so I finally packaged them up as SPM libraries.

1. swiftui-keyboard-avoider

One-line modifier that moves your view when the keyboard appears.

TextField("Email", text: $email)
  .keyboardAvoider()

2. swiftui-scroll-offset

Track ScrollView offset — great for collapsing headers.

OffsetTrackingScrollView { offset in
  print(offset.y)
} content: {
  // your content
}

3. swiftui-shimmer-loading

Shimmer / skeleton loading effect for any view.

Text("Loading...")
  .shimmer()

4. swiftui-flow-layout

Wrapping HStack for tags and chips. Uses the Layout protocol.

FlowLayout(spacing: 8) {
  ForEach(tags, id: \.self) { Text($0) }
}

5. ios-appstore-review-link

Open App Store review page with one line.

AppStoreReview.open(appID: "123456789")

Or grab them all at once: SwiftUI Essentials

All MIT licensed, zero dependencies. Would love any feedback or suggestions!

Magic Beyond Hogwarts: How to Build "Expensive" UI Without Overloading the GPU

Sat, 07 Feb 2026 17:06:01 +0000

You've probably seen this scenario before: a developer falls in love with a concept from Dribbble, spends two days implementing the most complex transition chain, and then wonders why their iPhone 15 Pro starts heating up after five minutes of app usage. Animation is always a deal with the devil (hardware). The question is just how favorable an exchange rate you can negotiate.

The Price of Every Frame: CPU, GPU, and Battery

When we launch an animation, we force the system to work at its limit for a short period of time. In an ideal world (60 or 120 FPS), we have about 8–16 milliseconds to prepare a frame.

CPU (Layout & Preparation): This is where the most "expensive" stuff happens. Recalculating constraints, creating view hierarchies, calculating paths - all of this falls on the central processor's shoulders. If you animate frame or bounds on a view with tons of child elements, expect trouble: the system will call layoutSubviews() at every step.
GPU (Rendering): The graphics chip takes care of rasterization and layer compositing. The main enemies here are transparency (Alpha Blend), blur (Visual Effects), and shadows without a specified shadowPath.
Battery: This is the "invisible" metric. High CPU/GPU Usage directly converts into percentage points of charge. Users might not notice a drop to 55 FPS, but they'll definitely notice that your messenger "ate" 20% of their battery in half an hour.

Implicit Animations: The Magic of `withTransaction`

In SwiftUI, we're used to .animation(.easeInOut, value: target). But sometimes we need finer control over the process, especially when we want to synchronize changes or suppress animation for specific elements.

I prefer using withTransaction for complex transitions. This allows you not just to "turn on" animation, but to pass context: for example, disable animation for a specific change inside the block while preserving it for everything else.

var transaction = Transaction(animation: .spring())
transaction.disablesAnimations = false // Flexible control over the logic

withTransaction(transaction) {
    self.showDetails.toggle()
    // This change will pick up the transaction settings
}

This is much cleaner than trying to wrap every view with its own .animation(). Plus, it helps avoid the "jello effect," when elements fly off in different directions due to conflicting instructions.

UIView.animate vs SwiftUI Animation

If you're still maintaining UIKit projects (or writing wrappers for SwiftUI), the question arises: what to use?

UIView.animate is good old-fashioned classic, working on top of Core Animation. It's predictable. But in SwiftUI, animations are built on a different principle: they depend on state changes (State-driven).

My rule is simple:

If you need to animate CALayer properties (for example, borderWidth or specific masks) - go with UIKit/Core Animation.
If you're working with navigation and content updates in SwiftUI - use native tools.

The main mistake in SwiftUI is animating everything with .animation(.default). Always specify the concrete value (value) that the animation should react to. Otherwise, you risk getting parasitic movements when other screen properties update.

The Cardinal Sin: Layout on Main Thread

The fastest way to kill performance is to force the Main Thread to calculate geometry during animation. When you change constraints inside an animation block, you trigger a heavy recalculation process for the entire tree.

How to do it right: Instead of changing height or width, use CGAffineTransform (in UIKit) or .scaleEffect() / .offset() (in SwiftUI). These properties are handled by the GPU. The system simply takes an already prepared "snapshot" of the view and transforms it without recalculating the positions of neighboring elements.

// Bad: triggers Layout recalculation
view.frame.size.height = 200 

// Good: just a visual transformation
view.transform = CGAffineTransform(scaleX: 1.2, y: 1.2)

Xcode Instruments: The Developer's Eyes

If animation "lags" to the naked eye - you've already lost. But how do you understand why it lags? I run Animation Hitches in Xcode Instruments at least once a week.

Core Animation Instrument: Shows frame rate and, more importantly, "Color Offscreen-Rendered Yellow". If your screen is flooded with yellow - you're forcing the GPU to do double work (for example, rendering masks or shadows without optimization).
Hitch Rate: Apple introduced this term to measure interface "stuttering". A good metric is less than 5 ms/s.

Accessibility: Respect Your User

Remember people who get motion sick from abrupt movements. iOS has a Reduce Motion setting.

Ignoring it is a sign of poor taste and unprofessionalism. If a user asked the system not to move, your full-screen zoom effect should turn into a simple and elegant crossfade.

In SwiftUI, this is done elementarily:

@Environment(\.accessibilityReduceMotion) var reduceMotion

var body: some View {
    Circle()
        .offset(x: moveIt ? 100 : 0)
        .animation(reduceMotion ? nil : .easeInOut, value: moveIt)
}

I always check this flag. Trust me, users with vestibular disorders will thank you (even though you'll never know about it).

The "Sufficiency" Guideline

Polish is cool, but it's easy to turn an app into a Christmas tree. Here are my internal criteria for "healthy" animation:

Duration: Most UI animations should fit within the 0.2 – 0.3 second range. Anything longer starts to irritate with frequent use.
Functionality: Animation should explain where an element came from and where it went. If it's just "for beauty" and doesn't carry meaning - delete it.
Responsiveness: If a user tapped a button, the reaction should be instant. Don't make them wait for an animation to finish to perform the next action (Interruptible animations are everything).

Animation is a balance between art and mathematics. Try right now to open your most complex screen in Xcode Instruments and look at the Hitch Rate. If you see red zones - start by replacing constraint animations with CGAffineTransform.

SwiftUI vs UIKit in 2026: When to Use What

Sat, 24 Jan 2026 16:38:16 +0000

The Myth That SwiftUI Will Replace UIKit

Let's get this straight right away: if someone tells you SwiftUI is the future and UIKit is legacy, don't believe them. Apple itself continues writing critical parts of its apps in UIKit. Open Settings on your iPhone - that's UIKit. Music? UIKit with sprinkles of SwiftUI. Photos? Same story.

Why is this happening? Because SwiftUI, despite all its advantages, can't handle certain tasks as efficiently as UIKit. I've seen projects where teams tried to write everything in SwiftUI "because it's trendy," then spent three months fighting navigation bugs and ended up rewriting in UIKit.

Over the past few years, SwiftUI has grown significantly. The Navigation API got better with NavigationStack and NavigationSplitView. We got proper scroll position tracking support. But the fundamental limitations haven't gone anywhere. When you need pixel-perfect control over layout or complex animation with precise synchronization between elements, SwiftUI starts struggling.

The truth is that in 2026, both frameworks have a right to exist. The question isn't what to choose, but when to use what. And most importantly - do you even need to pick just one?

Where SwiftUI Really Wins

SwiftUI shines when you need to quickly assemble UI from standard components. Declarative syntax isn't just pretty marketing words from Apple, it actually works.

Compare:

// UIKit
let label = UILabel()
label.text = "Hello"
label.textColor = .systemBlue
label.font = .systemFont(ofSize: 16, weight: .bold)
view.addSubview(label)
label.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
    label.centerXAnchor.constraint(equalTo: view.centerXAnchor),
    label.centerYAnchor.constraint(equalTo: view.centerYAnchor)
])
// SwiftUI
Text("Hello")
    .font(.system(size: 16, weight: .bold))
    .foregroundColor(.blue)

The difference is obvious. But it's not just about lines of code.

Live previews in SwiftUI - that's what made me actually fall in love with this framework. When you're writing a registration form and see changes in real-time without rebuilding the project, that saves hours. In UIKit you either launch the simulator every time or struggle with Interface Builder, which periodically breaks storyboards.

Yes, previews crash sometimes. Yes, after an Xcode update they might stop working for a couple days. But when everything works - it's incredibly convenient. You can set up multiple preview configurations with different data, screen sizes, dark/light mode simultaneously. Try doing the same in UIKit - you'll have to either write a playground or create separate view controllers for each case.

Cross-platform development - another SwiftUI ace. The same code works on iOS, macOS, watchOS, and - importantly in 2026 - visionOS. Apple is clearly betting on Vision Pro, and if you want to port your app there without a complete rewrite, SwiftUI gives you a head start.

Real-world example: I made a habit tracking app. The main screen was a list with checkboxes and statistics. Wrote the entire UI in SwiftUI in one day. Then the client asked for a macOS version. Added a couple #if os(macOS) checks to adapt the menu, and done. If this were UIKit, I'd have to write the entire macOS interface from scratch using AppKit.

Here's another point many people miss: state management in SwiftUI is built into the framework. @State, @Binding, @ObservableObject - these aren't just property wrappers, they're a whole philosophy of data management. In UIKit you have to build architecture yourself: MVVM, VIPER, Coordinator pattern. In SwiftUI basic cases work out of the box.

struct CounterView: View {
    @State private var count = 0
    
    var body: some View {
        VStack {
            Text("Count: \(count)")
            Button("Increment") {
                count += 1
            }
        }
    }
}

This code just works. No delegates, target-action, KVO, or notification center. Pressed button - state updated - UI redrawn. In UIKit the same task requires more code and explicit update management.

Personally, I use SwiftUI for:

App settings (forms with toggles, sliders)
Onboarding (five screens with animations between them)
Simple forms (registration, login)
Prototypes that need to be shown to clients in a couple days
Dashboards with charts and statistics
Any new features in existing apps where there are no strict performance requirements

When UIKit Is Still Irreplaceable

UIKit is older, which means more stable. There are no unexpected surprises that SwiftUI loves to deliver in every Xcode release.

Take gestures. SwiftUI has .gesture(), but try doing something more complex than a simple tap - for example, simultaneous pan and pinch recognition with different priorities. In UIKit it's UIPanGestureRecognizer + UIPinchGestureRecognizer with delegates, everything's clear and works predictably. In SwiftUI you'll have to build workarounds through UIViewRepresentable.

I had a project with a custom image editor. Users could zoom photos, rotate them, apply filters in real-time. On SwiftUI this turned into a nightmare. Gesture modifiers conflicted with each other, priorities didn't always trigger correctly. Rewrote it in UIKit in two days, and everything worked like clockwork.

Libraries. Almost the entire powerful iOS ecosystem is written for UIKit. Want to integrate a cool charting library like Charts (not Apple Charts, but third-party)? Most likely it's UIKit. Yes, you can wrap it through representable, but that's an additional layer of abstraction and potential lifecycle problems.

Performance control. In UIKit you know exactly when layout happens, when a view renders, you can optimize layoutSubviews, use drawRect for custom drawing. In SwiftUI the framework decides when to redraw something, and sometimes does it too often.

I encountered a situation where a complex SwiftUI view was redrawing 60 times per second for no visible reason. Profiling showed the problem was implicit state changes - somewhere deep in the hierarchy a @State was updating, and the entire subtree was redrawing. Debugging that was quite the quest. In UIKit this doesn't happen: if a view updates, someone explicitly called setNeedsDisplay or setNeedsLayout.

Another point: memory management. In SwiftUI it's very easy to catch a retain cycle through capturing self in closures. All those @StateObject and @ObservedObject add magic that sometimes doesn't work as you expect. In UIKit everything's explicit: there's weak, unowned, and you know exactly who's holding whom.

Collection views with custom layout. UICollectionView with custom UICollectionViewLayout is an incredibly powerful tool. You can do Pinterest-style masonry grids, circular layouts, complex transition animations between cells. SwiftUI has LazyVGrid and LazyHGrid, but they only cover basic cases. As soon as you need something non-standard - back to UIKit.

Accessibility. Strangely enough, in UIKit the accessibility API is more mature and predictable. In SwiftUI modifiers like .accessibilityLabel() work, but when you start doing something more complex - custom rotor actions, adjustable traits, grouped elements - UIKit gives more control.

I choose UIKit for:

Custom controls with non-standard behavior (slider with non-uniform scale, circular progress with animations)
Apps where every millisecond matters (video editors, games)
Projects with minimum iOS 13-14 (SwiftUI there is too raw)
Complex animations with CALayer and Core Animation
Working with large tables (thousands of rows with good performance)
Integration with complex third-party SDKs

Hybrid Approach: Best of Both Worlds

The most reasonable solution - combine them. Apple itself does this, why shouldn't we? A hybrid approach lets you use SwiftUI where it's convenient and UIKit where it's necessary.

UIKit in SwiftUI via UIViewRepresentable

Say you need a rich text editor in a SwiftUI app. The standard TextEditor is too simple - no formatting, can't change fonts or colors. Ready-made SwiftUI solutions either don't exist or cost money. Take the proven UITextView and wrap it:

struct RichTextEditor: UIViewRepresentable {
    @Binding var text: NSAttributedString
    var placeholder: String
    
    func makeUIView(context: Context) -> UITextView {
        let textView = UITextView()
        textView.delegate = context.coordinator
        textView.font = .systemFont(ofSize: 16)
        textView.backgroundColor = .clear
        textView.textContainerInset = UIEdgeInsets(top: 8, left: 8, bottom: 8, right: 8)
        return textView
    }
    
    func updateUIView(_ uiView: UITextView, context: Context) {
        // Important: only update if text actually changed
        if uiView.attributedText != text {
            let selectedRange = uiView.selectedRange
            uiView.attributedText = text
            // Preserve cursor position
            uiView.selectedRange = selectedRange
        }
    }
    
    func makeCoordinator() -> Coordinator {
        Coordinator(self)
    }
    
    class Coordinator: NSObject, UITextViewDelegate {
        var parent: RichTextEditor
        
        init(_ parent: RichTextEditor) {
            self.parent = parent
        }
        
        func textViewDidChange(_ textView: UITextView) {
            // Update binding only when text changes
            parent.text = textView.attributedText
        }
        
        func textViewDidBeginEditing(_ textView: UITextView) {
            if textView.text == parent.placeholder {
                textView.text = ""
            }
        }
    }
}

It works. But there are nuances. The most important - state synchronization between SwiftUI and UIKit can be painful. Make sure not to create unnecessary updates in updateUIView, otherwise you'll get an infinite redraw loop or lose focus in text fields.

Another example - custom map view with annotations. MKMapView from MapKit works great, but natively it's a UIKit component. Wrap it:

struct MapView: UIViewRepresentable {
    @Binding var region: MKCoordinateRegion
    var annotations: [MKPointAnnotation]
    
    func makeUIView(context: Context) -> MKMapView {
        let mapView = MKMapView()
        mapView.delegate = context.coordinator
        return mapView
    }
    
    func updateUIView(_ mapView: MKMapView, context: Context) {
        mapView.setRegion(region, animated: true)
        
        // Update annotations only if changed
        if mapView.annotations.count != annotations.count {
            mapView.removeAnnotations(mapView.annotations)
            mapView.addAnnotations(annotations)
        }
    }
    
    func makeCoordinator() -> Coordinator {
        Coordinator(self)
    }
    
    class Coordinator: NSObject, MKMapViewDelegate {
        var parent: MapView
        
        init(_ parent: MapView) {
            self.parent = parent
        }
        
        func mapView(_ mapView: MKMapView, regionDidChangeAnimated animated: Bool) {
            parent.region = mapView.region
        }
    }
}

SwiftUI in UIKit via UIHostingController

Reverse task: you have a large UIKit app, but a new settings screen is easier to write in SwiftUI. Or you need to add a beautiful dashboard with charts, and doing it in UIKit is pure hell.

class MainViewController: UIViewController {
    
    func showSettings() {
        let settingsView = SettingsView(onDismiss: { [weak self] in
            self?.dismiss(animated: true)
        })
        
        let hostingController = UIHostingController(rootView: settingsView)
        hostingController.modalPresentationStyle = .formSheet
        
        present(hostingController, animated: true)
    }
}

struct SettingsView: View {
    @AppStorage("notifications") private var notifications = true
    @AppStorage("darkMode") private var darkMode = false
    var onDismiss: () -> Void
    
    var body: some View {
        NavigationView {
            Form {
                Section("Preferences") {
                    Toggle("Enable Notifications", isOn: $notifications)
                    Toggle("Dark Mode", isOn: $darkMode)
                }
            }
            .navigationTitle("Settings")
            .toolbar {
                Button("Done", action: onDismiss)
            }
        }
    }
}

This is simpler than UIViewRepresentable. Main thing - properly handle lifecycle to avoid memory leaks. SwiftUI view inside hosting controller holds strong references to all its @ObservedObject and @StateObject, so be careful with closures.

Another important point: sizing. UIHostingController doesn't always correctly determine its size. If adding a SwiftUI view as a child view controller, explicitly set frame or constraints:

let hostingController = UIHostingController(rootView: mySwiftUIView)
addChild(hostingController)
view.addSubview(hostingController.view)

hostingController.view.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
    hostingController.view.topAnchor.constraint(equalTo: view.topAnchor),
    hostingController.view.leadingAnchor.constraint(equalTo: view.leadingAnchor),
    hostingController.view.trailingAnchor.constraint(equalTo: view.trailingAnchor),
    hostingController.view.heightAnchor.constraint(equalToConstant: 300)
])

hostingController.didMove(toParent: self)

I use a hybrid approach in most projects. The main architecture can be UIKit, but individual screens - SwiftUI. Or vice versa: SwiftUI base, but custom controls through UIViewRepresentable. Main thing - don't obsess over one technology and choose the right tool for the job.

Performance: Numbers, Not Myths

I ran tests on iPhone 15 Pro, iPhone 12 mini, and iPhone SE 2020. Here's what I got.

Startup time:

SwiftUI app (clean project): ~180ms
UIKit app (clean project): ~140ms

SwiftUI is slightly slower on startup due to additional runtime and framework initialization. On new devices the difference is imperceptible, on old ones - you feel it. If your app needs to launch instantly (camera, calculator), every millisecond matters.

Memory footprint: When displaying a list of 1000 elements with images:

SwiftUI List: ~45MB
UIKit UITableView: ~38MB

Again SwiftUI loses, but not critically. The 7MB difference for modern devices with 6-8GB RAM is insignificant. But if you're making an app for emerging markets where users are on old iPhones, those megabytes can become a problem.

Scroll performance: Here it gets more interesting. Complex list with images, text, and buttons:

SwiftUI on iPhone 15 Pro: stable 60 FPS (120 on ProMotion)
SwiftUI on iPhone 12 mini: drops to 45-50 FPS during fast scrolling
SwiftUI on iPhone SE 2020: drops to 40 FPS
UIKit on all devices: stable 60 FPS

SwiftUI works better on new hardware, but if your audience is on old iPhones, UIKit gives more predictable results. The difference is especially noticeable when cells have asynchronous image loading or complex calculations.

Navigation stacks: Deep navigation (7-8 screens) in SwiftUI sometimes glitches - screens don't dismiss correctly, especially with custom transitions or when combining sheets, fullScreenCover, and NavigationStack. In UIKit navigation controller works like a Swiss watch for 15 years already.

Animations: Simple animations (fade, scale, rotation) in SwiftUI are written in seconds and work smoothly:

@State private var isAnimating = false

Circle()
    .scaleEffect(isAnimating ? 1.5 : 1.0)
    .animation(.spring(response: 0.5), value: isAnimating)

Beautiful, simple, works. But try making a complex sequence of animations with dependencies - for example, element A moves, then element B fades in, then both rotate. In SwiftUI you'll have to use withAnimation, DispatchQueue.asyncAfter and pray the timings align.

In UIKit through UIView.animate or CAAnimation you have full control. You can set exact curves, completion handlers, group animations. For simple cases SwiftUI is more convenient, for complex ones - UIKit is more reliable.

Concrete case: Instagram-like feed Made a test: feed with posts (image, author name, likes, comments). 500 posts, scroll through the entire list.

SwiftUI version:

Memory: 65MB
Frame drops: 15-20% on iPhone 12
Code: ~150 lines

UIKit version:

Memory: 52MB
Frame drops: 2-3% on iPhone 12
Code: ~300 lines

UIKit wins on performance but requires twice as much code. What to choose? Depends on priorities. If development speed matters more than the last few percent of performance - SwiftUI. If the app needs to fly even on old hardware - UIKit.

Decision-Making Checklist

Here's how I make decisions for each new feature or project:

Use SwiftUI if:

Minimum iOS version of the project is 15+ (better 16+)
Need a quick prototype or MVP
UI consists of standard components (buttons, text, lists, forms)
Planning to support visionOS, macOS, or watchOS
Team is ready to deal with bugs and unstable API
Performance on old devices isn't critical
No dependency on complex UIKit libraries
Project is new or you can isolate the feature into a separate module

Use UIKit if:

Need to support iOS 13-14 (or even older)
Performance on old devices is critical
Complex custom gestures or animations required
Strong dependency on third-party UIKit libraries
No time for experiments with unstable API
Need pixel-perfect control over layout
Working with large data volumes (thousands of elements)
App needs to be maximally stable (fintech, medicine)

Use hybrid approach if:

Migrating from UIKit to SwiftUI gradually
Have legacy code that works and you're scared to touch it
Different screens have different requirements
Want new features in SwiftUI but base in UIKit
Need custom UIKit components in SwiftUI app
Team knows both frameworks

Red flags for SwiftUI:

Client requires iOS 13 support
App lags even on new devices
Xcode previews haven't worked for a week
Spending more time fighting the framework than on features
Need to integrate 10+ UIKit libraries

Red flags for UIKit:

Writing 500 lines of code for a simple form
Spending an hour on layout constraints for one screen
Junior developer can't figure out storyboards
Every UI change requires full rebuild

Conclusion: It's About Trade-offs, Not Trends

I manage several projects simultaneously. In one - pure SwiftUI, because it's an internal team tool with minimal performance requirements. In another - UIKit with small SwiftUI inclusions for simple screens like settings or onboarding. In the third - pure UIKit, because the client requires iOS 14 support and performance on old devices is critical.

Choosing a framework is about context, not hype. SwiftUI is a great tool for certain tasks. But it's not a silver bullet. UIKit isn't going anywhere for a very long time, and that's okay.

If SwiftUI solves your problem faster and more reliably - use it. If not - don't hesitate to write in UIKit. If you need both - combine them. Your job is to deliver a product that works, not follow trends from conferences.

Final advice: learn both frameworks. Even if you're a SwiftUI fanatic, knowing UIKit will make you a better developer. And vice versa. Understanding how UIKit works under the hood helps write more efficient SwiftUI code. And knowing SwiftUI patterns can improve your UIKit architecture.

In 2026, the best iOS developer isn't the one who only knows SwiftUI or only UIKit. It's the one who knows both and can choose the right tool for the specific task.

UIKit v/s SwiftUI in 2025

Wed, 22 Jan 2025 21:27:46 +0000

Choosing Between UIKit and SwiftUI in 2025: A Practical Guide

If you’re an iOS developer, chances are you’ve wondered whether to use UIKit or SwiftUI for your next project. With SwiftUI gaining traction and UIKit remaining a tried-and-true framework, the decision isn’t always straightforward. In 2025, the choice comes down to your app’s needs, your team’s skills, and where you see your project heading. Let us break it down.

UIKit: The Veteran Framework

UIKit has been around since 2008, forming the backbone of iOS app development for years. It is incredibly reliable and offers all the tools you need to build complex, high-performance apps. However, it does come with a steeper learning curve and requires more manual work.

When to Go with UIKit

Complex UIs: If your app needs intricate layouts, custom animations, or highly specific designs, UIKit’s flexibility is hard to beat.
Older iOS Support: For apps targeting users on older devices, UIKit is the safer choice.
Working with Legacy Code: Updating or extending an existing UIKit-based app? Sticking with UIKit simplifies the process.
Precision Animations: UIKit shines when you need precise control over animations or custom graphics.

Pros

Time-tested and stable.
Extensive documentation and community support.
Advanced debugging tools.
Handles complex UI designs effectively.

Cons

More boilerplate code.
Can feel outdated compared to modern approaches.
Slower development for simple tasks.

SwiftUI: The Future of Apple Development

SwiftUI, introduced in 2019, takes a fresh, declarative approach to building UIs. It simplifies code, integrates smoothly with Combine for reactive programming, and works across all Apple platforms. By now, it is a mature and capable framework, though some advanced use cases might still require UIKit.

When to Choose SwiftUI

Modern App Development: Starting fresh? SwiftUI’s faster development cycle and clean syntax are major advantages.

Prototypes and MVPs: Its simplicity makes SwiftUI perfect for quick prototypes or Minimum Viable Products.
Cross-Platform Apps: If you want to target macOS, watchOS, or tvOS alongside iOS, SwiftUI’s shared APIs are a huge plus.
Future-Proofing: SwiftUI is where Apple’s focus lies, making it a solid bet for the long term.

Pros

Cleaner, more readable code.
Faster development cycles.
Built-in support for responsive and dynamic UIs.
Unified development for multiple platforms.

Cons

Doesn’t support iOS versions below 13.
Some advanced features still need UIKit.
Smaller knowledge base compared to UIKit.
API changes as the framework evolves.

Performance: UIKit vs. SwiftUI

Both frameworks offer excellent performance, but UIKit gives you finer control over details, making it better for demanding tasks like custom graphics. On the other hand, SwiftUI’s declarative nature excels in apps with dynamic data and reactive flows. For mixed projects, combining both frameworks can give you the best of both worlds.

What About Your Team and Goals?

Team Expertise

If your team has a deep UIKit background, you might want to stick with it for complex projects.
Teams already comfortable with Swift and declarative programming will find SwiftUI more intuitive.

Project Goals

If your app needs to support older devices, UIKit is the way to go.
For quick turnaround and future-proof designs, SwiftUI is a better fit.

A Hybrid Approach

In practice, many developers use a mix of UIKit and SwiftUI. SwiftUI views can embed into UIKit projects, and UIKit components can integrate into SwiftUI apps. This flexibility makes it easier to choose the right tool for each part of your app.

Example

Imagine you’re building a modern app with a highly customized camera feature. You could use UIKit for the camera interface while developing the rest of the app in SwiftUI to save time.

Final Thoughts

In 2025, deciding between UIKit and SwiftUI depends on your app’s needs. UIKit remains a workhorse for complex or legacy projects, while SwiftUI is ideal for modern, future-ready apps. Evaluate your requirements, your team’s expertise, and the project’s timeline to make the best choice.

For most new apps, SwiftUI is the way forward. But UIKit isn’t going anywhere, and its reliability makes it a solid choice for many situations. Sometimes, the best approach is combining both frameworks to leverage their strengths.

Whichever you choose, focus on building great apps. The tools are just a means to that end.

Coder Legion - Recent posts tagged uikit

I open-sourced 5 tiny SwiftUI utilities I use in every project

1. swiftui-keyboard-avoider

2. swiftui-scroll-offset

3. swiftui-shimmer-loading

4. swiftui-flow-layout

5. ios-appstore-review-link

Magic Beyond Hogwarts: How to Build "Expensive" UI Without Overloading the GPU

The Price of Every Frame: CPU, GPU, and Battery

Implicit Animations: The Magic of withTransaction

UIView.animate vs SwiftUI Animation

The Cardinal Sin: Layout on Main Thread

Xcode Instruments: The Developer's Eyes

Accessibility: Respect Your User

The "Sufficiency" Guideline

SwiftUI vs UIKit in 2026: When to Use What

The Myth That SwiftUI Will Replace UIKit

Where SwiftUI Really Wins

When UIKit Is Still Irreplaceable

Hybrid Approach: Best of Both Worlds

UIKit in SwiftUI via UIViewRepresentable

SwiftUI in UIKit via UIHostingController

Performance: Numbers, Not Myths

Decision-Making Checklist

Conclusion: It's About Trade-offs, Not Trends

UIKit v/s SwiftUI in 2025

Choosing Between UIKit and SwiftUI in 2025: A Practical Guide

UIKit: The Veteran Framework

When to Go with UIKit

Pros

Cons

SwiftUI: The Future of Apple Development

When to Choose SwiftUI

Pros

Cons

Performance: UIKit vs. SwiftUI

What About Your Team and Goals?

Team Expertise

Project Goals

A Hybrid Approach

Example

Final Thoughts

Implicit Animations: The Magic of `withTransaction`