We have modified the program as we received in the previous(thread 764479) issue. Our program works very well and the notification problem has been almost solved in the test. Then, we tested it in the user's environment. At that time, one of the three iPhones stopped receiving notifications. After 10 minutes, VoIP notifications were received again. This device received PUSH notifications even when VoIP notifications did not come. We must explain to the user why this incident occurred. We would like to know if these three notifications were sent correctly to the device. Also, is there any other way for us to deal with this other than improving the network? [APNS LIST]Nov. 20th could not receive(failed) 15:06:13　5793987C-D1A4-811F-917F-87DD7F5083B3 15:07:09　667E0A2F-43B5-37FC-2F2A-45A6C27EFC34 15:19:31　1353DF78-519E-B1DC-82B7-8B890E59FE37 received（success） 15:04:09　19CC1937-533A-9AF4-9472-41C839E461D7 15:35:00　CD23AC57-6EC7-4523-941F-B103EDB4DEFB

When we upload workout data to HealthKit the route information with the workout detailed data is incomplete: just a few dots. When we select "Show all workout routes" the route data for the same workout shows correctly. We use the HKWorkoutBuilder to store the workout data, and add the location data with the HKWorkoutRouteBuilder to the workout with Is this an Apple Health issue, or do we have to change something in the way we store the location data to the workout?

I'm trying to add Cloud Kit integration to SwiftData app (that is already in the App Store, btw). When the app is installed on devices that are directly connected to Xcode, it works (a bit slow, but pretty well). But when the app is distributed to Testflight internal testers, the synchronization doesn't happen at all. So, is this situation normal and how can I test apps with iCloud integration properly?

