iOS开发：可否写入文件到App Bundle？如何统一管理多路径PDF资源

云原生阿岚

2026-9-3

核心规则与方案评估

iOS的App Bundle属于只读签名区域，任何尝试向Bundle内写入文件的操作都会直接运行失败，也会导致App Store审核被拒，绝对不要尝试往内置的ThePDFs目录写外部下载的PDF。
你提到的「首次启动将Bundle内PDF拷贝到Documents目录，后续统一从Documents读写」的方案是可行的，但存在明显缺点：内置PDF会同时在Bundle和Documents存两份，平白浪费一倍存储空间，且每次App更新内置资源后都要做增量拷贝逻辑，维护成本高。
你目前尝试的「Plist存储歌曲元数据+对应文件路径」的方案是更优选择：不需要移动现有内置文件，不会产生冗余存储，也不受文件实际存储位置限制，不管是Bundle内的内置PDF还是后续下载到Documents的PDF，都可以在同一个列表里统一展示，还可以扩展更多元数据字段。

当前代码报错原因

你遇到的NSDictionary initWithObjects:forKeys:]: count of objects (0) differs from count of keys (1)崩溃，由几个明确的逻辑错误导致：

变量名冲突：你先定义了Plist的存储路径名为path，后续遍历Bundle内PDF资源的循环中，又把单个PDF的遍历变量命名为path，循环内部的path会覆盖外层的Plist路径，导致路径读取完全错乱。
空值问题：首次运行时Plist文件不存在，你初始化的空字典里没有Questions对应的数组字段，直接调用objectForKey:@"Questions"拿到的是nil，向nil发送addObject:消息不会产生任何效果，后续构造字典时传入空值，就会出现对象数量和key数量不匹配的错误。
数据结构错误：你遍历歌曲名数组时，每次循环都把整个names数组塞到单条歌曲字典里，而不是当前遍历到的单个歌曲名+对应PDF路径，数据结构完全不符合预期。
冗余操作：构造完Plist内容后直接调用writeToFile:atomically:即可写入，不需要额外走NSPropertyListSerialization转成NSData再写，多一层操作就多一层出错概率。

修正后的实现代码

// 1. 定义Plist存储路径，注意变量名不要和后续循环变量冲突
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths firstObject];
NSString *plistPath = [documentsDirectory stringByAppendingPathComponent:@"mastersonglist.plist"];
NSFileManager *fileManager = [NSFileManager defaultManager];

// 2. 初始化Plist数据，不存在则创建带空歌曲数组的基础结构
NSMutableDictionary *songListData;
if ([fileManager fileExistsAtPath:plistPath]) {
    songListData = [[NSMutableDictionary alloc] initWithContentsOfFile:plistPath];
} else {
    songListData = [NSMutableDictionary dictionary];
    // 提前初始化歌曲数组，避免后续取到nil
    [songListData setObject:[NSMutableArray array] forKey:@"Songs"];
}
NSMutableArray *songArray = [songListData mutableArrayValueForKey:@"Songs"];

// 3. 仅在首次启动Plist为空时，读取Bundle内的内置PDF写入列表，避免重复添加
if (songArray.count == 0) {
    NSBundle *bundle = [NSBundle mainBundle];
    NSArray *bundlePDFPaths = [bundle pathsForResourcesOfType:@"pdf" inDirectory:@"thepdfpowerpoints"];
    
    for (NSString *singlePDFPath in bundlePDFPaths) {
        NSString *songName = [[singlePDFPath lastPathComponent] stringByDeletingPathExtension];
        // 单条歌曲结构：存名称、路径、来源标记，后续可以扩展更多字段
        NSDictionary *songItem = @{
            @"name": songName,
            @"filePath": singlePDFPath,
            @"source": @"bundle"
        };
        [songArray addObject:songItem];
    }
    // 直接写入Plist即可
    [songListData writeToFile:plistPath atomically:YES];
}

// 后续新增云端下载歌曲的逻辑：
// 1. 把下载的PDF存到Documents下自定义的DownloadedPDFs子目录
// 2. 构造对应songItem：name填歌曲名，filePath填下载后的本地路径，source标记为@"cloud"
// 3. 将新的songItem加入songArray，重新写入Plist即可在列表中展示

额外优化建议

TableView的数据源直接使用Plist读取到的歌曲数组即可，不需要每次启动遍历文件系统，加载速度更快，后续做搜索、排序、分组只需要操作这个数组就行。
可以给歌曲条目扩展实用字段：比如唯一ID、歌手/分类标签、云端版本号、是否收藏、下载时间，后续功能扩展不需要改动存储结构。
云端下载的PDF统一存到Documents下的自定义子目录，不要散落在Documents根目录，方便后续做缓存管理，同时可以给这个目录设置不备份属性，避免占用用户iCloud空间导致审核被拒。
当前450首+后续增量的量级用Plist存储完全足够，如果后续歌曲量超过千级，再考虑换成SQLite存储元数据即可，不需要一开始就上复杂的数据库方案。

内容的提问来源于stack exchange，提问作者user717452