是时候让Swift Package Manager大放异彩了
多年来，如何管理项目的依赖关系一直是Apple开发人员社区内的一个重要争论来源。从CocoaPods到迦太基，再到手工打印的脚本，子模块和老式的复制粘贴 - 总有很多不同的工具和技术可供选择。
当Swift Package Manager在2015年底推出时，作为Swift开源的一部分，最初看起来最大的依赖管理辩论终于结束了。它是来自Apple自己的软件包管理器- 专门用于解析，更新和构建Swift项目的依赖项。
然而，三年半之后，尽管它非常棒 - Swift Package Manager仍然是一个利基工具。我认为现在是它发光的时候了，真正成为每个人在第一次宣布它时会想到的东西 - 这是管理任何 Swift项目的依赖关系的默认方式。
但我的梦想是让Apple更进一步，并使Swift Package Manager不仅是一个管理依赖项的工具，而且还可以管理开发人员生态系统中的各种项目。要使用Package.swift清单定义任何Xcode项目，要使用Swift Playgrounds for iPad，请使用Swift Package Manager构建项目的方式而不是使用自己的.playgroundbook格式 - 并且可以轻松地在服务器，iOS之间共享项目配置应用程序和iPad游乐场。
小编这里有大量的书籍和面试资料哦（点击下载）
服务器端Swift成为一流的公民
就像Swift Package Manager一样，服务器端Swift到目前为止在Apple的开发人员工具套件方面有一些模糊的地位。虽然显然已经花费了大量精力将服务器端Swift开发成服务器应用程序的强大而强大的替代方案 - 无论是Apple还是来自社区各地的众多人和公司 - 它还没有成为真正的第一个班级公民。
我的梦想是Apple开始谈论服务器端Swift，就像他们谈论iOS，macOS，watchOS和tvOS一样 - 使它成为一个完全支持的，一流的Apple开发平台（尽管它实际上可能在非Apple上运行）硬件）。虽然Swift团队领导Ted Kremenek宣布Apple确实在服务器端使用Swift，但在制作时，当他作为Swift by Sundell播客的嘉宾时 - 我很乐意看到这一承诺更进一步。
例如 - 如果Xcode内置了服务器端Swift项目模板，如果本机支持调试服务器端请求和响应，或者Apple提供了一些运行基于Swift的云功能的方法，那就太棒了在他们的基础设施上（类似于亚马逊通过他们的Lambda平台提供的） - 例如在CloudKit的背景下。
所有上述内容都会发出一个更强大的信号，即服务器端Swift将继续存在，并且使所有Swift开发人员更容易访问 - 特别是那些服务器端编程经验有限的人。
True Swift API和框架
Swift 5的主要特点之一是该语言第一次保证ABI稳定。这不仅为减少框架之间的动态链接或第三方应用程序能够直接调用系统提供的Swift运行时和标准库实例提供了机会 - 但它也为Apple打开了大门。船舶真正的Swift框架。
因为尽管Apple通过互操作性注释为大多数C和Objective-C API提供了很好的Swift支持，但他们仍然缺少许多功能和惯例，如果他们愿意的话，他们很可能已经采用了这些API。已经用Swift编写了。
例如，通过使用关联类型（如节和单元类型），类似于UITableViewDataSource和UICollectionViewDelegate可以使协议更加类型安全，网络API URLSession可以采用Swift的Result类型，而不是要求我们处理可选Data和Error参数，并且可以使用模型化配置和选项具有关联值的枚举 - 而不是使用词典。
虽然Apple 去年已经以Create ML的形式发布了他们的第一个“纯Swift”框架，但是我很想看到今年推出的任何新框架 - 包括那些被用于代码运送到App Store的框架 -用Swift写的。这不是因为我讨厌Objective-C并希望看到它完全被抛弃，我也不希望在Swift中重写现有的框架（例如UIKit） - 我认为现在是时候让Apple开始充分利用Swift的潜力了面向开发人员的API和SDK。
Xcode完全采用语言服务器协议
该语言服务器协议是微软在努力规范像不同语言的自动完成和集成文档如何在源代码编辑器手柄事情开始的一个项目。我们的想法是，任何采用LSP的编辑器理论上都应该能够用任何提供LSP支持的语言编写代码。
去年年底，Apple宣布 Swift和Xcode最终将采用LSP--这将使Visual Studio Code和Atom等编辑能够获得真正的一流Swift支持。我对此感到兴奋的原因 - 以及为什么我希望今年的Xcode版本最终完全采用LSP作为编辑器和底层Swift语言服务通信的方式 - 因为它将使我们的Swift开发人员能够使用任何编辑器我们想要的，没有妥协。
虽然这个项目已经取得了很好的进展- 我的梦想是，如果Apple要让Xcode本身依赖LSP，那么我们会看到使Swift与LSP完全兼容的努力加速。我们还得到了更强有力的保证，SourceKit（处理Xcode的自动完成和语法突出显示）和LSP之间的桥梁将保持很长时间的维护和支持。
Swift作为本机脚本语言
使Swift如此出色的一个重要原因是它在很多方面都设法既强大又类型安全，但在语法方面也很轻巧。由于类型推断和API和关键字命名的低冗余方法等功能，Swift代码通常不需要大量的输入，这使其成为脚本和自动化的理想语言。
通常在编写脚本时，我们希望尽快自动化或解决特定任务。我们不打算设置复杂的架构或编排大量类型和文件 - 我们只是希望以最低的入门门槛完成任务。对于许多iOS和Mac开发人员来说，历史上最低的障碍是通过像Bash这样的工具，像Ruby或Python这样的脚本语言，或者像Automator这样的Mac应用程序。
我个人非常喜欢使用Swift进行脚本编写，但与此同时，它确实带来了一系列障碍，我很乐意将其删除。我的梦想是让Xcode提供一个File > New > Script选项，在iOS上的Siri快捷方式能够运行Swift代码（就像它可以运行JavaScript一样），并且用于Swift命令行工具来启用内联依赖声明（类似于什么swift-sh和Marathon提供）：
// This annotation would be resolved by the Swift Package Manager
// under the hood, making it easy to use dependencies in scripts.
@package(url: "https://github.com/johnsundell/files.git", from: "3.0.0")
import Files
for file in Folder.current.files {
let content = try file.readAsString()
let html = try makeHTML(fromMarkdown: content)
print("-- \(file.nameExcludingExtension) --")
print(html)
}
如果Swift脚本会越来越受欢迎，我认为这也会为整个Swift生态系统带来很多好处。例如，它很可能会鼓励更多开发人员创建任何Swift项目随后可以使用的实用程序包（用于文件管理，数据处理等）。
iPad上的Xcode
我确实保留了我最后的最大梦想 - 我知道这可能不会发生在今年 - 但这些都是我的梦想，所以我们走了：我真的很想在iPad上看到一些版本的Xcode。
我确实喜欢使用该应用程序，但它在功能方面有一些非常严格的限制。其中一部分实际上是Playgrounds应用程序的一个功能 - 它的相对简单性使学生和编程初学者更容易学习并开始学习 - 但它很可能总是限制它作为专业人士使用的方式开发工具。
因此，我不是在寻找Apple将Swift Playgrounds转变为Xcode - 我认为它应该仍然是一个专注于教育和原型设计的工具 - 而是在iOS上引入专用应用程序开发专用应用程序。我的iPad Pro比我的电脑更快（2017 MBP 13“没有TouchBar），而且它也更加通用和轻巧 - 所以我喜欢将它用于各种开发任务，而不会觉得我使用的是错误的工具为了这份工作。
而不是将Xcode移植到iPad（老实说，我不知道它是怎么可能的） - 我很想看到Apple制作一个可在Mac和iPad上运行的全新现代IDE。想象一下，作为使用Project Marzipan可以完成的皇冠上的宝石示例 - 我想不出任何能让开发人员开始将他们的iOS应用程序带到Mac上更有说服力的东西。
扫码进交流群 有技术的来闲聊 没技术的来学习
691040931
网友评论