I have a watchOS app and I just want to remove the support for old devices using armv7k CPU (Apple Watch S3 and earlier). Is this any way to do this? I've tried removing the armv7k arch from build setting. But App Store Connect tells me "Apps built with Watch OS 5.0 and later SDKs must contain additional architectures". Or can I specifiy something like UIRequiredDeviceCapabilities in Info.plist to make the app only supports newer arm64_32 watch? But I didn't find any useful information on required-device-capabilities - https://developer.apple.com/support/required-device-capabilities/.

I just discovered that the following simple code snippet has a very confusing behavior on iOS 15.0-15.1. When I go to the NavigationLink, the child page pops up unexpectly once the app goes into the background and reopens. This issue does not happen on iOS 14. struct ContentView: View {   var body: some View {     NavigationView {       TabView {         NavigationLink {           Text("👀 Go to background. This view will pop.")         } label: {           Text("Push")         }       }     }     .navigationViewStyle(.stack)   } } You may have noticed that I have nested the TabView in the NavigationView, and this issue is related to this structure. Like many social apps such as Telegram and WeChat, I believe nesting TabView in NavigationView is a widely used structure. I am very hopeful that this issue will be resolved.

Hello! I was looking at the Build Timeline in Xcode 14 and noticed that my project generates a huge number of concurrent tasks (as shown in the image). Hundreds of compilation tasks all seem to start and end at the same time. This made the entire build timeline meaningless, and I couldn't distinguish which tasks took longer. I don't know if this is a bug in the build system, or if it is designed that way? What's interesting is that this problem seems to occur only on my MBP M1 Max. The same project, built on the MBA M2, with no more than ten lines of task bars, seems to be much more useful.

