“translate scheme”

Hi Apple Developer Support, We are reaching out to request guidance on a testing constraint we have encountered related to iOS Universal Links and Associated Domains entitlements. As part of aligning with updated recommendations from our authentication provider, we have transitioned our mobile apps to use HTTPS redirect callbacks (Universal Links) instead of custom URI schemes. This works as expected in production and on real physical devices. However, we are encountering a significant issue in our cloud-based device testing environment. When our testing platform re-signs the app to run it on their infrastructure, the re-signing process strips the Associated Domains entitlement from the app bundle. As a result, iOS no longer honors our Universal Links, which breaks the authentication redirect flow — the callback cannot route back into the app after the user authenticates. We have identified a potential workaround that would involve disabling app re-signing in the testing platform, but this requires p

We are trying to determine whether a third-party DriverKit HID dext can seize or intercept raw HID input reports from an external mouse through any top case–related path in the HID stack. Our dext is based on IOUserHIDEventDriver, and the goal is to receive raw input reports before they are translated into higher-level pointer events. Apple’s public HIDDriverKit documentation describes IOUserHIDEventDriver as the driver object responsible for dispatching pointer, digitizer, scrolling, and related HID-originated events, but it is not clear to us whether any “top case” path is actually exposed or supported for third-party matching in DriverKit. What we want to clarify is specifically about external mouse devices, not the built-in trackpad itself. Questions: Is there any officially supported way for a third-party DriverKit HID dext to bind through a top case–related path and receive raw HID input reports from an external mouse? Is “top case” something that third-party DriverKit drivers can meaningfully

Hi everyone, I’m the developer of one sec, an app used by a large number of users globally to reduce time spent on social media and to build healthier digital habits. Because of this, we rely heavily on Apple’s Screen Time / DeviceActivity / FamilyControls, ManagedSettings APIs – and unfortunately, we’re seeing increasingly severe issues in production that directly impact hundreds of thousands of real iOS users. During the past years, we have been busy filing dozens of feedback requests for different Screen Time issues – and there has been no response from Apple at all. Developer Relations might be able to confirm that the bugs are present and that they ended up with the right team – but they are never addressed, neither are workarounds provided. Instead, the situation gets worse and worse. iOS 26 introduced a series of heavy regressions (which have been reported via Apple’s official bug report tool Feedback Assistant on iOS 26 beta 1 in June 2025 – and have not been addressed 10 Months later). This is very f

While Apple prides itself on providing the ultimate experience for both users and developers, many find themselves trapped in a technical black hole with no exit. The issue isn't just the complexity of the systems, but the sheer inability of these systems to handle a developer’s most basic need: accessing their account to manage their business. The Dead-End Loop: Too Many Verification Codes The disaster begins with a seemingly harmless but business-destroying message: You have sent too many verification codes. Please try again later. At this point, Apple’s system—with its supposed intelligence—decides to freeze your account for two days or more. You wait patiently, return after 48 hours to log in, only to be met by the exact same message. This isn’t security; it’s primitive technical failure. How can a company of Apple’s magnitude fail to program a smart system that distinguishes between a breach attempt and a developer trying to access their work tools? Persistent failure for over a month without a root solu

Among Japanese end users, audio issues during screen recording—primarily in game applications—have become a topic of discussion. We have confirmed that the trigger for this issue is highly likely to be related to changes to IOBufferDuration. When using setPreferredIOBufferDuration and the IOBufferDuration is set to a value smaller than the default, audio problems occur in the recorded screen capture video. Audio playback is performed using AudioUnit (RemoteIO). https://developer.apple.com/documentation/avfaudio/avaudiosession/setpreferrediobufferduration(_:)?language=objc This issue was not observed on iOS 18, and it appears to have started occurring after upgrading to iOS 26. We provide an audio middleware solution, and we had incorporated changes to IOBufferDuration into our product to achieve low-latency audio playback. As a result, developers using our product as well as their end users are being affected by this issue. We kindly request that this issue be investigated and addressed in a future update. “T

Recently I noticed that although my drive showed ~800Gb of usage, the folders within totally to around ~600Gb (and yes I was including hidden 'dot' files/folders. After some inspection I found that there are a whole set of Disk Media Images, that appear to be related to XCode simulators. Here's an extract from the command line diskutil list command: /dev/disk5 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +17.6 GB disk5 Physical Store disk4s1 1: APFS Volume iOS 26.2 Simulator 17.1 GB disk5s1 /dev/disk6 (disk image): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme +14.2 GB disk6 1: Apple_APFS Container disk7 14.2 GB disk6s1 /dev/disk7 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +14.2 GB disk7 Physical Store disk6s1 1: APFS Volume XROS 26.2 Simulator 13.8 GB disk7s1 /dev/disk8 (disk image): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme +17.2 GB disk8 1: Apple_APFS Container disk9 17.2 GB disk8s1 /dev/disk9 (synthesized): #: TYPE