Greetings, With MacOS 15 Sequoia, Apple updated key-value-observations in such a way, that an unremoved observation by a now deallocated object will no longer cause an exception, when the observed object triggers said observation. While this is fundamentally a positive change, the issue comes with the fact, that this change affects systems based on the version of their operating system and not the version of the operating system of the build system. Many of our customers use old operating system versions and old hardware - meaning they can't easily update. Since we need to use up to date Xcode versions to develop for newer systems, our developers tend to have rather new OS versions. This means, that we are increasingly facing bugs which only happen in customer systems but not in most developer (or QA) systems. Currently, we still can use earlier OS versions with Xcode to fix these bugs, but once the used Xcode versions no longer support MacOS 14 or below this will become a major hurdle. Are there known solutions to this issue? We are currently attempting to swizzle observer adding and removal in order to fix the problem for old systems as well, but this has proven to be quite difficult and unstable. Since any weakly held property in the middle of an observation keypath can cause crashes, one would have to split up observations into multiple subobservations, which is less simple than it sounds, due to custom implementations of addObserver (such as there seems to be in array controller proxies) and collection operators. Thanks for any suggestions!

I have a question regarding specifying URLs for a Message Filter App Extension. https://developer.apple.com/documentation/identitylookup/creating-a-message-filter-app-extension The documentation states “If you have servers that can help your app extension determine how to handle a message, you must add the Associated Domains capability to your Xcode project and specify those domains.” The term servers and domains is specified in the plural, and adding two occurrences of ILMessageFilterExtensionNetworkURL to the info.plist doesn’t cause a build error. So the first question is: 1.What is the behaviour of the OS when two instances of ILMessageFilterExtensionNetworkURL but specifying different urls is defined? Does the OS, for example always try one url first, and if that doesn’t respond after N seconds, it attempts the second one? Can the Message Filter Extension indicate which of multiple defined ILMessageFilterExtensionNetworkURL should be used at run time? 3.How does the OS behave if a URL specified for ILMessageFilterExtensionNetworkURL resolves to two VIPs? Will the OS retry if the first VIP is not accessible (similar to any typical browser or web application behavior). Thank you

I am testing App Clip on Testflight to show App Clip Card but it only shows a white Card with the message: “This app clip is not currently available in your country or region” (if using Local Expreriences, it shows normally) I have fully installed apple-app-site-association, App Clip Experience, Domain URL Status also validated ... don't understand why, is the app "Redy For Sale" new to show the Card?. I want to let customers test show App Clip Card without using Local Expreriences on Testflight If anyone knows, please help, thank you.

Hey! I am developing a macOS application with the help of an external vendor, who is supplying me with a closed-source XCFramework. In Xcode, when I import their XCFramework bundle, when running the app, or opening a SwiftUI preview, or interacting with the app in any form, I get the familiar dialog: "[SDK name].framework" Not Opened - Apple could not verify "[SDK name].framework" is free from malware that may harm your Mac or compromise privacy. (Regardless, the application can run on my machine.) But indeed, their cross-platform iOS/macOS XCFramework is not notarized at all (using spctl -a -t install), plus the macOS binary embedded is not code signed correctly (using codesign -d). The XCFramework itself is production code signed with a Developer ID certificate, however I believed the above issues to be valid. Now, I asked the vendor to provide a correctly distributed (so code signed and notarized) framework, however they pointed out that "when I embed and sign the product in my app, it will be re-signed anyways". I understand this is true, but I believe this to be an important security boundary. If I were to re-sign under my name a closed source binary - previously unchecked for malware by Apple Notary Service -, I would put myself up for embedding potentially malicious code in my app, which could only be traced back to me - which would in turn mean a security issue would hinder my reputation here. Am I being over-protective here, or is this a valid concern? I have no way to see the source code, so I strongly believe this XCFramework should be notarized correctly. I understand that an in-house XCFramework is fine unnotarized, given that I know its origin, but this seems like a unique case where notarization should be enforced from my side on the vendor.

When I launch the Quick Look Preview Extension target in Xcode, an app called Quick Look Simulator opens with an almost empty window: Online I read that the Terminal command qlmanage allows to test Quick Look plugins (which I think were an older format for creating Quick Look extensions), but running qlmanage -p /path/to/previewed/file -c public.text -g /path/to/QuickLookPreviewExtension.appex (where QuickLookPreviewExtension.appex is generated by the Xcode build and is located in the DerivedData folder) gives an error Can't get generator at QuickLookPreviewExtension.appex How can I debug a Quick Look Preview Extension?

