我一直在开发iOS应用程序大约一年。在那段时间里，我开发了相当数量的课程，我经常从应用程序回收到应用程序。例如，我有一堆与更容易编写表视图以控制应用内设置相关的类。
现在，我只是从一个应用程序中获取这些类并将它们粘贴到下一个应用程序中。我的问题是 - 在什么时候创建和使用静态库可能更容易？
答案 0 :(得分：1)
静态库也存在问题。
所以你想要的是一个解决方案，你可以在其中添加依赖项到实际的源代码。这样你就可以避免讨厌的GCC错误，并鼓励童子军规则！
我们的解决方案是基于Rake的简单依赖系统。它创建了指向共享库的源代码的sym链接，以及在构建服务器上构建时的硬拷贝（您不应该在开发人员自己的机器上构建分发二进制文件！）。
sym-links允许开发人员编辑共享代码，就像它是当前项目的一部分一样，同时确保任何清理，错误修复等始终传播到单个存储库并从中受益所有< / strong>使用共享库的项目。
构建服务器上的硬拷贝允许为版本标记共享库，因此您发送到App Store的v1.0的确切构建是永久可重现的！
我的一个colegue博客写了关于在此建立一个用于持续集成的构建服务器：http://blog.jayway.com/2010/01/31/continuos-integration-for-xcode-projects/
我会唠叨他博客并分享基于Rake的依赖系统。它基本上只是Ruby脚本的一小部分。
答案 1 :(得分：0)
我有自己的杂项库。
我在其中添加了一些我认为合理通用的内容，并且我可以设想将来在某些时候使用。
毕竟，将它添加到您的库中没有任何害处，即使您再也不使用它。
答案 2 :(得分：0)
一旦您厌倦了复制和粘贴，就应该创建一个库。或者，一旦你犯了第一个错误（错误）复制和（错误）粘贴。
或者，更像商业的术语：当净现值超过净现值时。
答案 3 :(得分：0)
如果您希望将课程分发给“团队”，那么您不必担心他们对您的代码所做的更改，从而保持图书馆的一致性。
或者如果您想将您的课程作为API出售给另一个DEV团队，那么您可以隐藏API用户的源代码。
我有一些“实用程序”类，我发现它很有用，我确实倾向于将类文件放入我的解决方案，因为我发现它更容易，更快，（不是额外的2到3次点击很重要），所以我真的假设我最喜欢habbit。
答案 4 :(得分：0)
另一种解决方案是使用支持子模块的版本控制系统（例如git）。您可以将每个辅助类（甚至是类的集合）包装在其自己的存储库中，该存储库可以导入到代码的主存储库中。
通过这种方式，您不必担心剪切和粘贴错误。此外，如果您对这些类进行了改进，可以将它们传播到使用它们的其他项目（如果您愿意），但是您可以随时回滚到以前的版本以进行错误修复/测试。
在github example
等网站上找到这样的帮助代码是很常见的答案 5 :(得分：0)
我有一个独立项目中的静态库。 这样我可以完全开发库，完成单元测试等，然后通过使另一个项目依赖它来简单地重复使用它。
这意味着我不需要剪切/粘贴，这也意味着如果我找到/修复错误，或添加/修改库的功能，那么它可以轻松地进行回归测试。
现在，使用该库的所有项目都可以从中受益。
所以对于我的钱来说，当你发现想要再次使用它时，是时候将一段“有用的代码”转换成一个库。
（当然，我们都有一些有用的代码片段，我们通过先前项目的复制/粘贴重复使用 - 这些代码片段不一定适合存放在库中。）