Hello everyone! Recently my watch app has been receiving a lot of crash reports, all of them from watchOS 9.0 and 9.1. The crash reports suggest SIGNAL 11 Segmentation fault: 11 crash, and the call stack is located in the WatchConnectivity framework -[WCSession onqueue_ sendMessageData:replyHandler:errorHandler:dictionaryMessage:] + 340 (WCSession.m:674). Now it has become the most common crash of my app. As I understand it, Segmentation fault: 11 suggests some binary or compiler-level problem. Maybe the way I'm calling the API is triggering a problem within the system? Sample Crash Log: Incident Identifier: xxx Hardware Model: Watch6,9 Process: WatchApp [2338] Path: xxx Identifier: io.qifeng.HiCoffee.watchkitapp Version: 4.1.1 (7992) AppStoreTools: 14A305 AppVariant: 1:Watch6,9:8 Code Type: 0200000C (Native) Role: unknown Parent Process: launchd [1] Coalition: io.qifeng.HiCoffee.watchkitapp [450] Date/Time: 2022-10-11 07:14:55.0777 +0200 OS Version: Watch OS 9.0 (20R361) Release Type: User Baseband Version: 5.00.00 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000004 Exception Codes: 0x0000000000000001, 0x0000000000000004 VM Region Info: 0x4 is not in any region. Bytes before following region: 68141052 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 40fc000-4100000 [ 16K] r-x/r-x SM=COW ....app/WatchApp Termination Reason: SIGNAL 11 Segmentation fault: 11 Terminating Process: exc handler [2338] Triggered by Thread: 7 Thread 0 name: Thread 0: 0 WatchApp 0x000000000418f1dc @objc ComplicationController2.getComplicationDescriptors(handler:) + 0 (<compiler-generated>:0) 1 libdispatch.dylib 0x000000002ba6b590 _dispatch_call_block_and_release + 24 (init.c:1518) 2 libdispatch.dylib 0x000000002ba6cd7c _dispatch_client_callout + 16 (object.m:560) 3 libdispatch.dylib 0x000000002ba7a114 _dispatch_main_queue_drain + 800 (inline_internal.h:2631) 4 libdispatch.dylib 0x000000002ba79de4 _dispatch_main_queue_callback_4CF + 40 (queue.c:7804) ... Thread 1 name: Thread 1: 0 libsystem_kernel.dylib 0x000000002c81c18c __ulock_wake + 8 ... Thread 2 name: Thread 2: 0 libsystem_kernel.dylib 0x000000002c81b0f8 kevent_qos + 8 ... Thread 6 name: Thread 6: 0 WatchConnectivity 0x000000005350996c __31-[WCXPCManager setupConnection]_block_invoke_2 + 0 (WCXPCManager.m:92) 1 libdispatch.dylib 0x000000002ba6b590 _dispatch_call_block_and_release + 24 (init.c:1518) 2 libdispatch.dylib 0x000000002ba6cd7c _dispatch_client_callout + 16 (object.m:560) 3 libdispatch.dylib 0x000000002ba73968 _dispatch_lane_serial_drain + 548 (inline_internal.h:2631) 4 libdispatch.dylib 0x000000002ba74454 _dispatch_lane_invoke + 388 (queue.c:3939) 5 libdispatch.dylib 0x000000002ba7e2a4 _dispatch_workloop_worker_thread + 628 (queue.c:6766) 6 libsystem_pthread.dylib 0x000000006580947c _pthread_wqthread + 280 (pthread.c:2618) 7 libsystem_pthread.dylib 0x000000006580951c start_wqthread + 8 Thread 7 name: Thread 7 Crashed: ☠️☠️☠️ 0 libdispatch.dylib 0x000000002ba81fd4 dispatch_source_cancel + 8 (inline_internal.h:231) 1 WatchConnectivity 0x00000000534f84b4 __81-[WCSession onqueue_sendMessageData:replyHandler:errorHandler:dictionaryMessage:]_block_invoke + 48 (WCSession.m:675) 2 libdispatch.dylib 0x000000002ba6cd7c _dispatch_client_callout + 16 (object.m:560) 3 libdispatch.dylib 0x000000002ba6fe7c _dispatch_continuation_pop + 388 (inline_internal.h:2631) 4 libdispatch.dylib 0x000000002ba81a90 _dispatch_source_invoke + 1760 (source.c:596) 5 libdispatch.dylib 0x000000002ba7cfe8 _dispatch_root_queue_drain + 332 (inline_internal.h:0) 6 libdispatch.dylib 0x000000002ba7d7a4 _dispatch_worker_thread2 + 168 (queue.c:6969) 7 libsystem_pthread.dylib 0x0000000065809440 _pthread_wqthread + 220 (pthread.c:2631) 8 libsystem_pthread.dylib 0x000000006580951c start_wqthread + 8 Thread 8 name: Thread 8: 0 libsystem_kernel.dylib 0x000000002c81e210 kevent + 8 ... Thread 9: 0 WatchApp 0x000000000458cd70 monitorCachedData + 756 (KSCrashCachedData.c:0) ... Thread 10: 0 libsystem_pthread.dylib 0x0000000065809514 start_wqthread + 0 I am currently unable to reproduce this problem on my own. Do you have any good suggestions for me?

I think the previous Self._printChanges() is really helpful when debugging the SwiftUI view and data model. However, it seems deprecated and does not work any more on iOS 16. Is there something similar to the Self._printChanges() in the latest version of SwiftUI?

Just found the rounded corners of Smart Stack previews are incorrect. They rendered as circular rounded corners, which are not consistent with other Apple Watch previews and also the physical Apple Watch. They should be changed to continuous rounded corners.

