以前改 Info.plist，我在文本编辑器里翻键值，改完还得担心 XML 格式对不对；加一张图标，要凑齐一堆尺寸；多语言更麻烦，.xcstrings 和 .strings 混着来，翻译进度全靠自己数。
在 VS Code 里开发 iOS，这类配置工作其实可以少折腾。KXApp 把几类常见文件接到了可视化编辑器上：双击打开就是表格，保存的仍是原文件格式，回到 Xcode 打开一模一样。前提还是那套——macOS、装好 Xcode、用 VS Code 打开工程。
这篇讲这种便捷开发怎么落地：四类文件，四个入口，以及几个容易忽略的细节。
| 要改什么 | 双击哪个文件 | 打开的是 |
|---|---|---|
| Info.plist、权限、隐私清单 | .plist / .entitlements / .xcprivacy |
属性列表 |
| 描述文件里的证书和设备 | .mobileprovision |
属性列表（只读） |
| App 图标、图片、颜色 | .xcassets |
资源目录 |
| Icon Composer 图标 | .icon |
图标文档 |
| 多语言文案 | .xcstrings / .strings / .stringsdict |
多语言 |
| 签名、版本号、Build Settings | project.pbxproj |
工程设置 |
一、Info.plist：为什么要用表格改？
属性列表编辑器是键、类型、值三列的表格，和 Xcode 里的样子接近。右键一行，可以添加行、添加子项、删除、复制键路径；常用键会显示成可读的名字，不用对着原始键名猜。
举个常见的：加一条相机权限说明。表格里添一行 NSCameraUsageDescription，类型选字符串，值写上用途，保存就完事啊。换成手写 XML，得先找对位置，再补 <key> 和 <string> 这一对标签，少一个括号就解析失败。
描述文件 .mobileprovision 也用这个编辑器打开，但是只读：能看到证书、设备列表和权限，改不了。这挺合理，描述文件本来就不该在编辑器里手改。
保存格式默认保持原样，XML 还是二进制都不变；想切换的话，用「plist 保存格式」命令。保存时是否按字母排序键、要不要显示 Root 行、行距多大，分别在 kxapp.plist.sortKeysOnSave、kxapp.plist.showRootRow、kxapp.plist.spacing 里调。
哪天想看原文，右键文件选「以文本方式打开」，或者在编辑器标题栏切换。表格不是唯一的入口，只是更省事的那个。
二、图标和图片：一张 1024 怎么铺满全套？
资源目录 .xcassets 打开后，左边是条目树，右边编辑选中的条目。可以新建 App 图标、图片集、颜色集、数据集、符号图片集和文件夹，把图片拖进对应的槽位。
App 图标支持「用一张 1024×1024 图生成全部尺寸」，一次填满；旧的多尺寸图标也能转成单尺寸图标；visionOS、tvOS 的图标和顶架图同样支持。提交前还能跑一遍编译检查，提前发现缺尺寸、格式不对这些问题。这一步别省，缺尺寸、格式不对，提交时才报出来更麻烦呢。图片集、颜色集、符号图片集这些，新建之后把文件拖进槽位就行，顺手把检查也跑一遍。
还有一个省事的入口：在 Xcode 工程视图里右键 target，选一张图片设为应用图标，工具会自动生成图标并设好 target 的图标名。新建资源目录时，它也会被加进 target 的资源阶段，不用回 Xcode 手动添加。
.icon 是 Icon Composer 的文档，编辑器里能改组、图层和填充，导入图片资源，预览默认、深色、着色几种外观。不是每个项目都有这种文件，遇到了知道它能打开就行。
三、多语言：.xcstrings 和 .strings 能不能一起改？
能。字符串目录 .xcstrings 和传统的 .strings / .stringsdict 会放在同一张表里编辑，每种语言显示翻译进度。
「添加语言」会同时登记到工程的已知语言里，和在 Xcode 里添加一样。「从源码同步字符串」会扫描源码里的本地化调用，把新的 key 加进来；项目里如果有自定义的本地化宏，写在 kxapp.l10n.extraMacros 里，扫描时一起带上。
表里能按复数、按设备变化，处理替换变量，标记需复核 / 已复核 / 不翻译。修改源语言文本时，已有翻译会自动标为「需复核」，这一点和 Xcode 一致，对应设置是 kxapp.l10n.markSourceEditsForReview。
实际改版时，我一般是先在代码里把新文案的 key 写进去，再回来点「从源码同步字符串」，把 key 收进表里，然后按语言填翻译。顺序反过来也行，只是容易漏吧。
翻译量大的项目，这个进度视图比在文件里一行行找 key 直观得多。
四、工程设置：Levels 视图看什么？
打开 project.pbxproj，或者在 Xcode 工程视图里右键工程 / target 选「编辑工程设置」「编辑目标设置」，会进到工程设置页。分 General 和 Build Settings 两页。
Build Settings 按 Xcode 的分组和名字显示，枚举值用下拉框选；可以按 Debug / Release 分别设置，也能添加用户自定义设置。保存时只写你改过的项，提交代码时 diff 很干净，不会因为整份文件重排而看不清改了什么。
Levels 视图是这里最有用的一个：它把 target、工程、xcconfig 和默认值几层同时摆出来，再给一个最终解析出来的值。某个设置为什么不生效，看一眼就知道是被哪一层覆盖了。以前遇到「明明改了 Build Setting 却不生效」，得在 Xcode 里一层层点开看是谁覆盖的。现在这几层摊在一张表里，target 一层、工程一层、xcconfig 一层、默认值一层，基本一眼就能定位嘛。
改工程设置、加资源、加语言都需要 Ruby 的 xcodeproj 组件。第一次用到时插件会提示一键安装，也可以自己运行 gem install --user-install xcodeproj。装过 CocoaPods 的机器一般已经有了。
五、几个容易踩的点
有些操作离不开组件。 纯浏览没问题，但改工程设置、动资源、加语言，得有 xcodeproj。提示找不到 Ruby 时，在 kxapp.rubyPath 里填上路径，确实省得来回翻文档。
保存格式别乱切。 默认保持原格式最稳；把二进制 plist 切成 XML，文件会变大，虽然能用，但没必要。改之前先备份，改坏了还能退回来。
新资源要确认进了 target。 新建资源目录时工具会自动加，但你如果手动搬了目录、或者从别处拷进来，还是回工程视图看一眼资源阶段，别等到打包才发现图片没进去。
它覆盖的是配置和资源这一层。 写代码、跑真机、断点调试、跑测试，走的是另外几个入口；复杂到需要写构建脚本的场景，还是 Xcode 更合适。多人协作时，一次只改一类文件，diff 好读，出问题也好回退。
六、和直接开 Xcode 比一比
Xcode 是这套配置的源头：所有设置它都认识，Interface Builder、Instruments 这些深水区也只在它里面。要在 Mac 上做完整开发，它绕不开。
VS Code 加 KXApp 的价值在于少切窗口：改 plist、换图标、补翻译、调 Build Settings，都在同一个编辑器里完成，旁边就是代码和 AI 助手。改完保存，切回 Xcode 看到的是同一份文件。
命令行也有路：plutil、PlistBuddy 能脚本化改 plist，适合 CI 和批量处理；缺点是复杂结构容易写错，改完还得自己校验。日常手改，表格还是更稳。这些文件都在版本控制里，改完 diff 能看清动了哪几个键，比整份 XML 重排好审得多。
便捷开发不是少写代码，是少在工具之间来回切。四类文件、四个入口，知道哪个文件该双击，配置工作就顺了。配置工作不该占掉写代码的注意力。 按改键值找属性列表，图标和图片进资源目录，多语言开字符串表，签名和 Build Settings 进工程设置。改完不确定的地方，回 Xcode 对一眼，两边本来就是同一份文件。