I've gotten to the point where I can use the mount(8) command line tool and the -t option to mount a file system using my FSKit file system extension, in which case I can see a process for my extension launch, probe, and perform the other necessary actions.
However, when plugging in my USB flash drive or trying to mount with diskutil mount, the file system does not mount:
$ diskutil mount disk20s3
Volume on disk20s3 failed to mount
If you think the volume is supported but damaged, try the "readOnly" option
$ diskutil mount readOnly disk20s3
Volume on disk20s3 failed to mount
If you think the volume is supported but damaged, try the "readOnly" option
Initially I thought it would be enough to just implement probeExtension(resource:replyHandler:) and the system would handle the rest, but this doesn't seem to be the case. Even a trivial implementation that always returns .usable doesn't cause the system to use my FSModule, even though I've enabled my extension in System Settings > General > Login Items & Extensions > File System Extensions.
From looking at some of the open source msdos and Disk Arb code, it seems like my app extension needs to list FSMediaTypes to probe. I eventually tried putting this in my Info.plist of the app extension:
<key>FSMediaTypes</key>
<dict>
<key>EBD0A0A2-B9E5-4433-87C0-68B6B72699C7</key>
<dict>
<key>FSMediaProperties</key>
<dict>
<key>Content Hint</key>
<string>EBD0A0A2-B9E5-4433-87C0-68B6B72699C7</string>
<key>Leaf</key>
<true/>
</dict>
</dict>
<key>0FC63DAF-8483-4772-8E79-3D69D8477DE4</key>
<dict>
<key>FSMediaProperties</key>
<dict>
<key>Content Hint</key>
<string>0FC63DAF-8483-4772-8E79-3D69D8477DE4</string>
<key>Leaf</key>
<true/>
</dict>
</dict>
<key>Whole</key>
<dict>
<key>FSMediaProperties</key>
<dict>
<key>Leaf</key>
<true/>
<key>Whole</key>
<true/>
</dict>
</dict>
<key>ext4</key>
<dict>
<key>FSMediaProperties</key>
<dict>
<key>Content Hint</key>
<string>ext4</string>
<key>Leaf</key>
<true/>
</dict>
</dict>
</dict>
</plist>
(For reference, the partition represented by disk20s3 has a Content Hint of 0FC63DAF-8483-4772-8E79-3D69D8477DE4 and Leaf is True which I verified using IORegistryExplorer.app from the Xcode additional tools.)
Looking in Console it does appear now that the system is trying to use my module (ExtendFS_fskit) to probe when I plug in my USB drive, but I never see a process for my extension actually launch when trying to attach to it from Xcode by name (unlike when I use mount(8), where I can do this). However I do see a Can't find the extension for <private> error which I'm not sure is related but does sound like the system can't find the extension for some reason.
The below messages are when filtering for "FSKit":
default 19:14:53.455826-0400 diskarbitrationd probed disk, id = /dev/disk20s3, with ExtendFS_fskit, ongoing.
default 19:14:53.456038-0400 fskitd Incomming connection, entitled 1
default 19:14:53.456064-0400 fskitd [0x7d4172e40] activating connection: mach=false listener=false peer=true name=com.apple.filesystems.fskitd.peer[350].0x7d4172e40
default 19:14:53.456123-0400 fskitd Hello FSClient! entitlement yes
default 19:14:53.455902-0400 diskarbitrationd [0x7461d8dc0] activating connection: mach=true listener=false peer=false name=com.apple.filesystems.fskitd
default 19:14:53.456151-0400 diskarbitrationd Setting remote protocol to all XPC
default 19:14:53.456398-0400 fskitd About to get current agent for 501
default 19:14:53.457185-0400 diskarbitrationd probed disk, id = /dev/disk20s3, with ExtendFS_fskit, failure.
error 19:14:53.456963-0400 fskitd -[fskitdXPCServer applyResource:targetBundle:instanceID:initiatorAuditToken:authorizingAuditToken:isProbe:usingBlock:]: Can't find the extension for <private>
(I only see these messages after plugging my USB drive in. When running diskutil mount, I see no messages in the console when filtering by FSKit, diskarbitrationd, or ExtendFS afterward. It just fails.)
Is there a step I'm missing to get this to work, or would this be an FSKit bug/current limitation?
Delve into the world of built-in app and system services available to developers. Discuss leveraging these services to enhance your app's functionality and user experience.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Security scoped bookmarks that were created before updating to macOS 14.7.5 cannot be resolved anymore after updating to macOS 14.7.5.
Reproduction:
Sandboxed app on macOS version 14.7.4
Create and store a security scoped bookmark to a user selected folder:
let url: URL = <user selected url from NSOpenPanel>
let data = try url.bookmarkData(options: [.withSecurityScope], includingResourceValuesForKeys: nil, relativeTo: nil)
<persistently store data>
Update to macOS 14.7.5
Resolve the previously stored bookmark:
let data: Data = <restore data from persistent storage>
var stale: Bool = true
let url = try URL(resolvingBookmarkData: data, options: [.withSecurityScope], relativeTo: nil, bookmarkDataIsStale: &stale)
Expected:
The bookmark is resolved correctly and the resulting url can be used to access the folder/file in the sandboxed app after starting access.
Observed:
URL(resolvingBookmarkData:) throws an error:
Error Domain=NSCocoaErrorDomain Code=259 "The file couldn’t be opened because it isn’t in the correct format."
New security scoped bookmarks created on macOS 14.5.7 can be resolved without issue.
The same appears to happen with macOS 13.7.5.
Entitlements:
com.apple.security.app-sandbox
com.apple.security.files.bookmarks.app-scope
com.apple.security.files.user-selected.read-write
This is very disruptive, as it appears that Sandboxed apps cannot access any previously stored bookmarks anymore.
Particularly after the recent ScopedBookmarkAgent issues in 14.7.1 and 15.0, which were resolved in 14.7.3/15.1 respectively: https://developer.apple.com/forums/thread/764435
I am writing an app using Microsoft's MAUI platform. I am posting this here because that team wants me to make an xcode project to help determine an issue I am having.
My MAUI app sends a broadcast packet on a UDP socket using address 255.255.255.255. This worked fine in iOS version 17.x. After upgrading my phone to iOS 18.x it stopped working.
The error I get is "no route to host".
The exact same code works fine on MacOS. It does not work on iPadOs 18.
My question here is 3 fold:
Did something specific change between iOS 17 and 18 that would cause a 'no route to host' error when sending a UDP broadcast packet?
Can someone provide sample code to show me how to do this type of broadcast using Swift in Xcode for iOS?
I read an article that said my app would need the com.apple.developer.networking.multicast entitlement in order to use boradcast functionality. This was introduced in iOS 14. Why did my app work fine in iOS 17 then? Is this what changed? Did this requirement use to be optional and is now required? I did get this entitlement from Apple and applied it to my provisioning profile and my app gave the same "no route to host" error. Why?
macos 15.4 beta claims to support FSKit. Is there an FSKit sample available?
I don't see anything useful in the published docs.
Original discussion pre iOS 26
Our app uses Auth0 with HTTPS callback, we've found the issue where AASA file is not ready immediately when app is initially launched, which is the exact issue from the above link.
The issue seems mostly fixed on later versions on iOS 18, however, we are seeing some indications of a regression on iOS 26. Here's some measurement over the last week.
| Platform | iOS 18 | iOS 26 |
|---------------|----------|--------|
| Adoption rate | 55% | 45% |
| Issue seen | 1 | 5 |
| Recover? | Yes | No |
This only 1 iOS 18 instance was able to recover after 1 second after the first try, however, all iOS 26 instances were not able to recover in couple tens of seconds and less than 1 minute, the user eventually gave up.
Is there a way to force app to update AASA file?
Are there some iOS setting (like using a VPN) that could potentially downgrade the AASA fetch?
Related Auth0 discussion:
https://community.auth0.com/t/ios-application-not-
recognizing-auth0-associated-domain/134847/27
My App payment encountered a unkonw((StoreKit.StoreKitError) error = unknown) error in iOS18.2, then the lldb log "Could not find a visible window in the scene for xxx purchase."."xxx" is purchase product id.
Why does this error occur, and how can I fix it?
My app is a VoIP softphone for Mac that allows people to make phone calls to a regular phone numbers. The app exists since before Mac App Store. The app declares itself to the system as capable of handling tel: URLs. Until now, people could change the default handler for tel URLs in FaceTime settings (Default for calls).
In macOS Tahoe 26, this doesn't seem to be possible any more. That option is gone from the FaceTime settings.
Is it completely gone or has it been moved somewhere else? If there is no UI control for this any more, is it possible to change it programmatically?
I see this in Tahoe Beta release notes
macOS now supports the Apple Sparse Image Format (ASIF). These space-efficient images can be created with the diskutil image command-line tool or the Disk Utility application and are suitable for various uses, including as a backing store for virtual machines storage via the Virtualization framework. See VZDiskImageStorageDeviceAttachment. (152040832)
I'm developing a macOS app using the Virtualization framework and need to create disk images in the ASIF (Apple Sparse Image Format) to make use of the new feature in Tahoe
Is there an official way to create/resize ASIF images programmatically using Swift? I couldn’t find any public API that supports this directly.
Any guidance or recommendations would be appreciated.
Thanks!
Hello everyone,
We are migrating our KEXT for a Thunderbolt storage device to a DEXT based on IOUserSCSIParallelInterfaceController.
We've run into a fundamental issue where the driver's behavior splits based on the I/O source: high-level I/O from the file system (e.g., Finder, cp) is mostly functional (with a minor ls -al sorting issue for Traditional Chinese filenames), while low-level I/O directly to the block device (e.g., diskutil) fails or acts unreliably. Basic read/write with dd appears to be mostly functional.
We suspect that our DEXT is failing to correctly register its full device "personality" with the I/O Kit framework, unlike its KEXT counterpart. As a result, low-level I/O requests with special attributes (like cache synchronization) sent by diskutil are not being handled correctly by the IOUserSCSIParallelInterfaceController framework of our DEXT.
Actions Performed & Relevant Logs
1. Discrepancy: diskutil info Shows Different Device Identities for DEXT vs. KEXT
For the exact same hardware, the KEXT and DEXT are identified by the system as two different protocols.
KEXT Environment:
Device Identifier: disk5
Protocol: Fibre Channel Interface
...
Disk Size: 66.0 TB
Device Block Size: 512 Bytes
DEXT Environment:
Device Identifier: disk5
Protocol: SCSI
SCSI Domain ID: 2
SCSI Target ID: 0
...
Disk Size: 66.0 TB
Device Block Size: 512 Bytes
2. Divergent I/O Behavior: Partial Success with Finder/cp vs. Failure with diskutil
High-Level I/O (Partially Successful):
In the DEXT environment, if we operate on an existing volume (e.g., /Volumes/MyVolume), file copy operations using Finder or cp succeed. Furthermore, the logs we've placed in our single I/O entry point, UserProcessParallelTask_Impl, are triggered.
Side Effect: However, running ls -al on such a volume shows an incorrect sorting order for files with Traditional Chinese names (they appear before . and ..).
Low-Level I/O (Contradictory Behavior):
In the DEXT environment, when we operate directly on the raw block device (/dev/disk5):
diskutil partitionDisk ... -> Fails 100% of the time with the error: Error: -69825: Wiping volume data to prevent future accidental probing failed.
dd command -> Basic read/write operations appear to work correctly (a write can be immediately followed by a read within the same DEXT session, and the data is correct).
3. Evidence of Cache Synchronization Failure (Non-deterministic Behavior)
The success of the dd command is not deterministic. Cross-environment tests prove that its write operations are unreliable:
First Test:
In the DEXT environment, write a file with random data to /dev/disk5 using dd.
Reboot into the KEXT environment.
Read the data back from /dev/disk5 using dd. The result is a file filled with all zeros.
Conclusion: The write operation only went to the hardware cache, and the data was lost upon reboot.
Second Test:
In the DEXT environment, write the same random file to /dev/disk5 using dd.
Key Variable: Immediately after, still within the DEXT environment, read the data back once for verification. The content is correct!
Reboot into the KEXT environment.
Read the data back from /dev/disk5. This time, the content is correct!
Conclusion: The additional read operation in the second test unintentionally triggered a hardware cache flush. This proves that the dd (in our DEXT) write operation by itself does not guarantee synchronization, making its behavior unreliable.
Our Problem
Based on the observations above, we have the conclusion:
High-Level Path (triggered by Finder/cp):
When an I/O request originates from the high-level file system, the framework seems to enter a fully-featured mode. In this mode, all SCSI commands, including READ/WRITE, INQUIRY, and SYNCHRONIZE CACHE, are correctly packaged and dispatched to our UserProcessParallelTask_Impl entry point. Therefore, Finder operations are mostly functional.
Low-Level Path (triggered by dd/diskutil):
When an I/O request originates from the low-level raw block device layer:
The most basic READ/WRITE commands can be dispatched (which is why dd appears to work).
However, critical management commands, such as INQUIRY and SYNCHRONIZE CACHE, are not being correctly dispatched or handled. This leads to the incorrect device identification in diskutil info and the failure of diskutil partitionDisk due to its inability to confirm cache synchronization.
We would greatly appreciate any guidance, suggestions, or insights on how to resolve this discrepancy. Specifically, what is the recommended approach within DriverKit to ensure that a DEXT based on IOUserSCSIParallelInterfaceController can properly declare its capabilities and handle both high-level and low-level I/O requests uniformly?
Thank you.
Charles
We have a that relies on accurate GPS location but we’ve noticed that every now and then the location ‘jumps’ a few hundred meters to a different location but reports horizonal accuracy less than 10m.
we think the device is picking up a rough location from a local WiFi rather than internal gps sensors.
can we
a) disable WiFi location Updates?
b) identify WiFi location Updates?
thank You
I have an app that uses NSPersistentCloudKitContainer stored in a shared location via App Groups so my widget can fetch data to display. It works. But if you reset your iPhone and restore it from a backup, an error occurs:
The file "Name.sqlite" couldn't be opened. I suspect this happens because the widget is created before the app's data is restored. Restarting the iPhone is the only way to fix it though, opening the app and reloading timelines does not. Anything I can do to fix that to not require turning it off and on again?
For a long time our app had this creation of a URLRequest:
var urlRequest = URLRequest(url: url, cachePolicy: .reloadIgnoringLocalAndRemoteCacheData, timeoutInterval: timeout)
But since iOS 26 was released we started to get crashes in this call. It is created on a background thread.
Thread 10 Crashed:
0 libsystem_malloc.dylib 0x00000001920e309c _xzm_xzone_malloc_freelist_outlined + 864 (xzone_malloc.c:1869)
1 libswiftCore.dylib 0x0000000184030360 swift::swift_slowAllocTyped(unsigned long, unsigned long, unsigned long long) + 56 (Heap.cpp:110)
2 libswiftCore.dylib 0x0000000184030754 swift_allocObject + 136 (HeapObject.cpp:245)
3 Foundation 0x00000001845dab9c specialized _ArrayBuffer._consumeAndCreateNew(bufferIsUnique:minimumCapacity:growForAppend:) + 120
4 Foundation 0x00000001845daa58 specialized static _SwiftURL._makeCFURL(from:baseURL:) + 2288 (URL_Swift.swift:1192)
5 Foundation 0x00000001845da118 closure #1 in _SwiftURL._nsurl.getter + 112 (URL_Swift.swift:64)
6 Foundation 0x00000001845da160 partial apply for closure #1 in _SwiftURL._nsurl.getter + 20 (<compiler-generated>:0)
7 Foundation 0x00000001845da0a0 closure #1 in _SwiftURL._nsurl.getterpartial apply + 16
8 Foundation 0x00000001845d9a6c protocol witness for _URLProtocol.bridgeToNSURL() in conformance _SwiftURL + 196 (<compiler-generated>:974)
9 Foundation 0x000000018470f31c URLRequest.init(url:cachePolicy:timeoutInterval:) + 92 (URLRequest.swift:44)# Live For Studio
Any idea if this crash is caused by our code or if it is a known problem in iOS 26?
I have attached one of the crash reports from Xcode:
2025-10-08_10-13-45.1128_+0200-8acf1536892bf0576f963e1534419cd29e6e10b8.crash
We tested call blocking on iOS 26 and noticed something strange: the call will not be blocked if an outgoing call was made to its number before. Nevertheless, it will be blocked if we delete the outgoing call record from the Phone.app Recents.
This behavior looks like a bug and is unexpected when using our application. Was this a planned callkit change in iOS 26? Is it possible to get the correct call blocking behavior back?
We set blocking rules with addBlockingEntry(withNextSequentialPhoneNumber:) and this problem is not present in iOS 18 and earlier.
Thank you in advance
All the threads only contain system calls. The crashed thread only contains a single call to my app's code which is main.swift:13.
What could cause such a crash?
crash.crash
I'm currently experimenting with the latest Xcode beta 15.3 (15E5194e) and attempting to integrate FinanceKit](https://developer.apple.com/documentation/financekit) into my project. However, I've encountered a persistent issue where the app crashes upon attempting to read or request authorization, accompanied by the following error message:
FinanceKit/FinanceStore+FinancialDataAuthorization.swift:52: Fatal error: Process is not entitled
Upon investigation, I've found no evident entitlements for FinanceKit, despite exploring options like Apple Wallet. Furthermore, I thoroughly examined the info.plist for relevant privacy values but found nothing pertinent.
Here's the code snippet that triggers the fatal error, whether it's the request or read function:
I don't see anything in entitlements for FinanceKit (I tried Apple Wallet and that didn't make a difference). Additionally, I checked for relevant privacy values for the info.plist but again didn't see anything relevant.
Here is the code to reproduce the error (note calling either function will result in the same fatal error):
import FinanceKit
import UIKit
class ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
requestFinancePermission()
// readFinancePermission()
}
private func requestFinancePermission() {
Task {
do {
let status = try await FinanceStore.shared.requestAuthorization()
} catch {
print("Error: \(error)")
}
}
}
private func readFinancePermission() {
Task {
do {
let status = try await FinanceStore.shared.authorizationStatus()
} catch {
print("Error: \(error)")
}
}
}
}
I'm seeking clarification on whether FinanceKit is currently usable or if there are additional steps needed for proper integration. Any insights or suggestions would be greatly appreciated. Thank you!
Hello,
I'm trying to adopt the new BGContinuedProcessingTask API, but I'm having a little trouble imagining how the API authors intended it be used. I saw the WWDC talk, but it lacked higher-level details about how to integrate this API, and I can't find a sample project.
I notice that we can list wildcard background task identifiers in our Info.plist files now, and it appears this is to be used with continued tasks - a user might start one video encoding, then while it is ongoing, enqueue another one from the same app, and these tasks would have identifiers such as "MyApp.VideoEncoding.ABCD" and "MyApp.VideoEncoding.EFGH" to distinguish them.
When it comes to implementing this, is the expectation that we:
a) Register a single handler for the wildcard pattern, which then figures out how to fulfil each request from the identifier of the passed-in task instance?
Or
b) Register a unique handler for each instance of the wildcard pattern? Since you can't unregister handlers, any resources captured by the handler would be leaked, so you'd need to make sure you only register immediately before submission - in other words register + submit should always be called as a pair.
Of course, I'd like to design my application to use this API as the authors intended it be used, but I'm just not entirely sure what that is. When I try to register a single handler for a wildcard pattern, the system rejects it at runtime (while allowing registrations for each instance of the pattern, indicating that at least my Info.plist is configured correctly). That points towards option B.
If it is option B, it's potentially worth calling that out in documentation - or even better, perhaps introduce a new call just for BGContinuedProcessingTask instead of the separate register + submit calls?
Thanks for your insight.
K
Aside: Also, it would be really nice if the handler closure would be async. Currently if you need to await on something, you need to launch an unstructured Task, but that causes issues since BGContinuedProcessingTask is not Sendable, so you can't pass it in to that Task to do things like update the title or mark the BGTask as complete.
Hi all,
I am adding the following StoreKit 2 code to my app, and I don't see anything in Apple's documentation that explains the unverified case. When is that case exercised? Is it when someone has tampered with the app receipt? Or is it for more mundane things like poor network connectivity?
// Apple's docstring on `shared` states:
// If your app fails to get an AppTransaction by accessing the shared property, see refresh().
// Source: https://developer.apple.com/documentation/storekit/apptransaction/shared
var appTransaction: VerificationResult<AppTransaction>?
do {
appTransaction = try await AppTransaction.shared
} catch {
appTransaction = try? await AppTransaction.refresh()
}
guard let appTransaction = appTransaction else {
AppLogger.error("Couldn't get the app store transaction")
return false
}
switch appTransaction {
case .unverified(appTransaction, verificationError):
// For what reasons should I expect this branch to be entered in production?
return await inspectAppTransaction(appTransaction, verifiedByApple: false)
case .verified(let appTransaction):
return await inspectAppTransaction(appTransaction, verifiedByApple: true)
}
Thank you,
Lou
Could someone please explain how to use a custom sound when setting up an alarm using AlarmKit? It keeps playing a default sound.
Also, I keep having an issue where the alarm sound plays but doesn’t show the alarm interface buttons unless the screen is locked.
Topic:
App & System Services
SubTopic:
General
I'm unable to view Changes or Diff View in the Deploy Schema Changes Dialog due to an Internal Error.
=1) The situation:
1A) I make both a "DExt" and a "SDK" for still-imaging-USB-gadgets and MACOS>=14 ,iPADOS>=17
1B) One of the USB-gadgets needs warm_up after PlugIn (i.e End-User-App must know "now-TheMomentOfPlugIn" with precision ~1sec).
=2) The question is how to do "1B" rationally?
=3) My speculative guess: in BSD-descendant I expect existence (somewhere) of a "normal file" through "macports etc", which has normal "file creation time". Such a "file creation time" (accessible better via IORegistryEntry... at SDK-level; possibly via IOUSBHostInterface at DExt-level) is cognitive target of mine.
=4) Additional constraints: Technically absent. I freely modify code either DExt (descendant of IOUSBHostInterface) or SDK-level (IORegistryEntryGetRegistryEntryID, IORegistryEntry...)
Topic:
App & System Services
SubTopic:
Drivers