将数据写入图片，能够达到很好的隐藏信息的目的。看到一些地方有相关的方式，我也尝试了下，然后遇到了问题。Xcode 编译运行后 Products 里面的可执行文件 读取不到我的信息。但是我将工程中的png图片手动覆盖生成的App中的图片后 又能读取到信息了。
很显然这俩文件不一样，但是怎么会不一样呢？
通过比对文件md5 验证了我的想法。 一开始怀疑 Xcode 缓存，通过重新编译排除了。 或者 文件引用路径出了问题 一直在搜索这个文件哪里来的。将工程发给其他机器，编译发现问题依然存在，所以也排除了引用路径的可能
后来同事提醒 Xcode 会对图片进行压缩，恍然大悟。
1、那么 Xcode 会做些什么呢？
Xcode 的 Build Setting 设置里面有一个 Compress PNG Files 的选项, 如果选择了 YES, 那么 Xcode 在编译阶段将会对所有 png 图片进行压缩。
原理摘抄自这里：https://www.cnblogs.com/xitang/p/3905590.html
标准的24bit PNG文件存储方式是按照顺序(红/绿/蓝/透明度)这样来存每一个像素即RGBA，而经过Xcode优化之后的PNG文件像素顺序变成了BGRA，这样的非标准的PNG文件在一般操作系统也就没办法读了。 苹果这么做是有原因的，在OpenGL的wiki有一篇文章 提到了绝大部分GPU的图像/纹理显存每个单元都是24bit的，RGBA和BGRA都有，但BGRA是主流的。 这样就说得通了：苹果为了减少图像运算时花在数据交换（从文件系统到显示出来）的时间，运用了类似DMA的原理，图形数据可以在总线里直接走而不用花掉CPU的时间去协助处理。
它是通过 Xcode 自带的一个工具 pngcrush 来做的. 在这个位置
/Applications/Xcode.app/Contents/Developer/usr/bin
这个工具是开源的
2、Xcode 是根据什么来做这些处理的呢？
由于对于每一个png 图片，在编译阶段进行处理 不可能根据数据内容来处理 如果这样，图片数量多的话 会极大的影响编译速度。我大胆推测是根据图片后缀来处理的
进行验证。果然，将 .png 去掉就没有处理了！
3、在 OSX10.8之前 系统也无法识别压缩后的PNG，会导致 png 无法显示
xcrun -sdk iphoneos pngcrush -revert-iphone-optimizations -q Local.png Local-standard.png
通过这样可以恢复 标准的 png
参考自这里： https://developer.apple.com/library/archive/qa/qa1681/_index.html
Xcode 对于 png 图片的处理 (Compress PNG Files)
原文：https://www.cnblogs.com/lesten/p/14253878.html