Kipple 是一系列 Swift 模块的集合，为快速原型设计、快速参考、教育、发现和个人使用提供常见的 Swift 功能，涵盖从日志记录到错误处理到运行 Swift 可执行文件等概念。
警告
此库中的代码以“按原样”公开，仅用于参考、教育、发现和个人使用。 因此，无法保证生产应用程序的稳定性；但是，如果您有兴趣在自己的项目中使用此库中的代码，请自行承担风险。
如果您遇到任何问题或有任何请求，请提交 GitHub issue，我们将尽力提供支持。
注意
以下所有文档链接均指向不稳定的 main 分支。对于特定版本的文档，请使用文档页面顶部的“查看最新版本文档”链接。
| 名称 | 文档 | 描述 |
|---|---|---|
| Kipple | 一个伞形模块，隐式导入所有其他模块。 | |
| KippleCodable | 文档 | Codable 的便捷功能。 |
| KippleCollections | 文档 | Collections 的便捷功能。导入 OrderedCollections。 |
| KippleCombine | 文档 | Combine 的便捷功能。 |
| KippleFoundation | 文档 | Foundation 的便捷功能。 |
| KippleDevice | 文档 | 围绕 UIDevice 的便捷功能。在 iOS、tvOS 和 watchOS 上导入 DeviceKit，但在 macOS 上返回硬编码值。 |
| KippleKeychain | 文档 | Apple Keychain Services 的便捷功能。导入 KeychainAccess。 |
| KippleLocalStorage | 文档 | UserDefaults 的便捷功能。 |
| KippleLogging | 文档 | 所有日志记录相关功能的便捷功能。在 Linux 上导入 swift-log，但在 Apple 平台上使用 OSLog。 |
Kipple 旨在保持第三方依赖项非常轻量。 也就是说，有一些依赖项对于日常功能来说至关重要，Kipple 会根据需要依赖它们。
值得庆幸的是，Swift 编译器非常高效，并且只有当您的项目引用它们时，才会编译依赖的模块。 例如，只有当您依赖 KippleLogging 时，才会编译 swift-log，但如果您只依赖 KippleFoundation，则不会编译 swift-log。
请注意，Swift Package Manager 仍然会检出所有依赖项（除了那些仅被其他包的测试目标所依赖的依赖项），但这些依赖项应该足够轻量，可以非常快速地检出和解析。
- apple/swift-collections - Swift 的常用数据结构。
- apple/swift-log - Swift 的跨平台日志记录 API。
- devicekit/DeviceKit - UIDevice 的值类型替代品。
- kishikawakatsumi/KeychainAccess - 适用于 iOS、macOS、tvOS 和 watchOS 的 Keychain 简单 Swift 包装器。
注意
此软件包还利用 KippleTools 作为开发依赖项，它处理 Kipple 项目的 linting、格式化和其他核心脚本需求。 此依赖项不会以任何方式拉入您的项目中，因为它未被此软件包的任何产品直接引用。
为了使 Kipple 专注于核心功能，还有一些额外的组件位于外部包中。 每个包都围绕更复杂的主题（例如网络或 UI）提供功能，某些应用程序不需要这些功能。
每个软件包实际上都名副其实 - 请查看它们各自的 README 以获取更多信息！
| 软件包 | 版本 | CI | 覆盖率 | Swift | 平台 |
|---|---|---|---|---|---|
| KippleNetworking |  |
 |
 |
 |
 |
| KipplePlugins |  |
 |
 |
 |
 |
| KippleTools |  |
 |
 |
 |
 |
| KippleUI |  |
 |
 |
 |
 |