I have a command line app under active development in XCode. It is based on receiving multicast traffic and processing it. I generate this traffic with another app, and generally just leave it running. When I do a build and run in XCode, I get a message asking me for Local Access. If I click yes, no network traffic will be received. I need to restart the command line tool multiple times until I get access. I'm also getting a ton of repeated entries in my Setting->Privacy->Local Access. If I configure xcode to launch with terminal, it does work, but that's not a great solution because of the external window (and the fact that I have terminal set "close if exit cleanly", so I lose my data. I can change that setting, but it is fairly inconvenient, and I don't get the console history in XCode. Is there a way to allow my apps to run from xcode without the pop-up or with the delay in activating the network and creating new entries in the Settings? Thanks!

I have been trying to access the test flight since yesterday but was not able to access instead it displayed the below message. "Before you can start testing, a developer has to invite you to test one of their TestFlight apps.To accept an invite, click on the link in the email or enter invitation redeem code" - Attached the scrrenshot Once I clicked on redeem there is a pop-up displayed that asked me to enter the Test flight invitation code which I did not get. - Attached the screenshot This is purely to test the Chrome beta version to test the compatibility and not any personal apps. Can someone help me out to solve this issue?

The user has already enabled local network permissions. However, when I use nw_connection_t for a local network TCP connection, nw_path_unsatisfied_reason returns nw_path_unsatisfied_reason_local_network_denied. The system logs also indicate a lack of local network permissions. This is an intermittent bug that typically occurs after uninstalling and reinstalling the app. Restarting the app does not help, toggling permissions on and off does not work, and uninstalling and reinstalling the app also fails to resolve the issue. Restarting the phone is the only solution, meaning users can only fix it by rebooting their device.

My application needs local network access. When it is started for the first time, the user gets a prompt to enable local network access (as expected). The application is then shown as enabled in Privacy & Security / Local Network and local network access is working. If macOS is then shutdown and restarted, local network access is blocked for the application even though it is still shown as enabled in Privacy & Security / Local Network. Local network access can be restored either by toggling permission off and on in Privacy & Security / Local Network or by disabling and enabling Wi-Fi. This behaviour is consistent on Sequoia 15.1. It happens sometimes on 15.0 and 15.0.1 but not every time. Is my application doing something wrong or is this a Sequoia issue? If it is a Sequoia issue, is there some change I can make to my application to work around it?

I have an app whose logic is in C++ and rest of the parts (UI) are in Swift and SwiftUI. When an exception is raised by some C++ code, I'm using the Linux signal handler mechanism to trap it. From my previous post, I understand that fatal exceptions like SIGSEGV, SIGBUS, SIGFPE etc., there's nothing much that can be done by the process. My only intent for using a signal handler is to log something, so that it becomes easy to fix during development. Ofc, even that logging can fail, based on the severity of the exception, but that's okay... make an attempt to log - if it works, great, else the process can terminate. I'm registering for SIGSEGV and SIGFPE with the following code // ExceptionHandlingCpp.hpp file struct tSignals { SignalHandlerFunc signalHandlerFunc; uint32_t signal; [[maybe_unused]] uint8_t reserved[4]; }; // ExceptionHandlingCpp.cpp file tSignals ExceptionHandlingCpp::unixSignals[] = { {HandleSignals, SIGFPE, {0}}, {HandleSignals, SIGSEGV, {0}}, {HandleSignals, SIGKILL, {0}}, }; std::string ExceptionHandlingCpp::signalToString(int signal) { switch(signal) { case SIGFPE: return "SIGFPE"; case SIGSEGV: return "SIGSEGV"; case SIGKILL: return "SIGKILL"; default: return "Unknown signal"; } } void ExceptionHandlingCpp::RegisterSignals() { LOG("ExceptionHandlingCpp::RegisterSignals()"); struct sigaction sa; sa.sa_flags = SA_SIGINFO; for(int i = 0; i < sizeof(unixSignals)/sizeof(tSignals); ++i) { sa.sa_sigaction = unixSignals[i].signalHandlerFunc; if(sigaction(unixSignals[i].signal, &sa, nullptr) == 1) { LOG("Failed to set " + signalToString(unixSignals[i].signal) + "'s signal handler!"); } else { LOG(signalToString(unixSignals[i].signal) + "'s signal handler set sucessfully!"); } } } In my signal handler (HandleSignals method), immediately after trapping a signal, I log something and set the default handler... This breaks out of the loop that occurs when returning from the signal handler. // ExceptionHandlingCpp.cpp void ExceptionHandlingCpp::HandleSignals(int pSignal, siginfo_t *pInfo, void *pContext) { LOG("ExceptionHandlingCpp::HandleSignals(int, signinfo_t*, void*)"); LOG("signal = " + signalToString(pSignal)); UnregisterSignals(pSignal); LOG("Returning from exception handler..."); } void ExceptionHandlingCpp::UnregisterSignals(int pSignal) { LOG("UnregisterSignals(int)"); struct sigaction defaultAction {}; defaultAction.sa_handler = SIG_DFL; if(sigaction(pSignal, &defaultAction, nullptr) == -1) { LOG("Error in resetting action for " + signalToString(pSignal)); } else { LOG("Successfully reset " + signalToString(pSignal) + "'s action to default!"); } } When I test this code by raising SIGSEGV (as shown below), void ExceptionHandlingCpp::DereferenceNullPtr () { LOG("DereferenceNullPtr()"); int* ptr = nullptr; LOG("Raising exception..."); int value = *ptr; } everything works as expected. Signal handler is invoked, default handler is set and the process immediately quits. But when I try to raise a SIGFPE, void* ExceptionHandlingCpp::DivisionByZero ([[maybe_unused]] void* pParms) { LOG("DivisionByZero()"); int num1; int num2; int result; num1 = 5; num2 = 0; LOG("Raising exception..."); result = num1 / num2; LOG("Returning from DivisionByZero() method"); return nullptr; } my signal handler is not invoked (as shown in the logs below). The process doesn't terminate either. It seems that the flow simply 'walks over' this division by zero instruction as if nothing happened and returns from that method, which shouldn't have happened, as the process should've terminated after reaching my signal handler. RegisterSignals() SIGFPE's signal handler set sucessfully! SIGSEGV's signal handler set sucessfully! SIGKILL's signal handler set sucessfully! .... DivisionByZero() Raising exception... Returning from DivisionByZero() method .... AppDelegate.applicationWillBecomeActive(_:) AppDelegate.applicationDidBecomeActive(_:) ... // UI is displayed Why is SIGFPE not raised? What am I missing here?

I've been trying very unsuccessfully to get the Filtering Network Traffic example code to work. I've read many forum posts but I still wasn't able to figure it out. I download the example project and set my development team for both targets. From then on the project is configured to create unique bundle identifiers and app group. Signing and provisioning profile is created and managed by Xcode with all the necessary entitlements. I am able to build the app (debug with provisioning profile) and then copy it to /Applications. I open the app, click start, enable and allow the network extension. Activity Monitor shows that the extension is running. But when I test local connections to port 8888 nothing happens in the app, the connection are just allowed. I tested with the following setup: create a local webserver with python3 -m http.server 8888 and make a request via curl and the webbrowser normal tcp connection with nc (nc -l 8888 and nc localhost 8888) I added lots of logging and I can see that the startFilter method is called, but never the handleNewFlow method. The only error I see in Console is networkd_settings_read_from_file Sandbox is preventing this process from reading networkd settings file at "/Library/Preferences/com.apple.networkd.plist", please add an exception. but don't know what to do about that. I also read the debugging guide (very helpful). I'm used to jump through a lot of hoops with this stuff, but I can't figure out what the problem is.

I am developing a macOS app that requires the ability to create new files in the same directory as a user-selected file, but I am encountering permission issues due to the App Sandbox restrictions. While the user can select a file (e.g., a.jpg) using a standard open panel, I cannot create an adjacent file (e.g., a.jxl) in the same folder because the sandbox only grants access to the selected file, not to other files in the directory. I understand that full disk access might be an option, but it requires user intervention and isn't suitable for this case. Is there any way to extend access to other files in the directory (including those not selected by the user) while remaining within the App Sandbox environment?

When executing timing benchmarks on macOs we see a much more variable sleep time relative to Linux on arm64 or Linux on x86_64 . If we have a timing loop firing every 16ms, we frequently see timings of 20+ms. We have turned off timer coalescing using sudo /usr/sbin/sysctl -w kern.timer.coalescing_enabled=0 But we are still seeing lots of spikes in expected period as compared to Linux. Is there anything we can further do to stabilize the timing of our macOs host and improve timer performance? Are there any settings we can alter (similar to the one above) to get more accurate timing performance? Example: These are sleeps that are used with standard C++ functions like std::this_thread::sleep_until() This is measured by having a loop printing the current system time and sleeping as above for (int i = 0; i < ITERATIONS; i++) { printf("%llu\n", current_time_ns()); std::this_thread::sleep_until(std::chrono::steady_clock::now() + std::chrono::milliseconds(16)) } The same code was compiled for arm64 macOS arm64 Linux x86_x64 Linux And was found to be far more variable in the macOS arm64 case.

hello, we're currently working on a way to adapt the behavior of our app when the device is running with a low free memory remaining, or a bad network. For the network, we though about implementing a speedtest, but the issue with this solution is that we want to test regularly the quality of the network, so if the device is running with a poor/bad network, the speedtest with stuck the app. I was looking for other way to check the displayed informations in the status bar: private func getWiFiRSSI() -> Int? { let app = UIApplication.shared var rssi: Int? let exception = tryBlock { guard let statusBar = app.value(forKey: "statusBar") as? UIView else { return } if let statusBarMorden = NSClassFromString("UIStatusBar_Modern"), statusBar .isKind(of: statusBarMorden) { return } guard let foregroundView = statusBar.value(forKey: "foregroundView") as? UIView else { return } for view in foregroundView.subviews { if let statusBarDataNetworkItemView = NSClassFromString("UIStatusBarDataNetworkItemView"), view .isKind(of: statusBarDataNetworkItemView) { if let val = view.value(forKey: "wifiStrengthRaw") as? Int { rssi = val break } } } } if let exception = exception { print("getWiFiRSSI exception: \(exception)") } return rssi } I've checked the AppStore Guidelines but I'm not sure that this kind of code will not be subject to rejection by the Review team. Anyone having trying to submit with a similar approach? Did you already managed to monitor network regularly, without using a speedtest? Thanks for the help!

Hi, all. We have a camera with only one WiFi module. It supports AP and STA modes coexisting, but the WiFi of AP and STA can only be in the same channel at the same time, that is, 2.4G or 5G. In the initial state, the App is connected to the camera through 5G WiFi, and the camera is in AP mode. When entering the network configuration mode, the camera will start the STA mode, and the AP and STA modes coexist. When the user selects 2.4G WiFi, the AP mode will switch from 5G to 2.4G. Android's WiFi and socket are not disconnected, iOS's socket will be disconnected 100%, and WiFi may be disconnected. What is the reason for this? Is there any way to solve it?

We have Mac OS VM which has two network interfaces and both are active. In our application we need “State:/Network/Global/IPv6” to do some task but on this machine it seems to be missing, however if we disable one of the interface then the same setting seems to be available and our code works fine. Please find the attached screenshots of working & non-working details:

I can build the SimpleFirewall application (https://developer.apple.com/documentation/networkextension/filtering_network_traffic ) using xcode: After I run the application, seems can't block any traffic. I find there is some logs from network extension process: networkd_settings_read_from_file Sandbox is preventing this process from reading networkd settings file at "/Library/Preferences/com.apple.networkd.plist", please add an exception. Any step I am missing ?

Hi, I'm trying to set up FIRDebugEnabled as launch arguments in app delegate based on user choice using ProcessInfo.processInfo.arguments. Which is working fine in iOS 17 and below devices and stoped working in iOS 18 Here is my sample, if condition { var arguments = ProcessInfo.processInfo.arguments arguments.append("-FIRDebugEnabled") ProcessInfo.processInfo.setValue(arguments, forKey: "arguments") }

The expected number of months for the below code should be -48 months. It used to work like this Until iOS17. Now when building with iOS 18 it gives -47 months. Changing the two dates with one day back works as expected import Foundation var calendar = Calendar(identifier: .gregorian) calendar.timeZone = .gmt let components1 = DateComponents( calendar: calendar, year: 2004, month: 2, day: 29 //28 in case of changing day to 28 it works as expected ) guard let date1 = components1.date else { exit(1) } let components2 = DateComponents( calendar: calendar, year: 2008, month: 2, day: 29 //28 in case of changing day to 28 it works as expected ) guard let date2 = components2.date else { exit(1) } print(date1) print(date2) let months = calendar.dateComponents([.month, .isLeapMonth], from: date2, to: date1) print(months)

Hi everyone, I'm experiencing crashes that consistently occur on iOS 18 devices, which seem to share a common root cause. I'm hoping for some guidance. Here are the details of the crashes as received from Xcode Organizer: Crash Trace 1: 0 CoreFoundation 0x0000000192c50e54 CF_IS_OBJC + 76 (CFRuntime.c:461) 1 CoreFoundation 0x0000000192c4dd3c CFRelease + 60 (CFRuntime.c:1202) 2 CoreFoundation 0x0000000192d015e0 _signalEventSync + 252 (CFStream.c:636) 3 CoreFoundation 0x0000000192d53050 ___signalEventQueue_block_invoke + 28 (CFStream.c:646) 4 libdispatch.dylib 0x000000019a93c370 _dispatch_call_block_and_release + 32 (init.c:1549) 5 libdispatch.dylib 0x000000019a93e0d0 _dispatch_client_callout + 20 (object.m:576) 6 libdispatch.dylib 0x000000019a9456d8 _dispatch_lane_serial_drain + 744 (queue.c:3934) 7 libdispatch.dylib 0x000000019a9461e0 _dispatch_lane_invoke + 380 (queue.c:4025) 8 libdispatch.dylib 0x000000019a951258 _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7193) 9 libdispatch.dylib 0x000000019a950aa4 _dispatch_workloop_worker_thread + 540 (queue.c:6787) 10 libsystem_pthread.dylib 0x000000021a00fc7c _pthread_wqthread + 288 (pthread.c:2696) 11 libsystem_pthread.dylib 0x000000021a00c488 start_wqthread + 8 (:-1) Crash Trace 2: 0 libobjc.A.dylib 0x0000000186f33c20 objc_msgSend + 32 1 CoreFoundation 0x0000000189cb14b8 _inputStreamCallbackFunc + 36 (CFObject.m:1952) 2 CoreFoundation 0x0000000189cb0aa8 _signalEventSync + 216 (CFStream.c:626) 3 CoreFoundation 0x0000000189d01e30 ___signalEventQueue_block_invoke + 28 (CFStream.c:646) 4 libdispatch.dylib 0x0000000191948370 _dispatch_call_block_and_release + 32 (init.c:1549) 5 libdispatch.dylib 0x000000019194a0d0 _dispatch_client_callout + 20 (object.m:576) 6 libdispatch.dylib 0x00000001919516d8 _dispatch_lane_serial_drain + 744 (queue.c:3934) 7 libdispatch.dylib 0x00000001919521e0 _dispatch_lane_invoke + 380 (queue.c:4025) 8 libdispatch.dylib 0x000000019195d258 _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7193) 9 libdispatch.dylib 0x000000019195caa4 _dispatch_workloop_worker_thread + 540 (queue.c:6787) 10 libsystem_pthread.dylib 0x000000021214bc7c _pthread_wqthread + 288 (pthread.c:2696) 11 libsystem_pthread.dylib 0x0000000212148488 start_wqthread + 8 Crash Trace 3: 0 libobjc.A.dylib 0x00000001941d9ce8 objc_loadWeakRetained + 156 (NSObject.mm:525) 1 CoreFoundation 0x0000000196d0a0f4 _outputStreamCallbackFunc + 36 (CFObject.m:1960) 2 CoreFoundation 0x0000000196d09724 _signalEventSync + 216 (CFStream.c:626) 3 CoreFoundation 0x0000000196d07948 ___signalEventQueue_block_invoke + 28 (CFStream.c:646) 4 libdispatch.dylib 0x000000019e9de248 _dispatch_call_block_and_release + 32 (init.c:1549) 5 libdispatch.dylib 0x000000019e9dffa8 _dispatch_client_callout + 20 (object.m:576) 6 libdispatch.dylib 0x000000019e9e75cc _dispatch_lane_serial_drain + 768 (queue.c:3934) 7 libdispatch.dylib 0x000000019e9e8124 _dispatch_lane_invoke + 380 (queue.c:4025) 8 libdispatch.dylib 0x000000019e9f338c _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7193) 9 libdispatch.dylib 0x000000019e9f2bd8 _dispatch_workloop_worker_thread + 540 (queue.c:6787) 10 libsystem_pthread.dylib 0x00000002220f3680 _pthread_wqthread + 288 (pthread.c:2696) 11 libsystem_pthread.dylib 0x00000002220f1474 start_wqthread + 8 Notable Points: All crashes occur only on iOS 18 and newer versions. The crashes are independent of the Xcode version used to build the app (tested with both Xcode 15.4 and 16). All crash traces occur in CoreFoundation and seem to have nothing related to our app codebase. I've attempted to profile the app using Instruments to identify any zombie objects, but the crashes do not manifest on my own devices. I've referred to discussions, including this forum thread, but have not yet found a solution. Questions: Has anyone else encountered similar issues on iOS 18? Are there specific aspects of iOS 18 that might contribute to these CoreFoundation and libobjc-related crashes? Would appreciate any suggestions for further diagnostics or potential workarounds. Thank you for your help!

