Hello,
It seems like the Kernel Debug Kit for macOS 15.0.1 (24A348) is missing from the list of downloads at developer.apple.com. It would be great if you could add them to the list of available downloads.
When trying to rebuild the kernel it fails with the following error message:
Error Domain=KMErrorDomain Code=34 "Missing Developer Kit: As of macOS 13.0, you will need to install a KDK matching your build 24A348 to rebuild kernel collections." UserInfo={NSLocalizedDescription=Missing Developer Kit: As of macOS 13.0, you will need to install a KDK matching your build 24A348 to rebuild kernel collections.}
But my macOS version is 15.0.1. Is there a workaround for this?
Core OS
RSS for tagExplore the core architecture of the operating system, including the kernel, memory management, and process scheduling.
Post
Replies
Boosts
Views
Activity
Hello,
with macOS Sequoia I've observed a sudden, substantial surge in reports about the Mac App Store version of my app Yoink no longer accepting files dropped to it, with the following message being logged in Console.app:
08:16:05.516307+0200 Yoink ---Yoink Error--- Could not create NSURL bookmark for /Users/<redacted>/Downloads/<redacted>/<redacted>.txt
err: Error Domain=NSCocoaErrorDomain Code=256 "Failed to retrieve app-scope key" UserInfo={NSDebugDescription=Failed to retrieve app-scope key}
The code line that causes this is the following:
NSData *bmData = [fileURL bookmarkDataWithOptions:NSURLBookmarkCreationWithSecurityScope
includingResourceValuesForKeys:nil
relativeToURL:nil
error:&err];
Sometimes a relaunch of Yoink, or a restart of the Mac resolves the issue, but only temporarily. Other times, even a restart doesn't work, but running
tccutil reset All at.EternalStorms.Yoink
in Terminal and then restarting the Mac works (again, temporarily).
The trial version and Setapp versions of my app both work as expected, however.
I myself cannot reproduce this issue, so any pointers would be greatly appreciated.
(This might be considered a follow up to https://developer.apple.com/forums/thread/46583 , years back)
Thanks a ton,
– Matthias
Hello, experts!
During a VOIP call, the following happens:
device 1 makes a call to device 2
device 2 deliberately does not receive the call
some time passes, timeout is triggered and the call is terminated with CXCallEndedReason = remoteEnded, as evidenced by a line in the logs of the incoming call:
`[info] reportCallWasEnded callId=[***-***-***], reason=[CXCallEndedReason(rawValue: 2)].`
What is the reason why CXEndCallAction may be called from CXProviderDelegate even though the call was not manually terminated by clicking on the “End Call” button
In iOS 18 if a number is registered with CallKit to be blocked, then if that number is also in contacts, then the number isn't blocked.
If a user has added a number to their contacts, then in all probability they might not want the number blocked, so this might seem reasonable behaviour.
However the point is, this is new behaviour for CallKit in iOS 18, and its never been like this before going back several years to the very first release. Why suddenly change it now, after all these years, without notice nor documentation, and take away that option from the user, should for some reason, they want to block a number which is also in their contacts.
This is quite a disruptive change for apps using CallKit.
My team has an app that uses BTLE heavily, and has been doing so successfully, including no issues continuing to receive data in the background and updating things in the app (for recording workouts).
We have a BTLE write queue that only tries to write when the CBPeripheral.canSendWriteWithoutResponse property is true, or when we get the notification from the system in peripheralIsReady(toSendWriteWithoutResponse:). This is used as a means to rate limit data transfer, as we transfer files, as well as require that packets always arrive in the correct order due to blob encoding.
However, we had a new requirement come in to periodically write data out to a connected peripheral. I noticed that as soon as the app was in the background, despite other delegate callbacks coming in, like didRecieveUpdatedValue:, neither the property canSendWriteWithoutResponse nor the delegate callback were called any longer. This meant our write queue didn't think it had permission to write, and packets would just stack up. The failure to deliver these updates didn't occur immediately after backgrounding, but did within 2-5s of backgrounding.
If, when in the background, I ignore the changing of that property, and instead just write the data to the peripheral, it works!
Can anyone explain why, despite other CBPeripheral callbacks happening when in the background, this one does not?
Hi, we are trying to get or set the NFC UID when doing HCE CardSession emulation, but can't find any way to either get the chip UID used in a session, or set it beforehand.
Is that possible with a normal HCE CardSession eventStream received ADPU event?
Or is another framework/product needed for this?
We've done a Interoperability request (INTEROP-214), which lead us to using HCE.
Our usecase is specifically interacting with EV chargers, that only support using the chips UID for identification.
Can Apple Pay / Wallet be an alternative to do such low level handling?
So if one were to start the attempt of porting an existing kext VFS filesystem, to use the new FSKit (Since presumably kexts could go away), how would that look now?
Is it ready? Are there any samples out there that already works (Filesystem using FSKit) ?
How is the documentation? ChatGPT did not seem to know much at all.
What would be Apple's reception to that?
How flexible is FSKit ? Is it locked to the idea of a mount is connected to a physical device (or partition)? Or is it more virtual, in that I will have a pool of disks, and present 1, or many, mount points?
Previously, I used to have the below code to get workgroup / domain name of the active directory service provider.
SCDynamicStoreRef storeRef = SCDynamicStoreCreate(NULL, (CFStringRef)@"GetWorkgroup", NULL, NULL);
CFPropertyListRef global = SCDynamicStoreCopyValue (storeRef,CFSTR("State:/Network/Global/SMB"));
id workgroup = [(__bridge NSDictionary *)global valueForKey:@"Workgroup"];
On few Macs (probably starting from Sonoma), the workgroup property is not set. What is the alternative to get this information programatically?
After the macOS Sequoia update, my app seems to have an issue with Bluetooth communication between macOS and iOS that uses CoreBluetooth for Central-Peripheral communication.
Setup:
The iPhone (in my case: iPhone 14 Pro with iOS 18.0 (22A3354)) acts as the Central, and the Mac (in my case: 14" MacBook Pro 2023 with macOS 15.0 (24A335)) as the Peripheral.
I’ve implemented a mechanism where the Central (iPhone) sends a message to the Peripheral (Mac) every 15 seconds to keep the connection alive (Because it needs to wait for notify characteristic updates).
I never noticed this kind of issue before, but with macOS Sequoia I get it permanently.
Issue:
The connection drops unexpectedly after a period of time (sometimes 20 seconds, sometimes a few minutes) with CBErrorDomain - code 6: The connection has timed out unexpectedly.
Sample Code:
Peripheral (Mac):
ContentView (Peripheral).txt
ContentViewModel (Peripheral).txt
Central (iPhone):
ContentView (Central).txt
ContentViewModel (Central).txt
Reproduce:
I attached sample code including the Central-Sample (for iPhone) and Peripheral-Sample (for Mac).
Just run the Peripheral-Sample (after granting Bluetooth permissions).
Then run the Central-Sample and select the Mac device in the list
After selecting it should connect, discover the service & characteristic and should start writing messages to it.
After some time the func centralManager(_ central: CBCentralManager, didDisconnectPeripheral peripheral: CBPeripheral, error: (any Error)?) {should get called with timed out unexpectedly error.
Could anyone please look into this issue and advise on whether there’s a known bug or any workaround? Any guidance would be greatly appreciated, as this impacts the stability of Bluetooth communication between the devices.
Thanks in advance.
Logs:
I also ran the console.app during this issue which got these errors (if this is helpful):
console_logs.txt
Documentation is sparse on this and it doesn't help that Apple's version differs from POSIX.
I know to specify ACL_TYPE_EXTENDED for acl_get_file() and know how to cycle through entries. From what I can tell, the tag is either ALLOW or DENY and you can check the permset for which actions the tag applies to.
I can't figure out how get the group or user the entry applies to. The only way I've been able to get this info is by using acl_to_text and scraping that output. Anyone know how to do this using the acl APIs?
Hi,
I'm building a Virtual Machine Manager on top of Hypervisor Framework and having a problem with hv_vcpu_run never return somehow. I tested the same code on Asahi Linux using KVM and everything are working correctly. I really have no idea what I'm doing wrong here.
How I setup a vCPU: https://github.com/obhq/obliteration/blob/main/gui/src/vmm/aarch64.rs
How I use the Hypervisor Framework: https://github.com/obhq/obliteration/blob/main/gui/src/vmm/hv/macos/cpu.rs#L402
Thanks in advance.
Hello,
Has anyone encountered issues with CoreBluetooth advertising and scanning between iOS 18/iPadOS 18 Beta 3 ? I'm want to know this is a bug or an intended change in behavior.
Issue Summary:
Central device on iOS 18/iPadOS 18 Beta 3 (foreground) and Peripheral device on iOS 17.5.1 (background) fail to communicate via BLE advertising.
The reverse setup or using non-iOS 18 devices works as expected.
Detailed Description:
I am developing an iOS/iPadOS application using CoreBluetooth for advertising and scanning. Here are the specifics of my setup:
The application uses a fixed BLE service UUID, and scanning is performed with the specified service UUID.
Background Modes Uses Bluetooth LE accessories and Acts as a Bluetooth LE accessory are enabled to allow advertising and scanning even when the app is in the background.
When the Central device is running iOS 18/iPadOS 18 Beta 3 and the app is in the foreground scanning, and the Peripheral device is running iOS 17.5.1 with the app in the background advertising, the Central device cannot receive the advertisements from the Peripheral device. ( CBCentralManagerDelegate.centralManager(_:didDiscover:advertisementData:rssi:) don't work.)
In the reverse scenario (Central on iOS 17.5.1 in the foreground scanning, and Peripheral on iOS 18/iPadOS 18 Beta 3 in the background advertising), the advertisements are received correctly.
Additionally, advertisements are received correctly in cases where both devices are not on iOS 18/iPadOS 18.
I am wondering if anyone else has encountered this issue or if there is any information available regarding whether this is a bug or an intended behavior change in iOS 18/iPadOS 18.
Thank you.
On the OS18 build in Xcode16 of my app, user is no longer asked for bluetooth permissions.
On the current market build, the user is asked for bluetooth permissions at startup along with Siri and notifications permissions. The siri and notification prompts still display, but not the Bluetooth.
I can't find any bluetooth permission related changes in hte release notes and nothing in the code or the info.plist has changed and "Privacy - Bluetooth Always Usage Description" is listed as expected.
I now get a "Allow "xxxz" to find devices on local networks?" But not the Bluetooth permission dialog.
Does anyone know why this is happening or how to fix it?
We recently started encountering a perplexing crash when we build our iOS application to device:
Termination Reason: DYLD 1 Library missing
Library not loaded: /usr/lib/libc++.1.dylib
Referenced from: <2A9D8B8D-E81E-3FEC-A4B7-1EA4841CFC4F> /Volumes/VOLUME/*/Walmart.app/Walmart
Reason: tried: '/usr/lib/libc++.1.dylib' (no such file), '/private/preboot/Cryptexes/OS/usr/lib/libc++.1.dylib' (no such file), '/usr/lib/libc++.1.dylib' (no such file, no dyld cache)
(terminated at launch; ignore backtrace)
Highlighted by Thread: 0
See attachment for full crash log.
We've been spinning our wheels trying to understand why this could be happening.
We've had the OTHER_LDFLAGS= -lc++ for some time now and we tried linking libc++.1.tbd to no avail.
Any help?
Walmart-2024-09-26-154332.ips
This code fails to decode when running on iOS 18.0 or 18.1 beta device. But succeeds below iOS 18, such as iOS 17.5.
Xcode Version 16.0 (16A242d)
let base64String = "1ZwoNohdE8Nteis/IXl1rg=="
if let decodedData = Data(base64Encoded: base64String, options: .ignoreUnknownCharacters) {
if let decodedString = String(data: decodedData, encoding: .ascii) {
print("Decoded string: \(decodedString)")
} else {
print("Failed to decode string using ascii encoding")
}
} else {
print("Failed to decode Base64 string")
}
According to Technical Note TN2083 the Window Server advertises itself in the global bootstrap namespace, which is why you can launch GUI applications from SSH sessions, even if sshd/sshd-keygen-wrapper is launched as a launch daemon (in a non-GUI per-session bootstrap namespace).
As I understand it this is also why SessionGetInfo() reports NO for sessionHasGraphicAccess, as the SSH session is not an Aqua session type, while CGSessionCopyCurrentDictionary() does return a valid dict, because in practice you have access to the window server.
However, the tech note advices against running GUI programs from SSH sessions, as other GUI services may not be exposed to the global or non-GUI per-session bootstrap namespace. It uses com.apple.dock.server as an example of such a service, showing how Activity Monitor has different behavior when launched via SSH than via the UI.
Based on the advice of the tech note, articles like https://aahlenst.dev/blog/accessing-the-macos-gui-in-automation-contexts/ recommends running CI UI tests via a Launch Agent instead of SSH.
Now, I've tried to reproduce the the Activity Monitor case on macOS 12 and macOS 15, and I can not reproduce the missing Dock features. The Testing with Xcode documentation also says that:
By default, when you use ssh to login to an macOS system that has no active user session running, a command-line session is created. To ensure that an Aqua session is created for an ssh login, you must have a user logged in on the remote macOS host system. The existence of a user running on the remote system forces Aqua session for the ssh login. Once there is a user running on the host system, running xcodebuild from an ssh login works for all types of tests.
Which begs the question: Does modern macOS versions expose GUI services to the global or non-GUI per-session bootstrap namespace, or otherwise enable UI testing from SSH sessions, so that UI tests can safely be run from SSH sessions (as long as the user is logged in to the remote system's UI). Has things changed in this regard?
I'm observing all sorts of race conditions occurring in various VNOPs my custom filesystem implements.
I'm inclined to attribute this to my implementation not following the locking rules expected by the system of a 3rd party filesystem as well as it should.
I've looked at how locking is done in Apple's own implementation of Samba and NFS clients.
The Samba client uses read/write locks to protect its node from data races.
While the NFS client uses mutex locks for the same purpose.
I realised that I don't have a clear model in my head of how locking should be done properly.
Thus my question, what are the locking rules for VFS and VNOP operations?
Thanks.
We have a push-to-talk client, Part of Push APNS, app never received the BG task expiry.
The app is suspended.
Received Push-To-Talk APNS
Here requested a BGTask and it got successfully registered
Since it is a PTT call path, it ended immediately(via code) due to internal restrictions Ex: DND mode for client specific. The client allowed BG time more than 30 seconds and looks client has been suspended but Never received a BG task expiration handler from OS
In sys diagnose logs confirmed, BGTask registered successfully
2024-09-03 16:18:47.331890 +0530 default AT&T EPTT : Created background task .
But never got fired expiration handler.
Feedback - FB15145380
Hello,
I am developing an application that involves writing data to RFID tags using NFC (ISO/IEC 14443A/B, Mifare, and FeliCa standards) for an electric vehicle charging station. However, I am consistently facing an issue where the Apple Wallet app is automatically triggered during NFC operations on iOS. This problem occurs every time I attempt to write data to the RFID tags, preventing the application from properly detecting or interacting with the NFC tags.
Here are the key details of the issue:
Device: iPhone (tested on various models and iOS versions)
Issue: Apple Wallet automatically opens during NFC tag writing operations.
Expected Behavior: My application should write data to RFID tags without triggering Apple Wallet.
RFID Standards: ISO/IEC 14443A/B, Mifare, FeliCa.
Code Implementation: I am using the Core NFC framework and NFCISO14443ReaderSession to communicate with the RFID tags. The same code works seamlessly with Android devices, but iOS continuously triggers the Wallet app.
Here’s a brief code snippet that demonstrates the problem:
import CoreNFC
func startNFCSession() {
let session = NFCISO14443ReaderSession(delegate: self, queue: nil, invalidateAfterFirstRead: false)
session?.alertMessage = "Hold your iPhone near the NFC tag."
session?.begin()
}
func readerSession(_ session: NFCISO14443ReaderSession, didDetect tags: [NFCISO14443Tag]) {
guard let tag = tags.first else { return }
session.connect(to: tag) { (error: Error?) in
if let error = error {
session.invalidate(errorMessage: "Connection failed: \(error.localizedDescription)")
return
}
// Write data to the tag here
// The Wallet app opens instead of allowing data writing.
}
}
I've taken steps to ensure that I am not using NDEF tags, as I understand that may interfere with the Wallet functionality. Despite using the lower-level NFCISO14443ReaderSession API, the issue persists.
I’ve also tried disabling all Wallet settings on the device, but the problem still occurs. Additionally, no such issues are experienced on Android devices with similar functionality, so it appears to be an iOS-specific problem.
Is there a way to prevent Apple Wallet from being triggered when using Core NFC to interact with RFID tags?
Any assistance or guidance on how to solve this issue would be greatly appreciated, as this is a critical feature for the functionality of the electric vehicle charging station system we are building.
Thank you in advance!
Any help?
Translated Report (Full Report Below)
Process: PokerStars [2219]
Path: /Applications/PokerStars.app/Contents/MacOS/PokerStars
Identifier: com.pokerstars.PokerStars
Version: 70.813 (70.813)
Code Type: X86-64 (Native)
Parent Process: launchd [1]
User ID: 501
Date/Time: 2024-09-30 11:40:02.5034 +0200
OS Version: macOS 15.0 (24A335)
Report Version: 12
Bridge OS Version: 9.0 (22P353)
Anonymous UUID: 4748D711-22F5-94D6-9366-54F5DEB78692
Time Awake Since Boot: 2800 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000017f7cb461
Exception Codes: 0x0000000000000001, 0x000000017f7cb461
Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [2219]
VM Region Info: 0x17f7cb461 is not in any region. Bytes after previous region: 1385022562 Bytes before following region: 105546682420127
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
CG raster data 12c800000-12ceef000 [ 7100K] r--/r-- SM=COW
---> GAP OF 0x5ffed3111000 BYTES
MALLOC_NANO 600000000000-600020000000 [512.0M] rw-/rwx SM=PRV