第一次了解 iOS 开发：从 Swift、SwiftUI 到公共组件

最近实习时，老板让我参与 Web 端功能的 iOS 客户端适配。之前我主要学习后端，也接触过项目的 Web 前端，对 iOS 开发几乎没有了解。看到 Swift 和 SwiftUI 时，连页面是怎样组织起来的都不太清楚。

今天跟着 AI 和官方资料学习了一些基础内容，发现其中不少思路和 Web 前端能对应起来。这篇文章记录我的初步理解，分享给同样没有接触过 iOS 开发的同学。

iOS 客户端开发是做什么

可以先把 iOS 客户端理解成运行在 iPhone 等设备上的应用。它负责展示界面、响应用户操作，并在需要时与后端交换数据。

例如用户在 App 中查看订单，客户端展示页面并发出请求，服务端处理后返回数据，客户端再把结果显示出来。这个过程和 Web 前端请求后端的思路相似，只是页面使用的技术和运行环境不同。

这次接触到的客户端使用 Swift 编写代码，页面采用 SwiftUI。Swift 是编程语言，SwiftUI 是 Apple 提供的界面开发框架；它们解决的问题不同，但经常配合使用。

Swift 和 SwiftUI 分别负责什么

Swift 可以用来定义数据、编写函数、处理业务逻辑和调用接口。SwiftUI 则提供了构建界面的视图、控件和布局方式。Apple 的 SwiftUI 介绍

如果从自己熟悉的 Web 前端来理解，可以做一个不完全等同的类比：

Swift 类似于用来编写应用逻辑的语言。
SwiftUI 的 View 类似于用来组织界面的组件。
SwiftUI 的状态变化可以驱动界面更新，思路上和 React 的状态更新有相通之处。

这些只是帮助入门的类比，具体语法、生命周期和平台能力并不完全一样。

SwiftUI 里的页面是什么样

SwiftUI 常用声明式的方式描述界面：写出界面由哪些视图组成、数据是什么样，再让框架根据状态更新界面。Apple：SwiftUI 入门

下面是一个最简单的页面示例：

swift 复制代码

import SwiftUI

struct WelcomeView: View {
    var body: some View {
        VStack {
            Text("欢迎使用")
            Text("这是一个 SwiftUI 页面")
        }
    }
}

可以先这样看：WelcomeView 是自定义视图，遵循 View 协议；body 描述它显示的内容；VStack 把里面的视图按垂直方向排列；Text 用来显示文字。页面可以由很多视图组合而成，就像 Web 页面可以由多个组件组成。

状态变化如何影响页面

如果页面上的内容会随着用户操作改变，就需要管理状态。例如点击按钮后显示一条提示，可以使用 @State 保存这段页面内部的临时状态：

swift 复制代码

import SwiftUI

struct MessageView: View {
    @State private var showMessage = false

    var body: some View {
        VStack {
            Button("显示提示") {
                showMessage = true
            }

            if showMessage {
                Text("操作完成")
            }
        }
    }
}

初始时 showMessage 为 false，提示不显示；点击按钮后它变成 true，SwiftUI 会更新依赖这份状态的界面。@State 适合保存视图相关的临时状态，不应直接当作持久化存储。需要让子视图读写父视图持有的状态时，可以进一步了解 @Binding。Apple：管理界面状态

为什么要提取公共组件

阅读客户端代码时，我了解到项目提取了一些公共组件，供不同页面复用。这一点和 Web 前端中的组件化很像。

比如多个页面都有样式一致的按钮，如果每个页面都重新写一份，后续调整颜色或间距时，就要检查多个地方。把共同的外观和行为封装起来，再通过参数传入不同文字和点击动作，会更容易保持一致。

下面是一个独立的教学示例，并非公司项目里的真实组件：

swift 复制代码

import SwiftUI

struct PrimaryButton: View {
    let title: String
    let action: () -> Void

    var body: some View {
        Button(title, action: action)
            .padding()
            .background(Color.blue)
            .foregroundColor(.white)
            .cornerRadius(8)
    }
}

struct DemoView: View {
    @State private var message = "等待操作"

    var body: some View {
        VStack {
            Text(message)
            PrimaryButton(title: "确认") {
                message = "已点击"
            }
        }
    }
}

PrimaryButton 接收文字和点击动作；DemoView 决定点击后修改什么状态。这样其他页面也可以使用按钮，并传入自己的动作。示例只是为了说明组件复用，实际项目中应优先使用已有组件和样式规范。

Web 端功能怎么适配到 iOS

"适配"可能有不同含义：有的项目用 SwiftUI 原生实现对应页面，有的在 App 中展示现有网页，也可能两种方式结合。Apple 的 WebKit 可以在应用中显示网页内容；实际采用哪种方式，要看项目已经如何设计。Apple：WKWebView

因此接到需求后，我会先确认：要适配的是哪个功能，现有客户端有没有对应页面和公共组件，数据是否继续使用已有后端接口，以及 iOS 上的交互需要怎样调整。屏幕大小、键盘弹出、导航返回和加载失败提示等，都可能影响实际体验。

我不会因为 Web 页面已经能用，就默认把网页代码复制过去能完成适配。先沿着客户端现有页面看一遍入口、组件和数据流，才能知道这次改动应该接在哪里。

用 AI 学习时，我会怎样验证

这次跟着 AI 了解了不少陌生概念，但生成的代码仍需要放回项目环境检查。我会先让 AI 解释当前文件和公共组件的用途，再根据需求提出小范围修改；之后检查是否复用了现有组件、状态在哪里改变、接口调用是否沿用项目写法。

iOS 开发通常会使用 Xcode 编写、运行和调试，并通过模拟器或设备查看效果。Apple：SwiftUI 入门路径页面展示之外，也要验证按钮、加载状态、异常提示和不同屏幕尺寸下的表现。具体怎么运行和验收，以团队项目的说明为准。

今日总结

今天对 iOS 开发有了一个初步认识：Swift 用来编写应用代码，SwiftUI 用视图组合界面，状态变化可以驱动界面更新。公共组件把重复的界面和行为集中起来，让不同页面可以复用。

现在还只是入门。接下来我想结合实际适配需求，继续弄清客户端页面、公共组件和接口之间的关系。AI 可以帮我解释陌生代码，但每次改动解决了什么、怎样验证，还是需要自己弄明白。