企业官网建设流程全解析

我是个写 SwiftUI 的老油条了，平时跟文件打交道的时间不少。今天想聊聊fileImporter这个东西，标题里我用了“越狱沙盒”和“数据偷渡”这两个词，先别急着误解——这可不是让你去搞什么系统漏洞，恰恰相反，我们用的是 Apple 官方开的那扇门，让 App 在严格沙盒规则下，合法、安全地访问用户主动选择的文件。很多初学者一听到“沙盒”就觉得 App 的数据被关进小黑屋了，什么都干不了，但实际上配合系统自带的文档选择器，我们完全可以用一种“看起来像越狱”的方式，把数据从沙盒里“偷渡”出去，或者从外面“走私”进来。这篇文章就是要彻底讲清楚这扇门的结构、钥匙和常见绊脚石，适合所有用 SwiftUI 做 iOS 或 iPadOS 应用，并且需要处理文件导入导出的开发者参考。

1. 沙盒机制与 fileImporter 的定位解析

1.1 iOS 沙盒到底是什么，它锁住了什么

先别急着写代码，我们得先搞清楚对手是谁。iOS 的沙盒机制可以理解成每个 App 都住在一间独立的小房间里，这个小房间就是它的Documents、Library、tmp这些目录。你可以在这个房间里随便折腾，但你不能随便闯进别人的房间，别人也不能随便进你的房间。系统的照片、通讯录、位置这类隐私数据，则像是楼道的公共区域，要进去得经过物业（系统）的同意，也就是权限弹窗。

这个设计从安全角度来说非常优秀。一个恶意 App 不能直接读你微信的聊天记录，也不能翻你备忘录里的日记。但副作用也很明显：如果用户想把一份 PDF 从邮件里存到我们的 App 里，或者想把 App 生成的数据导出给朋友，沙盒默认是不允许的。早期的 iOS 应用开发者想要实现文件共享，得通过各种绕道的方式——比如用UIDocumentInteractionController，或者自己搭服务器用局域网传输，折腾得不行。iOS 8 之后系统提供了UIDocumentPickerViewController，SwiftUI 在 iOS 14 开始也把它封装成了fileImporter和fileExporter，这才算把“在沙盒之间偷运文件”这件事变得既合法又体面。

1.2 fileImporter 的工作流程与权限模型

fileImporter并不是把你的 App 沙盒直接捅破，而是打开一个系统级的文件选择面板。这个面板运行在系统进程里，拥有对整个文件系统的只读访问权（取决于用户选择的位置）。用户选中文件后，系统返回给你一个URL，但这个 URL 并不是我们 App 沙盒内部的路径，而是指向一个外部文件的临时引用。

关键在于：你要通过URL.startAccessingSecurityScopedResource()这个方法，向系统申请对这个外部文件的临时访问权。申请成功后，你才能在当前 App 的内存中读取这个文件的内容。访问完毕后，要调用stopAccessingSecurityScopedResource()释放权限。这个过程在 WWDC 上有个很形象的比喻：系统递给你一张限时参观证，你只能在有限时间内看完画廊里的画，看完就得交还证件。

这个权限模型非常优雅，它既满足了用户“我要把这个文件给那个 App 处理”的需求，又最大限度限制了 App 的越权行为。我们标题里说的“越狱沙盒”，就是通过这种用户主动触发的机制，让 App 短暂地获得了访问沙盒外部文件的能力——而这一切都在系统可控范围内。

1.3 为什么需要这种“合法偷渡”

举个实际的场景：我的一个医疗类 App 需要导入用户从医院拿到的 PDF 检查报告。如果没有fileImporter，用户得先把 PDF 转存到 App 的文件夹里（实际上在 iPhone 上这个操作很反直觉），或者干脆把文件内容复制粘贴到文本框里，体验极差。有了fileImporter，用户直接从文件 App 选中报告，App 就能解析并展示，整个过程两秒钟。

再比如，很多笔记类 App 需要支持导入 Markdown、TXT 文件，或者把内部生成的笔记导出成文件给用户备份。这种双向的文件流转，现在都依赖fileImporter和fileExporter这对姊妹组件。可以说，只要你的 App 有任何“把数据拿进来”或“把数据送出去”的需求，这套机制就是现代 iOS 开发者的必修课。

2. 核心细节与实操要点拆解

2.1 fileImporter 的基本形态与参数含义

SwiftUI 中，fileImporter通常作为一个 View 的 modifier 存在。它的基本签名如下：

