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!

Hi, for https://developer.apple.com/documentation/corenfc/cardsession/, is the Select PPSE APDU forwarded to the 3rd party payment app for processing? The use case is to provide a specific list of AIDs controlled by the app rather than all the AIDs registered under the app's entitlement.

Supplying a complete copy the error from my log file below. Can someone tell me what changed in Sequoia that would be causing this error? If there a work around? Is there something I can do to correct this? Thanks, Ken 10.953 (I) DatabaseSaver.swift:207 phase1_startReadingRemoteDatabase(timeout:) Checking original database for out-of-band changes 10.975 (D) DatabaseSaver.swift:251 phase2_startResolvingConflict(localData:remoteData:remoteURL:) Original file is safe to overwrite. 10.975 (I) DatabaseSaver.swift:285 phase3_startWritingRemoteDatabase(resolvedData:) Writing database file 15.178 (E) LocalDataSource.swift:85 write(_:to:fileProvider:timeout:queue:completionQueue:completion:) Failed to write file [message: You don’t have permission to save the file “MyPasswords.kdbx” in the folder “Downloads”. 15.179 (E) FileAccessError.swift:217 make(from:fileName:fileProvider:) Failed to access the file [fileProvider: com.apple.FileProvider.LocalStorage, systemError: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “MyPasswords.kdbx” in the folder “Downloads”." UserInfo={NSUnderlyingError=0x6000014a0270 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}, NSFilePath=/Users/user123/Library/Mobile Documents/comappleCloudDocs/Downloads/MyPasswords.kdbx, NSURL=file:///Users/user123/Library/Mobile%20Documents/comappleCloudDocs/Downloads/MyPasswords.kdbx}] 15.179 (E) DatabaseSaver.swift:309 phase3_startWritingRemoteDatabase(resolvedData:) Failed to write database, cancelling 15.179 (E) DatabaseSaver.swift:432 finalize(withError:) Failed to open remote file [message: Cannot save file (macOS)]

I try to mix content filter and endpoint security in one system extension, but get error below when the program invoke es_new_client(returned ES_NEW_CLIENTRESULT_ERR_INTERNAL). Failed to open services: 0xe00002e2: Caller was denied connecting to the ES subsystem, possibly due to a sandbox violation. how to solve this error while keeping two functionalities in one system extension? or I have to seperate them?

I'm encountering an issue where a specific BLE device (a Telematics Control Unit) is being discovered by some iPhone models but not others, all running the same iOS version (18.0.1). Here's the breakdown: Successful discovery: iPhone 11, iPhone 14 Plus, iPhone 6s No discovery: iPhone 13, iPhone 12 mini Firmware: The TCU firmware is up-to-date. BLE: Bluetooth is enabled on all devices. I've tried basic troubleshooting like restarting devices and resetting network settings, but the issue persists. Could this be related to differences in Bluetooth chipsets or antenna designs between iPhone models, even with the same iOS version? Are there any known compatibility issues between this TCU and specific iPhone models? Any insights or suggestions for further debugging issue would be greatly appreciated!

hello, I would like to run benchmarks on p-cores vs e-cores, I suspect a difference of more than 50% is it possible to choose your processor (P or E) to run your program? nice day

Hi, I encounter unexpected behavior from the FileWrapper updates that occurs when I remove file using FileManager.removeItem If I first remove a file from the directory, then create NSFileWrapper instance, I get unexpected values from calls to matchesContents(of:) import Foundation let copyURL = URL(filePath: "/Users/marcinkrzyzanowski/Downloads/filewrappertest.test/COPY.png") // THIS OPERATION BREAKS IT. REMOVE IT TO WORK AS EXPECTED try! FileManager().removeItem(at: copyURL) let dirURL = URL(filePath: "/Users/marcinkrzyzanowski/Downloads/filewrappertest.test") let fw = try FileWrapper(url: dirURL) fw.fileWrappers // ["IMG_0736.png"] try FileManager.default.copyItem(at: URL(filePath: "/Users/marcinkrzyzanowski/Downloads/filewrappertest.test/IMG_0736.png"), to: copyURL) fw.fileWrappers // ["IMG_0736.png"] fw.matchesContents(of: dirURL) // true (expected: false) try fw.read(from: dirURL) fw.fileWrappers! // ["COPY.png", "IMG_0736.png"] fw.matchesContents(of: dirURL) // true I don't understand why the "FileManager.removeItem" affects the NSFileWrapper behavior in such a way. It does not change even when I add a delay after removeItem. Any idea?

Hello, using UIDocumentPickerViewController and startAccessingSecurityScopedResource(), I can access to a directory on iOS using Bookmark data, but when I save a Bookmark data, security-scoped bookmark not survive quitting the app and re-launching it. I used the Apple example here but my app doesn't appear in Settings > Privacy > Files and Folders ? Security-scoped bookmark is-it available on iOS ? Thanks.

The unified system log on Apple platforms gets a lot of stick for being ‘too verbose’. I understand that perspective: If you’re used to a traditional Unix-y system log, you might expect to learn something about an issue by manually looking through the log, and the unified system log is way too chatty for that. However, that’s a small price to pay for all its other benefits. This post is my attempt to explain those benefits, broken up into a series of short bullets. Hopefully, by the end, you’ll understand why I’m best friends with the system log, and why you should be too! If you have questions or comments about this, start a new thread and tag it with OSLog so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Your Friend the System Log Apple’s unified system log is very powerful. If you’re writing code for any Apple platform, and especially if you’re working on low-level code, it pays to become friends with the system log! The Benefits of Having a Such Good Friend The public API for logging is fast and full-featured. And it’s particularly nice in Swift. Logging is fast enough to leave log points [1] enabled in your release build, which makes it easier to debug issues that only show up in the field. The system log is used extensively by the OS itself, allowing you to correlate your log entries with the internal state of the system. Log entries persist for a long time, allowing you to investigate an issue that originated well before you noticed it. Log entries are classified by subsystem, category, and type. Each type has a default disposition, which determines whether that log entry is enable and, if it is, whether it persists in the log store. You can customise this, based on the subsystem, category, and type, in four different ways: Install a configuration profile created by Apple (all platforms). Add an OSLogPreferences property to your app’s Info.plist (all platforms). Run the log tool with the config command (macOS only) Create and install a custom configuration profile with the com.apple.system.logging payload (macOS only). When you log a value, you may tag it as private. These values are omitted from the log by default but you can configure the system to include them. For information on how to do that, see Recording Private Data in the System Log. The Console app displays the system log. On the left, select either your local Mac or an attached iOS device. Console can open and work with log snapshots (.logarchive). It also supports surprisingly sophisticated searching. For instructions on how to set up your search, choose Help > Console Help. Console’s search field supports copy and paste. For example, to set up a search for the subsystem com.foo.bar, paste subsystem:com.foo.bar into the field. Console supports saved searches. Again, Console Help has the details. Console supports viewing log entries in a specific timeframe. By default it shows the last 5 minutes. To change this, select an item in the Showing popup menu in the pane divider. If you have a specific time range of interest, select Custom, enter that range, and click Apply. Instruments has os_log and os_signpost instruments that record log entries in your trace. Use this to correlate the output of other instruments with log points in your code. Instruments can also import a log snapshot. Drop a .logarchive file on to Instruments and it’ll import the log into a trace document, then analyse the log with Instruments’ many cool features. The log command-line tool lets you do all of this and more from Terminal. The log stream subcommand supports multiple output formats. The default format includes column headers that describe the standard fields. The last column holds the log message prefixed by various fields. For example: cloudd: (Network) [com.apple.network:connection] nw_flow_disconnected … In this context: cloudd is the source process. (Network) is the source library. If this isn’t present, the log came from the main executable. [com.apple.network:connection] is the subsystem and category. Not all log entries have these. nw_flow_disconnected … is the actual message. There’s a public API to read back existing log entries, albeit one with significant limitations on iOS (more on that below). Every sysdiagnose log includes a snapshot of the system log, which is ideal for debugging hard-to-reproduce problems. For more details on that, see Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. For general information about sysdiagnose logs, see Bug Reporting > Profiles and Logs. But you don’t have to use sysdiagnose logs. To create a quick snapshot of the system log, run the log tool with the collect subcommand. If you’re investigating recent events, use the --last argument to limit its scope. For example, the following creates a snapshot of log entries from the last 5 minutes: % sudo log collect --last 5m For more information, see: os > Logging OSLog log man page os_log man page (in section 3) os_log man page (in section 5) WWDC 2016 Session 721 Unified Logging and Activity Tracing [1] Well, most log points. If you’re logging thousands of entries per second, the very small overhead for these disabled log points add up. Foster Your Friendship Good friendships take some work on your part, and your friendship with the system log is no exception. Follow these suggestions for getting the most out of the system log. The system log has many friends, and it tries to love them the all equally. Don’t abuse that by logging too much. One key benefit of the system log is that log entries persist for a long time, allowing you to debug issues with their roots in the distant past. But there’s a trade off here: The more you log, the shorter the log window, and the harder it is to debug such problems. Put some thought into your subsystem and category choices. One trick here is to use the same category across multiple subsystems, allowing you to track issues as they cross between subsystems in your product. Or use one subsystem with multiple categories, so you can search on the subsystem to see all your logging and then focus on specific categories when you need to. Don’t use too many unique subsystem and context pairs. As a rough guide: One is fine, ten is OK, 100 is too much. Choose your log types wisely. The documentation for each OSLogType value describes the default behaviour of that value; use that information to guide your choices. Remember that disabled log points have a very low cost. It’s fine to leave chatty logging in your product if it’s disabled by default. No Friend Is Perfect The system log API is hard to wrap. The system log is so efficient because it’s deeply integrated with the compiler. If you wrap the system log API, you undermine that efficiency. For example, a wrapper like this is very inefficient: -*-*-*-*-*- DO NOT DO THIS -*-*-*-*-*- void myLog(const char * format, ...) { va_list ap; va_start(ap, format); char * str = NULL; vasprintf(&str, format, ap); os_log_debug(sLog, "%s", str); free(str); va_end(ap); } -*-*-*-*-*- DO NOT DO THIS -*-*-*-*-*- This is mostly an issue with the C API, because the modern Swift API is nice enough that you rarely need to wrap it. If you do wrap the C API, use a macro and have that pass the arguments through to the underlying os_log_xyz macro. iOS has very limited facilities for reading the system log. Currently, an iOS app can only read entries created by that specific process, using .currentProcessIdentifier scope. This is annoying if, say, the app crashed and you want to know what it was doing before the crash. What you need is a way to get all log entries written by your app (r. 57880434). There are two known bugs with the .currentProcessIdentifier scope. The first is that the .reverse option doesn’t work (r. 87622922). You always get log entries in forward order. The second is that the getEntries(with:at:matching:) method doesn’t honour its position argument (r. 87416514). You always get all available log entries. Xcode 15 beta has a shiny new console interface. For the details, watch WWDC 2023 Session 10226 Debug with structured logging. For some other notes about this change, search the Xcode 15 Beta Release Notes for 109380695. In older versions of Xcode the console pane was not a system log client (r. 32863680). Rather, it just collected and displayed stdout and stderr from your process. This approach had a number of consequences: The system log does not, by default, log to stderr. Xcode enabled this by setting an environment variable, OS_ACTIVITY_DT_MODE. The existence and behaviour of this environment variable is an implementation detail and not something that you should rely on. Xcode sets this environment variable when you run your program from Xcode (Product > Run). It can’t set it when you attach to a running process (Debug > Attach to Process). Xcode’s Console pane does not support the sophisticated filtering you’d expect in a system log client. When I can’t use Xcode 15, I work around the last two by ignoring the console pane and instead running Console and viewing my log entries there. If you don’t see the expected log entries in Console, make sure that you have Action > Include Info Messages and Action > Include Debug Messages enabled. The system log interface is available within the kernel but it has some serious limitations. Here’s the ones that I’m aware of: Prior to macOS 14.4, there was no subsystem or category support (r. 28948441). There is no support for annotations like {public} and {private}. Adding such annotations causes the log entry to be dropped (r. 40636781). Metal shaders can log using the interface described in section 6.19 of the Metal Shading Language Specification. Revision History 2024-10-22 Added some notes on interpreting the output from log stream. 2024-09-17 The kernel now includes subsystem and category support. 2024-09-16 Added a link to the the Metal logging interface. 2023-10-20 Added some Instruments tidbits. 2023-10-13 Described a second known bug with the .currentProcessIdentifier scope. Added a link to Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. 2023-08-28 Described a known bug with the .reverse option in .currentProcessIdentifier scope. 2023-06-12 Added a call-out to the Xcode 15 Beta Release Notes. 2023-06-06 Updated to reference WWDC 2023 Session 10226. Added some notes about the kernel’s system log support. 2023-03-22 Made some minor editorial changes. 2023-03-13 Reworked the Xcode discussion to mention OS_ACTIVITY_DT_MODE. 2022-10-26 Called out the Showing popup in Console and the --last argument to log collect. 2022-10-06 Added a link WWDC 2016 Session 721 Unified Logging and Activity Tracing. 2022-08-19 Add a link to Recording Private Data in the System Log. 2022-08-11 Added a bunch of hints and tips. 2022-06-23 Added the Foster Your Friendship section. Made other editorial changes. 2022-05-12 First posted.

After installing the app with distribution certificate, iPhone is getting very slow in some random devices with iOS version 18.0.1 where as the same app installed through TestFlight & AppStore is working fine . Could you please provide your support to diagnose this issue? Devices with iOS 18.0.1 which are showing issues:- iPhone XR, iPhone 16 pro. Thanks.

Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: SIGNAL 6 Abort trap: 6 Terminating Process: APPX_MOBILE[14375] Triggered by Thread: 8 Application Specific Information: abort() called Thread 8 name: com.facebook.react.JavaScript Thread 8 Crashed: 0 libsystem_kernel.dylib 0x1d9927274 __pthread_kill + 8 1 libsystem_pthread.dylib 0x210e5aef8 pthread_kill + 268 2 libsystem_c.dylib 0x19183bad8 abort + 128 3 libsystem_malloc.dylib 0x199cb1c4c malloc_vreport + 896 4 libsystem_malloc.dylib 0x199cb18bc malloc_report + 64 5 libsystem_malloc.dylib 0x199cb0e94 find_zone_and_free + 528 6 APPX_MOBILE 0x1036f6018 0x102870000 + 15228952 7 APPX_MOBILE 0x1036f5f58 0x102870000 + 15228760 8 APPX_MOBILE 0x1036f9288 0x102870000 + 15241864 9 APPX_MOBILE 0x1036f8a4c 0x102870000 + 15239756 10 APPX_MOBILE 0x103746820 0x102870000 + 15558688 11 APPX_MOBILE 0x1037468f4 0x102870000 + 15558900 12 APPX_MOBILE 0x10374b4c8 0x102870000 + 15578312 13 APPX_MOBILE 0x1039ccfb4 0x102870000 + 18206644 14 APPX_MOBILE 0x103cb59c8 0x102870000 + 21256648 15 APPX_MOBILE 0x103cb57d0 0x102870000 + 21256144 16 APPX_MOBILE 0x103cb3d2c 0x102870000 + 21249324 17 hermes 0x104de11f0 facebook::hermes::HermesRuntimeImpl::JsiProxy::get(hermes::vm::SymbolID) + 96 18 hermes 0x104e10e68 hermes::vm::JSObject::getComputedWithReceiver_RJS(hermes::vm::Handlehermes::vm::JSObject, hermes::vm::Runtime&, hermes::vm::Handlehermes::vm::HermesValue, hermes::vm::Handlehermes::vm::HermesValue) + 732 19 hermes 0x104e004cc hermes::vm::CallResult<hermes::vm::HermesValue, (hermes::vm::detail::CallResultSpecialize)2> hermes::vm::Interpreter::interpretFunction<false, false>(hermes::vm::Runtime&, hermes::vm::InterpreterState&) + 10480 20 hermes 0x104dfdbb4 hermes::vm::Runtime::interpretFunctionImpl(hermes::vm::CodeBlock*) + 52 21 hermes 0x104e2e5d4 hermes::vm::Runtime::runBytecode(std::__1::shared_ptrhermes::hbc::BCProviderBase&&, hermes::vm::RuntimeModuleFlags, llvh::StringRef, hermes::vm::Handlehermes::vm::Environment, hermes::vm::Handlehermes::vm::HermesValue) + 1204 22 hermes 0x104dd6904 facebook::hermes::HermesRuntimeImpl::evaluatePreparedJavaScript(std::__1::shared_ptr<facebook::jsi::PreparedJavaScript const> const&) + 224 23 hermes 0x104dd679c facebook::hermes::HermesRuntime::evaluateJavaScriptWithSourceMap(std::__1::shared_ptr<facebook::jsi::Buffer const> const&, std::__1::shared_ptr<facebook::jsi::Buffer const> const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator> const&) + 88 24 hermes 0x104dd76dc facebook::hermes::HermesRuntimeImpl::evaluateJavaScript(std::__1::shared_ptr<facebook::jsi::Buffer const> const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator> const&) + 32 25 APPX_MOBILE 0x103d8ed54 0x102870000 + 22146388 26 APPX_MOBILE 0x103cb0cf0 0x102870000 + 21236976 27 APPX_MOBILE 0x1039d006c 0x102870000 + 18219116 28 APPX_MOBILE 0x1039d1044 0x102870000 + 18223172 29 APPX_MOBILE 0x103736628 0x102870000 + 15492648 30 APPX_MOBILE 0x10374265c 0x102870000 + 15541852 31 APPX_MOBILE 0x103742468 0x102870000 + 15541352 32 CoreFoundation 0x189aeb444 CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK + 28 33 CoreFoundation 0x189ad9658 __CFRunLoopDoBlocks + 356 34 CoreFoundation 0x189ad933c __CFRunLoopRun + 2432 35 CoreFoundation 0x189ad85b8 CFRunLoopRunSpecific + 572 36 APPX_MOBILE 0x10372be50 0x102870000 + 15449680 37 Foundation 0x188780158 NSThread__start + 724 38 libsystem_pthread.dylib 0x210e5937c _pthread_start + 136 39 libsystem_pthread.dylib 0x210e54494 thread_start + 8

I work on EdenFS, an open-source Virtual Filesystem that runs on macOS, Linux, and Windows. My team is very interested in using FSKit as the basis for EdenFS on macOS, but have found the documentation to be lacking and contains some mixed messaging on the future of FSKit. Below are a few questions that don’t seem to be fully covered by the current documentation: Does FSKit support process attribution? Each FUSE request provides a requester Process ID (and other information) through the fuse_in_header structure. Does FSKit pass similar information along for each request? Does the reclaimItem API function similarly to FUSE’s forget operation? If not, what are the differences? See #1 below for why forget/reclaimItem matters to us. Is Apple committed to releasing and supporting FSKit? Is there any timeline for release that we can plan around? Does FSKit have known performance/scalability limitations? We provide alternative methods that clients can use to make bulk requests to EdenFS, but some clients will necessarily be unable to use those and stress the default filesystem APIs. Throughput (on the order of tens of thousands of filesystem requests per minute) and request size are the main concerns, followed closely by directory size restrictions. Why we’re interested in FSKit As mentioned above, my team supports EdenFS on 3 platforms. On Linux, we utilize FUSE; on Windows, we utilize ProjectedFS; and on macOS, we’ve utilized a few different solutions in the past. We first utilized the macFUSE kext, which was great while it lasted. Due to (understandable) changes in supporting kernel extensions, we were forced to move to NFS version 3. NFS has been lackluster in comparison (and our initial investigations show that NFS version 4(.2) would be similar). We have had numerous scalability and reliability issues, some listed below: NFS does not provide a forget API similar to FUSE. EdenFS is forced to remember all file handles that have been loaded because the kernel never informs us when all references to that file handle have been dropped. We can hackily infer that a file handle should never be referenced again in some cases, but a large number of file handles end up being remembered forever. Many of our algorithms scale with the number of file handles that Eden has to consider, and therefore performance issues are inevitable after some time. NFS does not provide information about clients (requesters). We cannot tell which processes are sending EdenFS requests. This attribution is important due to issue #1. We are forced to work with tool owners to modify their applications to be VFS-friendly. If we can’t track down which tools are behaving poorly, they will continue to load excess file handles and cause performance issues. NFS “Server connections interrupted:” dialog during heavy load. Under heavy load, either EdenFS or system-wide, our users experience this dialog pop-up and are confused as to how they should respond (Ignore or Disconnect All). They become blocked in their work, and will be further blocked if they click “Disconnect All” as that unmounts their EdenFS mount. This forces them to restart EdenFS or reboot their laptop to remediate the issue. The above issues make us extremely motivated to use FSKit and partner with Apple to flesh out the final version of the FSKit API. Our use case likely mirrors what other user-space filesystems will be looking for in the FSKit API (albeit at a larger scale than most), and we’re willing to collaborate to work out any issues in the current FSKit offerings.

For a personal project, I have been writing some library to interface the CoreBluetooth API with the go language. Because of what it does, that library is written in objective-C with ARC disabled. One function I had to write takes a memory buffer (allocated with malloc() on the go side), creates an NSData object out of it to pass the data to the writeValue:forCharacteristic:type: CoreBluetooth method, and then releases the NSData as well as the original memory buffer: void Write(CBPeripheral *p, CBCharacteristic *c, void *bytes, int len) { NSData *data = [NSData dataWithBytesNoCopy:bytes length:len freeWhenDone:true]; [p writeValue:data forCharacteristic:c type:CBCharacteristicWriteWithoutResponse]; [data release]; } One thing I noticed is that the retainCount for data increases during the writeValue:forCharacteristic:type: API call. It is 1 before, and 2 after. This is surprising to me, because the documentation says "This method copies the data passed into the data parameter, and you can dispose of it after the method returns." I suspects this results in a memory leak. Am I missing something here ?

We hook the memory related APIs with ourselves' functions, like below: if ((malloc_get_all_zones(0, nullptr, reinterpret_cast<vm_address_t**>(&allZones), &numZones) == KERN_SUCCESS) && (numZones > 0) && (numZones > 0)) { if (allZones[0] == nullptr ) { return false; } trackZone = allZones[0] trackZone->malloc = &my_malloc; trackZone->calloc = &my_calloc; trackZone->valloc = &my_valloc; trackZone->memalign = &my_memalign; trackZone->free = &my_free; trackZone->free_definite_size = &my_free_definite_size; trackZone->try_free_default = &my_try_free_default; trackZone->realloc = &scf_realloc; } our functions are called when allocate memory with XCode15+MacOS14.6, but when we upgrade the compiling env to XCode16+MacOS15, it won't work any more.

It seems that the connection failure occurs when attempting to establish GATT connections with 9 BLE devices simultaneously. However, when connecting fewer than 8 or more than 10 devices, data can be received without issues. Upon investigation, the following points have been identified: This issue does not occur on iPad 10th generation. The iPad 9th generation uses Bluetooth 4.2, while the iPad 10th generation uses Bluetooth 5.0, so this difference might be the cause. The limitation is 9 devices per device, not per App. The issue occurs even when trying to connect 8 BLE devices with App 1 and 1 BLE device with App 2. It appears that the 9th device experiencing the connection failure is not receiving the result of the service discovery. According to the PacketLogger logs, the connection itself is established, but the service discovery results are not returned. When a 10th device is connected, the 9th device also connects successfully. Once the 10th device connects, the service discovery results for the 9th device are returned. The reproduction steps are as follows: Device: iPad 9th generation (iPadOS 17.6.1) Procedure: Prepare 9 BLE devices. Connect each BLE device to the iPad one by one. Data can be received from devices 1 through 8, but data cannot be received from the 9th device.

Hi, I am trying to write simple code that my iPhone acts as BLE peripheral (advertise packet). but i cannot see the advertisement on other devices that do scanning. What could be the cause? Code snippet ============= import SwiftUI import CoreBluetooth // 1. Conform to CBPeripheralManagerDelegate class BLEAdvertiser: NSObject, ObservableObject, CBPeripheralManagerDelegate { var peripheralManager: CBPeripheralManager? // 2. Start advertising func startAdvertising() { peripheralManager = CBPeripheralManager(delegate: self, queue: nil) } // 3. CBPeripheralManagerDelegate method called when state changes func peripheralManagerDidUpdateState(_ peripheral: CBPeripheralManager) { switch peripheral.state { case .poweredOn: // Define a service UUID let serviceUUID = CBUUID(string: "1234") // Custom UUID for your service // Create a CBMutableService let service = CBMutableService(type: serviceUUID, primary: true) // Add service to the peripheral manager peripheralManager?.add(service) // Start advertising the service let advertisementData: [String: Any] = [ CBAdvertisementDataServiceUUIDsKey: [serviceUUID], CBAdvertisementDataLocalNameKey: "My iPhone" ] peripheralManager?.startAdvertising(advertisementData) print("Started advertising!") case .poweredOff: print("Bluetooth is powered off.") case .resetting: print("Bluetooth is resetting.") case .unauthorized: print("Bluetooth access is unauthorized.") case .unsupported: print("Bluetooth is unsupported on this device.") case .unknown: print("Bluetooth state is unknown.") @unknown default: print("A new state that we don’t know about.") } } // 4. Optional: Handle peripheral manager adding service func peripheralManager(_ peripheral: CBPeripheralManager, didAdd service: CBService, error: Error?) { if let error = error { print("Failed to add service: \(error.localizedDescription)") return } print("Service added successfully!") } } struct ContentView: View { @StateObject private var bleAdvertiser = BLEAdvertiser() var body: some View { VStack { Text("BLE Advertising") .font(.largeTitle) .padding() Button(action: { bleAdvertiser.startAdvertising() }) { Text("Start Advertising") .padding() .background(Color.blue) .foregroundColor(.white) .cornerRadius(10) } } } }

The kernel sends SIGKILL to application if it handles ES_EVENT_TYPE_AUTH_OPEN and lldb is attached to this process. App: int main(int /*argc*/, char** /*argv*/) { es_client_t *pEpClient = nullptr; es_new_client_result_t result = es_new_client(&pEpClient, ^(es_client_t *pClient, const es_message_t *pMessage) { switch (pMessage->event_type) { case ES_EVENT_TYPE_AUTH_OPEN: { uint32_t authorizedFlags = pMessage->event.open.fflag; if ((authorizedFlags & FREAD) || (authorizedFlags & FWRITE)) { std::filesystem::path filePath = std::string(pMessage->event.open.file->path.data, pMessage->event.open.file->path.length); std::string fileName = filePath.filename(); if (fileName == "test.txt") { std::cout << "blocked fileName: " << filePath.filename() << std::endl; authorizedFlags &= ~FWRITE; authorizedFlags &= ~FREAD; } } if (es_respond_flags_result(pClient, pMessage, authorizedFlags, false) != ES_RESPOND_RESULT_SUCCESS) { std::cout << "es_respond_flags_result() failed with error " << std::endl; } } break; default: break; } }); if (result != ES_NEW_CLIENT_RESULT_SUCCESS) { std::cout << "es_new_client() failed." << std::endl; return 1; } es_event_type_t eventsList[] = { ES_EVENT_TYPE_AUTH_OPEN }; if (es_subscribe(pEpClient, eventsList, 1) == ES_RETURN_ERROR) { std::cout << "es_subscribe() failed." << std::endl; } // wait int i = 0; std::cin >> i; if (es_delete_client(pEpClient) == ES_RETURN_ERROR) { std::cout << "es_delete_client() failed." << std::endl; } return 0; } (lldb) process attach --pid 61127 .... (lldb) c Process 61127 resuming Process 61127 exited with status = 9 (0x00000009) Terminated due to signal 9 System log: Allowing set_exception_ports from [debugserver] on [ep_sample] for entitled process/debugger Client did not respond in appropriate amount of time (client pid: 61127), sent SIGKILL

Delete the Documents path of the app Will the files or folders in the documentDirectory path or applicationSupportDirectory path disappear or be deleted when the OS is updated? I know that sometimes all the files in the cachesDirectory path are deleted when the OS is updated or the device is rebooted. Sometimes, users of my app report that all the files in the documentDirectory path or applicationSupportDirectory path are deleted or disappear, or all the files are deleted and initialized. I thought that the files or folders in the documentDirectory path or applicationSupportDirectory path were not affected by the OS update, but am I wrong?

NFC reading starts but after BAC, during the reading of DG2 the NFC stops reading and returns with Tag connection Lost error . It almost fails everytime on iPhone 15 Pro max with the following error. What's the solution for this? This is really important because our app entirely relies on the NFC data to proceed forward. This always fails in iPhone 15 & 16. Same card works fine on older iPhone models. What change should we do or include for the newer models. Error Domain=NFCError Code=102 "Tag response error / no response" UserInfo={NSLocalizedDescription=Tag response error / no response, NSUnderlyingError=0x303bd6af0 {Error Domain=nfcd Code=29 "Tag Error" UserInfo={NSLocalizedDescription=Tag Error, NSUnderlyingError=0x303bd6910 {Error Domain=com.apple.nfstack Code=20 "No response from tag" UserInfo={NSLocalizedDescription=No response from tag}}}}}

We have a sandboxed swift app with an associated network extension where both write to the same log file in a shared container (via NSFileCoordinator) On sonoma all was good. With sequoia, we get a popup requesting access to the file from the user. I realize this is all in the name of security, but is there any way to prevent this popup? alf