Under Ventura, desktop wallpaper image names were stored in a sqlite database at ~/Library/Application Support/Dock/desktoppicture.db. This file is no longer being used under Sonoma. I have a process I built that fetches the desktop image file names and displays them, either as a service, or on the desktop. I do this because I have many photos I've taken, and I like to know which one I'm viewing so I can make edits if necessary. I set these images across five spaces and have them randomly change every hour. I tried using AppleScript but it would not pull the file names. A few people have pointed me to ~/Library/Application Support/com.apple.wallpaper/Store/Index.plist. However, on my system, this only reveals the source folder and not the image name itself. On one of my Macs, it shows 64 items, even though I have only five spaces! Is there a way to fetch the image file names under Sonoma? Will Sequoia make this easier or harder?

Hello, We are working on automating some processes for our mac virtual machines pool, and one of the things we are looking for is where we can download various different versions of macOS. When going to the download section of the apple dev portal, it only gives a download link of the latest macOS. Is there no way to obtain download URLs for previous macOS versions as well? For instance, we are trying to validate our automation scripts against Sonoma macOS so we are looking for the download URL , to put in our scripts , or to manually download the file ourselves. Thanks!

Hi, I'm trying to create merchant tokens in ApplePay sandbox environment, so then I can use them to invalidate token API call and lifecycle notifications testing. When processing test payment I use Apple Pay payment request taken directly from Apple's demo website (I skipped non important part of JSON) { ... "recurringPaymentRequest": { "paymentDescription": "A description of the recurring payment to display to the user in the payment sheet.", "regularBilling": { "label": "Recurring", "amount": "4.99", "paymentTiming": "recurring", "recurringPaymentStartDate": "2023-08-11T11:20:32.369Z" }, "trialBilling": { "label": "7 Day Trial", "amount": "0.00", "paymentTiming": "recurring", "recurringPaymentEndDate": "2023-08-11T11:20:32.369Z" }, "billingAgreement": "A localized billing agreement displayed to the user in the payment sheet prior to the payment authorization.", "managementURL": "https://applepaydemo.apple.com", "tokenNotificationURL": "https://applepaydemo.apple.com" }, ... } Payment is successful, but merchantTokenIdentifier in decrypted ApplePay token is always empty, regardless of test card used, I tried Visa, MasterCard, Amex. Anyone have an idea what I'm missing and how to get that merchant token? Is it even possible to test merchant tokens (lifecycle notifications) in sandbox?

Hello Currently, we are developing an application that collects measurement data from devices via USB port but we have some problems regarding input buffer size that might reduce the reading speed. The data size is quite big (~1.5 million bytes). For every read action, the app will check the available size in the input buffer by command: ioctl(serialPort.hHandle, FIONREAD, readBuffSize) Then that size will be passed as the desired size for the read command. Between read actions, there will be a short sleep (1 - 3 ms). Please confirm some points below: Regardless of the size of the measure data, the available size will only be up to 1020 bytes, is it expected? Is the above size OS defined or driver defined? Could we increase it? As we checked, there were some missing bytes between the measure data and the actual read data. Is there any chance that the data in the input buffer be overwritten while the read thread is in sleep? Any recommended technique that can increase reading speed while still maintaining the integrity of the data? Tested OS: Sonoma 14.5

We’ve encountered significant differences in our VoIP app’s workflow between iOS 17 and iOS 18, particularly on devices with Dynamic Island. Our app functioned as expected in iOS 17 and even iOS 18 on devices without Dynamic Island, but with the public release of iOS 18 on Dynamic Island-supported iPhones, we’re receiving a lot of feedback from users reporting confusing behavior during both incoming and outgoing calls. Here’s a breakdown of the issue: In iOS 17 and iOS 18 (on non-Dynamic Island models), when our app initiates a second call, the app remains in the foreground, allowing the user to see both calls within our UI. Users can manage their calls, swap between them, and even merge them, all without leaving the app. If the user switches to the CallKit controller via the app switcher, it reflects the state of the calls in our app, which has worked well for our users. However, on iOS 18 devices with Dynamic Island, adding a second call now backgrounds our app and brings the CallKit controller UI to the foreground. This causes confusion, as users lose context of managing multiple calls within our app. Though users can switch back to our app manually, this extra step disrupts their workflow, especially when handling multiple active calls. This change doesn't occur on iOS 18 devices without Dynamic Island. Additionally, during an active call, if an incoming call arrives, the Dynamic Island notification takes over, and the app UI is again backgrounded in favor of the CallKit controller screen. Even when declining the incoming call from the notification, the user remains in the CallKit controller UI, requiring another step to return to our app using the app switcher or the "app" button in CallKit. This inconsistent behavior makes call management unnecessarily complex for our users, who need a streamlined experience, especially since our app is used in healthcare communications that is often critical in nature. Is there any documentation on changes to CallKit behavior specific to Dynamic Island devices in iOS 18? We’d appreciate any guidance on designing a VoIP experience that doesn’t involve these disruptive view switches, particularly for Dynamic Island-supported iPhones. Thank you for your help!

