The docs for symbolicating a crash file state: To symbolicate in Xcode, click the Device Logs button in the Devices and Simulators window, then drag and drop the crash report file into the list of device logs. However, this button is no longer available on Xcode 15 (now replaced by a "Open Recent Logs" which opens a Finder window). Is it possible for the docs to be updated? What is the solution in Xcode 15?

Hi there -- I'm cleaning up the accessibility in our app and making sure it adheres to Apple's suggested guidelines. For accessibilityHint, apple lists a couple of suggestions in the doc here: https://developer.apple.com/documentation/objectivec/nsobject/1615093-accessibilityhint Notably this one is one that I'm having to change a lot in our app: Don’t include the action type in the hint. For example, don't create hints like “Tap to play the song” or “Tapping plays the song.” However, we have some buttons that do different actions based on a double or triple tap in VoiceOver, so our hint looks something like: "Double tap to do X, Triple Tap to do Y" This violates the accessibilityHint guidelines, but I feel like changing this would mean the customer loses out on valuable information. What does apple suggest we do in this case? Thanks in advance!

I'm not really sure if I'm using the right lingo here because there's so little documentation on this, so apologies in advance. I have an app with a few custom intents that I'm attempting to transition to AppIntents. I have the newly transitioned intents showing up in the Shortcuts app as expected, however when I run them I get an immediate failure saying "The operation couldn't be completed" (see photo). Note that the "AppIntentsClient" class mentioned in the photo is the dependency I'm trying to import. I've narrowed it down to the @Dependency that I'm using in my intent handler. At the top of the intent handler I have a line: @Dependency private var appIntentsClient: any AppIntentsClient // NOTE: AppIntentsClient is a protocol -- could that be the issue? And if I comment out this line, the intent no longer throws that error. I'm following the guidelines shown in sample apps by setting the dependency on my main app's startup in didFinishLaunchingWithOptions like so: // gets called by the main app `didFinishLaunchingWithOptions` func onDidFinishLaunching() { let adapter = AppIntentsAdapter() //AppIntentsAdapter adheres to protocol AppIntentsClient self.appIntentsAdapter = adapter AppDependencyManager.shared.add(dependency: adapter) MyAppShortcuts.updateAppShortcutParameters() } Unfortunately there is virtually no documentation around AppDependencyManager or AppDependencies in general. Both documentation pages have at most one line, but don't indicate why this would be failing for me. Is there any information out there on why these errors may be happening? I've also looked at the Console app to see if the OS logs anything, but nothing of value was found. https://developer.apple.com/documentation/appintents/appdependencymanager https://developer.apple.com/documentation/appintents/appdependency

