Overview

I am using a Sonoma VM (14.6) where i have installed xcode 16.2. When i try login into apple id into xcode, i am getting this error. I know i am entering the correct credentials. Not sure why this issue is. In other Sequioa and Tahoe VM , i was able to login.

Currently I am not finding any API to read the status of Message Filter Extension from settings. Are we planning for any future releases ?

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.

Hi! If the Team ID changes (due to app ownership change) but the bundle ID remains same, during over-installation from previous version of the app with old Team ID to newer version of the app with new Team ID, does the saved Userdefaults Standard in local devices will still be accessible after over-installation?

I read on this documentation : https://developer.apple.com/help/app-store-connect/reference/app-uploads/on-demand-resources-size-limits that On Demand Resources a legacy technology. Does this mean ODR will be deprecated? If so, when will it officially take effect? Our application is planning to use it, so we need more information to support our decision.

Hi. I enter a password using the security command at the command line. It appears in the keychain access app, but not in the passwords app. I don't understand why. rickhedin@Ricks-MacBook-Pro zalando % security add-generic-password -U -s "birds" -a "cats" -w "dogs" rickhedin@Ricks-MacBook-Pro zalando % rickhedin@Ricks-MacBook-Pro zalando % security find-generic-password -s "birds" -wa "cats" dogs rickhedin@Ricks-MacBook-Pro zalando % I'm told the two apps are two views of the same data, so I guess some filter must be being applied?

After updating to visionOS 26.2 Beta 2 (and Beta 3), I'm unable to establish a spatial connection to Vision Pro. This was working fine before the update. To test, I've created a fresh spatialApp project from the Xcode template with zero modifications, but I'm hitting the same issue - the Vision Pro is discovered but won't connect. Am I forgetting to update the config somewhere? Any ideas what might be causing this and how to fix it? Thanks! Warning: -[NSWindow makeKeyWindow] called on <NSWindow: 0xa1f811900> windowNumber=1b9 which returned NO from -[NSWindow canBecomeKeyWindow]. ((processConfiguration != nil && configuration != nil) || (processConfiguration == nil && configuration == nil)) - /AppleInternal/Library/BuildRoots/4~CBS0ugAIF7BrQZjLe6r0lhPXO4GJmNDTovxYoV0/Library/Caches/com.apple.xbs/Sources/ExtensionKit/ExtensionKit/Source/HostViewController/Internal/EXHostSessionDriver.m:80: `processConfiguration` and `configuration` must be both non-nil or both nil Unable to obtain a task name port right for pid 415: (os/kern) failure (0x5) CCContextDeviceGroup.mm(291):+[CCContextDeviceGroup checkBinaryArchivesForDevice:withBundle:]: Failed to find any binary shader archive

We are integrating Apple’s DeclaredAgeRange SDK. To comply with relevant regulatory requirements, our understanding is as follows: The app is only required to obtain the declared age range for users located in Texas. For users outside of Texas, we should not proactively request age range information. Accordingly, we would like to confirm the following: Are we required to present the age range request prompt to all users in the United States? If yes, we are concerned that this may significantly impact the overall user experience. If it is permissible to request age range only for Texas users, how can we reliably determine whether a user is located in Texas on the client side? For example, does Apple provide an API or recommended method for accurately identifying a user’s region (specifically Texas)?

我提供的 ICP 备案号之后，应该如何操作，才能在中国大陆上架？

Hi everyone, I submitted an appeal to the App Review Board over 14 days ago, but I still haven’t received any update or acknowledgment. I’m now at a standstill, as this delay is blocking my app release and preventing me from moving forward. Is there a typical timeframe for ARB responses? And is there any recommended way to follow up or get the appeal looked at? Any insight from others who’ve been through the process would be appreciated. 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.)

Q4: When an alarm is dismissed (either by swiping or pressing the power button), can an app detect this action and execute code in response? What about force closed apps? When an alarm is dismissed, the stopIntent set in the AlarmConfiguration is called. Any code in the perform method of this AppIntent would execute. 我看到这样的描述，但是测试发现锁屏状态下闹钟响起时按下电源键不走AlarmConfiguration的stopIntent。设计确实是这样吗？

Hello, everyone! I encountered problems during the application review process. My app has been in the "Waiting for Review" state for over one week, while usually the review process is completed within 12 hours. And currently, there is no update of any information, and it is unknown what kind of problem has hindered it. Has anyone else experienced such a delay recently? Any suggestions on how to speed up the process or upgrade issues with Apple would be greatly appreciated.

Hi, I have a couple of questions regarding the “Offload Unused Apps” feature in iOS: 1. Is there a way to track how many users have offloaded our app? • We’re looking to understand whether Apple provides any visibility — via App Store Connect, analytics, or any API — into how often the app has been offloaded on user devices. • Specifically, we’d like to know if there’s any way to count devices that have our app offloaded (app binary removed but data retained). 2. Will push notifications still work if the app is offloaded? • Does iOS still deliver push notifications to the device if the app is offloaded? • If a user taps a notification for an offloaded app, will the app reinstall and open automatically? If there are any recommended best practices for handling offloaded app states or detecting reinstalls via push or analytics, that would be helpful too. Thanks in advance!

