www.thoughtworks.com
Things to Love and Hate about Swift/SwiftUI
Excerpt
## 8. Hate: There is no natural way to create a design system If you are reusing a default value for padding, text size, etc, there's no real straightforward way to create a design system for that. We’ve looked at the following options: Using modifiers, but these need to be added on every single component. Creating extensions of the classes, but it’s a bit overkill and artificial to only add a few tiny cosmetic changes. Adding style constants in a centralized place and directly applying them where needed. ## 7. Love: Extensions Almost every code that lives in production has some class that’s been inflated beyond reasonable proportions. Especially when you’re working under tight deadlines like it was in our case. Swift's answer to this are extensions: chop your class into smaller parts based on whatever criteria you pick. In our case we’ve cut up a 1000+ line viewModel into bite-sized chunks of 200 lines based on responsibility. … ## 5. Hate: Preview in a legacy project The preview feature won't work on a project that has UIKit implemented. This is because it will need to build the whole project to create the preview, and even then it will sometimes give you errors related to pods. So if you are building SwiftUI over a UIKit project, you should not use the Preview View as it will only make your development slower. … ## 3. Hate: Lack of test support Even the most pragmatic programmer on our team, with more dirty tricks up his sleeve than there are duplicate questions on stackoverflow, was running out of ideas for testing certain functionality. Mocking parts of the code was often virtually impossible, even when using protocols. Unlike with javascript, where you can mock just about anything, with Swift you have to really code with testability in mind. … ## 1. Hate: Features unavailable for “lower” iOS versions We were very surprised that a simple feature like setting the focus on a Textfield via code was not supported in SwiftUI out-of-the-box (Basic support starts from iOS15 and up). The most bugs that we needed to solve revolved around using multiple modals in iOS14 for things such as alerts.
Source URL
https://www.thoughtworks.com/insights/blog/mobile/things-to-love-and-hate-about-swift-swiftUIRelated Pain Points
SwiftUI Preview doesn't work with UIKit legacy projects
6The Preview feature in SwiftUI requires building the entire project and fails with compatibility errors when UIKit is present in the codebase. This prevents developers from using Previews to speed up development in mixed UIKit/SwiftUI projects.
SwiftUI backward compatibility limitations
6SwiftUI requires minimum OS versions (iOS 13+, macOS 10.15+, tvOS 13+, watchOS 6+) and many features only work on newer versions (e.g., TextInput focus on iOS 15+). Projects supporting older OS versions cannot use SwiftUI or must maintain UIKit fallbacks.
Unit testing cannot access private members, forcing code contortions
5Swift's testing model prevents access to private members, forcing developers to contort code and add unnecessary interface elements to enable testing. This is inefficient for bug fixes, feature flagging, and other testing scenarios where private access is warranted.
Difficulty creating design systems in SwiftUI
5SwiftUI lacks a natural, straightforward mechanism for creating reusable design systems. Developers must choose between adding modifiers to every component, creating artificial extensions, or scattering style constants throughout the codebase—none of which are clean solutions.