-
Perfdog 成本变高之后，Windows 上还能怎么做 iOS APP 性能测试
在不少团队里，Perfdog 曾经是一个顺手就用的性能测试工具。但当项目规模变大、设备数量增多，或者只是想在 Windows 环境下长期跑一些 iOS APP 性能测试时，费用和使用门槛就开始变得现实起来。问题并不是 Perfdog 不好，而是当你真正把它当成日常工具时，会发现它更适合集中式、阶段性的测试，而不是贯穿整个开发周期。主要是太贵了。Windows 环境下做 iOS 性能测试，本身就不轻
-
iOS 安装了证书，HTTPS 还是抓不到
第一次遇到这个问题时，我其实挺笃定的。证书装了、信任也点了、代理设置没问题，按经验来看，HTTPS 理应可以被解密。但现实是，请求能看到，连接能建立，唯独内容始终是空的，或者直接什么都没有。如果你也遇到过这种情况，大概会和我当时一样，下意识认为自己漏了某个步骤。证书这一步，其实并没有想象中关键在 iOS 抓包过程中，安装并信任证书几乎是每个教程都会强调的关键步骤。但在真正场景里，这一步往往只是必要
-
iOS 抓包工具有哪些？不同类型的抓包工具可以做什么
刚开始做 iOS 开发时，我并没有认真思考过“抓包工具有哪些”这个问题。原因很简单，能看到接口请求，能验证返回结果，就够了。但当问题开始只在真机出现，只在部分用户出现，或者只在某些网络环境下出现时，原本熟悉的抓包方式突然变得不可靠，这时才会意识到——并不是所有抓包工具，解决的是同一类问题。代理型抓包工具，仍然是最容易上手的一类在 iOS 开发日常中，代理抓包工具几乎是默认配置。它们适合完成的事情非
-
iPhone APP 性能测试怎么做，除了Instruments还有什么工具？
在不少团队里，iPhone APP 性能测试往往被理解成一个固定动作：版本快发了，跑一遍 Instruments，看下 CPU、内存、有没有明显卡顿。但在真实项目中，性能问题很少在这种“标准流程”里一次性暴露出来。更多时候，它是伴随使用场景逐渐显现的——上线后用户反馈、长时间使用后的异常、或者某些机型上偶发的体验下降。性能测试真正开始的时间点，其实很模糊我参与过的项目里，性能测试很少有一个严格的“
-
Windows 环境下有哪些可用的 iOS 上架工具， iOS 上架工具的使用方式
在 iOS 生态里，Mac 一直被视为默认前提，但在不少团队中，真正长期在线、承担构建和发布工作的机器，反而是 Windows 或 Linux 服务器。这就带来一个很现实的问题，当开发或运维环境不在 macOS 上时，iOS 上架到底还能不能推进？Windows 上架并不是问题，问题是哪些步骤被强制绑定在 Mac 上把 iOS 上架流程拆开来看，其实并非每一步都依赖 Xcode：代码编译：可以发生
-
iOS逆向工程中方法名混淆的完整实现指南
iOS逆向混淆方法名实现指南介绍在iOS开发中，逆向工程是指通过分析已有的应用程序，获取其源代码或者开发过程中使用的技术，从而实现自己的目的。其中，混淆方法名是一种常见的逆向工程技术，通过改变方法名的命名规则，使得逆向工程师难以理解和分析代码。本文将介绍如何实现iOS逆向混淆方法名。流程图journey title iOS逆向混淆方法名实
-
工程师必看，Mac 抓包软件的使用场景
在多数团队里，Mac 更多被当作开发和构建工具使用。直到某次问题只在 macOS 本机上复现，或者某个请求只在 Mac 客户端出现异常，抓包这件事才真正被提上日程。我第一次认真整理 Mac 抓包软件的使用边界，也是从这种只在本机出问题的场景开始的。浏览器与本机请求，是最容易混在一起的在 Mac 上抓包，很容易遇到一个情况，你以为抓的是某个应用的请求，实际上抓到的是浏览器、系统服务、甚至后台更新的流
-
App Store 上架流程中常见的关键问题
如果只看表面，App Store 上架似乎是一件很明确的事情：生成 IPA → 上传 → 等审核。但在真实工程环境中，上架更像是一条被拆散的链路。每一个环节单独看都不复杂，但一旦它们分散在不同工具、不同系统、不同角色手中，问题就会慢慢显现出来。我第一次意识到这一点，是在一次看似“没有任何异常”的发布失败之后。上架之前，应用在体系里的状态必须是确定的在 App Store 的体系中，一个应用并不是因
-
iOS 内存监控中常被忽略的运行期问题
在 iOS 项目里，内存监控经常被当成一件“有问题才去看”的事情。没有明显的 OOM，没有 crash，看起来一切正常，于是很容易被放到后面。但只要你接触过线上反馈，尤其是那种“用久了就慢”“偶尔被系统杀掉”的问题，就会发现：内存问题不是一次性事故，而是一种长期状态。我真正开始系统性关注 iOS 内存监控，并不是因为某次严重崩溃，而是因为太多问题解释不清。内存问题，往往不会在你盯着它的时候出现有一
-
iPhone HTTPS 抓包在真机环境下面临的常见问题
在 iOS 开发中，HTTPS 抓包本来是一件很日常的事情。接口联调、参数确认、返回值校验，代理抓包工具几乎能覆盖大多数需求。但真正让 iPhone HTTPS 抓包变得困难的，往往不是开发阶段，而是问题已经只在真机环境出现的时候。我第一次认真研究 iPhone HTTPS 抓包，也是被这种问题逼出来的。一个看起来不像网络问题的异常那次的问题发生在一个已经稳定运行的功能上。接口没有改动，服务端日志
-
fastlane 与 Appuploader 命令行协作的发布方式
在不少 iOS 项目里，fastlane 几乎是自动化的代名词。它把签名、构建、测试、上传串成一条流水线，让“点一下就发布”成为可能。但在真实工程中，我逐渐发现一个问题，fastlane 擅长的是构建阶段的自动化，而不是所有发布阶段的确定性。当项目开始引入多环境、多系统协作时，单纯依赖 fastlane 往往会遇到一些边界。自动化失败，往往不是工具不行，而是没有划分清楚功能我第一次认真考虑把 fa
-
React Native 混淆在真项目中的方式，当 JS 和原生同时暴露
在 iOS 项目里，只要引入了 React Native，安全讨论就会自然变得复杂。一部分逻辑在 JS 里，一部分在原生层，最终又被打包进同一个 IPA。很多团队一开始会下意识地把“混淆”理解成 JS 侧的问题，但在真正经历过一次逆向或资源替换之后，往往会意识到：React Native 的安全问题，很少只存在于某一层。这篇文章并不想给出一个“React Native 混淆最佳方案”，而是从工程实
-
iOS 崩溃日志的分析方法，将崩溃日志与运行过程结合分析
在 iOS 开发里，崩溃日志几乎是所有问题里“看起来最明确”的一种。它有堆栈、有异常类型、有线程信息，甚至有现成的工具帮你符号化。但真正做过一段时间线上排查之后，你会慢慢发现一个事实：很多崩溃，光看那一份 crash log，其实是不够的。崩溃并不总是发生在问题的起点那次的问题并不复杂：App 偶发闪退，但频率不高，也不集中在某个页面。从 Crash 日志本身来看：堆栈不固定有时是 EXC_BAD
-
苹果应用商店上架App流程，签名证书、IPA 校验、上传
在不少团队里，苹果应用商店上架往往被理解为一个动作：构建完成 → 上传 → 等审核。但真正经历过多次发布的人会发现，上架并不是一个点，而是一段连续的工程过程。很多问题并不会在“上传”那一步暴露，而是更早就已经埋下了伏笔，只是直到审核阶段才被放大。我参与过的项目里，真正影响上架效率的，往往不是某个工具不好用，而是流程中的角色和边界没有被想清楚。上架之前，应用必须先在体系里站得住在 Apple App
-
uni-app 项目在 iOS 上架过程中常见的问题与应对方式
在 uni-app 项目里，开发阶段通常推进得很顺。页面逻辑、接口对接、跨端兼容，一旦跑通，团队很容易形成一种判断：“剩下的就是打包和上架了。”但真正进入 App Store 上架流程后，很多问题才开始出现，而且这些问题往往和 uni-app 本身关系不大。它们更像是 跨端开发与原生发布体系之间的缝隙。uni-app 解决的是开发效率，不是发布复杂度这是我在多个项目中反复确认的一点。uni-app
-
抓包工具有哪些？代理抓包、数据流抓包、拦截转发工具
刚开始做开发时，我对“抓包工具有哪些”并没有太多概念。浏览器有 Network 面板，iOS 有代理抓包工具，看起来已经覆盖了大多数需求。直到有一次问题卡住，我才意识到：并不是我不会用抓包工具，而是我一直在用同一类抓包方式。一个促使我重新整理工具链的场景当时排查的是一个跨端问题：Web 页面正常，App 内 WebView 偶发异常；接口日志完整，但客户端行为不一致。我最初的做法很直觉——换代理、
-
App 加密加固方法在真实项目中的演变
在很多团队的安全实践里，“App 加密加固”一开始往往等同于几行混淆脚本，或者在编译阶段加一点防护逻辑。直到某一天，应用被重签、被改资源、被分析，大家才意识到：问题并不只出在代码有没有被看懂，而是整个 App 太容易被“拿来用”了。这篇文章想从工程实践的角度，讨论 App 加密加固方法在真实项目中是如何一步步演进的，以及为什么越来越多团队会把注意力从源码层，逐渐移向成品包（IPA）层。一、加固需求
-
iOS上架被卡在 4.3条款 怎么办？分析应用被判定为相似应用的常见原因
第一次遇到 4.3 被拒时，我并没有太意外。项目是典型的工具型应用，功能明确、逻辑简单，但审核意见里那句“与 App Store 上已有应用过于相似”，还是让人停下来重新审视整个上架过程。后来几次 4.3 相关的项目让我逐渐意识到：4.3 并不只是在看产品形态，它也在放大工程和发布层面的“相似性”。4.3 并不是单纯的“UI 相似”问题很多讨论 4.3 的文章，会把重点放在界面差异上。但在实际审核
-
安装加固之后的 IPA 如何测试
在 iOS 项目里，加固完成那一刻往往并不是终点，反而是风险真正开始集中的阶段。不少团队第一次做 IPA 加固时，都会有一个直觉判断：能正常安装、能打开首页，应该就没问题了吧？但在后续版本里，这种判断经常会被现实推翻。真正出问题的，往往不是启动，而是某个页面、某个配置、某个只在特定路径下才会触发的逻辑。这篇文章想讨论的，不是“怎么加固 IPA”，而是加固之后该怎么测。一、为什么“加固后的测试”总是
-
苹果 App 上架流程，结合 Xcode、CI 等常见工具
在不少团队里，苹果 App 上架被视为开发流程的终点。功能完成、测试通过，接下来似乎只是把应用提交给 App Store。但真正经历过多次发布的人，往往会意识到：上架并不是开发的收尾，而是一次独立的工程行为。我参与过的项目里，功能复杂度差异很大，但上架阶段遇到的问题却出奇相似。问题很少来自代码，而更多来自 证书、应用标识、构建产物与上传方式之间的错位。上架之前，应用在苹果体系中的身份必须清晰在苹果
