Hello, I have an app in AppStore "Counter Widget". https://apps.apple.com/app/id1522170621 It allows you to add a widget to your homescreen/lockscreen to count anything. Everything works fine except for one scenario. iOS 18+ I create 2 or more widgets for one counter. For example, medium and small widgets. I click on the widget button to increase or decrease the value. The button in the widget uses Button(intent: AppIntent) to update the value and calls WidgetCenter.shared.reloadAllTimelines() to update the second widget for the same counter. For iOS 18 in this particular scenario, you don't even have to call the WidgetCenter.shared.reloadAllTimelines(). iOS already knows that there is a widget with the same INIntent settings and will update it itself. Both widgets are updated and show the new value. Everything is correct. Now on the homescreen I open the widget configuration for one of the widgets to change the INIntent for the widget. For example, i change the background to wallpaper. This is just a skin for the widget, and the widget is associated with the same counter value as before. As in (2), I click the widget button to increase or decrease the value. But now only one widget is updated. iOS ignores my call to WidgetCenter.shared.reloadAllTimelines() and does not update the second widget connected to the same counter. As I found, iOS, when I call WidgetCenter.shared.reloadAllTimelines() from the widget itself, updates other widgets only if INIntent is absolutely equal for them. Overriding isEqual for them did not help. That is, I cannot specify which fields from my INIntent can be ignored during such an update and consider that widgets are equal and need to be updated. Obviously iOS make this compare outside my code. The main problem is that when the user adds a widget to the lock screen and increases and decreases the value there. After that, he opens the home screen and the widget there is not synchronized with the value from the widget on the lock screen. How to solve this problem?