My development team admin requested the Enterprise API for camera access on the vision pro. We got that granted, got a license for usage, and got instructions for integrating it with next steps. We did the following: Even when I try to download and run the sample project for "Accessing the Main Camera", and follow all the exact instructions mentioned here: https://developer.apple.com/documentation/visionos/accessing-the-main-camera I am just unable to receive camera frames. I added the capabilities, created a new provisioning profile with this access, added the entitlements to info.plist and entitlements, replaced the dummy license file with the one we were sent, and also have a matching bundle identifier and development certificate, but it is still not showing camera access for some reason. "Main Camera Access" shows up in our Signing & Capabilities tab, and we also added the NSMainCameraDescription in the Info.plist and allow access while opening the app. None of this works. Not on my app, and not on the sample app that I just downloaded and tried to run on the Vision Pro after replacing the dummy license file.

Trying to make a sheet-like view that attaches at the bottom to another view so I'd like to have only the top two corners rounded. This works for a blurred effect: let glassView = UIVisualEffectView(effect: UIBlurEffect(style: .systemMaterial)) glassView.layer.cornerRadius = 20 glassView.layer.maskedCorners = [.layerMinXMinYCorner, .layerMaxXMinYCorner] glassView.layer.masksToBounds = true but if I try to use the iOS 26 UIGlassEffect, all 4 corners become rounded: let glassView = UIVisualEffectView(effect: UIGlassEffect()) glassView.layer.cornerRadius = 20 glassView.layer.maskedCorners = [.layerMinXMinYCorner, .layerMaxXMinYCorner] glassView.layer.masksToBounds = true

After uploading the build to Test Flight, we are successfully able to download the ODR tags. Submitting that same build for an App Review, they are having issues. After further investigation, they are not able to resolve the hostname when trying to download the tag. This failure on the app is causing our app to be rejected. It would be great to get some guidance on how best to resolve this situation for the App Review team. Thanks!

iOS BGProcessingTask + Background Upload Not Executing Reliably on TestFlight (Works in Debug) Description: We are facing an issue with BGTaskScheduler and BGProcessingTask when trying to perform a background audio-upload flow on iOS. The behavior is inconsistent between Debug builds and TestFlight (Release) builds. Summary of the Problem Our application records long audio files (up to 1 hour) and triggers a background upload using: BGTaskScheduler BGProcessingTaskRequest Background URLSession (background with identifier) URLSession background upload task + AppDelegate.handleEventsForBackgroundURLSession In Debug mode (Xcode → Run on device), everything works as expected: BGProcessingTask executes handleEventsForBackgroundURLSession fires Background URLSession continues uploads reliably Long audio files successfully upload even when the app is in background or terminated However, in TestFlight / Release mode, the system does not reliably launch the BGProcessingTask or Background URLSession events. Technical Details We explicitly register BGTaskScheduler: BGTaskScheduler.shared.register( forTaskWithIdentifier: "example.background.process", using: nil ) { task in self.handleBackgroundProcessing(task: task as! BGProcessingTask) } We schedule it using: let request = BGProcessingTaskRequest(identifier: "example.background.process") request.requiresNetworkConnectivity = true request.requiresExternalPower = false try BGTaskScheduler.shared.submit(request) We also use Background URLSession: let config = URLSessionConfiguration.background(withIdentifier: sessionId) config.sessionSendsLaunchEvents = true config.isDiscretionary = false AppDelegate.handleEventsForBackgroundURLSession is implemented correctly and works in Debug. Issue Observed (TestFlight Only) In TestFlight builds: BGProcessingTask rarely triggers, or the system marks it as NO LONGER RUNNING. Background upload tasks sometimes never start or complete. No logs appear from our BGProcessingTask handler. system logs show messages like: NO LONGER RUNNING bgProcessing-example.background.process Tasks running in group [com.apple.dasd.defaultNetwork] are 1! This occurs most frequently for large audio uploads (30–60 minutes), while small files behave normally. What We Have Verified Proper Info.plist values: Permitted background modes: processing, audio, fetch BGTaskSchedulerPermittedIdentifiers contains our identifier BGProcessingTask is being submitted successfully (no errors) App has microphone permission + background audio works Device plugged/unplugged doesn’t change outcome Key Question for Apple We need clarification on: Why BGProcessingTask behave differently between Debug and TestFlight builds? Are there additional restrictions or heuristics (related to file size, CPU usage, runtime, network load, or power constraints) that cause BGProcessingTask to be throttled or skipped in Release/TestFlight? How can we guarantee a background upload continues reliably for large files (100MB–500MB) on TestFlight and App Store builds? Is there an Apple-recommended pattern to combine BGProcessingTask + Background URLSession for long-running uploads? Expected Result Background uploads should continue reliably for long audio files (>30 minutes) when the app goes to background or is terminated, in the same way they currently function in Debug builds.

Hey, I successfully set my app to use alarm kit, alarm is showing up and everything, but I noticed that the sound I created (mp3 files, less than 30 sec each) only plays once, does not repeat itself. Is that intended?

Trying to figure out how to send btc, eth, etc, phone to phone. Square app allows for the phone to turn into a payment terminal for fiat currencies and payment systems. the data encryption logic and sending p2p is similar but can that functionality be enabled for alternative purposes i.e. sending crypto phone to phone (designated wallet on one phone to designated wallet on another)?