really easy to access to you account

I am working with the CLBackgroundActivitySession and CLServiceSession to figure out why our app is sometimes terminated in the background. I am unable to understand what "insufficientlyInUse" corresponds to, it could be understood as The location data is not being used enough the "While in use" permission is not enough It will be very helpful if the entire enum can be explained, I am attaching the one for CLServiceSession since it is a superset of CLBackgroundActivitySession from CoreLocation extension CLServiceSession { public struct Diagnostic { public var authorizationDenied: Bool { get } public var authorizationDeniedGlobally: Bool { get } public var authorizationRestricted: Bool { get } public var insufficientlyInUse: Bool { get } public var fullAccuracyDenied: Bool { get } public var alwaysAuthorizationDenied: Bool { get } public var serviceSessionRequired: Bool { get } public var authorizationRequestInProgress: Bool { get } } ... } Looking forward to hearing from you

I have a need to do a coverage test for the networkextension function code implemented by the system extension, but I don't know how to implement this method. For example, how do you use gtest or how do you use xctest to achieve these capabilities? If you know, please let me know. Thanks

We're creating macOS VMs on both 15.x and 14.x hosts and only the 14.x created VMs can run on both 15 and 14 hosts. If we create the VMs on 15.x, something is done by Virtualization that prevents it from running on 14.x. We've tried digging in and don't see anything that our code is doing that's special. What is Apple doing to the VMs created on 15.x hosts that's special here?

https://feedbackassistant.apple.com/feedback/15645457 Metal passthrough on intel VMs causes com.apple.screensharing.menuextra to crash and screensharing to exit Create a 15.1 VM with metal passthrough on 15.0.1 or 15.1 host, enable Screen Sharing, then try connecting to with VNC after restarting the machine. I'm using Anka to create the VM. You'll see VNC work (open vnc://192.168.64.3:5900), then a few seconds in show "Reconnecting...", then work, then go to "Reconnecting..." for ~5m until it eventually works consistently. You'll see launchd showing exits/failures (see screenshots) You'll see diagnostic reports showing things like: Thread 0 Crashed:: Dispatch queue: com.apple.RenderBox.Encoder 0 libsystem_kernel.dylib 0x7ff801da5b52 __pthread_kill + 10 1 libsystem_pthread.dylib 0x7ff801ddff85 pthread_kill + 262 2 libsystem_c.dylib 0x7ff801d00b19 abort + 126 3 libsystem_c.dylib 0x7ff801cffddc __assert_rtn + 314 4 Metal 0x7ff80d045d72 MTLReportFailure.cold.1 + 41 5 Metal 0x7ff80d01fa2a MTLReportFailure + 513 6 Metal 0x7ff80cfb74e0 +[MTLLoader sliceIDForDevice:legacyDriverVersion:airntDriverVersion:] + 200 7 Metal 0x7ff80cf265c9 +[_MTLBinaryArchive(MTLBinaryArchiveInternal) deserializeBinaryArchiveHeader:fileData:device:] + 89 8 Metal 0x7ff80cf10f0c -[_MTLBinaryArchive loadFromURL:error:] + 537 9 Metal 0x7ff80cf10288 -[_MTLBinaryArchive initWithOptions:device:url:error:] + 844 10 RenderBox 0x7ff9041a15fd RB::(anonymous namespace)::load_library_archive(NSBundle*,