警告
在考虑此安装方法之前，请阅读稳定性部分。
Swift Package Manager (SPM)是用于管理 Swift 代码分发的工具。 它与 Swift 构建系统集成，可自动执行下载、编译和链接依赖项的过程。
您可以像这样将 Kipple 添加到您的 Swift 项目中
let package = Package(
...
dependencies: [
// Use .upToNextMinor to ensure you avoid breaking changes as much as possible.
.package(url: "https://github.com/bdrelling/Kipple", .upToNextMinor(from: "0.x.0")),
// Better yet, link to an explicit git commit to ensure stability.
.package(url: "https://github.com/bdrelling/Kipple", revision: "abcd123"),
],
...
)
Swift Package Manager 包含在 Swift 3.0 及更高版本中。
或者，您可以随意将任何模块、文件或代码行复制到您自己的 Swift 项目中！
所有 Kipple 库均在 MIT 许可证下发布。 有关详细信息，请参见 LICENSE。
Swift 版本：软件包的目标是至少支持与两个最新的 Xcode 主要版本捆绑在一起的所有 Swift 版本。（例如：在撰写本文时，Xcode 15.2 已发布，因此 Kipple 支持 Xcode 14.0 及更高版本，这意味着 Swift 5.7 是所有软件包的最低版本。）有关 Swift 和 Xcode 版本的参考，请参阅 swiftversion.net。
注意
由于 SwiftUI 在 iOS 17 / Swift 5.9 中使用 @Observable 取得了重大进展，因此 KippleUI 的最低版本是 5.9 而不是 5.7。
平台：所有软件包都旨在与平台无关，并且可以在 Swift 可以运行的任何地方运行，但少数例外，例如 KippleUI 之类的软件包，它与 Apple 平台 SDK（SwiftUI、UIKit、AppKit 等）紧密相关，因此不考虑 Linux、Windows 或 Android，并且这些软件包将无法在这些平台上构建。 对于新的和新兴的平台（例如使用 Xcode 15 的 visionOS），Kipple 软件包可能要到下一个 Xcode 主要版本发布后才能获得支持。
平台版本：与 Swift 版本支持类似，所有平台的最低版本都由两个最新的 Xcode 主要版本引入的 SDK 决定。（示例：在撰写本文时，Xcode 15.2 已发布，因此 Kipple 支持 iOS 16.0+、macOS 13.0+、watchOS 9.0+、tvOS 16.0+ 和 Linux。）有关 Xcode 版本及其捆绑的 SDK 的参考，请参阅 xcodereleases.com。
软件包管理器：鉴于这些项目主要用于参考和教育，而不是要直接依赖，Kipple 软件包仅支持 Swift Package Manager 以便于维护。
Kipple 处于非活跃维护状态，这意味着根据需要对上述软件包进行更新，无论是为了消除错误、删除过时的内容、更新 Swift 和平台兼容性，还是为了添加新的内容以用于教育目的。
因此，此组织中的每个存储库都包含以下免责声明
警告
此库中的代码以“按原样”公开，仅用于参考、教育、发现和个人使用。 因此，无法保证生产应用程序的稳定性；但是，如果您有兴趣在自己的项目中使用此库中的代码，请自行承担风险。
如果您遇到任何问题或有任何请求，请提交 GitHub issue，我们将尽力提供支持。
也就是说，我自己在许多应用程序和项目中使用所有这些存储库，其中许多是生产环境。 我还利用两个 CI 报告（GitHub Actions 和 Swift Package Index），并尽我所能尽可能多地使用测试来覆盖核心功能。
我将尽力解决您在我的存储库中打开的所有 Issues 和 Pull Requests，以感谢您帮助提高这些软件包以及我自己的（以及其他人的）应用程序的稳定性。 如果您没有及时收到我对 Issue 或 Pull Request 的回复，请不要犹豫再次 ping 我。
对软件包维护者的一个重要提示：请不要将这些软件包作为您自己的软件包的依赖项！ 这样做可能会给您的消费者带来传递风险，他们可能没有选择使用像这样的不稳定软件包。
如果您遇到任何问题或有任何要求，请随意打开 GitHub Issues 或 Pull Requests。
“Kipple”的概念来自 Philip K. Dick 的书 仿生人会梦见电子羊吗？。
Kipple 是无用的物体，例如垃圾邮件或用完最后一根火柴的火柴盒或昨天报纸的口香糖包装纸。 当没有人时，kipple 会自行繁殖。 例如，如果您睡觉时在公寓里留下任何 kipple，第二天早上醒来时，它的数量是原来的两倍。 它总是越来越多。
没有人能战胜 kipple，除非是暂时的，也许在一个地方，[...] 这是一个在整个宇宙中运行的普遍原则； 整个宇宙都在朝着完全、绝对 kipple 化的最终状态前进。
对于每个新项目，开发人员都会一遍又一遍地编写大量相同的样板代码，这些代码会Swift地堆积起来。 它本身并不是无用的代码，但它通常是相当琐碎的解决方案，每个项目都重复一遍又一遍，永远不能保证引入臃肿的第三方依赖项，但一遍又一遍地重新创建它可能是一种负担。
主要版本零 (0.y.z) 用于初始开发。 任何事物都可能随时更改。 公共 API 不应被认为是稳定的。 — SemVer 规范 #4。
Kipple 使用主要版本零来表明项目的易变性。
所有 Kipple 库均在 MIT 许可证下发布。 有关详细信息，请参见 LICENSE。