I see that iOS 18 has tinted app icons. Does anyone know what will happen if we choose not to provide a version of our icon for tinting?

I've got a package that includes SwiftLint purely as a build tool plugin for use while working on the package. I don't want to have every app that uses my package have to clone and build all of SwiftLint's dependencies just because they've added my package. Is there some way to avoid that? What's the best course of action here?

I have a UIButton inside a dynamically-populated stack view that is within a self-sizing table view cell, and although it has a maximumContentSizeCategory of XXXL it is clearly not respecting that. Has anyone else run into this issue, and if so have you found a workaround? I used the appliedContentSizeCategoryLimitsDescription property described here: https://useyourloaf.com/blog/restricting-dynamic-type-sizes to confirm that the maximumContentSizeCategory is indeed being set correctly. This is in the iOS 16.2 iPhone 14 Pro simulator, running in Xcode 14.2.

Hi, My team is in the process of upgrading from Xcode 13 to Xcode 14 for our development. Today I noticed that our code coverage reporting in Xcode is showing a clearly incorrect result: 0.0% when it should be saying a significantly higher number based on Xcode 13's calculations also run today. We have now reproduced the 0.0% issue on two different computers. Has anyone else noticed something like this? It looks like coverage is being reported just fine for our CocoaPods, but not for our internal targets. This is a predominantly-Swift codebase. In the Build Settings, I've tried setting "Enable Code Coverage Support" to true and "Generate Legacy Test Coverage" to false for our main target even though previously "Enable Code Coverage Support" was only true for the test target; however that does not make a difference. xcodebuild yields the same results when I attempt to generate a .xcresult from the command line. Thank you in advance for any guidance you might be able to provide me on this.

I'm trying to add a file that contains calls to NSLocalizedString to a Siri IntentsUI target, but I keep getting an error that NSLocalizedString is not available. This is confusing to me because I see that IntentsUI imports UIKit, which as far as I know then imports Foundation. I was able to work around the issue by importing Foundation into the file I'm working with, but is that the right way to go about this? What's the best practice for adding localized strings to app extension targets?