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
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
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?
I can develop a PacketTunnelProvider on Mac with xcode.
I work with my self codesign.
But when I sign it with Developer ID after read https://developer.apple.com/forums/thread/737894 , it still fail when I turn on the vpn .
Hi all, I have set up a trivial test project to try Apple-hosted background assets following the instructions in the three articles at https://developer.apple.com/documentation/backgroundassets.
When I run the local mock server with xcrun ba-serve and set the URL override in Settings as described in the "Testing asset packs locally" article, I am able to download a test pack on my iOS devices. On the Mac that I use to run the mock server, however, the same call to AssetPackManager.shared.assetPack(withID: "TestAssetPack") that works on iOS always reports
The asset pack with the ID “TestAssetPack” couldn’t be looked up: No asset pack with the ID “TestAssetPack” was found.
even when not running the mock server, which led me to believe that it may not be hitting it at all. In fact, the macOS app will download asset packs uploaded to App Store Connect even when running the local server and setting the xcrun ba-serve url-override to the exact same string as in Settings on iOS. My initial suspicion was that something is wrong with the URL override, so I have tried all combinations of the Mac's hostname, IP address or "localhost" (with the corresponding SSL certificates) with and without port 443, always prefixing with "https://" for the url-override. All the same.
Does anyone have an idea what may be the issue here?
My asset pack has the following manifest:
{
"assetPackID": "TestAssetPack",
"downloadPolicy": {
"onDemand": {}
},
"fileSelectors": [
{
"file": "TestAsset.txt"
}
],
"platforms": [
"iOS",
"macOS"
]
}
I am running v26.1 for macOS, iOS & Xcode.
Edit:
Just to be clear, my assumption here is that the URL overrides (in Settings on iOS or via ba-serve on macOS) is what should cause the app to hit the mock server. Is that correct or am I missing something?
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?
macos 15.4 beta claims to support FSKit. Is there an FSKit sample available?
I don't see anything useful in the published docs.
I'm unable to view Changes or Diff View in the Deploy Schema Changes Dialog due to an Internal Error.
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
Hello team,
I am trying to find out a way to block urls in the chrome browser if it is found in local blocked list cache. I found URL Filter Network very much suitable for my requirement. But I see at multiple places that this solution is only for Enterprise level or MDM or supervised device. So can I run this for normal user ? as my targeting audience would be bank users. One more thing how can I test this in development environment if we need supervised devices and do we need special entitlement ?
When trying to run sample project in the simulator then getting below error
Platforms: macOS 15.x (Sequoia), Intel-Based
App type: Endpoint Security (ES) client, notarized Developer ID app + LaunchDaemon
Goal: Boot-time ES client that runs on any Mac (managed or unmanaged)
Summary
Our ES client launches and functions when started manually (terminal), but when loaded as a LaunchDaemon it fails to initialize the ES connection with:
(libEndpointSecurity.dylib) Failed to open service: 0xe00002d8: Caller lacks TCC authorization for Full Disk Access
We can’t find a supported way to grant Full Disk Access (SystemPolicyAllFiles) to a system daemon on unmanaged Macs (no MDM). Local installation of a PPPC (TCC) profile is rejected as “must originate from a user-approved MDM server.”
We’re seeking confirmation: Is MDM now the only supported path for a boot-time ES daemon that requires FDA? If so, what’s Apple’s recommended approach for unmanaged Macs?
Environment & Artifacts
Binary (path placeholder):
/Library/Application Support///App/.app/Contents/MacOS/
Universal (x86_64 + arm64)
Notarized, hardened runtime; Developer ID Team <TEAM_ID>
Entitlements include:
com.apple.developer.endpoint-security.client (present)
Daemon plist (simplified; placeholders used):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
<key>Label</key> <string>com.example.esd</string>
<key>Program</key>
<string>/Library/Application Support/<VENDOR>/<PRODUCT>/Platform/<daemon-exec></string>
<key>WorkingDirectory</key>
<string>/Library/Application Support/<VENDOR>/<PRODUCT>/Platform</string>
<key>RunAtLoad</key><true/>
<key>KeepAlive</key><true/>
</dict></plist>
Designated requirement (abridged & masked):
identifier "<BUNDLE_ID>" and anchor apple generic and certificate 1[...] and
certificate leaf[...] and certificate leaf[subject.OU] = "<TEAM_ID>"
What works
Launching the ES client manually (interactive shell) succeeds; ES events flow.
Signature, notarization, entitlements, Gatekeeper: all OK.
What fails (daemon)
launchctl print system/ shows it starts, but Console logs:
(libEndpointSecurity.dylib) Failed to open service: 0xe00002d8:Caller lacks TCC authorization for Full Disk Access
System TCC DB shows ES consent rows but no allow for TCCServiceSystemPolicyAllFiles for the daemon binary.
Installing a PPPC mobileconfig locally (system scope) is blocked as “must originate from a user-approved MDM server.”
Repro (minimal)
Install app bundle + LaunchDaemon plist above (placeholders).
Verify entitlements & notarization:
codesign -dvvv --entitlements :- ""
spctl --assess --type execute -vv ""
Start daemon & watch logs:
sudo launchctl bootstrap system "/Library/LaunchDaemons/.plist"
log stream --style compact --predicate 'process == "" OR subsystem == "com.apple.TCC"' --info
Observe FDA denial message only in daemon context.
Attempt to add FDA via PPPC profile (system scope) → rejected unless installed by user-approved MDM.
Questions for Apple
On macOS 14/15, is Full Disk Access for system daemons strictly MDM-only via PPPC (i.e., not installable locally)?
Under what conditions would libEndpointSecurity report a Full Disk Access denial at client initialization, given ES consent is distinct from FDA?
For unmanaged Macs needing boot-time ES processing, does Apple recommend a split: root LaunchDaemon (ES subscription; no protected file I/O) + per-user LaunchAgent (user-granted FDA) via XPC for on-demand disk access?
Would moving ES connection code into a System Extension change FDA requirements for unmanaged devices, or is FDA still governed by PPPC/MDM?
If behavior changed across releases, can Apple confirm the intended policy so vendors can document MDM requirements vs. unmanaged install paths?
What we’ve tried
Verified signature, notarization, hardened runtime, ES entitlement present.
Confirmed context difference: manual run OK; daemon fails.
Inspected system TCC: ES consent rows present; no FDA allow for daemon.
Tried installing system-scoped PPPC locally → blocked as “must originate from a user-approved MDM server.”
Considered LaunchAgent-only, but ES needs root; evaluating daemon+agent split to keep ES in root and put FDA-gated work in user space.
What we need
A definitive statement on the supported way to grant FDA to a system daemon on macOS 14/15.
If MDM PPPC is required, we’ll ship “daemon mode requires MDM” and provide a daemon+agent fallback for unmanaged devices.
If a compliant non-MDM path exists for daemon FDA on unmanaged Macs, please share exact steps.
Thanks! Happy to provide additional logs privately if helpful.
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
Hi and help needed! I updated my iPhone 16 Pro max to iOs 26. When I go to the software update section, the beta developer tab is gone, and it says "Unable to check for update"
I reset my network settings and restarted the device. No change.
Any help would be appreciated.
Topic:
App & System Services
SubTopic:
Core OS
I'm using a Mac Studio in a homelab context and use Homebrew to manage the installed services. The services include things that access the local network, for example Prometheus which monitors some other servers, a reverse proxy which fronts other web services on the network, and a DNS server which can use another as upstream.
Local Network Access permissions make it impossible to reliably perform unattended updates of services because an updated binary requires a GUI login to grant local network permissions (again).
I use brew services to manage the services as launchd agents, i.e. they run in a non-root GUI context. I know that I can also use sudo brew services which instead installs the services as launchd daemons, but running services as root has negative security implication and generally doesn't look like a good idea to me.
If only there was a way to disable local network access checks altogether…
I can reproduce the bug that CallKit doesn't active audiosession after the outgoing call put on hold because of an incoming call.
VoIP calling with CallKit
Steps to reproduce:
Download SpeakerBox example app from the link above and start it with XCode
Start a new outgoing call
Call your phone from other phone
Hold and Accept the call
After a few secs finish the call from the other phone
The outgoing call will be still on hold
Click on the call and click Toggle Hold
The call won't be active again because the audiosession is activated.
Logs:
Received provider(_:didDeactivate:)
Received provider(_:didDeactivate:)
Received provider(_:didDeactivate:)
Received provider(_:didDeactivate:)
Received provider(_:didDeactivate:)
Requested transaction successfully
Starting audio
Type: stdio
AURemoteIO.cpp:1162 failed: 561017449 (enable 3, outf< 1 ch, 44100 Hz, Float32> inf< 1 ch, 44100 Hz, Float32>)
Type: Error | Timestamp: 2024-08-15 12:20:29.949437+02:00 | Process: Speakerbox | Library: libEmbeddedSystemAUs.dylib | Subsystem: com.apple.coreaudio | Category: aurioc | TID: 0x19540d
AVAEInternal.h:109 [AVAudioEngineGraph.mm:1344:Initialize: (err = PerformCommand(*outputNode, kAUInitialize, NULL, 0)): error 561017449
Type: Error | Timestamp: 2024-08-15 12:20:29.949619+02:00 | Process: Speakerbox | Library: AVFAudio | Subsystem: com.apple.avfaudio | Category: avae | TID: 0x19540d
Couldn't start Apple Voice Processing IO: Error Domain=com.apple.coreaudio.avfaudio Code=561017449 "(null)" UserInfo={failed call=err = PerformCommand(*outputNode, kAUInitialize, NULL, 0)}
Type: Notice | Timestamp: 2024-08-15 12:20:29.949730+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d
Route change:
Type: Notice | Timestamp: 2024-08-15 12:20:30.167498+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d
ReasonUnknown
Type: Notice | Timestamp: 2024-08-15 12:20:30.167549+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d
Previous route:
Type: Notice | Timestamp: 2024-08-15 12:20:30.167568+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d
<AVAudioSessionRouteDescription: 0x302c00bc0,
inputs = (
"<AVAudioSessionPortDescription: 0x302c01330, type = MicrophoneBuiltIn; name = iPhone Mikrofon; UID = Built-In Microphone; selectedDataSource = (null)>"
);
outputs = (
"<AVAudioSessionPortDescription: 0x302c004d0, type = Receiver; name = Vev\U0151; UID = Built-In Receiver; selectedDataSource = (null)>"
)>
Type: Notice | Timestamp: 2024-08-15 12:20:30.167626+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d
A user of my app reported that when my app copies files from a QNAP NAS to a folder on their Mac, they get the error "Result too large". When copying the same files from the Desktop, it works.
I asked them to reproduce the issue with the sample code below and they confirmed that it reproduces. They contacted QNAP for support who in turn contacted me saying that they are not sure they can do anything about it, and asking if Apple can help.
Both the app user and QNAP are willing to help, but at this point I'm also unsure how to proceed. Can someone at Apple say anything about this? Is this something QNAP should solve, or is this a bug in macOS?
P.S.: I've had users in the past who reported the same issue with other brands, mostly Synology.
import Cocoa
@main
class AppDelegate: NSObject, NSApplicationDelegate {
func applicationDidFinishLaunching(_ aNotification: Notification) {
let openPanel = NSOpenPanel()
openPanel.canChooseDirectories = true
openPanel.runModal()
let source = openPanel.urls[0]
openPanel.canChooseFiles = false
openPanel.runModal()
let destination = openPanel.urls[0]
do {
try copyFile(from: source, to: destination.appendingPathComponent(source.lastPathComponent, isDirectory: false))
} catch {
NSAlert(error: error).runModal()
}
NSApp.terminate(nil)
}
private func copyFile(from source: URL, to destination: URL) throws {
if try source.resourceValues(forKeys: [.isDirectoryKey]).isDirectory == true {
try FileManager.default.createDirectory(at: destination, withIntermediateDirectories: false)
for source in try FileManager.default.contentsOfDirectory(at: source, includingPropertiesForKeys: nil) {
try copyFile(from: source, to: destination.appendingPathComponent(source.lastPathComponent, isDirectory: false))
}
} else {
try copyRegularFile(from: source, to: destination)
}
}
private func copyRegularFile(from source: URL, to destination: URL) throws {
let state = copyfile_state_alloc()
defer {
copyfile_state_free(state)
}
var bsize = UInt32(16_777_216)
if copyfile_state_set(state, UInt32(COPYFILE_STATE_BSIZE), &bsize) != 0 {
throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno))
} else if copyfile_state_set(state, UInt32(COPYFILE_STATE_STATUS_CB), unsafeBitCast(copyfileCallback, to: UnsafeRawPointer.self)) != 0 {
throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno))
} else if copyfile(source.path, destination.path, state, copyfile_flags_t(COPYFILE_DATA | COPYFILE_SECURITY | COPYFILE_NOFOLLOW | COPYFILE_EXCL | COPYFILE_XATTR)) != 0 {
throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno))
}
}
private let copyfileCallback: copyfile_callback_t = { what, stage, state, src, dst, ctx in
if what == COPYFILE_COPY_DATA {
if stage == COPYFILE_ERR {
return COPYFILE_QUIT
}
}
return COPYFILE_CONTINUE
}
}
When I've tried to use UIDevice on my Mac running my Catalyst application, testing code
UIDevice *d=UIDevice.currentDevice;
for (NSString *k in @[@"name", @"systemName", @"systemVersion", @"model", @"localizedModel"])
NSLog(@"%@ -> %@", k, [d valueForKey:k]);
to my great surprise I am getting
name -> iPad
systemName -> iPadOS
systemVersion -> 26.3
model -> iPad
localizedModel -> iPad
What the. How do I determine the real values? Thanks!
I'm writing a read-only filesystem extension.
I see that the documentation for loadResource(resource:options:replyHandler:) claims that the --rdonly option is supported, which suggests that this should be possible. However, I have never seen this option provided to my filesystem extension, even if I return usableButLimited as a probe result (where it doesn't mount at all - FB19241327) or pass the -r or -o rdonly options to the mount(8) command. Instead I see those options on the volume's activate call.
But other than saving that "readonly" state (which, in my case, is always the case) and then throwing on all write-related calls I'm not sure how to actually mark the filesystem as "read-only." Without such an indicator, the user is still offered the option to do things like trash items in Finder (although of course those operations do not succeed since I throw an EROFS error in the relevant calls).
It also seems like the FSKit extensions that come with the system handle read-only strangely as well. For example, for a FAT32 filesystem, if I mount it like
mount -r -F -t msdos /dev/disk15s1 /tmp/mnt
Then it acts... weirdly. For example, Finder doesn't know that the volume is read-only, and lets me do some operations like making new folders, although they never actually get written to disk. Writing may or may not lead to errors and/or the change just disappearing immediately (or later), which is pretty much what I'm seeing in my own filesystem extension. If I remove the -F option (thus using the kernel extension version of msdos), this doesn't happen.
Are read-only filesystems currently supported by FSKit? The fact that extensions like Apple's own msdos also seem to act weirdly makes me think this is just a current FSKit limitation, although maybe I'm missing something. It's not necessarily a hard blocker given that I can prevent writes from happening in my FSKit module code (or, in my case, just not implement such features at all), but it does make for a strange experience.
(I reported this as FB21068845, although I'm mostly asking here because I'm not 100% sure this is not just me missing something.)
We have received some information that with the release of iOS 18, there have been notable changes in how this API behaves, can apple team shed some light on this? on ios 17 this worked without much issues, what has changed on ios 18?
Hello everyone,
I am migrating a legacy KEXT to a DriverKit (DEXT) architecture. While the DEXT itself is working correctly, I am completely blocked by a code signing issue when trying to establish the UserClient connection from our SwiftUI management app.
Project Goal & Status:
Our DEXT (com.accusys.Acxxx.driver) activates successfully (systemextensionsctl list confirms [activated enabled]).
The core functionality is working (diskutil list shows the corresponding disk device node).
The Core Problem: The userclient-access Signing Error
To allow the app to connect to the DEXT, the com.apple.developer.driverkit.userclient-access entitlement is required in the app's .entitlements file.
However, as soon as this entitlement is added, the build fails.
Both automatic and manual signing fail with the same error:
`Provisioning profile ... doesn't match the entitlements file's value for the ... userclient-access entitlement.`
This build failure prevents the generation of an .app bundle, making it impossible to inspect the final entitlements with codesign.
What We've Confirmed:
The necessary capabilities (like DriverKit Communicates with Drivers) are visible and enabled for our App ID on the developer portal.
The issue persists on a clean system state and on the latest macOS Sequoia 15.7.1.
Our Research and Hypothesis:
We have reviewed the official documentation "Diagnosing issues with entitlements" (TN3125).
According to the documentation, a "doesn't match" error implies a discrepancy between the entitlements file and the provisioning profile.
Given that we have tried both automatic and manual profiles (after enabling the capability online), our hypothesis is that the provisioning profile generation process on Apple's backend is not correctly including the approved userclient-access entitlement into the profile file itself. The build fails because Xcode correctly detects this discrepancy.
Our Questions:
Did we misunderstand a step in the process, or is the issue not with the entitlement request at all? Alternatively, are there any other modifications we can make to successfully connect our App to the DEXT and trigger NewUserClient?
Thank you for any guidance.
See crash details here:- https://pastebin.com/i9u5PE4X
There's a comprehensive thread here, folks!
https://discussions.apple.com/thread/255651156?sortBy=oldest_first
Thanks for any thoughts.