We are reaching out to discuss an issue we have encountered with our app's activation process while running in the background. Currently, we are employing an iBeacon-based activation scheme, but we have noticed that after the app is activated, it is unable to receive UUID data from the scan-response while in the background. We are considering the possibility of embedding the UUID data into the advertisement so that the app can receive it once activated by the iBeacon. Additionally, we are preparing to use both Core Bluetooth’s “Performing Long-Term Actions in the Background” feature and the iBeacon scheme simultaneously for app activation. We would like to know if these two methods can coexist without any mutual interference. Currently, we are utilizing a method of updating the beacon advertisement after connection and disconnection to enhance the app's activation capability. However, in some scenarios where the signal is weak, the app does not detect the vehicle after being activated and will not be reactivated by the same beacon after going into sleep mode. Our current approach is to update the beacon advertisement every 10 seconds to improve this capability. We have outlined our proposed changes and would appreciate your confirmation on whether they could lead to better optimization: 1.Embedding the UUID from the scan-response into the advertisement. 2.Updating the iBeacon advertisement content every 10 seconds. 3. Simultaneously using Core Bluetooth's "Performing Long-Term Actions in the Background" feature along with the iBeacon scheme for app activation. Additionally, we would like to know if these changes could potentially cause any other issues. Thank you for your assistance, and I look forward to your insights on this matter.

