Storyboard是用于开发iOS、macOS、tvOS和watchOS用户界面的非常有用的工具。它除了提供一种用auto layout进行可视化布局界面的方法之外，还提供了一种构建和查看视图控制器之间的导航和关系的方法。如果使用得当，它们可以极大地简化和减少开发人员在项目中进行交互所需的代码量。那么为什么不是所有的开发者都使用storyboard呢？
不使用storyboard的一个被提及的最多的原因就是合并冲突。在一个团队中，如果多人同时使用一个storyboard，这种情况下，合并冲突是一种常见现象，这足以阻止在团队中使用storyboard。而且storyboard是机器生成的XML，合并冲突难以诊断和解决。但是，很多情况下，并不一定非要这样做。
有五种常见情况，在storyboard中经常遇到合并冲突。这篇文章将详细介绍这些内容，以描述合并冲突是如何发生的，如何避免以及如何解决它们。
在Swift中，我们有引用类型（比如：类）和值类型（比如：结构体、元组、枚举）。值类型具有复制语义。这意味着如果你将一个值类型分配给一个变量，该值的底层数据将会被复制。你会得到两个具有相同内容的值，但分配在不同的内存地址中。
如下例所示，把str1赋值给str2后，str2的内容和str1的内容相同，都是字符串“Hello”，但两个值的内存地址不同。
|
然而，把包含大量信息的值类型作为参数分配或传递给函数时，对于性能来说，复制是非常昂贵的操作。为了尽量减少这个问题，Swift标准库为一些值类型（比如数组、字典）实现了一套叫做写时复制的机制。
其核心思想是，如果有多个调用者（callers）同时要求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变。
所以，如果只是将数组分配给一个变量或将其传递给一个函数并不会复制它，直到对它进行修改时才可能会进行复制，这样就提高了性能。
1996年，Kent Beck提出了一个称作极限编程(Extreme Programming)的软件开发方法。它基于12条编程实践规则，其中一条规则倡导：开发者必须编写单元测试，并且软件的所有部分都必须经过彻底的测试。所有测试都必须在软件(或新功能)发布给客户之前通过。应当先于测试的生产代码之前编写测试。
这种测试优先的程序设计方法被称作测试驱动开发(Test-Driven Development，以下简称TDD)。它的基本思想是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，完成测试代码的编写，然后再编写相关的实际功能代码，以满足这些测试用例。然后如此继续添加其他功能，直至完成全部功能的开发。
做客户端开发，不可避免的需要和文本输入打交道。今天我们来聊聊，如何在iOS里面打造更好的文本输入体验。
全文包含4部分内容：
UIView中的updateConstraints方法一直是一个令人纠结的地方。按照苹果官方文档中给出的建议：
Custom views that set up constraints themselves should do so by overriding this method. When your custom view notes that a change has been made to the view that invalidates one of its constraints, it should immediately remove that constraint, and then call setNeedsUpdateConstraints to note that constraints need to be updated. Before layout is performed, your implementation of updateConstraints will be invoked, allowing you to verify that all necessary constraints for your content are in place at a time when your custom view’s properties are not changing.
当视图的改变使得某个约束无效时，应当把该约束移除，并调用setNeedsUpdateConstraints以标记视图需要更新约束，然后在updateConstraints中更新约束。
然而，实际上却并不那么好用：
AutoLayout中，Content Compression Resistance和Content Hugging这两个概念，从字面上很难理解它们意思和用途，苹果官方文档中相关描述也比较少。中文翻译中大多数都把它们按字面翻译成内容压缩阻力和内容吸附性，也不是很好理解。最近搜索和查看了一些文章和资料，搞清楚了它们的作用，在此整理一下。
本文翻译自：stackoverflow
有人在stackoverflow上问了一个问题：
如何在UITableViewCell中使用Autolayout来实现Cell的内容和子视图自动计算行高，并且保持平滑的滚动？
这个问题获得了接近1000的支持和1100+的收藏，答案更是超过了1800+的支持，很详细的说明了如何在iOS7和iOS8上实现UITableView的动态行高计算。答案对实现UICollectionView的动态行高也具有参考意义，所以在这里将这个答案翻译了一下，希望对大家有所帮助。以下是答案的全文翻译：
全文略长，不喜欢阅读可以直接看示例代码：
本文分享一些在由Objective-C转换至Swift的过程中产生的思考，并尝试总结了一些技巧建议和一些误区陷阱。本文尽量通过对比来展示这两种语言在同一个问题上的不同处理方法。开始吧！
第一个重大的变化是：interface.h/implementation.m的文件结构被舍弃了。
我是这种文件结构的坚定支持者。只通过接口文件来获取或共享类相关的信息，不仅安全而且很方便。
在Swift中，接口和实现并没有分离。我们只能实现自己的类（并且在写代码的时候甚至不能添加可见性修饰符）。
如果你已经做过一段时间的iOS开发，那么你一定听说过模型—视图—控制器或MVC模式。这是构建iOS应用的标准方式。不过最近，我越来越厌倦MVC的缺点。本文，我们先重温一下MVC是什么，它有什么缺点。然后再介绍一种构建应用的新方式：Model-View-ViewModel。
模型-视图-控制器模式(Model-View-Controller)是构造代码的权威范式。苹果甚至这么说。MVC模式，所有对象都被界定为，要么是一个模型，要么是一个视图，或者要么是一个控制器。模型持有数据，视图向用户呈现一个可交互的界面，视图控制器做模型和视图之间的中介者。
这个图表中，视图将用户交互通知给控制器。然后视图控制器根据这个状态的变化来更新模型。然后该模型通知(通常是通过KVO的方式)相关的控制器更新它们的视图。iOS应用大部分代码都采用这种机制。
在iOS和Mac OS上，NSCoding是一种简单方便的数据存储方法。它可以直接将你的数据模型对象写入一个文件，之后又可以直接将它们读入内存而不需要编写任何文件解析和序列化的逻辑。将一个对象（假设它已经实现了NSCoding协议）保存至一个文件，只需要这样做：
|
之后要加载时，只需要这样：
|