I am building a MacOS desktop app (https://anukari.com) that is using Metal compute to do real-time audio/DSP processing, as I have a problem that is highly parallelizable and too computationally expensive for the CPU. However it seems that the way in which I am using the GPU, even when my app is fully compute-limited, the OS never increases the power/performance state. Because this is a real-time audio synthesis application, it's a huge problem to not be able to take advantage of the full clock speeds that the GPU is capable of, because the app can't keep up with real-time. I discovered this issue while profiling the app using Instrument's Metal tracing (and Game tracing) modes. In the profiling configuration under "Metal Application" there is a drop-down to select the "Performance State." If I run the application under Instruments with Performance State set to Maximum, it runs amazingly well, and all my problems go away. For comparison, when I run the app on its own, outside of Instruments, the expensive GPU computation it's doing takes around 2x as long to complete, meaning that the app performs half as well. I've done a ton of work to micro-optimize my Metal compute code, based on every scrap of information from the WWDC videos, etc. A problem I'm running into is that I think that the more efficient I make my code, the less it signals to the OS that I want high GPU clock speeds! I think part of why the OS is confused is that in most use cases, my computation can be done using only a small number of Metal threadgroups. I'm guessing that the OS heuristics see that only a small fraction of the GPU is saturated and fail to scale up the power/clock state. I'm not sure what to do here; I'm in a bit of a bind. One possibility is that I intentionally schedule busy work -- spin threadgroups just to waste energy and signal to the OS that I need higher clock speeds. This is obviously a really bad idea, but it might work. Is there any other (better) way for my app to signal to the OS that it is doing real-time latency-sensitive computation on the GPU and needs the clock speeds to be scaled up? Note that game mode is not really an option, as my app also runs as an AU plugin inside hosts like Garageband, so it can't be made fullscreen, etc.

I updated to iOS 18.2 beta 2, and with it, I am able to see behind the early access requested by just swiping down, but when I do swipe down, the app closes. Does this mean I'm close to getting access?

Hello, Since 2017 I provide a free and open source Remote Desktop for macOS, Windows and Linux that supports macOS 10.7 to macOS 15. Screen capture is done with CGDisplayCreateImage and works fine. But there is a problem on macOS 15 Sequoia I can not capture the screen in the pre-login context (I am referring to the login screen before the user access into his account). The screen capture in pre-login context works fine for all macOS versions except macOS 15 Sequoia. In last weeks I tried to fix the issue without success: tried CGDisplayStream tried AVCaptureScreenInput tried ScreenCaptureKit tried to sign the App (and executable) None of these work before the user login, but them works only when the user is logged in. Additional info: I run the App with "launch agent" when user is connected. I run the App with "launch daemon" when user is not connected. Any help would be greatly appreciated!

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

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

Under iPhone 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 try deviceController?.setupCommissioningSession(with: payload, newNodeID: commissioningDeviceID) After some time: func controller(_: MTRDeviceController, statusUpdate status: MTRCommissioningStatus) Return failure

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.

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 am working on an app on which I want to develop a feature to install eSIMs. I am trying to follow the approach of installing the eSIM with the Universal Link solution by appending the activation code to the link https://esimsetup.apple.com/eSIM_QRCode_Provisioning?carddata=. I was able to successfully call the link and install the eSIM. But after installation, the user stays on the settings app. Is it possible to bring my app back to foreground after installation? Furthermore, is there a way I can listen to the installation result from my app?

I am working in Carrier app i want to check sim change event in my iOS app. please guide me how i can get sim change event. Thanks

I'm developing an app which supports for connect with an BLE device. There are some views for showing data from bluetooth. The code below for an example: @EnvironmentObject var bleManager: BLEManager // a class implemented CBCentralManagerDelegate var body: some View { // bleConnected is a CBPeripheral if let bleConnected = bleManager.bleConnected { if let services = bleConnected.services { ForEach(services, id:\.self) { service in // UI for print uuid, descriptions ... showServiceDescriptionView(services) if let characteristics = service.characteristics { ForEach(characteristics, id:\.self) { characteristic in // UI for print uuid, data for each characteristic showCharacteristicsDetailView(characteristic) } } } } } } } But it seems that Xcode Preview do not support connect to a real bluetooth device. So the preview window in Xcode will always be a empty view. I only can see the data on the real device. But it's important for me to design UI on the preview. So are there any method to mock a fake CBPeripheral in the Previewer? Or are there any other way to achieve this?

If I go to "System Settings" -> "General" -> "About", it says "MacBook Air" and below that "M2, 2022" How can I get these strings programatically? The following C code gets me #include <stdio.h> #include <sys/sysctl.h> int main() { static const unsigned namelen = 2; int name[namelen] = {CTL_HW, HW_PRODUCT}; char buffer[256]; size_t bufferSize = sizeof(buffer); if (0 != sysctl(name, namelen, buffer, &bufferSize, NULL, 0)) { perror("sysctl"); return 1; } printf("%s\n", buffer); } the string "Mac14,2", which is the hardware model identifier. But I want to get the user-friendly model name, e.g. "MacBook Air (13-inch, M2, 2022)". How can I do this?

Hi. I am having trouble with the issue where the media name and storage information name, which matched in MacOS 14 and earlier, are now inconsistent with the volume label and "NO NAME" in MacOS 15. The problem is that while changing the name on macos 15 will temporarily unify the names, if you overwrite them on Windows they revert to "NO NAME". At first I thought it was reflecting BS_VolLab in the boot sector, but that doesn't seem to be the case. Do you have any ideas for writing a program for Windows to solve this problem?

Two days ago, the build number was 24B83, and now it's 24B2083, yet software updates don't see 24B2083 as the latest download.

Extracting an archive into the same directory on my custom filesystem more than once fails with the following message: Unable to finish expanding 'misc.tar.xz' into 'extractme'. Could not move 'misc' into destination directory. I.e. initial extraction succeeds with archive contents extracted into extractme/misc. Subsequent extraction fails to rename extractme.sb-db71cd27-lFjN1f/misc to extractme/misc 2. This behaviour is observed on macOS Monterey and Ventura. It does work as expected on macOS Sonoma though. Dtrace(1)-ing the archive being extracted over smbfs results in the following sequence of calls being made: 2 -> smbfs_vnop_lookup AUHelperService-2163 -> extractme/misc 2 nameiop:0 2 <- smbfs_vnop_lookup AUHelperService-2163 -> extractme/misc 2 -> 2 ;ENOENT 2 -> smbfs_vnop_lookup AUHelperService-2163 -> extractme.sb-db71cd27-lFjN1f/misc nameiop:0x2 ;DELETE 2 <- smbfs_vnop_lookup AUHelperService-2163 -> extractme.sb-db71cd27-lFjN1f/misc -> 0 2 -> smbfs_vnop_lookup AUHelperService-2163 -> extractme/misc 2 nameiop:0x3 ;RENAME 2 <- smbfs_vnop_lookup AUHelperService-2163 -> extractme/misc 2 -> EJUSTRETURN 1 -> smbfs_vnop_rename AUHelperService-2163 -> extractme.sb-db71cd27-lFjN1f/misc -> extractme/nil 2 <- smbfs_vnop_rename AUHelperService-2163 -> extractme.sb-db71cd27-lFjN1f/misc -> extractme/nil -> 0 2 -> smbfs_vnop_lookup AUHelperService-2163 -> TheRooT/extractme/misc 2 nameiop:0 3 <- smbfs_vnop_lookup AUHelperService-2163 -> TheRooT/extractme/misc 2 -> 0 ;Successful lookup What I don't understand is what causes vnop_lookup to be called for misc to be removed from the temporary directory and renamed into 'misc 2' and placed in the destination directory, 'extractme' via vnop_rename? I had a look at smbfs_vnop_lookup and rename and didn't see anything that would cause 'misc 2' to come into being. Based on the output of the dtrace(1) script running on my custom filesystem, there are no vnop_lookup and vnop_rename calls being made to remove the 'misc' directory from the temporary directory and to rename it to 'misc 2' and place it in the destination directory at extractme. Archive extraction proceeds no further after extracting the archive contents into the temporary directory. What am I missing?

Hey, when I try to run my project on an iOS Simulator, I get the following message: JournalingSuggestions is not available when building for iOS Simulator. and Linker command failed with exit code 1 (use -v to see invocation) Steps to reproduce this behavior: Create a new Xcode project Add the Journaling Suggestions Capability Add the Journaling Suggestions Framework Under "Target > Build Phases > Link Binary with Libraries", select “optional“ for JournalingSuggestions.framework Under "Target > Build Settings > Other Linker Flags > Debug" select „Plus“ and add „iOS or iOS Simulator“ and paste this -Xlinker -weak_framework -Xlinker JournalingSuggestions into the editable field. Do the same for "Target > Build Settings > Other Linker Flags > Release" This tread is about the same problem, but is already checked as answered. That's why I'm creating this new tread. The last two bullet points are results from advice from the other thread. MacBook Air, M1, 2020, macOS: 14.6.1, Xcode: 16.0 Thanks for your help!

I am running on Sequoia 15.1 24B83 with the appropriate KDK on both my host and target systems. I am trying to examine the target when it has crashed either due to triggering an NMI or causing a crash in my company's kext. I am not getting very far! I can attach from the host to the target. But I can't run any useful commands, starting with showallkexts. It shows up in the list of 'Current user-defined commands' but fails with the above attribute error when I try to run it. I get that same error trying to use other user-defined commands. I followed the host setup instructions in the KDK readme, but this traceback leads me to think I have overlooked something. If this is something folks have seen before, I would appreciate any guidance!

We’re encountering issues with a system extension that subscribes to multiple events. Some users are experiencing performance problems when running our extension alongside other system extensions like Microsoft Defender and Crowdstrike, which seem to generate a high volume of events. However, on certain Macs with an identical setup, there are no performance issues, making it difficult to pinpoint the cause. Has anyone found ways to improve compatibility with other system extensions? Currently, we’re ignoring and caching events from other extensions to avoid unnecessary processing. The specific ES events contributing to the issue seem to be: • ES_EVENT_TYPE_AUTH_EXEC • ES_EVENT_TYPE_AUTH_OPEN I realize this is a broad question, but the documentation for endpoint security extensions is quite limited. Any insights or suggestions would be greatly appreciated!