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?

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?

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?

I have an app that deploys back to macOS 10.13. It also uses code from Network.framework, which was introduced in macOS 10.14. In code, I use import Network to import the framework. Because the framework is not available on our oldest deployment target, I'm also adding -weak_framework Network to our Other Linker Flags. This builds and runs just fine. However, upon inspecting the actual binary with otool -L, it appears that the app is trying to link to /System/Library/PrivateFrameworks/Network.framework instead of /System/Library/Frameworks/Network.framework. This results in a rejection from App Store review, because it detects that we're using private APIs. This seems like a bug in the linker, and I've filed FB9715763 accordingly. But in the meantime, I have an app to ship. Is there a way to tell the linker to use a particular path for this framework? I've tried adding /System/Library/Frameworks to Framework Search Paths, but that doesn't seem to be helping.

The WWDC 2021 CloudKit session talked about the new encryptedValues field on CKRecord. It also indicated that CKAssets have already been end-to-end encrypted in previous releases. The documentation indicates that for encrypted values such as these: CloudKit encrypts the fields’ values on-device before saving them to iCloud, and decrypts the values only after fetching them from the server. The encryption keys are available exclusively to the record’s owner and, if the user shares the record, that share’s participants. For a client that is accessing CloudKit via the HTTP interface, the documentation indicates that assets have a downloadURL property which can be used to fetch the asset. Does this URL download the already-decrypted asset? Or does it need to be encrypted after downloading? If the asset is already decrypted at the time it is downloaded, how can this work, since as I understand it the key should not even be available to Apple. If the asset is not decrypted at that point, is there documentation about how we need to decrypt it?

My app needs to upload some media files to a server. Usually it's only a few, but occasionally a user will have 1,000+ files to upload. These files are user data and we want to maximize the chances of the files making it to the server, so we're using a background URL session to queue up the uploads. However, what we're seeing is that for some users, the uploads just… stall. We're reconnecting to the background session, and the requests are all there; they're just not making any progress. This is true even when the app is in the foreground. I've configured the background URL session to use isDiscretionary = false, which I believe should indicate to the system that we really want these uploads to happen right away if possible. If we switch to using a regular session instead of a background URL session, the uploads all go through just fine. What we'd like is for the uploads to go through just like a normal session while the app is in the foreground. When the app is quit, we'd love for the uploads to continue in the background at whatever rate the system chooses. It seems to me that the system is throttling the uploads, even while the app is in the foreground. Is that something that happens with background URL sessions? Is there a way to make it not happen? Here's how I'm configuring the URL session: let config = URLSessionConfiguration.background(withIdentifier: "my-custom-identifier") config.isDiscretionary = false config.allowsCellularAccess = true config.sessionSendsLaunchEvents = false

I'm trying to get a persistent reference for a SecIdentityRef so I can reliably retrieve it later. I've tried a variety of things in the query parameter of SecItemCopyMatching, but I can't get it to work. I know the item exists in the keychain; I just barely called SecItemAdd not long ago. Here's what I've got right now:let identityArray: CFArray = [identity] as CFArray let query: [CFString: AnyObject] = [kSecClass: kSecClassIdentity, kSecMatchItemList: identityArray, kSecReturnPersistentRef: true] var _persistentItems: AnyObject? let copyResult = SecItemCopyMatching(query, &_persistentItems) // copyResult is -50 (errSecParam)I've tried the following other queries as well:let query = [kSecMatchItemList: selfArray, kSecReturnPersistentRef: true] // Produces -50 (errSecParam)let query = [kSecClass: kSecClassIdentity, kSecValueRef: identity, kSecReturnPersistentRef: true] // Produces -25291 (errSecNotAvailable)let query = [kSecValueRef: self, kSecReturnPersistentRef: true] // Produces -25300 (errSecItemNotFound)Is it possible to get a persistent keychain ref to a SecIdentityRef on iOS? (For that matter, I need to do the same on OS X, but I've generally found that the OS X APIs are more likely to do what I expect.)