The future of the Swift "ecosystem"

Using Swift
1

Hello everyone!

I'm a complete newbie not only to Swift but also to the Apple world. Please help me choose topics/sections to study so I don't waste time and then find out that the topic is outdated and no one will use it anymore.

My initial wishes:

  • Swift programming language
  • Target device: desktop
  • Application format: console, graphical
  • I'm considering combining it with the C programming language
  • Using vector instructions (SIMD)
  • cli/vim, Xcode, or VSCode

My starting point

  • low skills
  • old age

My question for experienced programmers: what resources and/or training materials have you used or are using for your learning? What tools do you use?

What is the future of Apple's tech stack? What things are not worth learning because they have already been abandoned or will be abandoned in the near future?

Thanks!

2

First of all, welcome. I’m surprised no one has yet responded, but I think maybe you asked a lot of “big questions” with many different possible answers.

what resources and/or training materials have you used or are using for your learning?

What resources to recommend will very much depend on your prior experience, and how you prefer to learn, but I’ll just drop a couple of links here that match what you’ve said you’re looking for:

  • The Swift book is quite good, but it’s more of a reference guide than a learning tool, in my experience. Still, it might be worth reading some of the introductory chapters, especially if you are already an experienced programmer in some other language/environment.
  • Apple has tons of development resources, and they can feel overwhelming (and disorganized). But since you’ve said you’re interested in macOS desktop development, for example, you can find a page specific to that here: macOS - Apple Developer . (Don’t miss the “getting started” link halfway down the page.)
  • Also worth noting that Apple does publish a developer application. There’s not much use for it, IMO, because all of the information there is also on the website. developer.apple.com But it does have all the WWDC videos from the last few years in there, and if you’d prefer to watch videos to learn how to do things, that’s another avenue for tutorials and learning.

Unless you are already very familiar with C development, I’d probably recommend you stay focused on learning Swift for your first application or two (as opposed to mixing it with C).

There’s no better way to learn than to pick a project (nothing too ambitious at first), and just begin to make progress on it. Scoping the features for a software project is its own skill, so I won’t go into that here, but try to break things into small chunks and

What tools do you use?

I primarily develop for iOS, so I use Xcode day-in and day-out. I also have Terminal open to commit my work to git, and sometimes execute command-line applications. When icons or graphics are needed, Apple has a library of them available for developers to use called SF Symbols. There’s an application available to browse them.

What is the future of Apple's tech stack?

This is impossible to answer, but Swift is definitely a part of that future. Can’t go wrong there.

Apple keeps their decisions very much internal. Swift is open source, and much of the language planning does happen here “in the open”, but that’s not to be conflated with Apple and their plans. I will personally be somewhat slow to adopt the latest Apple technologies in my applications, because you never know which are going to “catch on” and become important in the future. Apple announces new technologies (and here I’m speaking primarily of OS-specific feature APIs and developer tools) every year at WWDC, and for me it’s very much worth keeping abreast of those announcements, but I tend not to act on them until they’ve been around for a year or two.

What things are not worth learning because they have already been abandoned or will be abandoned in the near future?

This is another near-impossible question to answer. If you haven’t done this already, and you can get away with avoiding it, I’d personally stay away from C and C++ development. Swift is only one of a few different “higher level” languages that were made specifically to avoid many of the problems inherent in those languages. They will likely never be abandoned entirely (just as assembly won’t), but you don’t need to know them.

Good luck!

1 Like
3

Thank you! Very helpful!

I've already read some information and visited the sites on your list.

But as a beginner, I'm encountering some misunderstandings about the Swift language. What's the starting point, what should I learn like the Lord's Prayer?

Am I correct in understanding that the foundation of the language is Protocols? Are they something like open-ended capabilities for a type/composite type? If I learn a Protocol, will the rest be much easier?

Yeah. Sorry.

4

No. Protocols power Swift's generics system, but you'd start with simple value and reference types and build up.

If you're interested in SwiftUI, I suggest 100 Days of SwiftUI which has a brief intro to Swift before jumping into SwiftUI.

The Hacking With Swift website also has a lot of other content, and the Swift blog can help you track changes and new features over time.

2 Likes
5

Am I correct in understanding that the foundation of the language is Protocols? Are they something like open-ended capabilities for a type/composite type? If I learn a Protocol, will the rest be much easier?

I think, if you are a beginner to the ideas and concepts of programming, then you can largely ignore protocols to start. You need to know that they exist, and that “protocol conformance” means adding existing functionality to your structures, classes, and enums. (And you should probably familiarize yourself with how to do that.) But you shouldn’t need to make your own protocols, and I wouldn’t get too hung up on the details. You won’t have a reason to “go deep” on protocols until you get into more complex programming.

One of my guiding principals as a computer programmer for the last 25+ years is that “keeping it simple” helps to build larger (and easier to understand) projects.

What's the starting point, what should I learn?

