You can use swift package manager to create an executable target, which you can then run on macOS from the command line. Most frameworks (aside from UI) are shared between iOS and macOS like AVFoundation. If you don’t have access to macOS, you can still use swift package manager to build and run code on Linux or Windows, though you unfortunately won’t have access to any Apple frameworks.

The article discusses that organic foods are worse for the environment.

When Apple introduced the iPhone they required automatic reference counting to be used in Objective-C rather than tracing garbage collection (the language supported both) due to performance reasons (iPhones were significantly slower than Macs). At least Apple seems to think that reference counting is faster than tracing garbage collectors. The compiler can do a lot to remove unnecessary releases and retains. Additionally each retain is just incrementing an integer, and each release is just decrementing an integer and comparing the integer to 0, so the overhead is pretty small.

Metal — it’s a proprietary graphics API made by Apple

Hacking with Swift is a great resource. They have quite a few books related to development in Apple platforms (some free). You’ll probably want to do some research on if you want to learn SwiftUI or UIKit. UIKit is still used much more frequently in industry, but SwiftUI is becoming more mainstream, and is easier to learn. Hacking with Swift has books for both frameworks.

Personally, I’d recommend just jumping into writing a simple app (probably by following along with a tutorial) since you already know how to code, and have a grasp of the basics of Swift. There isn’t too much you need to learn about Xcode initially, and any tutorial for creating your first app should walk you through any Xcode specific steps you do need to do. Most of your learning will probably be related to either UIKit or SwiftUI, which are the frameworks you use for actually getting stuff on the screen. While learning these, you’ll undoubtedly pick up more knowledge about Swift and Xcode, which will improve those skills. I certainly don’t think you need to become an expert in Swift or Xcode before learning UIKit or SwiftUI. As you learn more, you’ll learn what areas you need to improve on, and can tailor your journey from there.

Quartz is a layer beneath SwiftUI or AppKit. SwiftUI is still using Quartz under the hood. The way you use Quartz directly from SwiftUI vs AppKit is a bit different, though still fairly similar. A more fair comparison of the SwiftUI code would be:

struct HelloWorldView: View {
  var body: some View {
    Canvas { context, _ in
      context.draw(
        Text("HelloWorld")
          .font(.system(size: 24))
          .foregroundColor(.black),
        at: CGPoint(x: 20, y: 20)
      )
    }
  }
}

Alternatively an AppKit solution (not using Quartz directly) would be something like:

class HelloWorldView: NSView {
  override init(frame frameRect: NSRect) {
    super.init(frame: frameRect)
    let text = NSAttributedString(
      string: “Hello World”,
      attributes: [.font: NSFont.systemFont(ofSize: 24), .foregroundColor: NSColor.black]
    )
    let label = NSTextField(labelWithAttributedString: text)
    addSubview(label)
  }

  required init?(coder: NSCoder) {
    fatalError()
  }
}

In either AppKit or SwiftUI, you can access Quartz directly to implement custom views. However, most of the time the UI code you write in either SwiftUI or AppKit won’t call Quartz directly at all, but will instead be composed of built-in views, like (NS)TextField or (NS)Button. Under the hood, SwiftUI is mainly just using the AppKit components at the moment, but provides a significantly nicer way to use them (especially in regards to layout and data synchronization).

Swift. Mostly because it’s by far what I’m most familiar with. Two things come to mind for what I most like about it. 1. Progressive disclosure: I found learning Swift to be simple since I didn’t have to directly concern myself with advanced features, but as I learned more I could take advantage of these more advanced features. 2. Clarity: I find Swift far more readable than most other languages. I think this is a combination of language features (argument labels for example) and consistency across the standard library and popular third party libraries. I think Swift finds a good middle ground between brevity and expressiveness; there’s never too much boilerplate to write, but the code is usually fairly self documenting.

I don’t think Apple has every really had great backwards compatibility. Apple’s last PowerPC computers shipped in 2005, and in 2009 Snow Leopard released with no PowerPC support. That’s 4 years of upgrades, which is about the same as it is now for macOS.

It an expression that means “I agree with what you just said”

Purely from the standpoint of making GUI apps in macOS/iOS, Swift is almost certainly the best choice. All of Apple’s UI frameworks are written in Swift (technically often Objective-C, but with Swift in mind), and designed to be used from Swift. It’s kind of possible to do this in C++ using Objective-C++, but nearly all of the UI code is going to be Objective-C anyways (Objective-C is the language that used to be the default on Apple platforms, but was replaced by Swift). It’s also certainly possible to use libraries for other languages that wrap this functionality, but these often can be missing features and/or be harder to work with. Additionally when looking for help, you’re likely to find much more support out there for the native frameworks since that’s what most people are using.

Happy to see those new options in Xcode 15. Those seem really useful.

Yeah not sure why Find Selected Symbol defaults to contains instead of matching. My search results get polluted with other symbols when I search for example MyStruct.image and MyStruct also has the property imageName.