如何将iOS备忘录文本导出至自有应用？技术实现咨询
你已经确认了功能的可行性，主流应用确实都在用类似方案实现，我来帮你理清UTIs、Extensions、UIActivityTypes的差异，同时解决重复项的问题：
一、核心技术方案对比与最优选择
这三个选项都是iOS内容共享体系里的关键部分，适配场景各有不同：
UTIs（Uniform Type Identifiers）：这是基础中的基础——你得先告诉系统“我的应用能处理备忘录的文本内容”。在主应用的
Info.plist里配置LSItemContentTypes，添加备忘录常用的类型（比如public.plain-text、com.apple.mail-note），让系统知道你的应用是这类内容的接收方。但它只是“资格认证”，还需要配合下面的方案让用户能触发导入操作。Share Extension（应用扩展）：这是让你的应用出现在备忘录分享/导出列表的最优方案，也是Notion、印象笔记这类主流应用的做法。你需要在项目里添加一个Share Extension target，然后在它的
Info.plist里设置NSExtensionActivationRule，明确指定支持的UTI类型（比如只匹配文本）。这样用户在备忘录里点“分享”按钮时，你的应用就会出现在列表里，点击后就能直接把文本传递到你的应用里。UIActivityTypes：这个是用来自定义系统活动的，适合你需要在分享菜单里加一些特殊操作（比如“一键同步到XX”）。但开发成本比Share Extension高，而且用户对Share Extension的认知更贴近“导出/分享”的场景，所以除非你有特殊需求，不然不优先选这个。
总结：优先用「Share Extension + UTIs」的组合，既符合系统交互逻辑，开发成本也低，还能完美匹配你的需求。
二、重复项问题的排查与解决
如果你的应用在备忘录导出列表里重复出现，大概率是这几个原因：
- 同时配置了Share Extension和自定义UIActivity，导致两个入口；
- Share Extension的
NSExtensionActivationRule配置太宽泛（比如匹配了所有类型），系统多次识别； - 测试时多次安装应用/扩展，设备上残留了旧的配置缓存。
解决步骤：
- 检查项目，只保留Share Extension这一种导入入口；
- 收紧
NSExtensionActivationRule的条件，比如用SUBQUERY精确匹配文本类型，示例配置：
<key>NSExtensionActivationRule</key> <string>SUBQUERY (extensionItems, $extensionItem, SUBQUERY ($extensionItem.attachments, $attachment, ANY $attachment.registeredTypeIdentifiers UTI-CONFORMS-TO "public.plain-text").@count >= 1).@count >= 1</string>
- 完全卸载设备上的主应用和扩展，清理Xcode的Derived Data后重新安装测试。
三、实现安全重复导入的小技巧
要做到反复、安全地导入备忘录文本，你可以这么做：
- 在Share Extension接收文本时，基于备忘录的标题、最后修改时间和内容生成一个唯一哈希值（比如用SHA256）；
- 用
App Groups在扩展和主应用之间共享数据，把已导入的哈希值存在共享容器里； - 每次导入前先检查哈希值是否存在，避免重复导入相同内容；
- 如果用户确实需要重复导入，可以在主应用里加一个“允许重复导入”的开关，灵活处理场景。
内容的提问来源于stack exchange，提问作者KRA2008
