Understanding SwiftUI: Architecture, Features, and Adoption in Qunar's Large iOS Client

Introduction SwiftUI has been available for two years but has not yet seen large‑scale adoption due to its iOS‑only scope, requirement of iOS 13, and its closed‑source nature. Nevertheless, it offers higher development and runtime efficiency compared with UIKit and Objective‑C, and this article aims to familiarize engineers with SwiftUI for better technology selection and to promote Swift infrastructure in Qunar's large client.

SwiftUI Codebase SwiftUI relies on two underlying frameworks: SwiftUI.framework for UI construction and Combine.framework for data‑flow binding. The article shows a traditional Objective‑C button creation example and its SwiftUI equivalent, highlighting the concise DSL of SwiftUI.

- (void)viewDidLoad {
    CGRect screen = [[UIScreen mainScreen] bounds];
    UIButton *centerBtn = [UIButton buttonWithType:UIButtonTypeCustom];
    [centerBtn setFrame:CGRectMake(screen.size.width/2-30, screen.size.height/2-15, 60, 30)];
    [centerBtn setTitle:@"Test Button" forState:UIControlStateNormal];
    [self.view addSubview:centerBtn];
}

var body: some View {
    Button(){
        Text("Test Button")
            .frame(width: 60, height: 30, alignment: .center)
    }
}

Rendering Process Each SwiftUI view is built by chaining modifier calls (each line starting with a dot) that return a new view. The system recursively assembles these views into a render tree, compares the new tree with the previous one, and only updates the parts that have changed.

Text(self.title)
    .font(Font.system(size: 14))
    .fontWeight(.semibold)
    .foregroundColor(.white)
    .frame(alignment: .center)
    .offset(x: -3.5, y: 2)

Lifecycle Since WWDC 2020, SwiftUI introduces a new application lifecycle that replaces AppDelegate and SceneDelegate . Developers implement the App protocol, provide a SceneBuilder , use scenePhase to monitor scene state, and connect legacy lifecycle methods via UIApplicationDelegateAdaptor . The new lifecycle is wrapped in WindowGroup , simplifying access to lifecycle events and decoupling pages.

Language Characteristics SwiftUI describes UI rather than constructing it, allowing the same code to render differently on iOS, macOS, or watchOS. For example, a Picker appears as a wheel selector on iOS and as a dropdown on macOS, demonstrating platform‑adaptive UI without extra code.

Data State and Binding SwiftUI provides three binding mechanisms:

@State & @Binding – private, simple value storage within a view.

ObservableObject & @ObservedObject – shared state across view hierarchies.

@EnvironmentObject – convenient for “jump‑over” state sharing across many layers.

These property wrappers implement reactive programming concepts, enabling automatic UI updates when the underlying data changes.

SwiftUI Syntax Features Key language features include:

Opaque Return Types – allow functions to hide concrete return types behind protocols (e.g., some Shape ).

Property Wrappers – encapsulate repetitive getter/setter logic with @ syntax.

Function Builders – DSL‑style syntax for building view hierarchies without explicit commas or type annotations.

func reverseGeneric() -> some Shape { return Rectangle(...) }
let x = reverseGeneric() // type(of: x) == Rectangle

VStack(alignment: .leading) {
    Text("Hello, World")
    Text("Longzhao.zhao")
}

Comparison with Other Declarative UI Frameworks The article compares SwiftUI, React Native (RN), and Flutter across syntax, hot‑reload, cross‑platform support, and performance. SwiftUI benefits from Swift 5.1 features like Function Builders, while RN uses JSX and Flutter relies on Dart’s hot‑reload. Performance tests show SwiftUI leading, followed by Flutter and RN.

Hot Reload SwiftUI offers static and dynamic previews; dynamic previews require a compile step and lack the seamless hot‑reload of RN or Flutter. RN’s HMR can cause occasional red screens, while Flutter’s hot‑reload injects updated Dart code into the VM but may fail for certain static or enum changes.

Cross‑Platform & Performance SwiftUI targets Apple platforms (iOS, watchOS, macOS, iOS 14 widgets) and promotes “Learn once, apply anywhere” within that ecosystem. RN and Flutter support broader OSes, including Android, web, and desktop. In intensive UI scenarios, SwiftUI shows the best CPU usage, Flutter is second, and RN lags.

Adoption in Qunar’s Large Client Qunar uses SwiftUI for iOS 14 widgets and several feature pages. The article outlines when to choose Flutter (high‑performance cross‑platform pages), RN (lower‑performance but fast iteration), or native UIKit/SwiftUI (high‑performance pages requiring iOS 13+). It also discusses bridging Swift with existing Objective‑C, RN, and Flutter code.

Objective‑C to Swift/SwiftUI Migration Most Objective‑C APIs have Swift equivalents; some patterns like @synchronized and dispatch_once need custom Swift implementations. Sample Swift utilities for synchronization and one‑time execution are provided.

// Swift synchronized lock
func synchronized(_ lock: AnyObject, block: () -> Void) {
    objc_sync_enter(lock)
    block()
    objc_sync_exit(lock)
}

// Swift dispatch_once
public extension DispatchQueue {
    private static var _onceTokens = String()
    public class func once(token: String, block: () -> Void) {
        objc_sync_enter(self)
        defer { objc_sync_exit(self) }
        if _onceTokens.contains(token) { return }
        _onceTokens.append(token)
        block()
    }
}

Conclusion Swift is now Apple’s strategic language, with increasing Swift‑only frameworks and deprecation of Objective‑C documentation. Qunar plans to expand SwiftUI usage, provide mixed Swift/Objective‑C modules, and build a Swift foundation framework to accelerate migration and improve development efficiency.