In Xcode 15 beta 3 and beta 4, if you add a AppShortcuts.xcstrings catalog or legacy AppShortcuts.strings files to the project, the project will always fail to build due to the following error. error: Unable to call validation: The data couldn’t be read because it isn’t in the correct format. (in target 'LearnAppShortcuts' from project 'LearnAppShortcuts') Command ValidateAppShortcutStringsMetadata emitted errors but did not return a nonzero exit code to indicate failure The error seems related to a cli called ValidateAppShortcutStringsMetadata. Reproducing Steps (1) In Xcode 15 beta 3/4, create a new iOS app project. (2) Add an arbitrary AppIntent and AppShortcutsProvider. import AppIntents struct MyAction: AppIntent { static let title: LocalizedStringResource = "My Action" func perform() async throws -> some IntentResult { return .result() } } struct MyAppShortcts: AppShortcutsProvider { static var appShortcuts: [AppShortcut] { AppShortcut(intent: MyAction(), phrases: [ "Perform action with \(.applicationName)" ], shortTitle: "Perform My Action", systemImageName: "heart") } } (3) Create a new AppShortcuts.xcstrings catalog file and add it to the iOS target (4) Build the project. The string catalog will be updated as expected. However, the build will fail.

The #warning complier directive seems broken in Xcode 15 beta 5. The warning messages are not shown in the Issue Navigator until you open the corresponding source file. #warning("some custom warning message")

In Xcode 15 beta 1 to 5, the watch face preview of accessoryRectangular and accessoryCircular are always rendered in tinted mode, even if you choose multicolor. (NOTE: Please don't ask me to provide diagnostic data for Preview. Because this issue is 100% reproducible.)

Hello! In Xcode 15 beta 1-5, a large number of old Xcode Cloud entries are displayed in the Report Navigator. These old entries do not contain any content. This issue does not occur when viewing the same project in Xcode 14.

Hello everyone! I noticed that the UISearchBar on visionOS automatically supports the Look-To-Dictate function. However, for a regular UITextView, I couldn't find the corresponding API. How can I make a UITextView support the Look-To-Dictate function? This is a great system feature. (I noticed there is a protocol called UILookToDictateCapable but no idea how to use it.)

Hello! My app supports iOS and visionOS in a single target. But when I preview the app on iOS device/simulator, an error occurred: The RealityKitContent.rkassets is located in my RealityKitContent package that is linked on visionOS. It seems that Xcode Preview is ignoring the link settings and attempt to build RealityKitContent.rkassets on iOS. Reproduce Steps: Clone my demo project at https://github.com/gongzhang/rkassets-preview-issue-demo Build the app for iOS (success) Preview ContentView.swift (failed due to RealityKitContent.rkassets issue)

Hello, I just discovered that on iOS 17.0 (release), if Measurement<UnitVolume> is used in App Intent, the system will incorrectly parse mL (milliliters) as megaliters. They differ by 9 orders of magnitude. This issue only occurs in the English + United Kingdom regional format. Sample code: https://github.com/gongzhang/AppIntentUnitVolumeBugUnderEnGB Screen recording: https://youtu.be/rMMAHOFpPXs

One of my users' device (iOS 17.0) consistently fails to refresh the purchase receipt through SKReceiptRefreshRequest, resulting in the following error (ASDServerErrorDomain Code=500332). Error Domain=SKErrorDomain Code=0 "发生未知错误" UserInfo={NSLocalizedDescription=发生未知错误, NSUnderlyingError=0x28357f300 {Error Domain=ASDServerErrorDomain Code=500332 "Unhandled exception" UserInfo={NSLocalizedDescription=Unhandled exception, NSLocalizedFailureReason=An unknown error occurred}}} The user has tried checking their App Store account, restarting the device, etc., but none of these actions have helped. Does anyone know what might be causing this issue?

Hello everyone! I've found that on the current iOS 17.0/17.1, the Button with an AppIntent within a widget can be tapped at a high frequency. Even if the AppIntent triggered by the first tap has not finished executing, the user can still trigger the AppIntent again. This can lead to repeated or accidental operations by the user. Since there is already an invalidatableContent() API, I think the system should know when an AppIntent has not finished executing. I suggest that in this state, the system should not accept repeated taps from the user. This way, the behavior and appearance of the button would be consistent.