'''写这篇文章，是因为经历了一个“被扒源代码”的真实事件。

我们上线了一个 B 端 App，功能不复杂，但涉及几个行业定制协议和组件封装。上线一周后，团队在 GitHub 上偶然发现一个“XX App 教学源码分析”仓库，打开一看，基本把我们项目的架构、命名、核心资源全分析清楚了。虽然不涉及商业机密，但那一刻真的让人后背发凉。

这才意识到：不是我们项目被盯上了，而是任何不上锁的 IPA 都是待宰羔羊。市面上 class-dump、IDA、Hopper 等工具太好用了，哪怕你写得再规范、再干净，也架不住代码暴露得太清楚。

于是我开始研究 iOS 加固方案，走过不少弯路。以下是整理出的几种常见做法和推荐工具，供参考：

1. Plist 精简和属性隐藏

首先检查 Info.plist，这往往是分析者的第一入口。

删掉没必要的字段，隐藏主类路径（Main storyboard name）、第三方 SDK 标识、Scheme 配置等是第一步。可以在 Xcode 的 Build Phase 添加脚本处理，比如自动替换某些字段为默认值或空。

2. 资源图像加密或混淆命名

很多逆向者就是靠资源路径和图片来判断 UI 架构。比如看到 login_icon.png 和 submit_bg@2x.png 就知道你写了哪些页面。

处理方式是写一个小工具，批量重命名并替换资源文件，甚至通过改变 MD5 或编码方式让它们在文件系统中“看起来不同”。

3. IPA 级别的混淆加固工具

代码混淆是重点。OC/Swift 的命名暴露是非常致命的事情，class-dump、Ghidra、IDA 都可以轻松导出类结构和方法名。

这里我试过多个工具，后来稳定用下来的是一个叫 Ipa Guard 的工具。它不需要源码，直接在 IPA 上操作，混淆函数名、类名、变量名，还可以处理图片资源和 plist，最重要的是支持 OC、Swift、Flutter、React Native、H5 几乎所有主流框架。

比如，我测试时原函数名是 -[UserManager loginWithUser:]，混淆后直接变成了 -[XZ93_qL9 xq9_z29:]，class-dump 扫出来完全看不懂了。

它适合做为构建流程的一部分放到自动化管道里，比如 Jenkins 打包完直接调用命令行处理，效率很高。

4. 网络请求加固：反调试 + 签名机制

如果你的 API 调用逻辑也暴露，那很可能还会被别人复用接口。

我们后来在网络层加入了：

• App 签名验证（请求中带唯一 token）
• 时间戳 + 签名校验
• 简单的 AES 加密 Payload·
• 检查是否在越狱设备或模拟器环境下运行

这些虽然不能完全防住，但对于低门槛的抓包和自动脚本工具足够有效。

5. 基本的防调试手段

比如使用 ptrace 阻止调试器附加，检测 DYLD_INSERT_LIBRARIES 环境变量是否被注入，判断是否运行在 Jailbreak 环境等，这些是比较基础的做法，App 安全 SDK 里都有实现，也可以自己通过 runtime 加一层。

我是踩过坑之后才知道：上线不等于安全结束，而是风险的开始。

App 安全不是要追求绝对防御，而是尽可能提高攻击成本。很多人不动你，是因为发现你动起来很麻烦。

我强烈建议每个开发者哪怕资源有限，也至少做一层 IPA 混淆，把最容易被读懂的部分“打乱”。像 Ipa Guard 这种不改源码、上手快的工具，就非常适合在小团队中应用。

如果你也有相关经验或踩过坑，欢迎留言补充，我们一起把这个“容易被忽视但非常必要”的安全环节做得更好。'''

