Xcode 15 beta 8 + iOS 17 beta 8

FB13154996

Useful link: https://github.com/feedback-assistant/reports/issues/359

FB12765484 Still seeing this on iOS 17.0 release and iPadOS 17.0 release. Similar reports: https://developer.apple.com/forums/thread/734946 https://developer.apple.com/forums/thread/717669

The Environment(\.colorScheme) is broken. Always in dark mode. FB12765484 https://developer.apple.com/forums/thread/734615

The Environment(\.colorScheme) is broken. Always in dark mode. FB12765484 https://developer.apple.com/forums/thread/734615

Crash log from my widget extension on watchOS 9 (but the extension deployment target is watchOS 10). The missing symbol is _$s21DeveloperToolsSupport13ColorResourceV4name6bundleACSS_So8NSBundleCtcfC. Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: DYLD 4 Symbol missing Symbol not found: _$s21DeveloperToolsSupport13ColorResourceV4name6bundleACSS_So8NSBundleCtcfC Referenced from: <D018EC5D-C49D-387D-8E1D-52FBA6099567> /***.app/PlugIns/WatchComplications.appex/WatchComplications (built for watchOS 10.0 which is newer than running OS) Expected in: <3DEFD17C-9665-3448-964C-B3218FDE4DF9> /System/Library/Frameworks/DeveloperToolsSupport.framework/DeveloperToolsSupport (terminated at launch; ignore backtrace) Triggered by Thread: 0 Thread 0 Crashed: 0 dyld 0x000000006954ec5c __abort_with_payload + 8 1 dyld 0x000000006955a31c abort_with_payload_wrapper_internal + 100 (terminate_with_reason.c:102) 2 dyld 0x000000006955a34c abort_with_payload + 12 (terminate_with_reason.c:124) 3 dyld 0x00000000694f4740 dyld4::halt(char const*) + 332 (DyldProcessConfig.cpp:2758) 4 dyld 0x00000000694f2be0 dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3484 (dyldMain.cpp:0) 5 dyld 0x00000000694f176c start + 1872 (dyldMain.cpp:1107)

@yellow8 No, the issue persists. I'm truly disappointed with the Xcode Previews team. It's not about the bugs, but their response to them. Every time I report a bug in Previews, they respond with a standard template asking for a diagnostic file. As you can see in this post, even when I provide detailed steps that reproduce the issue 100% of the time, they simply ignore them and continue to request the diagnostic file. They might even tell you it's a known issue, but still, they ask for a diagnostic file. So, I've given up.

FB13196716

Also reported: FB13213919

Fixed in iOS 17.1 beta 2.

FB13258033

@alex_taffe Hi:) In my app the value of @Environment(\.colorScheme) is correct. The system renders the live activity widget both in light and dark scheme since iOS 17.1 beta 2.

Hi, @Developer Tools Engineer Some of my users have encountered issues related to CloudKit in the past week, including myself frequently encountering CKError.Code.serviceUnavailable. The tricky part is that some devices will encounter data inconsistency issues, with no errors reported, making it very difficult to debug. (It seems that records created by another device cannot be queried through CKQuery, not 100% confirmed.) At present, I can only provide this information, but I can confirm that there have been some new issues with CloudKit's service in the past week. I don't know if it's useful to submit a FB in this situation. Do you have any suggestions?

The reasons for needing to distinguish the runtime environment include: App's custom UI controls and gestures need to be optimized for interaction on visionOS, such as the size of the touch area. Some user guide texts related to interaction in the app need to be distinguished for different platforms. The app sometimes needs to present to the user its type of device. It is very confusing for users to display Vision Pro as an iPad. FB13465097