燃烧时我们会过桥

使用KitBridge为macOS，iOS和tvOS开发应用程序

因此，您想编写适用于iOS，macOS甚至tvOS的应用程序吗？ 最近有很多关于Photos.app内部的UXKit.framework的讨论，或者可能是另一个替代框架来弥合AppKit / UIKit的分歧。 尽管这可能尚未实现，但没有什么阻止我们现在改进跨macOS，iOS和tvOS的代码的可移植性。

那么，那是什么一回事呢？

虽然UIKit显然是从开发AppKit的经验中衍生出来的，但对于开发人员来说，创建一个更加现代的框架却没有AppKit的负担是一种绿色的领域。 行李的缺乏使开发工作更加简化，但是有经验的AppKit开发人员会遭受附带损害，他们会发现某些更改难以适应，特别是如果他们需要经常来回移动时。

特别是，有很多支持类可以在UIKit和AppKit之间共享，但不是：NS / UIImage，NS / UIColor，NS / UIBezierPath和基础类NS / UIView。 区别不仅仅在于名称，还在于API缺少一些阻抗匹配，这使得将它们与其他现有框架配对更加容易且易于实现。

困扰水域的桥梁

首先，有一段历史，KitBridge是一个相当新的热点，它是基于QRKit原型中的一些最初构想于今年开始的，该构想使用简单的桥接标头，NSImage类别和#ifdef的战略性使用实现了非常有限的跨平台视图框架。实现中的指令。 该简单的标题和类别使QRKit可以在所有目标平台上提供相同的API。

KitBridge以此为出发点，并在此基础上进行了扩展，以包括更多的类和更多的类别，从而平衡了视图的开发。 使用KitBridge，您始终可以将UIKit API用于任一平台上的桥接类。 在iOS和tvOS上，使用本机方法，而在macOS（通常需要更多CPU和内存）上，这些方法按类别提供。 在某些情况下，UIKit缺乏可信赖的AppKit方法，并且也提供了这些方法。

除了扩展网桥支持的类的数量外，KitBridge还使项目更容易在版本之间共享单个实现文件，至少对于View，App Delegates和Controller而言。

建在桥上

虽然KitBridge并未涵盖所有可能的移植问题（我一直在逐个添加功能，因为我需要为各种应用程序提供功能），但它确实为编写可移植的Views和Controller提供了很多支持，并且已经支持了另外两个框架，这些框架提供了有用的一组视图：CardView.framework和SparkKit.framework。

CardView.framework提供了一个具有单个接口的NS / UITextView子类，用于添加样式化的文本和图形。 CardView最初是从DeskLamp提取的，并已进入OrangeCard和iStumbler。 现在，该框架已经与KitBridge集成在一起，一旦考虑到非UI平台的差异，我将把OrangeCard从macOS引入iOS和tvOS。

SparkKit.framework提供了一组数据可视化工具，它们具有饼图，环形图，条形图，堆栈图，网格图和列式数据视图，这些视图也建在BridgeKit之上。 通过协调NS / UIBezierCurve接口来启用它，以便视图具有相同的绘图代码。 iStumbler的最新版本使用SparkKit绘制Channels和WiPry插件的网格视图，我希望在以后的更新中替换折线图和水平指示器。

剩下的工作

消除应用程序和UI套件之间的差异有助于简化便携式应用程序，但仍有许多工作要做。 随着我在这些框架之上构建的应用程序的发展，我希望KitBridge也将发展。 既然似乎有一些兴趣，我想介绍一下框架，因为我认为它们在将应用程序从macOS移植到iOS（反之亦然）时可以节省时间，我希望您喜欢与他们合作。