On macOS 26.1 (25B78) I can't give Full Disk Access to sshd-keygen-wrapper. Now my Jenkins jobs do not work because they do not have the permission to execute the necessary scripts. Until macOS 26.1 everything worked fine. I restarted the machine several times and tried to give access from Settings -> Privacy & Security -> Full Disk Access but it just does not work. I tried logging with ssh on the machine and executing a script but again nothing happened.
Overview
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
My app start up has became horrid. It takes 1 minute to open SQLlite database for my rust core. Impossible to work...
I have Address Sanitizer, Thread Perf Checker and Thread Sanitizer disabled...
Hello,
I have an app that is using iOS 26 Network Framework APIs.
It is using QUIC, TLS 1.3 and Bonjour. For TLS I am using a PKCS#12 identity.
All works well and as expected if the devices (iPhone with no cellular, iPhone with cellular, and iPad no cellular) are all on the same wifi network.
If I turn off my router (ie no more wifi network) and leave on the wifi toggle on the iOS devices - only the non cellular iPhone and iPad are able to discovery and connect to each other. My iPhone with cellular is not able to.
By sharing my logs with Cursor AI it was determined that the connection between the two problematic peers (iPad with no cellular and iPhone with cellular) never even makes it to the TLS step because I never see the logs where I print out the certs I compare.
I tried doing "builder.requiredInterfaceType(.wifi)" but doing that blocked the two non cellular devices from working. I also tried "builder.prohibitedInterfaceTypes([.cellular])" but that also did not work.
Is AWDL on it's way out? Should I focus my energy on Wi-Fi Aware?
Regards,
Captadoh
My team has developed an app with a Matter commissioner feature (for own ecosystem) using the Matter framework on the MatterSupport extension.
Recently, we've noticed that commissioning Matter devices with the MatterSupport extension has become very unstable. Occasionally, the HomeUIService stops the flow after commissioning to the first fabric successfully, displaying the error: "Failed to perform Matter device setup: Error Domain=HMErrorDomain Code=2." (normally, it should send open commissioning window to the device and then add the device to the 2nd fabric). The issue is never seen before until recently few weeks and there is no code changes in the app. We are suspected that there is some data that fail to download from the icloud or apple account that cause this problem.
For evaluation, we tried removing the HomeSupport extension and run the Matter framework directly in developer mode, this issue disappears, and commissioning works without any problems.
Topic:
App & System Services
SubTopic:
Core OS
Tags:
HomeKit
Provisioning Profiles
Matter
ThreadNetwork
Since October 3rd, I've stopped receiving responses to the Private Access Tokens challenge.
I'm using this link: https://demo-issuer.private-access-tokens.fastly.com/.well-known/token-issuer-directory. I receive tokens from Fastly and return a header to the iOS app, but then I don't receive another authentication request from iOS.
The user has automatic verification enabled on their phone. The problem is global and affects all my mobile app users.
Has anyone encountered a similar problem and found a solution?
Topic:
Privacy & Security
SubTopic:
General
Hello,
I am having a recurring issue using Swift Playgrounds version 4.6.4 on macOS 26.1.
Upon opening a file and every other time I start typing in the code section I get a prompt, the image below, two or three times. It doesn't matter if I accept or decline all or some of the prompts, as soon as I start typing on another line I get prompted another two or three times for permission.
It appears to me that prompt generates every time the preview pane tries to update. Declining the prompt breaks the preview but accepting the prompt only gets you through a single line of code before it appears again.
I believe this issue started after I updated to macOS26.1 as I had not encountered it before. I've also opened other files with Swift Playgrounds and encounter the same problem.
It could also be unrelated to the update and could be an issue with some permission setting somewhere, however, I have been unable to find what or where it could be.
Is anyone else experiencing this?
Thank you for your time :)
I have an app on the App Store for many years enabling users to post text into clouds in augmented reality. Yet last week abruptly upon installing the app on the iPhone the screen started going totally dark and a list of little comprehensible logs came up of the kind:
ARSCNCompositor <0x300ad0e00>: ARSCNCompositor (0, 0) initialization failed. Matting is not set up properly.
many times, then
RWorldTrackingTechnique <0x106235180>: Unable to update pose [PredictorFailure] for timestamp 870.392108
ARWorldTrackingTechnique <0x106235180>: Unable to predict pose [1] for timestamp 870.392108
again several times and then:
ARWorldTrackingTechnique <0x106235180>: SLAM error callback: Error Domain=Slam Error Code=7 "Non fatal error occurred due to significant drop in a IMU data" UserInfo={NSDescription=Non fatal error occurred due to significant drop in a IMU data, NSLocalizedFailureReason=SlamEngineNodeGroup Failure: IMU issue: gyro data stream verification failed [Significant data drop]. Failed on timestamp: 870.413247, Last known timestamp: 865.350198, Delta: 5.063049, System timestamp: 870.415781, Delta between system and frame: 0.002534. }
and then again the pose issues several times.
I hoped the new beta version would have solved the issue, but it was not the case. Unfortunately I do not know if that depends on the beta version or some other issue, given the app may be not installed on the Mac simulator.
Trying to post a question about packages on this forum, I keep cueing the message:
'This post contains sensitive language. Please revise it in order to continue.'
There is nothing in my query that is remotely ‘sensitive’.
I don’t know what to do next.
Thanks in advance for any advice.
Regards,
Lar
Hello!
I am experiencing some strange bugs around DeviceActivityEvents:
When creating a DeviceActivityEvent we can assign a threshold and applicationTokens.
The idea is, that after the user has spent said threshold on said apps, eventDidReachThreshold is called.
includesPastActivity is set to false.
On iOS 26 however, it happens (quite reliably after updating to a new beta seed) quite often that eventDidReachThreshold is called immediately (after a couple of seconds) instead of waiting for the threshold to be met.
Is anyone else seeing similar issues on iOS 26?
Only workaround I have found is to ask users to re-grant Screen Time permissions. This only holds for about two weeks though or at most until the next iOS 26 beta update is installed.
Feedback filed under:
FB18061981
FB18927456
Topic:
App & System Services
SubTopic:
General
Tags:
Family Controls
Device Activity
Managed Settings
Screen Time
Since iOS 18.3, icons are no longer generated correctly with QLThumbnailGenerator.
No error is returned either.
But this error message now appears in the console:
Error returned from iconservicesagent image request: <ISTypeIcon: 0x3010f91a0>,Type: com.adobe.pdf - <ISImageDescriptor: 0x302f188c0> - (36.00, 36.00)@3x v:1 l:5 a:0:0:0:0 t:() b:0 s:2 ps:0 digest: B19540FD-0449-3E89-AC50-38F92F9760FE error: Error Domain=NSOSStatusErrorDomain Code=-609 "Client is disallowed from making such an icon request" UserInfo={NSLocalizedDescription=Client is disallowed from making such an icon request}
Does anyone know this error? Is there a workaround?
Are there new permissions to consider?
Here is the code how icons are generated:
let request = QLThumbnailGenerator.Request(fileAt: url, size: size, scale: scale, representationTypes: self.thumbnailType)
request.iconMode = true
let generator = QLThumbnailGenerator.shared
generator.generateRepresentations(for: request) { [weak self] thumbnail, _, error in
}
Out of nowhere I got some red banner on top of my iPhone 13 mini / iOS 17.5. I cannot pin point the root cause of this. What I can say is that it only happens to Simulators of a certain type, e.g. iPhone 12 and 13 mini, but not iPhone 14 for example.
I have installed Xcode 26.1.0 and 26.1.1, out of which 26.1.0 is selected:
$ xcode-select -p
/Applications/Xcode-26.1.0.app/Contents/Developer
And following runtimes:
$ xcrun simctl runtime list
== Disk Images ==
-- iOS --
iOS 17.5 (21F79) - CF933623-A258-44F8-B248-C0F25C0C343B (Ready)
iOS 26.1 (23B80) - D11C3CDC-EE3D-44CC-8B92-9B7D00B54B0B (Ready)
Total Disk Images: 2 (14.6G)
Installing the newer 26.1 23B86 runtime doesn't help either.
As per the US state law including SB2420 in Texas.
We are suppose to meet their compliance.
We have following queries
Could you please confirm whether the provided Declared Age Range API framework is available for sandbox testing
How does the API respond for a region other than Texas
Hello. I have an 12 year old app that still has some objective-c code in it. I have a place where i have a flip animation between 2 view controllers that looks like this:
[UIView transitionFromView:origView
toView:newViewController.view
duration:0.5
options:UIViewAnimationOptionTransitionFlipFromRight
completion:nil];
It has looked like this since 2012 at least.
In our production release, it works prior to 26.1, but in 26.1 and 26.2, the flip is off-center and looks weird. it's like both edges flip the same way. It's a little bit hard to explain.
If seen at least 2 other app store apps that i have installed behave this way too, from 26.1 and onwards.
Anyone else seen this? Is there anything that can be done about it?
Thankful for thoughts.
Hi,
We use Flat package installers (.pkg based installers) to install our applications on macOS. In macOS 26.1, installation is failing with the error
Unable to use PK session due to incompatible packages. Terminating. 2025-11-03 14:22:36+05:30 Admin-3 installer[1160]: Install failed: The Installer could not install the software because there was no software found to install.
Same installer package is working on macOS 26.
Any help is greatly appreciated.
When I use the .zoom transition in a navigation stack, I get a glitch when interrupting the animation by swiping back before it completes.
When doing this, the source view disappears. I can still tap it to trigger the navigation again, but its not visible on screen.
This seems to be a regression in iOS 26, as it works as expected when testing on iOS 18.
Has someone else seen this issue and found a workaround? Is it possible to disable interrupting the transition?
Filed a feedback on the issue FB19601591
Screen recording:
https://share.icloud.com/photos/04cio3fEcbR6u64PAgxuS2CLQ
Example code
@State var showDetail = false
@Namespace var namespace
var body: some View {
NavigationStack {
ScrollView {
showDetailButton
}
.navigationTitle("Title")
.navigationBarTitleDisplayMode(.inline)
.navigationDestination(isPresented: $showDetail) {
Text("Detail")
.navigationTransition(.zoom(sourceID: "zoom", in: namespace))
}
}
}
var showDetailButton: some View {
Button {
showDetail = true
} label: {
Text("Show detail")
.padding()
.background(.green)
.matchedTransitionSource(id: "zoom", in: namespace)
}
}
}
Topic:
UI Frameworks
SubTopic:
SwiftUI
Several app developers are struggling with the inability to provide a separate app icons that looks nice on older macOS versions while at the same time provide Icon Composer icons that look great on macOS Tahoe 26. An ability to provide separate icons is super important to those who have app icons that follow the curvature of the default icon borders (as the corner rounding radius is different for Sequia and Tahoe). Take a look at this for example:
https://github.com/ghostty-org/ghostty/issues/7564#issuecomment-3042061547
Question: Is there a definitive/recommended way to address this issue? How can a developer add a glass icon variant that looks good on Tahoe and provide a bitmap icon for older macOS versions?
Some background info:
Prior to Xcode 26 beta 4, one could add an App Icon to Assets to be used as app icon for legacy macOS versions (Sequia and older) and use a new Icon Composer icon (placed in the project root) for macOS Tahoe 26. Enabling "Include all app icon assets" under target settings ensured that older macOS versions would use the old app icons while Tahoe the new Icon Composer glass one.
Since Xcode beta 4 this technique no longer works. Xcode instead insists on populating Assets.car with Icon Composer generated variants, disregarding the App Icon provided in Assets. Although the App Icon in Assets makes its way to a .incs file in the app bundle's Contents/Resources folder, but that is not used by macOS anymore and is there for some compatibility purposes. The Assets.car file (which matters) only contains the variants generated by Icon Composer and does not contain the png icons provided in the Assets.
We have developed a Parental/Self control app using Screen time API.
We have used individual authentication to authorize the app, using the instructions here:
https://developer.apple.com/documentation/familycontrols/authorizationcenter
The problem is , that individual auth can be disabled easily , by the following steps:
enter Settings app.
in Settings app, click on the Parental/Self control app.
click to disable screen time restriction.
show the device owner's face/fingerprint. (or pin code)
Why is that a problem:
Parental control apps, or self-control apps, are about giving control to the software, To make it hard for the user to disable the restrictions.
So using the flow I have introduced above, it's super-easy for a user to disable his Parental control restrictions, which misses the entire point of Parental/Self control idea.
Furthermore, not only the user have the means to unlock his screen time restrictions, he also MUST have the means to unlock it.
This makes Screen time (with individual auth) useless:
I have a code ready to make a great parental control app for my clients, with amazing ideas, but I can't use the Screen time API unless this problem is fixed.
Why child-parent auth is not enough:
My clients are grownups people between ages of 15-40, that are interested in self-control, so they don't have iCloud child accounts.
also, the child-parent auth solution forces my clients to give some control to other person, and my clients prefer their privacy. Some of them prefer self-control and not parental-control.
What I suggest as a solution:
1: Give more options to users how to disable the Screen time restrictions. including:
a second faceID / FingerPrint (that isn't the same as the one used to unlock the device)
a second pin password.
a string password
2: Give the users the option to choose to not have the device's owner Face/Finger/Pincode ID , as a method to disable the Screen time restrictions.
We have a Java application built for macOS. On the first launch, the application prompts the user to allow local network access. We've correctly added the NSLocalNetworkUsageDescription key to the Info.plist, and the provided description appears in the system prompt.
After the user grants permission, the application can successfully connect to a local server using its hostname. However, the issue arises after the system is rebooted. When the application is launched again, macOS does not prompt for local network access a second time—which is expected, as the permission was already granted.
Despite this, the application is unable to connect to the local server. It appears the previously granted permission is being ignored after a reboot. A temporary workaround is to manually toggle the Local Network permission off and back on via System Settings > Privacy & Security, which restores connectivity—until the next reboot.
This behavior is highly disruptive, both for us and for a significant number of our users. We can reproduce this on multiple systems...
The issues started from macOS Sequoia 15.0
By opening the application bundle using "Show Package Contents," we can launch the application via "JavaAppLauncher" without any issues. Once started, the application is able to connect to our server over the local network. This seems to bypass the granted permissions? "JavaAppLauncher" is also been used in our Info.plist file
Since upgrading to Xcode 26 beta 4 and using the iOS 26 simulator for testing our app, we've stopped being able to receive device tokens for the simulator from the development APNS environment.
The APNS environment is able to return meta device information (e.g. model, type, manufacturer) but there are no device tokens present. When running the same app using the iOS 18.5 simulator, we are able to register the device with the same APNS environment and receive a valid device token.
Hi all,
We are migrating a SCSI HBA driver from KEXT to DriverKit (DEXT), with our DEXT inheriting from IOUserSCSIParallelInterfaceController. We've encountered a data corruption issue that is reliably reproducible under specific conditions and are hoping for some assistance from the community.
Hardware and Driver Configuration:
Controller: LSI 3108
DEXT Configuration: We are reporting our hardware limitations to the framework via the UserReportHBAConstraints function, with the following key settings:
// UserReportHBAConstraints...
addConstraint(kIOMaximumSegmentAddressableBitCountKey, 0x20); // 32-bit
addConstraint(kIOMaximumSegmentCountWriteKey, 129);
addConstraint(kIOMaximumByteCountWriteKey, 0x80000); // 512KB
Observed Behavior: Direct I/O vs. Buffered I/O
We've observed that the I/O behavior differs drastically depending on whether it goes through the system file cache:
1. Direct I/O (Bypassing System Cache) -> 100% Successful
When we use fio with the direct=1 flag, our read/write and data verification tests pass perfectly for all file sizes, including 20GB+.
2. Buffered I/O (Using System Cache) -> 100% Failure at >128MB
Whether we use the standard cp command or fio with the direct=1 option removed to simulate buffered I/O, we observe the exact same, clear failure threshold:
Test Results:
File sizes ≤ 128MB: Success. Data checksums match perfectly.
File sizes ≥ 256MB: Failure. Checksums do not match, and the destination file is corrupted.
Evidence of failure reproduced with fio (buffered_integrity_test.fio, with direct=1 removed):
fio --size=128M buffered_integrity_test.fio -> Test Succeeded (err=0).
fio --size=256M buffered_integrity_test.fio -> Test Failed (err=92), reporting the following error, which proves a data mismatch during the verification phase:
verify: bad header ... at file ... offset 1048576, length 1048576
fio: ... error=Illegal byte sequence
Our Analysis and Hypothesis
The phenomenon of "Direct I/O succeeding while Buffered I/O fails" suggests the problem may be related to the cache synchronization mechanism at the end of the I/O process:
Our UserProcessParallelTask_Impl function correctly handles READ and WRITE commands.
When cp or fio (buffered) runs, the WRITE commands are successfully written to the LSI 3108 controller's onboard DRAM cache, and success is reported up the stack.
At the end of the operation, to ensure data is flushed to disk, the macOS file system issues an fsync, which is ultimately translated into a SYNCHRONIZE CACHE SCSI command (Opcode 0x35 or 0x91) and sent to our UserProcessParallelTask_Impl.
We hypothesize that our code may not be correctly identifying or handling this SYNCHRONIZE CACHE opcode. It might be reporting "success" up the stack without actually commanding the hardware to flush its cache to the physical disk.
The OS receives this "success" status and assumes the operation is safely complete.
In reality, however, the last batch of data remains only in the controller's volatile DRAM cache and is eventually lost.
This results in an incomplete or incorrect file tail, and while the file size may be correct, the data checksum will inevitably fail.
Summary
Our DEXT driver performs correctly when handling Direct I/O but consistently fails with data corruption when handling Buffered I/O for files larger than 128MB. We can reliably reproduce this issue using fio with the direct=1 option removed.
The root cause is very likely the improper handling of the SYNCHRONIZE CACHE command within our UserProcessParallelTask. P.S. This issue did not exist in the original KEXT version of the driver.
We would appreciate any advice or guidance on this issue.
Thank you.