'''作为一名在创业团队里做iOS开发的工程师，我深知时间和效率的价值。我们没有大厂的资源和时间成本去“慢慢调Bug”，但对产品质量和性能的要求却一样不能妥协。

这些年我陆续尝试了很多工具，有些看起来酷炫但实用性一般；也有一些一开始不起眼，但用过后就回不去了。今天分享我真实使用后留下的5个工具，全部实战验证有效，尤其适合团队小、任务紧、节奏快的移动开发者。

1. Instruments（Xcode自带）

很多新手对它望而却步，但Instruments其实是苹果生态里最核心的性能分析工具。像Leaks、Time Profiler、Allocations这些模块，虽然学习曲线略陡，但熟练掌握后，基本能解决80%的性能与内存问题。

不过它的缺点也明显：数据碎片化、保存性差、多人协作不友好。尤其是一些不易复现的问题，经常需要重复采集，工作效率大打折扣。

2. KeyMob（真机性能监控与调试）

这是我们团队近半年用下来评价非常高的一款工具。它不像传统调试工具那样复杂，连接iPhone后就能直接看到包括CPU占用、内存、帧率、磁盘IO、网络波动在内的多维指标。

实例一：线上卡顿问题复盘

有一次线上反馈App在iPhone SE2上打开“图表展示页”有严重卡顿。我们测试了无数次都无法复现。后来通过KeyMob的历史卡顿轨迹记录，发现该页面加载了一个大图片，并且在主线程做了解码操作，才导致老设备加载卡顿。优化后，该问题一次修复。

实例二：数据文件解密

在调试某个数据同步逻辑时，我们需要验证App写入的本地文件内容。KeyMob内置的文件解密与导出工具，让我们直接在Mac上提取目标文件，并解密查看内容结构，快速发现了一个字段命名错误导致的数据未写入问题。

更重要的是，它不需要越狱，UI简洁，几乎没有学习成本。每次上线前我们都会跑一次KeyMob全流程作为稳定性检查。

3. Proxyman & Charles（抓包调试）

iOS的网络抓包工具其实选择不少，但如果你关心界面体验与HTTPS友好度，Proxyman是比Charles更现代的选择。它支持SwiftUI界面调试、自定义断点模拟，还可以协同多个模拟器进行并发测试。

我们经常用它来模拟延迟、请求失败等场景，对于优化异常处理逻辑特别有用。

4. Fastlane（自动打包部署）

手动打包是最不值钱的事情。Fastlane能帮你自动化完成签名、构建、上传TestFlight、发版本邮件提醒等一整套流程。

我们给它加了一个小功能：如果某次打包失败，它会自动在Slack群里发通知，并附上Xcode的build log，省去了重复排查流程。

5. Reveal（UI层级分析）

调UI布局错位、Z-index冲突时，用断点调试简直是折磨。Reveal让你可以像玩3D模型一样查看App界面结构。特别是在处理自定义动画或Popup层叠关系时，它能精准还原真实结构，效率提高不是一点点。

写在最后

工具再多，也只是手段，真正重要的是你在实战中怎么用它们。每个项目的需求不同，但调试、测试、优化这些过程是任何一位开发者都绕不开的。找到合适自己的工具，能节省下来的不仅是时间，更是解决问题的信心和节奏感。

以上这些工具，都是我自己或团队真实在用的。希望这篇文章能为你省下一些反复摸索的时间。如果你也有实用工具，欢迎留言互相交流。'''

华为手机mate 50, 在进行“运行到Android App基座"操作时，打开USB调试后，只有在“选择USB配置”中选择“音频来源”才能成功。

点击进入插件市场

ReferenceError: uni is not defined
at _callee2$ (utils.js? [sm]:21)
at s (regeneratorRuntime.js:1)
at Generator.<anonymous> (regeneratorRuntime.js:1)
at Generator.next (regeneratorRuntime.js:1)
at asyncGeneratorStep (asyncToGenerator.js:1)
at c (asyncToGenerator.js:1)
at asyncToGenerator.js:1
at new Promise (<anonymous>)
at Object.<anonymous> (asyncToGenerator.js:1)
at Object._setSs (utils.js? [sm]:22)(env: Windows,mp,1.06.2409140; lib: 3.8.3)

如果出现这个问题，不要把那些js文件放在static下面
类似我放的那个图，一开始utils文件夹在static目录下，拿出来就好了