I think you really need to know that Swift is a strongly typed language. (And if you don’t know what that means, you’ll need to do some reading about it.) Additionally, Swift has the concept of “optionals”, which can really confuse beginners. It broadly means that a variable can hold a value or not hold a value (and instead its value is nil). To work with the value that may or may not be there, you need to “unwrap” that value so it is no longer optional. There are a few different ways to do this, but this is probably a concept you should read up on.

Both of the above concepts are covered in “The Basics” chapter of the Swift book. You should probably familiarize yourself with everything else in there as well. Don’t worry too much about memorizing all the details, but you should understand the gist of what each section is about, so you can come back to it later when you do need those specific details.

1 Like
6

Thanks to @Jon_Shier, and @grid !!!

A few days later, I was able to write my first program in Swift. :smiling_face_with_sunglasses:

To do this, I needed to understand how the documentation works. For example, I was able to guess that when I see "Classes and Structures" starting with "CG," it means Core Graphics Library, and starting from "CF" means Core Foundation. It was intuitive. But there are counterexamples, unfortunately.

And the strangest thing was when I found this in the documentation!!!

In other words, in a method where you see an NSData * parameter, you can pass in a CFDataRef, and in a function where you see a CFDataRef parameter, you can pass in an NSData instance. This also applies to concrete subclasses of NSData.

let mutableData = NSMutableData()
    guard let destination = CGImageDestinationCreateWithData(
        mutableData, "public.png" as CFString, 1, nil) else { return nil }
    
    CGImageDestinationAddImage(destination, cgImage, nil)
    guard CGImageDestinationFinalize(destination) else { return nil }
    
    return mutableData as Data

My brain broke. Why did the authors do this? To save an image, I must to move it from one library (Class) to another library (Class). Why?

Also this:

The Uniform Type Identifiers framework provides a collection of common types that map to MIME and file types ....... The identifier types can also identify other resources, such as directories, volumes, or packages.
Explicitly specify relationships between types by marking them as subtypes of other types. For example, the type UTTypePNG has the identifier public.png.

"public" only!.

But there are things I really liked, like extensions. It's a flexible and amazing solution to not touch the original code directly like this

extension FixedWidthInteger {
    func do_what_you_want {
        return ...
    }

First output from my code below (it is simple image)

if let pngData = createPNG(from: box, width: 128, height: 128) {
    try? pngData.write(to: URL(fileURLWithPath: "random_pixels.png"))
}

random_pixels
random_pixels128×128 11.9 KB

PS I move Xcode (and all artifacts) to external SSD. Motivation is simple - save space on Macintosh HD and most intuitive folders structure.

1 Like
7

I’m glad you’re making progress here.

Why did the authors do this?

The answer is rooted in history [1].

One key goal of Mac OS X was a smooth transition from Mac OS 9. Mac OS 9 didn’t have Objective-C, so Foundation wasn’t available there. However, many APIs that were going to be shared between Mac OS 9 and Mac OS X needed Foundation ‘currency’ types, for things like data and strings. To solve this, we rewrote the core of these currency types in C, published that as Core Foundation, and rehosted the Objective-C types of top of those [2].

To make this easier on the Mac OS X side, these currency types were toll-free bridged to their Foundation equivalents. For example, CFData is toll-free bridged to NSData, CFString to NSString, and so on. See see Toll-Free Bridged Types within Core Foundation Design Concepts in the Documentation Archive.

When Swift was introduced one of its key goals was interoperability with Objective-C. Thus it’s easy to convert between Swift’s Data and Foundation’s NSData, and from there CFData

Core Graphics dates to the very beginning of the Mac OS X project. Within Mac OS X there was a low-level layer that could not use Objective-C [3]. Core Graphics was part of that layer. Given that, it has to use Core Foundation ‘currency’ types.

Image I/O was introduced slightly later, but it has similar restrictions.

"public" only!.

I’m not sure what you mean by this, but I wanted to explain how you’d use a UTType in this context, namely:

CGImageDestinationCreateWithData(…, UTType.png.identifier as CFString, …)

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

[1] Normally I don’t answer why questions — see tip 3 in Quinn’s Top Ten DevForums Tips — but in this case we’re well past the statute of limitations (-:

[2] Note that this was historically true but is no longer true. In the intervening 25 years this has changed twice, with the core implementations moving first to Objective-C and then to Swift. If you’re curious, check out Tony’s talk on this.

[3] Part of the rationale for that was that Objective-C means Foundation and Foundation had a constant and not-insubstantial overhead. Bringing that in to every process was problematic.

6 Likes
8

I believe you mean Image I/O has similar restrictions. Core Image is an Objective-C framework.

3 Likes
9

Sir, my hats off to you! Thank you so much for clarifying this! And I apologize for breaking your own rules [1]

1 Like
10

I believe you mean Image I/O

Yes! Thanks for the correction. I fixed my earlier post, just to avoid further confusion.

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

1 Like