I'm working on a network extension that provides a VPN tunnel. The logic behind the tunnel provider requires me to connect the backend to pull recent configuration and then configure the routing. It works in general but fails with some circumstances. I have 100% reproducible fails if I run OpenVPN tunnel in parallel. When it happens it looks like the network extension cannot connect the backend (any internet resource actually). Requests fail by timeout. To troubleshoot this situations I've added NWPathMonitor at my NEPacketTunnelProvider subclass: pathMonitor?.pathUpdateHandler = { path in logger.info("Path update: \(path)") logger.info(" : \(path.availableInterfaces)") } On successful scenarios I observed logs: 14:53:19:829 Starting VPN tunnel... 14:53:19:895 Path update: satisfied (Path is satisfied), interface: en0[802.11], scoped, ipv4, ipv6, dns, uses wifi 14:53:19:899 : [en0] 14:53:22:237 Path update: satisfied (Path is satisfied), interface: en0[802.11], scoped, ipv4, ipv6, dns, uses wifi 14:53:22:253 : [en0, utun12] 14:53:22:325 VPN tunnel is started. But if I start another tunnel first using OpenVPN (it's our corporate VPN) I observe failures with such log messages: 14:54:26:113 Starting VPN tunnel... 14:54:26:140 Path update: satisfied (Path is satisfied), interface: en0[802.11], scoped, ipv4, ipv6, dns, uses wifi 14:54:26:141 : [en0] 14:55:28:259 Failed to start VPN tunnel. utun12 that was used by the extension in case of success is now occupied by the OpenVPN tunnel. The system creates utun13 for me but it feels like its misconfigured: > ifconfig (omitted most of the output) utun12: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 172.28.11.236 --> 172.28.10.1 netmask 0xfffffe00 nd6 options=201<PERFORMNUD,DAD> utun13: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM> Is it a system bug and what else can I do to diagnose the root cause of these failures?

Is it possible to use CloudKit and add integrations, Google Drive for example. If possible, how?

Our app experience the strange crash,causing the app to not launch.This crash suddenly began to happen on October 25. At present, all the Hardware Model of mobile phones that occurred were on iPhone17,1 and the iOS system version was iOS18.0.1. This crash was all from users on the appstore, and was collected via Xcode - Organizer - &gt; Crashes. I've attached the crash report.Thanks Distributor ID: com.apple.AppStore Hardware Model: iPhone17,1 Process: XxxxxxXXX [31230] Path: /private/var/containers/Bundle/Application/6E9E07EA-B7A4-4D57-B419-743DDCF7C3A6/XxxxxxXXX.app/XxxxxxXXX Identifier: com.XxxxxxXXX.XxxxxxXXX Version: 8.1.10 (811001) AppStoreTools: 16A242d AppVariant: 1:iPhone17,1:18 Code Type: ARM-64 (Native) Role: unknown Parent Process: launchd [1] Coalition: com.XxxxxxXXX.XxxxxxXXX [8069] Date/Time: 2024-10-31 03:30:38.7437 +0800 Launch Time: 2024-10-31 03:30:38.7415 +0800 OS Version: iPhone OS 18.0.1 (22A3370) Release Type: User Baseband Version: 1.00.00 Report Version: 104 Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: GUARD 5 Triggered by Thread: 0 Thread 0 Crashed: 0 dyld 0x00000001b2da32b0 lsl::PreallocatedAllocatorLayout&lt;278528ull&gt;::init(char const**, char const**, void*) + 436 (Allocator.h:537) 1 dyld 0x00000001b2d9ca38 start + 1960 (dyldMain.cpp:1289) Thread 0 crashed with ARM Thread State (64-bit): x0: 0x2010003030100000 x1: 0x0000000fffffc0d0 x2: 0x0000000000000002 x3: 0x00000001b2d717ab x4: 0x0000000000000000 x5: 0x0000000000000000 x6: 0x0000000000000000 x7: 0x0000000000000000 x8: 0x2010003030100000 x9: 0x2010003030100000 x10: 0x000000016d1dbdfb x11: 0x00000001b2dddf30 x12: 0x0000000000000050 x13: 0x0000000000000044 x14: 0x0000000000052010 x15: 0x0000000000000000 x16: 0x0000000000000000 x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x000000018a7e0000 x20: 0x000000016d1dbb30 x21: 0x000000016d1dbad0 x22: 0x00000001f0794050 x23: 0x000000016d1db7b8 x24: 0x0000000fffffc10c x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000 x28: 0x0000000000000000 fp: 0x000000016d1db850 lr: 0x00380001b2da3130 sp: 0x000000016d1db7b0 pc: 0x00000001b2da32b0 cpsr: 0x60000000 esr: 0x92000047 (Data Abort) byte write Translation fault Binary Images: 0x102c24000 - 0x1056d3fff main_executable_path_missing arm64 &lt;086a82c13b863f4485895baddc3144ba&gt; /main_executable_path_missing 0x1b2d69000 - 0x1b2dec693 dyld arm64e &lt;5db839882ee63756bd07b8d67b1133a5&gt; /usr/lib/dyld EOF 2024-10-26_17-41-58.4222_+0800-841f6bdf4b2d436606ce55595ffc94d64e9af744.crash 2024-10-26_19-44-40.1115_+0800-7d4d654c76a10108b431acc612d6063b1edb1c3e.crash 2024-10-27_17-12-02.4926_+0800-6a4b6ec4cff928cf746162b9371a3176c3667c21.crash 2024-10-28_21-42-02.6780_+0800-c66c71c13414e7ff14ba783c883730c1361523b5.crash 2024-10-29_05-47-00.3943_+0800-ac7c1f5b6caf9aa97d71744a8f980c32d47eab80.crash 2024-10-31_03-30-38.7437_+0800-e1c54dc8879f97932cbb1520a04210bea6d7aaf4.crash 2024-11-03_07-57-18.8892_+0800-c7704569afc79ce50ac10b66e185de87425b1969.crash 2024-11-03_08-27-19.0514_+0800-c069e2f8dfa6767b8e301513aff3c3a7ea331e2c.crash

To resolve this issue, please revise the app preview to only use video screen captures of the app. These may include narration and video or textual overlays for added clarity

The app exits immediately on startup, there is no crash message, and I can't get any valuable diagnostic information. It doesn't even get to the main function. It feels like exit is being called somewhere, and then I used atexit to register the relevant handler. Finally, I found the following stack printout It looks like it's a dynamic linking issue, so what's the best way to troubleshoot it. This problem only occurs in release versions.

We developed a app in which the I need the app to update the User's location even in background( even after terminating from the recent UI ), Currently I am receiving the location updates when the user has kept the app in open and if minimised, But I want that it should update the location even when it is removed from recent app (minimised UI)(after terminating the app) Is it possible to do so.???

I'm integrating AdMob rewarded interstitial ads into my live iOS app using CocoaPods and package dependency management. The ads are working fine when I use the bundle identifier com.CreativeCub.ProgrammingHu, but when I use the correct identifier com.CreativeCub.ProgrammingHub, the ads stop working. Here’s what I’ve tried: Verified that the bundle identifier matches across Xcode and AdMob. Double-checked the App ID and Ad Unit ID in the AdMob dashboard for com.CreativeCub.ProgrammingHub. Reinstalled the AdMob SDK using CocoaPods. Attempted to integrate AdMob using Swift Package Manager. Created a test project to rule out potential issues with my existing project. Despite these steps, ads only work when I use the shortened bundle identifier (com.CreativeCub.ProgrammingHu), which is not the correct one. Contacted Google admob support for the same but did not worked Tried running in different MacBook system

I'm continually getting an error with a new CloudKit container when I try to save data. error: Couldn't get container configuration from the server for container "iCloud.com.***.***" here's the class: private var db = CKContainer(identifier: "iCloud.com.***.***").privateCloudDatabase func addTask(taskItem: TaskItem) async throws { checkStatus() do { try await db.save(taskItem.record) } catch { print("error: \(error.localizedDescription)") } } func checkStatus() { let id = CKContainer(identifier: "iCloud.com.***.***").containerIdentifier print(id ?? "unknown") Task { let status = try await CKContainer(identifier: "iCloud.com.***.***").accountStatus() switch status { case .available: print("available") case .noAccount: print("no account") case .restricted: print("restricted") case .couldNotDetermine: print("could not determine") case .temporarilyUnavailable: print("temporarily unavailable") @unknown default: break } } } The account status reports as available but gives the error on an attempt to save.. I'm trying to work out what I might be doing wrong..

Under iOS18.1 and Xcode 16.1, use Matter and MatterSupport to pair Matter devices. It was found that Matter over WIFI devices could not trigger the PASE process let device = try deviceController? .deviceBeingCommissioned(withNodeID: commissioningDeviceID) After some time: func controller(_: MTRDeviceController, statusUpdate status: MTRCommissioningStatus) Return failure Device logs: E (47956) chip[ZCL]: Commissioning window is currently not open I (48789) chip[EM]: <<< [E:17954r S:13425 M:26847390 (Ack:206367876)] (S) Msg TX to 1:00000000EE53575F [AE90] [UDP:[FE80::148F:AC68:D736:CA5C%st1]:58332] --- Type 0001:09 (IM:InvokeCommandResponse) E (48798) chip[DL]: Long dispatch time: 867 ms, for event type 3 I (48804) chip[EM]: >>> [E:17954r S:13425 M:206367876 (Ack:26847387)] (S) Msg RX from 1:00000000EE53575F [AE90] --- Type 0001:08 (IM:InvokeCommandRequest) I (48819) chip[EM]: <<< [E:17954r S:13425 M:26847391 (Ack:206367876)] (S) Msg TX to 1:00000000EE53575F [AE90] [UDP:[FE80::148F:AC68:D736:CA5C%st1]:58332] --- Type 0000:10 (SecureChannel:StandaloneAck) I (48838) chip[EM]: >>> [E:17954r S:13425 M:206367876 (Ack:26847387)] (S) Msg RX from 1:00000000EE53575F [AE90] --- Type 0001:08 (IM:InvokeCommandRequest) I (48851) chip[EM]: <<< [E:17954r S:13425 M:26847392 (Ack:206367876)] (S) Msg TX to 1:00000000EE53575F [AE90] [UDP:[FE80::148F:AC68:D736:CA5C%st1]:58332] --- Type 0000:10 (SecureChannel:StandaloneAck) I (48935) chip[EM]: >>> [E:17954r S:13425 M:206367877 (Ack:26847390)] (S) Msg RX from 1:00000000EE53575F [AE90] --- Type 0000:10 (SecureChannel:StandaloneAck) I (48952) chip[EM]: >>> [E:17955r S:13425 M:206367878] (S) Msg RX from 1:00000000EE53575F [AE90] --- Type 0001:0a (IM:TimedRequest) I (48957) chip[EM]: <<< [E:17955r S:13425 M:26847393 (Ack:206367878)] (S) Msg TX to 1:00000000EE53575F [AE90] [UDP:[FE80::148F:AC68:D736:CA5C%st1]:58332] --- Type 0001:01 (IM:StatusResponse) I (48998) chip[EM]: >>> [E:17955r S:13425 M:206367879 (Ack:26847393)] (S) Msg RX from 1:00000000EE53575F [AE90] --- Type 0001:08 (IM:InvokeCommandRequest) I (49019) esp_matter_command: Received command 0x00000000 for endpoint 0x0000's cluster 0x0000003C I (49019) chip[ZCL]: Received command to open commissioning window I (49025) chip[DIS]: Updating services using commissioning mode 2 I (49087) chip[DIS]: CHIP minimal mDNS started advertising. I (49093) chip[DIS]: Advertise operational node 752B90252951AE90-000000005B4AA994 I (49094) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'; instance name: 752B90252951AE90-000000005B4AA994. I (49105) chip[DIS]: mDNS service published: _matter._tcp I (49109) chip[DIS]: Advertise commission parameter vendorID=5493 productID=8228 discriminator=0741/02 cm=2 I (49120) chip[DIS]: CHIP minimal mDNS configured as 'Commissionable node device'; instance name: 1D59D05DF5376A3B. I (49137) chip[DIS]: mDNS service published: _matterc._udp I (49137) chip[ZCL]: Commissioning window is now open I (49143) chip[EM]: <<< [E:17955r S:13425 M:26847394 (Ack:206367879)] (S) Msg TX to 1:00000000EE53575F [AE90] [UDP:[FE80::148F:AC68:D736:CA5C%st1]:58332] --- Type 0001:09 (IM:InvokeCommandResponse) I (49161) app_main: Commissioning window opened I (49200) chip[EM]: >>> [E:17955r S:13425 M:206367880 (Ack:26847394)] (S) Msg RX from 1:00000000EE53575F [AE90] --- Type 0000:10 (SecureChannel:StandaloneAck) I (69380) SENSOR: Temp: 236 I (69383) ACInterface: AC event ntc :236

The VM gets a NAT IP just fine, but it doesn't have access through the proxy so I'm guessing 15.x macOS setup has a bug where it can't break out of a loop trying to phone home back to macOS. FBID: FB15689777 This is not an issue for 14.x VMs. It's also seen across different Virtualization tools.