'''### 从租云Mac到自动化上传工具，记录一个跨平台开发者避坑苹果生态的真实历程。

我自己是做Flutter开发的，平时项目跑在Android上都很顺利。但要把App上架到App Store时，真的被“苹果生态”这一套整晕了。

你以为发布App只是打包然后上传？不，苹果告诉你——要先买开发者账号，再搞开发证书、发布证书、签名文件，然后你还得用Xcode登录才能传IPA。
我不是没想配台Mac，但对我这种一年发布1-2次iOS应用的开发者来说，这个投入太不划算。

所以我开始尝试各种“非Mac上架方案”，以下是我的真实踩坑与替代路径。

方案一：租用云Mac

很多人第一反应就是：那我租台Mac吧！于是尝试了 MacStadium、MacInCloud 这类服务。

优点：

• 正规Xcode开发环境，100%兼容苹果上传要求
• 可以通过远程桌面登录使用

问题在于：

• 延迟高，上传过程常中断
• 国内访问这些服务不稳定，经常卡死
• 配置开发证书时，有时候操作不当会导致证书丢失，要重头再来
• 按小时计费，成本不低，体验像是在租个情绪化的同事：你不确定它哪一刻会出错

所以除非你是长期需要远程Mac环境的团队，否则不推荐个人开发者尝试。

方案二：找朋友/外包代上架

我一开始也想“蹭一下朋友的Mac”，结果发现：

• 朋友虽然愿意帮忙，但需要我手动导出证书、生成描述文件，还得给他操作文档
• 一出错就是来回截图解释，沟通成本极高
• 而且这种方式缺乏持续性，下一次就不一定找得到人了

方案三：使用自动化上传工具（例如APP开发助手）

后来我无意中在GitHub和博客里刷到了这个工具：APP开发助手。看了下介绍，主要功能有：

• Windows、Linux、Mac三平台支持
• 账号登录、证书生成、p12导出、Profile自动化配置
• IPA签名与上传，一步步图形化界面指引

我第一次用是在一个React Native项目中，整个流程：

1. 填写开发者账号（Apple ID）
2. 添加Bundle ID
3. 获取设备UDID
4. 添加描述文件，下载生成的证书和描述文件
5. 使用HBuilder进行打包操作，上架App Store

全程不到一小时，对比我用云Mac上架App花3小时还失败一次的经历，可以说是极大的提升。

日常分享：

帮客户上线一个工具类App，项目完全在Windows上开发完成。对方只提供了IPA文件和开发者账号。
我用APP开发助手顺利处理完上传。重点是，它还能检测API兼容性和必要性字段（如版本号、Bundle ID），让我避免了一次审核退回。
客户都以为我用了什么神秘工具，其实就是这套流程背后做了智能封装。

总结：适合你的才是“最佳方案”

对于独立开发者、小型团队，App上架是一件重要但又高频度不高的事。没必要为此投入Mac设备或长期云服务。

以下是我个人建议：

iOS上架确实门槛高，但并不是不可逾越。
工具的存在就是为了让流程更平滑。希望这篇文章能给也在为此头疼的开发者一些实际参考。

如果你也有过类似困扰，欢迎留言交流。你是怎么把App发布上App Store的？'''

'''## iOS HTTPS 抓包踩坑记：几种方案尝试与替代工具记录

最近负责一个 iOS App 的调试任务，遇到了 HTTPS 接口抓包难题，顺手做个记录，顺带分享一些试过的工具和方案。

背景

这个 App 启用了 HTTPS 双向认证和证书 pinning，很多传统的抓包方法都失效。起初只是想看看接口返回结构，但发现普通的代理类工具根本看不到请求内容。项目紧急，只能开始四处试工具。

尝试的工具/方案

1. Charles

大家都熟，用了很多年。但这次基本抓不到东西，主要原因是：

• App 拒绝代理连接
• 系统层面有弹窗/信任证书问题
• 部分请求是走私有栈，直接绕过系统代理了

2. Proxyman

UI 比 Charles 好很多，对规则支持也不错，但在 iOS 15+ 上和 Charles 一样，抓包成功率不高。对有 pinning 的应用基本无解。

3. Wireshark

更偏向协议分析工具，不适合实际项目中做应用层调试。偶尔用来查看端口是否真的建立连接。

4. 其他工具

在群里有人提到一个叫 Sniffmaster 的工具。我起初是抱着试一试的心态用的，结果还真能看到 HTTPS 包内容，甚至带 response body。

它的工作机制看起来不是基于代理，而是更底层一点。好处是绕开了 pinning 和描述文件限制，对一些安全防护重的 App 比较友好。

实际测试下来，还能用 JS 写拦截脚本对请求和响应做一些定制化修改，比如模拟服务器故障、响应内容异常等场景，用来测前端兜底逻辑还挺方便。

一个小例子

我们调了一个转账接口，后端返回是这样的：

json复制编辑{  
  "code": "0000",  
  "message": "Success",  
  "balance": 18423.67  
}

用脚本把 balance 改成了负数 + code 改成异常码，重新走了一遍流程，前端果然弹出了兜底页面，顺利验证完毕。

总结

这次的抓包过程还是有不少坑，感触最深的是：

• 模拟器能抓不代表真机能抓
• HTTPS + Pinning 是现在很多 App 的标配，代理类工具逐渐没那么万能了
• 工具没有最好，只有适合自己项目的

建议配置两种类型工具备用：
代理型（如 Charles、Proxyman）用于调试内部测试包
非代理型（如 Sniffmaster）用于应对上架版或安全策略更强的场景

以上是我这次的一点踩坑记录，希望对同样在调 HTTPS 的开发者有帮助。

如果你也有好用的抓包方案或脚本工具，欢迎评论区交流。'''