We've observed an issue where the video button on the CallKit UI is disabled during Video VoIP calls. This issue appears to be specific to notch devices running SDK 26 and iOS 26 beta 7, specifically on iPhone 11. We have not seen this behavior on devices with Dynamic Island or on older iOS versions. For further details, please refer to the attached video and sysdiagnose file. : FB19827793 Our experimentation suggests this issue is exclusively present on non-Dynamic Island devices with iOS 26 beta.

Hi Anyone had luck to make EnergyKit work yet? Using Xcode 26 (latest beta), physical iPhone with the latest iOS26 beta.

As the title says. This happens even when not in dark mode.

Has anyone encountered a situation like mine below? I’ve submitted feedback, but it seems like I’ll have to wait for a while. ContactProviderManager Fails with Custom domainIdentifier, Works Only with "defaultDomain" Category: Developer Tools / Frameworks Subcategory: ContactProvider Framework Reproducibility: Always iOS Version: iOS 18.0 (and later) Xcode Version: Xcode 16.0 (or later)  Description: When initializing a ContactProviderManager with a custom ContactProviderDomain using any identifier other than "defaultDomain", the initializer throws a ContactProviderError.domainNotRegistered error. The documentation for ContactProviderDomain (https://developer.apple.com/documentation/contactprovider/contactproviderdomain) does not provide any method to register custom identifiers, making it impossible to use ContactProviderManager with a desired custom identifier. The only successful case is when the identifier is "defaultDomain". print("Error: (error)") // No error, initialization succeeds Steps to Reproduce: Create a Contact Provider Extension in an iOS app targeting iOS 18.0. In host app, Attempt to initialize a ContactProviderManager with a custom ContactProviderDomain identifier: ​import ContactProvider func enableExtensionExample() async {    do {        // The app creates a contact provider manager with custom domain.        let manager =  try ContactProviderManager(domainIdentifier: "com.mycompany.customdomain")               // May prompt the person to enable the custom domain.        try await manager.enable()    } catch {       print("Error: \(error)") // Prints ContactProviderError.domainNotRegistered    } } Try the same with the default identifier: ​import ContactProvider func enableExtensionExample() async {    do {        // The app creates a contact provider manager with a default domain.        let manager =  try ContactProviderManager(domainIdentifier: "defaultDomain")               // May prompt the person to enable the default domain.        try await manager.enable()    } catch {       print("Error: \(error)") // No error, initialization succeeds    } } Build and run the app on a device or simulator running iOS 18.0 or later. Observe that the initializer fails with domainNotRegistered for any identifier other than "defaultDomain". Expected Behavior: The ContactProviderManager should initialize successfully with any valid ContactProviderDomain identifier, provided the domain is properly configured or registered, allowing developers to use custom identifiers for organizing contacts (e.g., for different categories or sources). Actual Behavior: The ContactProviderManager initializer throws ContactProviderError.domainNotRegistered for any ContactProviderDomain identifier other than "defaultDomain". Only the "defaultDomain" identifier succeeds, limiting the ability to use custom domains. Impact: Developers cannot use custom identifiers to categorize or manage contacts in separate domains, restricting the ContactProvider framework’s flexibility. This forces reliance on the "defaultDomain" identifier, which may not suit use cases requiring distinct contact groups (e.g., personal vs. business contacts). Suggested Fix: Provide an API to register custom ContactProviderDomain identifiers, such as a ContactProviderManager.register(domain:) method. Update the ContactProviderDomain and ContactProviderManager documentation to clarify how to use custom identifiers or explicitly state if only "defaultDomain" is supported. If custom identifiers are not intended to be supported, document this limitation clearly to avoid developer confusion. Feedback : FB20104001 (ContactProviderManager Fails with Custom domainIdentifier, Works Only with "defaultDomain")

I created a new project, packaged it with my own enterprise certificate, installed and used it. There were no problems on most devices. However, on some devices with system versions of 18.3 and 18.4, the app crashes when opened after trusting the certificate. It seems that there is something wrong with the certificate, but I have confirmed that the certificate is fine. May I ask what the cause of this issue is?

在执行完 INIntent 或者AppIntent的Shortcuts后，刷新 WidgetKit桌面小组件

Hey! I'm trying to create an XPC messaging feature between my daemon and main application. I'm trying to use the new Swift low-level API available from macOS 14.0. The documentation is extremely confusing when looking at it from Swift: The xpc_listener_t type Seems to be something I shouldn't use in the Swift API, and would rather have to use XPCListener. Also, it appears to have no public API other than the xpc_listener_set_peer_code_signing_requirement function. Which would make it impossible to create this type. However, when going into xpc.h, one can see that there is an API in fact: API_AVAILABLE(macos(14.0), macCatalyst(17.0)) API_UNAVAILABLE(ios, tvos, watchos) XPC_EXPORT XPC_SWIFT_NOEXPORT XPC_RETURNS_RETAINED XPC_WARN_RESULT xpc_listener_t _Nullable xpc_listener_create(const char * service, dispatch_queue_t _Nullable target_queue, xpc_listener_create_flags_t flags, xpc_listener_incoming_session_handler_t incoming_session_handler, xpc_rich_error_t _Nullable * _Nullable error_out); which is a very unusual declaration - the first parameter for example shows up as Int8 type in Swift. Not to mention I haven't been able to create the next parameter, xpc_listener_create_flags_t at all, even though it seems to be a UInt64-based flag based on the C declaration, but passing UInt64(0) throws a compiler error. It really seems like something I shouldn't use from Swift. But then again, the extremely important security-related API mentioned above, xpc_listener_set_peer_code_signing_requirement can only take an xpc_listener_t object as a parameter, not an XPCListener type. There seems to be no conversion available between the two. However the documentation in the XPC framework seems to be telling the story of these two types being very equal, because of the following: The xpc_session_t type seemingly again has only deprecated methods mostly, the important one staying behind is xpc_session_set_peer_code_signing_requirement. However, this would again require the creation of an xpc_session_t object, for which in the XPC framework one will find declarations like: @available(macOS, introduced: 13.0, deprecated: 14.0, renamed: "XPCSession") @available(macCatalyst, introduced: 16.0, deprecated: 17.0, renamed: "XPCSession") @available(iOS, unavailable) @available(tvOS, unavailable) @available(watchOS, unavailable) public typealias xpc_session_t = OS_xpc_object plus basically all API of XPCSession being originally declared as xpc_session_* APIs and all of them having deprecated: 14.0, renamed: * marks. This is telling me xpc_session_t and XPCSession are in fact the same/same-ish. But again, there is seemingly no conversion between these two types. Which brings me to again being unable to create a code signing requirement for the XPCSession object. I've read some older forum posts, and I saw Apple Engineers admitting the code signing requirement APIs are missing from the new Swift APIs, however they seem to have been added in macOS 14.4 - although it appears to have been mistakenly added to the C-family functions, which have not been exposed to Swift correctly, because they still use the deprecated xpc_listener_t and xpc_session_t types. So my question is: what is going on here? :) Making XPC connections without a code signing requirement in 2025 seems like a no-go, so do I have to still stick with C - even though this new API seems to be focused on Swift?

