Xcode automatically generates an InfoPlist.xcstrings file for all targets, even framework targets. In frameworks, this doesn't include any user-facing content - it only has the bundle name and the copyright string. But neither of these are going to be used by users. Is there a way to tell Xcode that it doesn't need to generate these xcstrings files for content that is not user-facing?

Whenever I switch branches, Xcode seems to update the originHash field in Package.resolved. I then have to tell Xcode to manually resolve packages again. That sounds like a bug, and I can just file a bug about that. But what I want to know is… why is the originHash changing in the first place? What does that represent? Should I be committing the value that it's trying to change to? Or should I be discarding that change?

Xcode's fix-its like to insert code like this: if #available(iOSApplicationExtension 15.0, *) { // Use some iOS 15 API here. } Usually, I just change those to this: if #available(iOS 15.0, *) { // Use some iOS 15 API here. } It's not clear to me, though, what the difference between the two is. Is iOSApplicationExtension more or less restrictive than iOS? Are there APIs that you could only call within the first block above? There are some APIs that are marked unavailable in extensions, but they don't seem to be affected by this attribute. This, for example, compiles just fine: if #available(iOSApplicationExtension 15.0, *) { // This is marked NS_EXTENSION_UNAVAILABLE_IOS print(UIApplication.shared) } So what's the difference?

The WeatherKit REST API returns different weather objects for different data sets (currentWeather, forecastDaily, forecastHourly, etc.) . Via the REST API, I can request the "current" weather for any given date, using the currentAsOf query parameter. However, in the native WeatherKit framework, I don't see any way to get a "CurrentWeather" object for a past date, even though this appears to be possible via the REST API. So if I want to know what the temperature was at 10:30am yesterday, for example, the best I can do with the native framework is request the hourly weather for 10:00am and 11:00am yesterday, and then average the two. But if I use the REST API, I could query that directly. Is this correct? Is there no way to get "current" weather conditions for past dates? (Or, alternatively, is currentAsOf not actually doing what I think it's doing?)

Xcode 14 no longer supports bitcode. The release notes say this: Starting with Xcode 14, bitcode is no longer required for watchOS and tvOS applications, and the App Store no longer accepts bitcode submissions from Xcode 14. Xcode no longer builds bitcode by default and generates a warning message if a project explicitly enables bitcode: “Building with bitcode is deprecated. Please update your project and/or target settings to disable bitcode.” The capability to build with bitcode will be removed in a future Xcode release. IPAs that contain bitcode will have the bitcode stripped before being submitted to the App Store. Debug symbols for past bitcode submissions remain available for download. (86118779) However, as I understand it, Xcode 13 still requires bitcode for Apple Watch targets. I'm trying to clean up warnings when building with Xcode 14 betas, so that we can really try it out during the beta period. However, I'm concerned that if I disable bitcode for the Apple Watch targets, it will either fail to build in Xcode 13, or it will get rejected by App Store Connect. Is there a way to disable bitcode when building under Xcode 14 without causing problems in Xcode 13?