The WWDC 2019 had a major impact on the UI toolkit landscape: while the venerable AppKit APIs remained available, Apple removed the old Carbon APIs and introduced 2 brand new frameworks: Mac Catalyst and SwiftUI.
Apple sporadically mentioned some apps built with these new UI toolkits. In this article, I try to bring a better overview of Apple’s use of AppKit, Mac Catalyst and SwiftUI in the different versions of macOS, from macOS Mojave to macOS Ventura.
SwiftLint is a great tool to enforce Swift style and conventions. Thanks to the Xcode Build Phases, integrating SwiftLint in an Xcode project is simple: a Build Phase automatically triggers swiftlint when compiling your project.
Sadly at the moment, you can’t easily integrate SwiftLint with Swift Packages: A Swift Package has no Build Phases and no way to automatically runs scripts.
This article explains how to use a post action script in Xcode to automatically trigger SwiftLint afer a successful Swift Package compilation.
A couple of months ago, I released a new app called Dependencies on the Mac App Store. You can download and try it for free at https://apps.apple.com/app/dependencies/id1538972026.
In this article, I explain how I built the command line support and released it in the Mac App Store. Implementing this feature turned out to be tricky, mostly due to the lack of documentation on this specific subject. This post might be of interest if you are planning to add a Command Line tool to your app distributed on the Mac App Store.
Let’s say you want to have a different behavior in your app depending on whether you build it in Xcode or you perform an Archive. And you want this behavior to be done at compile time. Note that the use of different configurations is not what is wanted.
With Xcode 5, it is now possible to compile an application for armv7 and/or arm64.
You can compile an application as 32-bit and/or as 64-bit and you can run this application in a 32-bit or 64-bit iOS Simulator:
You may want to stop into the debugger if something bad happened while executing your program. The easier way to do that is to have a breakpoint always set and to run your program in the debugger.
But sometimes you want to break even if there are no breakpoint. For example you know that something is wrong now and your program will crash later.