Our product (rockhawk.ca) uses the Multipeer Connectivity framework for peer-to-peer communication between multiple iOS/iPadOS devices. My understanding is that MC framework communicates via three methods: 1) infrastructure wifi (i.e. multiple iOS/iPadOS devices are connected to the same wifi network), 2) peer-to-peer wifi, or 3) Bluetooth. In my experience, I don't believe I've seen MC use Bluetooth. With wifi turned off on the devices, and Bluetooth turned on, no connection is established. With wifi on and Bluetooth off, MC works and I presume either infrastructure wifi (if available) or peer-to-peer wifi are used. I'm trying to overcome two issues: Over time (since iOS 9.x), the radio transmit strength for MC over peer-to-peer wifi has decreased to the point that range is unacceptable for our use case. We need at least 150 feet range. We would like to extend this support to watchOS and the MC framework is not available. Regarding #1, I'd like to confirm that if infrastructure wifi is available, MC uses it. If infrastructure wifi is not available, MC uses peer-to-peer wifi. If this is true, then we can assure our customers that if infrastructure wifi is available at the venue, then with all devices connected to it, range will be adequate. If infrastructure wifi is not available at the venue, perhaps a mobile wifi router (battery operated) could be set up, devices connected to it, then range would be adequate. We are about to test this. Reasonable? Can we be assured that if infrastructure wifi is available, MC uses it? Regarding #2, given we are targeting minimum watchOS 7.0, would the available networking APIs and frameworks be adequate to implement our own equivalent of the MC framework so our app on iOS/iPadOS and watchOS devices could communicate? How much work? Where would I start? I'm new to implementing networking but experienced in using the MC framework. I'm assuming that I would write the networking code to use infrastructure wifi to achieve acceptable range. Many thanks! Tim