通过 Xcode simulator 启动一个模拟器，再加上苹果自家的 UI 测试框架 XTest，走 Accessibility API 读取 App 界面的元素树（按钮/文本框/文本内容），并模拟点击、输入、滚动，这样就可以安全地拿到很多被限制的内容了，例如微信/小红书等内容读取。 之前爬取 Linkedin 内容的时候，被平台检测到，还发出了警告，想到了这个安全的操作，让 AI Agent 尝试了下，确实可行。 iOS Simulator 里跑的是真 Safari / App，发出去的每个请求都带着合法 User-Agent、TLS 指纹，服务端看到的就一普通 iPhone 用户在刷 feed。因此技术上几乎无痕😄

这个项目是可以在模拟器跑app ，不过当时测试多领国正常，跑tg这种项目会闪退

有人发布了一个完全越狱、开源、预构建的 iOS 26 虚拟机 仓库: 这个可以试试

模拟器装不了app，走网页跟playwright连chrome操作比有啥优势

iOS Simulator 是 x86/arm64 模拟器架构（simulator slice），而 App Store 下载的 IPA 是 iOS device slice（真机 arm64）。两者二进制不兼容，所以你没法把微信、小红书这种 App Store 安装的应用直接拖进 Simulator 跑。

感觉最麻烦的还是风控和登录态

the reason most dev tools don't talk about this is that it's not code you're writing, but a new way to think about app interactions. ai and automation are just better at rethinking how we test, not just doing more tests

这个方向很有意思，本质上是在把人的操作界面变成 AI 可用的上下文入口。 我最近做 SocialDataX 也有类似感受：AI 工作流真正卡住的，往往不是 Agent，而是稳定、可复用的数据进入方式。

这个Token花费如何？

这个思路好猛 Xcode simulator + Accessibility API 确实是目前最稳的方案了 服务端看到的就是普通iPhone用户

其实就是ax tree 不解决问题，大部分反爬是服务器端的

卧槽这思路有点东西，LinkedIn 的 detection 确实烦，模拟器跑真 Safari 算是终极解法了

牛B，我准备试试

获取元素树这个方案，还是有局限。我现在开发的Agent是用纯视觉方案。

能拦截网络请求吗

也只能在浏览器里跑吧，不能安装这些APP，倒是也有用。

Accessibility API读元素树这个思路比截图OCR靠谱太多。我们做browser自动化也踩过这个坑——截图+视觉识别延迟高且不稳定，直接读DOM元素树才是正路。Xcode simulator+XTest给CC提供了structured input，模型处理结构化数据的准确度比处理截图高一个量级

期待你测试一下小红书

目前我用maestro跑，但是实在不好用

iOS 模拟器不能装app

安卓simulator的adb 操作不是更成熟？