.fileImporter( isPresented: $isImporting, allowedContentTypes: [.plainText, .pdf], allowsMultipleSelection: true ) { result in // 处理结果 }

参数不多，但每个都藏着细节：

• isPresented：绑定一个Bool，当你要弹出文件选择器时，把它设为true，选择完成后系统自动置回false。
• allowedContentTypes：一个[UTType]数组，声明你的 App 能接受哪些文件类型。从 iOS 14 开始，UTType取代了老的kUTType字符串，我们可以用.plainText、.pdf、.image、.json这些系统预设类型，也可以自定义。
• allowsMultipleSelection：是否允许多选，默认是false。如果你做批量导入功能，需要打开这个开关。
• result：回调里返回一个Result<[URL], Error>，成功时给你一个或多个选中文件的 URL 数组（即使单选也返回数组，只是里面只有一个元素）。

看起来很简单对吗？但真正写起来，坑都在后面。最容易踩的坑就是拿到 URL 之后，什么都不做直接试着读取文件内容，然后崩溃或读取失败。原因就是忘了申请安全作用域的访问权。

2.2 安全作用域访问：拿到 URL 只是开始

系统返回给你的 URL 指向的是一个“外部”文件，你的 App 默认是没有读取权限的。务必在读取之前调用：

let didStart = url.startAccessingSecurityScopedResource() defer { url.stopAccessingSecurityScopedResource() }

startAccessingSecurityScopedResource()会返回一个Bool，表示你是否成功获得了访问权。一般来说，只要 URL 是从fileImporter合法回调里拿到的，这个值都会是true，但为了健壮性，我们最好检查一下。

这里有一个很经典的错误：在回调里同步调用了startAccessing，然后立刻异步去读文件内容，结果在异步线程里传的 url 是安全的，但忘了在读取前没有申请访问权，因为访问权绑定的是当前线程还是进程呢？

真实答案是：安全作用域访问权绑定的是当前进程，而不是线程。所以你可以在主线程申请，子线程读取，只要不调用stopAccessing就行。但要注意，defer的执行时机是你当前作用域结束的时候。如果你的读取是异步回调，而defer在回调函数结束时已经执行了stop，那么你异步读取时权限已经被释放了。这是最常见的坑之一。

所以推荐的做法是：在回调里同步协调读取数据，或者显式地在异步读取完成后再调用stop。对于大文件，同步读取会卡 UI，我建议先申请权限，然后复制到沙盒内临时目录，再释放权限，之后在沙盒里慢慢处理。

2.3 选择文件类型：UTType 的前世今生

UTType是 Uniform Type Identifier 的 Swift 封装。你可以把它理解成 MIME 类型的升级版，它定义了一套层级化的类型体系。比如.image是一个抽象类型，它包含了.jpeg、.png、.tiff等具体类型。fileImporter的allowedContentTypes支持这种层级关系，你设置.image后，系统面板会允许选择所有符合图片类型的文件。

常用类型速查表：

如果你要支持自定义文件格式，比如你的 App 有专属的.myformat文件，就要在 Info.plist 中声明Imported Type Identifiers，然后通过UTType(exportedAs:)或UTType(importedAs:)来创建对应的 UTType 常量。这块稍微复杂，有兴趣的朋友可以查阅文档，我这里就不展开了。

3. 实操过程：从零搭建一个文件导入导出工具

3.1 需求设定与界面搭建

为了让这篇文章不流于空谈，我们来做一个具体的示例：一个简单的 Markdown 阅读器，支持从“文件”App 导入.md或.txt文件，在界面中展示文本内容；同时支持将当前文本内容导出成一个.txt文件，方便用户备份。

界面结构非常简单：一个NavigationStack，里面放一个ScrollView和Text，展示当前文件的文件名和内容。工具栏上有两个按钮，一个导入，一个导出。我们先定义状态变量：

import SwiftUI import UniformTypeIdentifiers struct ContentView: View { @State private var isImporting = false @State private var isExporting = false @State private var importedFileName: String? @State private var importedContent: String = "还没有导入文件" var body: some View { NavigationStack { VStack(alignment: .leading) { if let fileName = importedFileName { Text(fileName) .font(.headline) .foregroundColor(.secondary) } ScrollView { Text(importedContent) .padding() } } .navigationTitle("MD Reader") .toolbar { ToolbarItemGroup(placement: .topBarTrailing) { Button("导入") { isImporting = true } Button("导出") { isExporting = true } } } .fileImporter( isPresented: $isImporting, allowedContentTypes: [.plainText, .text, .markdown], allowsMultipleSelection: false ) { result in handleImportResult(result) } .fileExporter( isPresented: $isExporting, document: TextFileDocument(text: importedContent), contentType: .plainText, defaultFilename: "export.txt" ) { result in // 处理导出结果 print(result) } } } func handleImportResult(_ result: Result<[URL], Error>) { // 后续实现 } }

注意[.plainText, .text, .markdown]这里我加了一个.markdown类型。实际上.markdown在 iOS 14 之前不是系统预设类型，在 iOS 15 之后才慢慢支持。如果必须兼容旧系统，可以自定义 UTType。我这里只是为了演示，真机测试时.plainText一般就够用了。

3.2 处理导入：安全访问与内容复制

核心逻辑在handleImportResult里。我建议严格按照以下步骤：

1. 从Result中获取第一个 URL。
2. 调用url.startAccessingSecurityScopedResource()。
3. 读取文件内容。
4. 调用url.stopAccessingSecurityScopedResource()。

为了不阻塞 UI，我们可以把读取操作放到后台队列。但注意安全作用域生命周期，我习惯先在主线程申请访问权，然后异步读取，读取完成后再回到主线程更新 UI。伪代码：

func handleImportResult(_ result: Result<[URL], Error>) { switch result { case .success(let urls): guard let url = urls.first else { return } let didAccess = url.startAccessingSecurityScopedResource() defer { if didAccess { url.stopAccessingSecurityScopedResource() } } // 尝试异步读取内容 DispatchQueue.global(qos: .userInitiated).async { [weak self] in do { let content = try String(contentsOf: url, encoding: .utf8) let fileName = url.lastPathComponent DispatchQueue.main.async { self?.importedFileName = fileName self?.importedContent = content } } catch { DispatchQueue.main.async { // 处理错误，比如编码不对 } } } case .failure(let error): print("导入失败: \(error.localizedDescription)") } }

但如果你仔细看，上面的defer是在函数作用域内，也就是说stopAccessing会在函数返回时立刻执行，而异步读取可能还没开始。这在大多数情况下其实也没问题，因为我实测中发现，只要申请过一次访问权，系统会给你一个短暂的“宽限期”，比如几秒钟内异步读取仍然可以访问。但这种行为没有官方保证，属于玄学范畴。为了稳定，我建议把读取动作放在defer之前，即同步读取。

大部分文件都不算大，比如一个几 MB 的文本文件，同步读取几十毫秒就能完成，完全能接受。如果是超大文件（比如几百 MB 的视频），那你可能不应该用String(contentsOf:)处理，而是考虑流式读取。对于文本阅读器这种场景，同步读取是最省心的方案：

func handleImportResult(_ result: Result<[URL], Error>) { switch result { case .success(let urls): guard let url = urls.first else { return } do { let accessing = url.startAccessingSecurityScopedResource() defer { if accessing { url.stopAccessingSecurityScopedResource() } } let content = try String(contentsOf: url, encoding: .utf8) importedFileName = url.lastPathComponent importedContent = content } catch { print("读取失败: \(error.localizedDescription)") } case .failure(let error): print("导入失败: \(error.localizedDescription)") } }

这里有个注意点：String(contentsOf:encoding:)默认要求文件是 UTF-8 编码。如果用户选择的文件是 GBK 或 UTF-16，这里会抛错。我们可以用String(contentsOf:usedEncoding:)让系统自动识别编码，或者用Data(contentsOf:)读取原始字节，然后自己判断编码。我个人更推荐先用Data读取，再通过String(data:encoding:)尝试多种编码，这样兼容性最好。

3.3 文件导出：fileExporter 的文档封装

导出比导入稍微麻烦一点，因为fileExporter需要一个遵循FileDocument协议的类型来封装要写入的数据。我们先定义这个类型：

import SwiftUI import UniformTypeIdentifiers struct TextFileDocument: FileDocument { static var readableContentTypes: [UTType] { [.plainText] } var text: String init(text: String) { self.text = text } init(configuration: ReadConfiguration) throws { guard let data = configuration.file.regularFileContents, let string = String(data: data, encoding: .utf8) else { throw CocoaError(.fileReadCorruptFile) } text = string } func fileWrapper(configuration: WriteConfiguration) throws -> FileWrapper { let data = Data(text.utf8) return FileWrapper(regularFileWithContents: data) } }

这个协议要求你实现两个方法：一个是从文件读入内容时初始化自身，一个是把自身内容编码成FileWrapper以便系统写入文件。我们的例子很简单，就是把文本转成 Data。如果你的文件结构复杂（比如包含图片、附件等），你可以在FileWrapper里创建目录和多个文件，系统会自动帮你打包成一个文件包或目录。

然后在视图中使用：

.fileExporter( isPresented: $isExporting, document: TextFileDocument(text: importedContent), contentType: .plainText, defaultFilename: "export.txt" ) { result in if case .success(let url) = result { print("成功导出到 \(url)") } }

这里有个容易忽略的点：defaultFilename只是默认的文件名，用户在选择位置时可以修改。另外导出的 URL 也是外部 URL，如果你的 App 之后需要继续访问这个文件，同样需要调用startAccessingSecurityScopedResource()。不过导出完成后，这个 URL 一般只是给用户看的，我们自己的 App 不需要保存它，所以通常不需要额外访问。

3.4 复制到沙盒：最稳妥的“偷渡”

上面我们的导入操作是直接读取外部 URL 的内容。这种方式的坏处是：如果用户选择的是 iCloud Drive 里的文件，而文件没有下载到本地（只有占位符），读取时可能需要等待下载，甚至可能失败。而且我们的 App 并没有保存这个文件的副本，下次启动时想再访问同一个 URL，权限早就失效了。

所以更稳妥的“数据偷渡”做法是：把选中的文件复制到我们自己的沙盒目录，以后只跟沙盒副本打交道。示例：

func importAndCopyFile(from url: URL) throws -> URL { let accessing = url.startAccessingSecurityScopedResource() defer { if accessing { url.stopAccessingSecurityScopedResource() } } let documentsDirectory = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first! let destinationURL = documentsDirectory.appendingPathComponent(url.lastPathComponent) // 如果同名文件已存在，先删除旧文件，或者生成唯一文件名 try? FileManager.default.removeItem(at: destinationURL) try FileManager.default.copyItem(at: url, to: destinationURL) return destinationURL }

复制完成后，这个destinationURL就是我们沙盒内的合法文件了。以后想怎么读怎么写都行，不用再申请安全作用域权限。这种方式才是真正把数据“转移到自己的领土”，我强烈建议所有需要长期使用导入文件内容的 App 都采用这个策略。

3.5 多选批量导入的处理技巧

allowsMultipleSelection设为true时，回调里会返回一个 URL 数组。处理逻辑类似，但有几个细节要注意：

• 系统返回的 URL 顺序通常和用户选择顺序一致，但 iOS 并没有在文档中保证，所以如果你需要固定的顺序，应该自己排序，比如按文件名。
• 逐个处理 URL 时，每个 URL 都要单独调用startAccessingSecurityScopedResource()，你不能用一个 URL 的权限去访问另一个 URL。
• 如果文件很多，复制到沙盒时创建了多个副本，建议放在同一个导入目录里，用时间戳或 UUID 生成子目录，避免文件重名。

我习惯把多选导入封装成一个方法，返回一个[URL]（沙盒内副本的 URL），用do-catch保证部分文件失败不影响其他文件导入。

4. 常见问题与排查技巧实录

4.1 拿到了 URL 却读取不到内容

这个问题的九成原因都是没有申请安全作用域访问权。很多新手只看到 URL，就以为可以直接读，结果控制台报错You don’t have permission to access。自查步骤：

1. 检查是否调用了startAccessingSecurityScopedResource()。
2. 检查是否过早调用了stopAccessingSecurityScopedResource()。
3. 检查 URL 是否来自非fileImporter回调（比如你自己拼了个路径，当然不能访问）。

另外还有一种情况：你在模拟器上测试，从 Mac 的文件夹里选了一个文件，模拟器有时候对权限的处理和真机不太一样。如果你发现真机正常、模拟器不正常，或者反过来，可以先把模拟器里的文件应用删掉重装，或者换一台设备试试。

4.2 文件类型明明放在了允许列表里，但灰显不可选

这通常是因为 UTType 不匹配或者系统不知道这个文件属于你声称的类型。比如你允许了.markdown，但用户的.md文件在系统注册为net.daringfireball.markdown，而你没有在 Info.plist 里声明这个类型的导入标识，系统就无法把它和你声明的 UTType 关联起来。

解决办法有两个：

• 使用更宽泛的类型，比如.plainText或.text。
• 在 Info.plist 的Imported Type Identifiers中添加自定义 UTType，并声明对应的扩展名和 MIME 类型。

注意，即使你声明了自定义类型，系统也可能需要重启才能生效。我遇到过改了 Info.plist 但模拟器不认的情况，重启模拟器或杀进程重开就好了。

4.3 fileExporter 导出的文件用户打不开，或者内容乱码

大概率是编码问题。Data(text.utf8)写出来的是 UTF-8 内容，如果用户用旧版记事本打开，默认可能是 ANSI 编码，看到的一堆问号。这时候可以改为导出带 BOM 的 UTF-8，或者导出为 UTF-16。具体要看你的目标用户群体。

另外，如果你导出的文件类型是.pdf或者.rtf，那么FileDocument的内容就必须是完整的 PDF 二进制数据或 RTF 数据，而不是简单的纯文本。很多人想着“我拼个 HTML 字符串，存成.pdf扩展名就行了”，结果生成的 PDF 根本打不开。这是因为文件内容格式和扩展名不匹配。正确做法是使用相应的框架（如 PDFKit、Core Text）真正生成 PDF 数据。

4.4 导入的 iCloud 文件处于“未下载”状态怎么办

当用户从 iCloud Drive 选择一个尚未下载到本地的文件时，startAccessingSecurityScopedResource()可能会触发下载，但下载需要时间。如果你在回调里立即读取，会卡住或者超时。

我的处理方案是：先尝试读取，如果抛错，就使用Coordinator或者NSFileCoordinator来协调读取。简单版代码如下：

let coordinator = NSFileCoordinator() var error: NSError? coordinator.coordinate(readingItemAt: url, options: [], error: &error) { (url) in // 在这个闭包里读取文件 }

用NSFileCoordinator的好处是它会等待文件下载完成，并且处理 iCloud Drive 的并发冲突。不过要注意NSFileCoordinator是 Foundation 的老 API，用起来有点繁琐，但效果很稳。

如果不想这么复杂，还可以在 UI 上提示用户“请先在文件 App 中下载该文件”，但这个体验比较糟糕，我是能避则避。

4.5 安全作用域访问权的生命周期

这个问题是玩家们反复踩坑的地方。简单总结一下：

• 访问权在 App 进程内有效，一旦进程被系统杀掉，你保存的 URL 就失效了。
• 即使 App 没有被杀，App 在后台待久了，这个权限也可能被系统撤销。所以绝对不要长期持有一个外部 URL 的访问权。
• 如果是你的 App 自己通过fileExporter导出的文件，写入完毕后那个 URL 的访问权限也结束了，需要重新申请才能再次访问。

基于这些规则，唯一的长期保存方案就是复制到沙盒。所以如果你有“记住用户最近打开的文件”这种需求，请务必复制文件，而不是存 URL。

4.6 真机调试时的额外注意事项

模拟器上一切正常，真机一选文件就闪退？我遇到过好几次。主要原因通常是你在 Info.plist 里没有配置LSSupportsOpeningDocumentsInPlace或者UIFileSharingEnabled，但这些参数和fileImporter关系不大。更可能的是：

• 你访问了非公开目录，比如试图从FileManager的临时目录或缓存目录读取文件。
• 你选择的文件格式与UTType不匹配，导致系统在导入过程中崩溃。
• 你的 App 使用了扩展（Extension），在扩展里使用fileImporter有额外限制。

调试真机问题，最好用 Xcode 的 Console 查看崩溃日志，不要只看普通的输出日志。崩溃日志会明确告诉你异常类型，比如NSInvalidArgumentException或者沙盒相关的异常。

4.7 处理用户取消选择

用户点了“取消”按钮，Result会返回一个failure，错误类型通常是CocoaError.userCancelled。很多新手会把这个当成真正的错误来处理，弹出一个“导入失败”的提示，用户就会觉得很莫名其妙。

正确处理方式是先判断错误码：

case .failure(let error): if let nsError = error as NSError?, nsError.domain == NSOSStatusErrorDomain, nsError.code == userCancelledErr { // 用户取消了，什么都不做 } else { // 真正的错误 } }

实际上 SwiftUI 的fileImporter在用户取消时，回调可能根本不会被触发？根据我个人测试，取消时result会返回failure，错误域是NSCocoaErrorDomain，错误码是NSUserCancelledError（即 3072）。保险起见，你可以直接捕获所有 failure，然后通过判断是否用户取消来决定是否展示错误。

5. 越狱沙盒的进阶玩法：文件导入与相册联动

因为标题里有“越狱”两个字，我再多分享一个“偷渡”思路。很多人不知道，fileImporter不仅能访问“文件”App 里的文件，如果你在allowedContentTypes里包含.image，系统面板还会自动提供“照片”入口，用户可以直接从相册选择照片。这比使用 PHPicker 的 UI 更统一，但注意它返回的 URL 指向的是临时的图片副本，而不是相册中的原始资源。

这个技巧特别适用于“把图片保存到 App 内部”或者“批量导入图片作为附件”的场景。比如我做过一个知识库 App，允许用户从文件 App 或相册导入多张图片构建一个页面。用fileImporter一把梭，代码量极简：

.fileImporter( isPresented: $isImportingImage, allowedContentTypes: [.image], allowsMultipleSelection: true ) { result in // 复制到沙盒 }

不过有一点要注意：从相册导入的图片，系统可能转换了格式（比如 HEIC 转成了 JPEG），文件后缀名会变。如果要在导入后保留原始格式，最好用PHAssetAPI 结合 PHPicker 来实现，而不是fileImporter。这是另一个话题了。

5.1 fileImporter 与 Drag & Drop 的结合

在 iPadOS 上，fileImporter还可以和dropDestination无缝配合。用户可以从“文件”App直接拖拽文件到你的 App 中，然后你用DropDelegate的performDrop方法接收 URL，处理逻辑和fileImporter一样。区别在于拖拽传入的 URL 是否是安全作用域 URL？我测试的结果是不需要显式申请访问权，因为系统在拖拽时已经赋予了访问权限，但你仍需要调用startAccessingSecurityScopedResource()才能获取稳定的权限。不过不要紧，统一调用一次就行，系统会幂等处理。

这种交互方式在 iPad 上尤其好用，因为用户可以同时打开两个 App，直接把文件从分屏视图里拖过来。相比弹个选择面板，拖拽更高效，也更符合“数据偷渡”那种自由奔放的感觉。但要注意，dropDestination接收的是[URL]或者是Data类型，如果系统把文件内容解析成 Data 传给你，那就没有 URL 了，这时候你也就不需要处理安全作用域权限。

5.2 处理大文件与内存预警

如果你导入的是几百 MB 的视频或设计文件，千万别直接用Data(contentsOf:)全部载入内存。应该使用流式读取，或者复制文件后，用AVFoundation等框架按需读取。

举个例子，我的一个剪辑类 App 支持从文件 App 导入视频素材。导入时我仅仅把文件复制到沙盒，然后记录路径，最后用AVAsset(url:)去加载资源，而不会把整个视频二进制读进内存。这种“延迟加载”的策略可以保证 App 即使处理超大文件也不会爆内存。

5.3 自定义文件类型的导入导出实战

最后聊聊自定义文件格式。如果你的 App 需要导入导出某种私有格式，比如一个带加密的.abc文件。你可以在 Info.plist 中定义：

• UTTypeIdentifier：com.yourcompany.abc
• UTTypeDescription：ABC Archive
• UTTypeConformsTo：public.data
• UTTypeTagSpecification：public.filename-extension->abc

然后在代码里创建对应的 UTType：

extension UTType { static var abcArchive: UTType { UTType(importedAs: "com.yourcompany.abc") } }

之后就能在fileImporter的allowedContentTypes里直接使用.abcArchive了。注意，如果你的自定义类型同时要能被其他 App 识别，最好也注册为Exported Type Identifiers，这样系统才会把这个文件类型与你的 App 关联。否则，其他 App 打开这种文件时可能显示为“无法打开的文件”。

这部分比较繁琐，但却是很多垂直领域 App 的刚需。如果你做的是 GIS、医学影像、音频工程这类行业应用，自定义文件格式的支持一定是绕不开的。

最后再分享一个我自己的习惯。以前我总是在fileImporter的回调里写完所有处理逻辑，导致这个回调函数越来越长，最后变成一坨意大利面。后来我把它抽成了一个单独的FileTransferManager类，专门负责安全作用域访问、复制到沙盒、保存文件到最近列表等操作。视图层只管弹窗和展示结果，文件操作全交给这个管理器。实测下来代码整洁很多，调试也方便。如果你要在一个项目里多个地方用fileImporter，强烈建议也这么做。

这篇文章写得比较长，核心就是一句话：fileImporter是 Apple 给我们开的一扇窗，让我们能在沙盒限制下合法地“偷渡”文件，学会它，你的 App 就拥有了和整个文件系统交互的能力。真机多试试，遇到问题别怕，对照上面说的几个常见坑排查一遍，基本上都能解决。