【fastlane】可以有效地帮助我们简化测试、打包、部署、发布等流程。 只需要完成一些简单的配置，之后我们只需要一行命令即可完成这些常规的重复流程，what a relief ! 话不多说，马上和 Ficow 一起嗨起来吧~

如果您希望大批量导入 TestFlight 测试用户，或者您想邀请测试用户但是又不希望邀请用户到 App Store Connect，您可以考虑添加【外部测试人员】。

想要提前测试即将发布到 App Store 的App？ 【TestFlight】 是你的不二之选。 只需要几分钟，Ficow 让你在新版 App 尚未上架前就试用它。这样，就可以提前发现问题，确认最终的线上版本可以正常工作。 千万不要等到App审核发布之后才发现问题，老板可能会找你促膝长谈喔~

MVC 模式是一个非常经典且精简的设计模式，常见的 iOS 项目基本上都采用了这种模式进行开发。 然而，随着项目规模的增长，MVC 模式已经无法很好地帮助我们解耦，构建一个易维护的项目变得愈发艰难。 业务逻辑愈加复杂，导致项目的代码量剧增是最直接的原因。某个 View Controller 可能会有几千行代码，这样的项目代码易读性非常差，维护难度也会增大。而且，这也容易导致数据的读写不同步，在较为混乱的代码中维护复杂的数据流，非常容易导致盘根错节的问题。 MVP 在 MVC 的基础上采用了面向接口/协议编程，最终使业务逻辑代码更易测试。如果结合 Clean Architecture，还可以有效地减轻我们的思维负担。 接下来，请和 Ficow 一起结合架构图来分析这两种App设计模式吧~

如今，项目中的业务逻辑越来越复杂，代码量也疯狂飙升，某个 View Controller 可能会有几千行代码。这些项目的代码易读性非常差，维护难度也比较大，测试的难度更大！ 如果需要进行人工测试，而且如果App中的运行时状态非常多，就会非常消耗测试人员。 有什么办法可以解决或者至少缓解一下这个问题吗？目前来看，自动化测试是一个最优解。对于开发人员而言，单元测试是最常见的自动化测试，也是比较有效的测试方法。 然而，想写出易测试的代码需要掌握一定的知识和技巧。接下来，请和 Ficow 一起看看如何基于依赖注入和控制反转构建易测试的代码吧~

在发送营销内容前，市场部的工作人员都会设计衡量营销效果的方案。移动互联网时代，推送消息是大多数企业常用的营销手段。 那么，如何衡量推送消息的转化率呢？ 大致的计算方式： 消息接收率 = 成功接收消息的设备数量 / 消息发送量 消息查看率 = 查看消息的设备数量 / 成功接收消息的设备数量 可以看出，成功接收消息的设备数量 是必不可少的参数。所以，要衡量推送消息的转化率，必须要能够准确地追踪【推送消息已接收】事件。

App Extensions 可以有效地扩展应用的使用场景，让用户更便捷地享用我们提供的服务。 某些 App Extensions 相对来说会比较常见，如：Home 页面的小插件(Widget)、分享、富文本推送通知等等。 越来越多的应用开始支持 App Extensions，调试 App Extension 自然必不可少。如何调试并且高效地调试就变成了一个我们需要解决的问题。 可能有朋友会说，在 Scheme 处选中 App Extension，然后直接运行就可以了。 抱歉，这样做是不行的呢！如果您也这样认为，那么 Ficow 建议您去回顾官方文档对 App Extension 的讲解。实际上，App Extension 是不可以作为可执行程序独立运行的，它只能被动地被系统启动。 现在，和 Ficow 来了解一下相关的内容吧~

应用在执行后台任务时，莫名其妙地就崩溃了。登录 Firebase 查看 Crashlytics 控制台，在 crash_info_entry_0 这个 Key 对应的 Value 处看到一个令人困惑的错误：BUG IN CLIENT OF LIBDISPATCH: Unbalanced call to dispatch_group_leave()。 查看了相关的代码，并没有调用 dispatch_group 或相关的方法。好吧，先请强大的 Google 帮帮我~ Google 的搜索结果里面有一条记录是苹果官方的开发者论坛：crash iOS 14 - Unbalanced call to dispatch_group_leave() 其中，GaelPB 的推测观点 是比较接近最终答案的（不过，不正确）。 在此，Ficow 先说明问题的成因： App 在 iOS 14 中执行后台任务时，completionHandler 被多次调用，就会导致崩溃。 这是如何调查出来的呢？问题如何解决呢？希望后文中 Ficow 的 debug 思路能够对您有帮助~

如今，很多App都会在加载数据的时候显示一个加载指示器（旋转菊花？）。然而，有些App经常会处于加载状态，而且加载的时间很长。如果您遇到这种App，您会选择怎么解决这种问题呢？ 1. 换一个更快的网络？ 2. 反馈问题，期待App团队进行改进？ 3. 找到这个App的替代品，卸载这个App？ 我猜，大多数人都会选择最后一个选项。如何避免咱们的App因为网络延迟太久而被用户抛弃，无疑是我们这些App开发人员要面对的一个问题。 别怕，苹果工程师给大家带来了灵丹妙药！来，和 Ficow 一起瞧瞧吧~

如今，在开发 iOS 应用的过程中，我们经常会采用 AutoLayout 来配置页面布局。然而，UIScrollView 这个家伙好像不好驾驭。别担心，Ficow 来陪你一起驯服这只倔驴子！ 只要吃透本文中的几个重要概念，我相信您以后可以游刃有余地使用 AutoLayout 来配置 UIScrollView 的布局。 如果您未曾听说或者使用过 UILayoutGuide 以及 UIScrollView 的 frameLayoutGuide 和 contentLayoutGuide 属性，理解并掌握这些内容对您也会大有裨益。