Hi everyone, I am trying to compress my data using LZMA2 with the help of CocoaPods. Here are the steps I followed to achieve LZMA2 compression: Added the pod 'SWCompression', '~> 4.8' dependency to my Podfile and installed the pod using the terminal. When I try to compress the data using LZMA2, I am unable to do so because in SWCompression, LZMA2 compression is marked as TBD (To Be Determined). Here is the current status of SWCompression: Deflate BZip2 LZMA/LZMA2 LZ4 Decompression ✅ ✅ ✅ ✅ Compression ✅ ✅ TBD ✅ Zlib GZip XZ ZIP TAR 7-Zip Read ✅ ✅ ✅ ✅ ✅ ✅ Write ✅ ✅ TBD TBD ✅ TBD Since LZMA2 compression is still marked as TBD, is there any other way to achieve LZMA2 compression for my data in SwiftUI?

I am trying to follow the guidance for testing a Local Experience, as listed in the Testing Your App Clip’s Launch Experience - https://developer.apple.com/documentation/app_clips/testing_your_app_clip_s_launch_experience documentation. I have successfully created my App Clip target, and can confirm that running the App Clip on my device does launch the App Clip app as I expected. Further, I can successfully test the App Clip on device, by setting the _XCAppClipURL argument in the App Clip's scheme. I would like to test a Local Experience. The documentation states that for testing Local Experiences; To test your app clip’s invocation with a local experience, you don’t need to add the Associated Domains Entitlement, make changes to the Apple App Site Association file on your web server, or create an app clip experience for testing in TestFlight. Therefore, I should be able to configure a Local Experience with any desired domain in Settings -> Developer -> Local Experience, generate a QR code or NFC tag with that same URL, and the App Clip experience should appear. I have taken the following steps; Built and run my App Clip on my local device. In Settings -> Developer -> Local Experience, I have registered a new experience using a URL prefix https://somewebsite.com Set my Bundle ID to com.mycompany.myapp.Clip, which exactly matches the Bundle Identifier, as listed in Xcode, under my App Clip target. Generated a QR code which directs me to https://somewebsite.com In theory, I believe I should be able to open the Camera app on my device, point the camera at the QR code, and the App Clip experience should appear. However, I received mixed experiences. 50% of the time, I receive a pop-up directing me to open https://somewebsite.com in Safari, the other 50% of the time, no banner or action occurs whatsoever. Is this an issue anyone has faced before, or have I pursued these steps out of order?