uniapp 编译为app之后如何监听程序退出/杀死。

​
最近提交上架ios app store 出现这个问题大家是如何解决的？
apple给的错误邮件提示如下：
 

Please correct the following issues and upload a new binary to App Store Connect.

ITMS-90725: SDK version issue - This app was built with the iOS 17.5 SDK. All iOS and iPadOS apps must be built with the iOS 18 SDK or later, included in Xcode 16 or later, in order to be uploaded to App Store Connect or submitted for distribution.

Apple Developer Relations  

我用appuploader提交上架显示成功，但是apple发邮件提示ios sdk版本问题，开发工具是用的uniapp 开发，hbuilder。

开始我以为是appuploader问题，后面发现是hbuilder更新的问题。

解决办法：

更新HBuilder开发工具到最新版本，然后还要执行依赖管理工具，使用下面命令

npx @dcloudio/uvm@latest

要注意的点是这个命令很可能失败，注意用梯子或者选择cn的节点进行，更新成功才行。单独更新hbuilder，不更新依赖管理无法解决这个问题。

​

岗位职责：
1.使用 UniApp 和 Vue 3 开发高质量的多端兼容应用。
2.实现大屏数据可视化界面，能够编写简单的 CSS 动画。
3.利用 ECharts 和 G6 等图表库进行数据可视化。
4.与设计团队紧密合作，确保前端界面美观且符合用户体验标准。
5.优化现有项目的性能，提升用户体验。
6.参与代码审查，确保代码质量和团队协作。

任职资格：
1.本科及以上学历，计算机或相关专业，至少3年以上前端开发经验，特别是使用 Vue 3 和 UniApp 的经验。
2.熟练掌握APP、小程序开发流程，多端兼容优先。
3.熟悉 HTML5, CSS3, JavaScript (ES6+)，有使用 ECharts 和 G6 等数据可视化工具的经验，能够编写简单的 CSS 动画。
4.对 Element Plus、Ant Design、uView 或 iView 有深入理解和实际项目经验。
5.优秀的沟通能力和团队合作精神。

简历请投递：ghn@ruixuejiaoyu.vip

我升级到了最新的稳定版本，然后费劲九牛二虎之力下载了云打包的相关插件（自动提示下载的，一直下载中【估计本机环境问题】......反复操作，折腾下载了24小时），然后最关键的一步：

执行：
npx @dcloudio/uvm@latest

打包后，目前 apple transportor 还没报问题【我点了手动“验证”】，应该不会再报这个错了：

SDK version issue. This app was built with the iOS 17.5 SDK. All iOS and iPadOS apps must be built with the iOS 18 SDK or later, included in Xcode 16 or later, in order to be uploaded to App Store Connect or submitted for distribution. (90725)

官方的ios原生项目简介使用插件工程的做法在XCode16往往会遇到问题
如果你无需开发插件包，而且使用离线打包，那可以跳过很多繁琐的步骤

其实很简单，仅需要在原先离线包中AppDelegate.m所在的目录下添加一个<TestModule>.m文件，引入"DCUniModule.h"， 便可完成

#import <Foundation/Foundation.h>  
// 引入 DCUniModule.h 头文件  
#import "DCUniModule.h"  

@interface TestModule : DCUniModule  

@end  

UNI_EXPORT_METHOD(@selector(init:callback:))  

- (void)init:(NSDictionary *)options callback:(UniModuleKeepAliveCallback)callback {  
    if (callback) {  
        callback(@{@"status": @"initialized"}, NO);  
    }  
}

完成之后用官方教程配置原生插件
这里需要的插件id可以随便选