I have a simple wrapper class around WCSession to allow for easier unit testing. I'm trying to update it to Swift 6 concurrency standards, but running into some issues. One of them is in the sendMessage function (docs here It takes [String: Any] as a param, and returns them as the reply. Here's my code that calls this: @discardableResult public func sendMessage(_ message: [String: Any]) async throws -> [String: Any] { return try await withCheckedThrowingContinuation { (continuation: CheckedContinuation<[String: Any], Error>) in wcSession.sendMessage(message) { response in continuation.resume(returning: response) // ERROR HERE } errorHandler: { error in continuation.resume(throwing: error) } } } However, I get this error: Sending 'response' risks causing data races; this is an error in the Swift 6 language mode Which I think is because Any is not Sendable. I tried casting [String: Any] to [String: any Sendable] but then it says: Conditional cast from '[String : Any]' to '[String : any Sendable]' always succeeds Any ideas on how to get this to work?

Hi, I'm migrating my project from the old .strings files to String Catalogs (.xcstrings files). Everything is migrating over fine except for my custom intents. Right now the localization files for my custom intents all live "under" the definition file like so: But there is no option to migrate to a string catalog. I even tried removing the localization files, and re-adding them using the "Localize..." button, but that just creates the old .strings files, not the new string catalog. Is this not supported yet for intents definitions? I can't find any documentation about this. It would be a real shame to have part of my app on string catalogs and this one piece on the old Localizable.strings format.

Hi there, I successfully created an AppIntent for our app, and when I had it in the same target as our main app it showed up fine in the shortcuts app. Then I realized that many of the new System Control widgets introduced in iOS 18 (e.g. lockscreen, control center) live in the widget extension target, but they also need to reference that same AppIntent. So to fix this, I thought I'd migrate out the code into it's own SPM package that both the WidgetExtension and the Main App processes can reference. However, after doing that and rebuilding, the intent no longer shows up in the Shortcuts app. Furthermore, my AppShortcutsProvider class now has this error when trying to define the list of appShortcuts: App Intent <name> should be in the same target as AppShortcutsProvider Is this intended, and if so, how do we reference the same AppIntent across multiple targets?

I'm working on a large multi-platform iOS project (iOS, iPadOS, watchOS, tvOS, visionOS) and have successfully migrated from legacy .strings files to modern String Catalogs (.xcstrings). However, I'm unable to export localizations using xcodebuild -exportLocalizations due to cross-platform framework dependency issues. (Note: I did have AI help me write this question, so apologies in advance for any errors) Project Structure Main iOS/iPad app with multiple extensions watchOS companion app tvOS app visionOS app 49 .xcstrings files successfully migrated across all targets Uses Swift Package Manager for modularization The Problem When attempting to export localizations using xcodebuild -exportLocalizations, the build fails because it tries to build all targets across all platforms, including watchOS targets that depend on third-party xcframeworks that don't include watchOS slices: xcodebuild -exportLocalizations \ -project MyProject.xcodeproj \ -scheme MyApp \ -localizationPath ./export \ -configuration Debug Error: error: While building for watchOS, no library for this platform was found in 'Frameworks/<incompatible>.xcframework'. (in target 'Target') These frameworks cannot be modified to add watchOS support (third-party/legacy dependencies). What Works vs. What Doesn't Works: Building the iOS app through Xcode GUI Fails: Exporting localizations through Xcode GUI (Product → Export Localizations...) Fails: xcodebuild -exportLocalizations with any combination of flags Attempted Solutions (All Failed) Platform-specific destination: xcodebuild -exportLocalizations -destination "generic/platform=iOS" ... SDK constraint: xcodebuild -exportLocalizations -sdk iphoneos ... Excluding architectures: xcodebuild -exportLocalizations EXCLUDED_ARCHS="armv7k arm64_32" ... Build first, then export: xcodebuild build -scheme MyApp -sdk iphoneos && \ xcodebuild -exportLocalizations ... All approaches still attempt to build watchOS targets despite platform constraints. Observations The -exportLocalizations flag appears to ignore -destination and -sdk flags It seems to scan and build ALL schemes/targets in the project regardless of constraints Regular builds (xcodebuild build) work fine with platform constraints Current Workaround I created a Python script that parses .xcstrings JSON files directly and generates XLIFF output, which works but feels like it's bypassing Apple's intended workflow. Questions for Apple Is there a way to limit xcodebuild -exportLocalizations to specific platforms? The documentation doesn't mention any flags for this, and -destination/-sdk appear to be ignored. Why does -exportLocalizations require building ALL targets across ALL platforms? Both the Xcode GUI (Product → Export Localizations) and xcodebuild -exportLocalizations fail with identical build errors, suggesting this is by design. Is there a reason localization export can't be limited to buildable targets? Is the intended workflow to have ALL targets buildable across ALL platforms before exporting localizations? This seems impractical for multi-platform projects with platform-specific dependencies. Are there any build settings or configuration options that can exclude specific targets/platforms from the localization export scan? Is directly parsing .xcstrings files and generating XLIFF an acceptable alternative, or does this miss important metadata that -exportLocalizations would include? Environment Xcode 16.x / 26.x (reproduces on both) macOS Tahoe Project uses String Catalogs (.xcstrings) format Mixed SPM packages and traditional target structure Any guidance on the correct approach for multi-platform localization export would be greatly appreciated. Is this a known limitation, or is there a recommended pattern I'm missing?