Hello, We're facing an issue with app links failing and falling back to browser website journeys. Our apple-app-site-association file is hosted publicly and the app to app journeys have been working correctly up to very recently - we are trying to identify any potential network infra changes that could have impacted the Apple CDN being able to retrieve the apple-app-site-association file. We can see in the iPhone OS logs that the links cannot be verified by the swcd process, and using the app-site-association.cdn-apple.com/a/v1 api via curl can also see the CDN has no record of the AASA file. Due to the traffic being SSL and to a high volume enterprise site it is difficult for use to trace activity through anything other that the source IPs - we cannot filter on user-agent for "AASA-Bot/1.0.0" as breaking the SSL would be impactful due to the load. Is it possible to get a network range used by the Apple CDN to retrieve the AASA file as this would help us identify potential blocking behaviour? Thank you.

I don't see anything obvious in this crash report. Can anyone learn me what went wrong? ZZZMMMM-2025-01-28-212901.ips

Hello, In our application, we have implemented an app extension to allow users to open the main app directly from the share activity window. To achieve this, we used the openURL(:) method from the NSExtensionContext class, as documented here: openURL(:). However, we received one post from Apple stating that opening the main app directly is typically only supported in extensions such as Today widgets or iMessage apps. They also mentioned that this approach may require an additional review during the App Store submission process. Link: https://developer.apple.com/documentation/foundation/nsextensioncontext/1416791-openurl Could someone clarify: If using openURL(_:) in a share extension to open the main app would lead to potential issues during App Store submission? Are there specific guidelines or alternative approaches we should follow to ensure compliance? Any insights or recommendations would be greatly appreciated. Thank you!

I'm developing a watchOS app for Watch Ultra 2 that implements water detection using CMSubmersionManager. I would like to make it appear in the Auto-Launch settings menu, but my app is not appearing in the settings (Settings > General > Auto-Launch > When Submerged > Selected App).... What additional steps should I take to make this work? Environment Device: Watch Ultra 2 watchOS: 11.2 Xcode: 16.0 Implementation I have implemented the following as per documentation: Added the Shallow Depth and Pressure capability and Entitlement. Added the "Shallow Depth and Pressure" capability Confirmed entitlement "com.apple.developer.submerged-shallow-depth-and-pressure" was automatically added Note: I initially thought I should use "com.apple.developer.submerged-depth-and-pressure" (without "-shallow") since I'm targeting a maximum depth of 6 meters, but this resulted in compilation errors. ref: https://developer.apple.com/forums/thread/740083 ref: https://developer.apple.com/forums/thread/735296 Added NSMotionUsageDescription and WKBackgroundModes <key>NSMotionUsageDescription</key> <string>Required for water detection</string> <key>WKBackgroundModes</key> <array> <string>underwater-depth</string> </array> According to the documentation: "It also adds your app to the list of apps that the system can autolaunch when the wearer submerges the watch." What additional steps are needed to make the app appear in Auto-Launch settings? Has anyone successfully implemented this feature?

Reading text out of PDFs with PDFKit results in some text being returned way out of order when using .string or .attributedString functions. Way out of order means not just wrong sorting of words on a line or wrongly showing up on the next line (as has happened with PDFKit on older iOS releases, e.g. 17.x), but some text (one or more words) may show up near the end of a page of text, while it should show near the beginning. As Page.characterBounds(at:) is buggy in iOS 18.x returns wrong bounds, devs cannot correct such faulty PDFKit behaviour programmatically. I believe it is on Apple to fix this iOS 18 bug asap. Thank you for giving it priority as this is killing apps that need PDFKit to get and parse text data out of PDFs. I have filed Feedback FB16264926.

Hello, I added a printer using lpadmin command. ` lpadmin "-p", "print_queue", "-D", "print queue", "-P", "temp/data/driver.ppd", "-E", "-o", "printer-error-policy=abort-job", "-o", "printer-is-shared=false", "-o", "cupsIPPSupplies=false", "-o", "cupsSNMPSupplies=false", "-o", "ColorModel=Color", "-o", "Media=A3", "-o", "OutputPaperSize=A3" then I set default printing options for your user account via lpoptions `lpoptions "-p", "print_queue", "-o", "Duplex=DuplexNoTumble", "-o", "Media=A3" But still default values in system print dialog are set to a4 and grayscale. Why? Is there any way how to change it to correspond with values set by these commands? Also tried to change driver files defaults, but again, nothing.