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”

If you’re looking for the best utilization of your hardware, I wouldn’t be surprised if Apple’s ML frameworks were best. Since Apple has a small set of hardware, they can write software that takes advantage of it better. Consider looking into Core ML which is by Apple and for Swift. Of course this will only work for Apple hardware, but if this is just for personal interest/hobby then that doesn’t really matter.

Something to consider as well is learning both. Swift is certainly the best choice for making macOS/iOS GUIs. Other languages are probably better than Swift for your ML needs (could be rust, Python, etc.). However it’s totally possible to have an app using multiple languages. You could have the UI portion be in Swift, but the ML portions be in another language.

At my company we have a Mac app with the GUI written in Swift, shared logic with our Windows app written in C++, and some libraries written in Rust. So it’s certainly possible.

One caveat is that some languages don’t work with each other very well. Swift and Python do work well together iirc, so doing UI code in Swift and ML code in Python may not be a bad idea.

If you want to just stick to Swift, Apple does have some ML frameworks for Swift that you can use. I don’t do any work with ML, so I have no idea if these frameworks are any good, or have good resources for learning.

If you want to just stick with whatever language you use for ML, there are GUI libraries in nearly every language. These certainly won’t be as robust or as nice to work with as the native frameworks in Swift, but they could probably get the job done. I do know that a major issue with GUIs in Python is the difficulty in multi threading, which is a must for any app that performs long tasks without the UI freezing.

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.