Dear Erica, Where can you find a list of all the Foundation classes losing the NS prefix? Will any UI ones do the same? — Seivan

The whole “NS prefix stripping” initiative is part of Tony Parker and Philippe Hausler’s SE-0086, which you’ll find by following the link to the proposal. It contains a list of the classes affected by SE-0086’s adoption.

The reasoning behind this proposal goes like this: Swift has a compelling interest in creating a core library suite to support common Swift design patterns. This interest in unifying a core library extends to platforms that lack historic ties to NeXTStep.

To provide this universal support, the Swift Programming Language requires the creation of a family of libraries that will ship with the compiler. This core functionality extends beyond the existing Swift Standard Library and is tentatively called the Swift Core Libraries.

Key elements that will be developed for the library include dispatch, internationalization/localization, and unit testing. As these libraries are both fundamental and native to the Swift language, their naming style needs to be “Swifty”. This renaming differentiates them from Cocoa Foundation:

In addition to adopting the guidelines for method names, the names of the fundamental types should follow the spirit of the guidelines too. The type names should be clear, concise, and omit needless words or prefixes. In combination with adopting Swift semantics for many of these types (SE-0069), and continued improvement to the implementations, this will make core library API feel like it belongs to the Swift language instead of like a foreign invader.

To answer your question, classes tied specifically to Objective-C and the Objective-C runtime, as well as those that are Apple platform specific (AppKit and, as you asked, UIKit) will retain their NS (or UI) prefix. Those that are more universally applicable will slowly lose that prefix through a series of upgrades and redesigns, especially as the tension between Swift value type and Foundation reference type implementations are better explored.

SE-0086 has been through a significant revision. Numerous classes  included in the original write-up were later removed:

The authors wrote,

 We considered simply dropping the prefix from all types. However, this would cause quite a few conflicts with standard library types. Also, although Foundation’s framework boundary is an easy place to programmatically draw the line for the drop-prefix behavior, the reality is that Foundation has API that feels like it belongs to higher level frameworks as well. We believe this approach better identifies the best candidates for dropping the prefix.

Because of this revision, fairly universal items like attributed strings, time zones, tasks, and sort descriptors did not make it through the first round of renames but may be considered again as the Swift language evolves.

SE-0086 and its heirs will not be taking up the case of renaming the core UI elements that are so tied to Apple’s platforms and their look and feel. That said, I would love to see a push to expand the Swift language to include more constructed literals, and here is my reasoning why.

A constructed literal expresses concepts that are inherently cross-platform. Swift’s constructed literal set currently includes colors, paths, and images. Colors and images fall under the platform-specific umbrella that excludes them from being part of the core library system.

Using a constructed literal allows these platform-tied elements to participate in the core Swift language because implementation details are left to the destination platform. You don’t have to work whether an item is a UIColor, an NSColor, an SKColor, or a CIColor because a color literal builds on an underlying commonality that colors can be expressed using RGBA notation.

Extending the constructed literal set from colors, paths, and images to  views, fonts, and more provides an interesting way to move forward. Like colors and images, these platform types are essentially universal concepts. They could defer of implementation details to destination platforms, allowing them to be created in core Swift.

While I’d love to see this discussed, it’s pretty clear that this kind of additive proposal will probably be deferred to at least Swift 5, as Swift 4 focuses on a much more narrow set of goals.