I’m developing a dedicated children’s audio player using MusicKit JS. Ideally, a child would have access to their own Apple Music library and listening history while remaining managed through Family Sharing. Apple Developer Support confirmed that MusicKit cannot be authorized for an under-13 Apple Account due to age restrictions. Is there an Apple-supported alternative, such as parent authorization with access to a child’s library through any other SDK/API path?

iOS already gives users a simple per-app Microphone permission: Settings → Apps → [App] → Microphone: On/Off Why isn’t there an equivalent permission in the other direction? Settings → Apps → [App] → Audio Output: On/Off This would solve a surprisingly common problem: I may deliberately be listening to Spotify, an audiobook or a podcast, then open another app which suddenly produces audio from an advertisement or autoplaying video. That audio may mix with, duck, or even interrupt what I actually chose to listen to. As I understand the current architecture, apps use AVAudioSession to describe how their audio should interact with other audio. But much of that policy is therefore controlled by the application producing the unwanted audio, rather than by the device owner. The simplest solution wouldn’t require a per-app mixer or complicated audio controls. Just one user-controlled permission: Allow Audio Output: On / Off When disabled, iOS would prevent that app from producing audible media output, while audio sessions belonging to other apps would continue normally. Conceptually, this seems very similar to the existing Microphone permission: Microphone: Can this app receive audio from my device? Audio Output: Can this app produce audio on my device? More advanced controls — per-app volume, permission to interrupt other audio, ducking policy, etc. — could potentially come later. But they aren’t necessary to solve the fundamental problem. I’m curious from an AVAudioSession perspective: Is there a technical reason why iOS could not enforce an OS-level per-app Audio Output permission in the same way it already enforces Microphone access? And if there isn’t, would others find this useful?

The iOS 26 sample below speaks well on iPhone/iPad devices and the iOS simulator. But it does not speak on "Mac (Designed for iPad)", with a voice downloaded via the macOS settings. Instead it issues this warning : Invalid maui voice identifier com.apple.voice.enhanced.en-US.Samantha How to make an iOS app speak on "Mac (Designed for iPad)", with a downloaded voice ? Note : I use iOS 26.5.2 and macOS 26.5.2. I use voices that can be found in System Settings > Accessibility > Read & Speak > System voice. I have checked that "Samantha (Enhanced)" is the "System voice" in the macOS settings. I have checked that the same issue occurs with other voices and other languages. There is no such issue for a voice that never needs to be downloaded. import AVFAudio import SwiftUI @main struct SampleApp: App { var body: some Scene { WindowGroup { SampleView() } } } struct SampleView: View { private var synthesizer = AVSpeechSynthesizer() var body: some View { Button("Speak", action: speak) } private func speak() { let utterance = AVSpeechUtterance(string: "I speak English.") utterance.voice = AVSpeechSynthesisVoice(language: "en") self.synthesizer.speak(utterance) } }

We capture Apple Log video using AVCaptureVideoDataOutput with: AVCaptureDevice.activeColorSpace = .appleLog or .appleLog2 kCVPixelFormatType_422YpCbCr10BiPlanarVideoRange (x422) AVAssetWriter for the final ProRes/HEVC recording We need to bake spatial operations such as a centre crop and optional anamorphic desqueeze into the recorded raster. We want the result to remain Apple Log for subsequent grading; we do not want to display-transform or convert it to HLG. Core Image/Core Graphics does not appear to expose a public Apple Log or Apple Log 2 CGColorSpace. Core Video instead identifies the signal using kCVImageBufferLogTransferFunctionKey. Would this be the supported Core Image approach for spatial-only processing? let image = CIImage( cvPixelBuffer: sourceBuffer, options: [.colorSpace: NSNull()] ) let context = CIContext( mtlDevice: metalDevice, options: [ .workingColorSpace: NSNull(), .outputColorSpace: NSNull(), .cacheIntermediates: false ] ) let outputImage = image .cropped(to: cropRect) .transformed(by: spatialTransform) context.render( outputImage, to: destinationX422Buffer, bounds: outputBounds, colorSpace: nil ) We would then copy the source buffer’s Apple Log colour and Log-transfer attachments to the destination buffer and append it to an AVAssetWriterInputPixelBufferAdaptor. Could an Apple engineer clarify the following? Does CIImage(cvPixelBuffer:) natively interpret kCVImageBufferLogTransferFunctionKey, even though no public Apple Log CGColorSpace exists? When NSNull()/nil is supplied as above, does Core Image leave the Apple Log values unmanaged during crop and affine operations? When rendering x422 to x422, can Core Image preserve the Log signal apart from expected resampling/rounding, or does it internally perform a colour conversion such as YCbCr → RGB → YCbCr? For scaling or anamorphic desqueeze, is Apple’s recommended workflow to: resample the encoded Apple Log values with colour management disabled, or explicitly decode Apple Log to a linear working space, resample, and encode back using a custom Metal implementation? Is copying kCVImageBufferLogTransferFunctionKey and the related colour attachments from source to destination sufficient for AVAssetWriter, assuming the writer settings were obtained from recommendedVideoSettingsForAssetWriter(writingTo:)? Is there ever a supported reason to use HLG as an intermediate for Apple Log processing, or should that be avoided? This this part, we are concerned about preserving the captured Log signal in a recording pipeline, not applying a viewing LUT or displaying Apple Log. Next, we also support optional LUT processing with CIColorCube. Some LUTs are technical Apple Log-to-display transforms, while others expect linear or Rec.709 input. If the image is created with .colorSpace: NSNull(), we understand that the LUT receives unmanaged Apple Log code values and that the LUT itself must perform the required transfer-function and gamut conversion. Does Core Image synthesize an Apple Log-aware input color space from kCVImageBufferLogTransferFunctionKey, or must applications implement Apple Log/Apple Log 2 decoding explicitly before using ordinary Core Image filters? Is there a supported CGColorSpace, ColorSync profile, or Core Image conversion API for this? Additionally, what numeric range does CIColorCube receive when its source is an x422 video-range Apple Log buffer— normalized Log RGB values, or values requiring explicit video-range conversion?

Summary. iPhone 17 Pro Max + Blackmagic Camera ProDock, genlock BNC in from a generator confirmed at a true 30.00 fps. follow(_:videoFrameDuration:delegate:) reaches .activeSync in ~2 s. On one unit the lock then holds for 10+ minutes. On a second unit, same binary and same reference, it detaches 6 s to ~4 min after lock: .activeSync → .ready with input.externalSyncDevice == nil, no runtime error and no delegate error. Calling follow() again on the still-running session is rejected with -11800 every time, while unfollowExternalSyncDevice() plus a stopRunning()/startRunning() bounce recovers reliably. I am not looking for a fix. I want to know whether my call sequence is wrong, whether this transition is expected, and how a shipping app should be structured around it. Questions Is re-following a running session supported? Is the unfollow + bounce the intended reset sequence, or is there a lighter-weight way to clear whatever state the -11800 is keyed on? And once detached, is re-acquisition entirely the app's responsibility, or is the system expected to re-calibrate on its own while the reference is present? Is a hard detach a legal outcome for an already-calibrated input? The documentation describes .freeRunSync as the hold-over when a locked input loses sync. Is that hold-over guaranteed, or must an app also handle .activeSync → .ready with a nil externalSyncDevice? Is anything in my call sequence wrong (code in a reply below), and is polling input.externalSyncDevice the right signal to key recovery on, or is there a supported notification for detach? Setup. Video-only AVCaptureSession: one .builtInWideAngleCamera input, one AVCaptureVideoDataOutput. No multi-cam, no depth output, no synchronizer, no audio. Both frame durations set to CMTime(1, 30) before the input is created, never rewritten while a follow is live. Device A (iOS 26.0.1) holds: 601 s and 956 s runs, zero detaches. Device B (26.3.1, then 26.5.2) has 39 drops across 6 logs. The ProDock, cable and generator were swapped between units; the failure followed the phone. Caveat: n=2, and unit and OS build vary together. The detach. No AVCaptureSessionRuntimeError and no delegate error (-11892 has never been observed here, so this is not the documented frame-duration-mismatch path). The session keeps running and delivering frames. Status is .ready, not .unavailable — the ProDock stays enumerated, the reference unchanged. No confirmed drop has passed through .freeRunSync. PTS ground truth, independent of the follow state: while locked, every frame PTS sits exactly on the 1/30 grid, zero drift. At the drop there is exactly one teardown gap, 238–337 ms across 8 runs, after which the clock free-runs at ~30.013 fps (444 ppm) and never returns to the grid. On -11800. It surfaces through AVCaptureSessionRuntimeErrorNotification. The bounce recovers 3/3, with no activeFormat change. Caveat: -11800 is AVErrorUnknown and I see it in unrelated cases too, so I do not assume it is specific to retained follow state. Ruled out. Exposure duration — a run at ≤ 16.67 ms, within the recommendation in the follow() documentation, still drops. Reference drift — zero, by microsecond PTS. Accessory chain — full swap; the failure followed the phone. Another client — Final Cut Camera holds genlock on the fragile unit with the same ProDock and reference. Load and resolution — load changes time-to-drop, not whether it drops; with recording and audio off it still drops, and Device B drops at both 12 MP and 1080p. Code and supporting logs are in replies below; the length limit would not take them inline. Per-frame PTS CSVs, raw status logs, and a minimal Xcode project that still drops are available on request. Prior art read: forums/thread/799739 and thread/804594 — neither covers post-lock detach or re-acquisition.

If an app allows people to create a playlist and add more songs to that created playlist, it would make sense to guard them from accidentally adding the same song to the playlist more than once. In this code, even though it is successfully receiving the existing playlist from the request, its tracks and entries always show as nil even when there are songs in the playlist. Any suggestions for how to guard against adding duplicates to a playlist? Thank you! var request = MusicLibraryRequest<Playlist>() request.filter(matching: \.name, equalTo: "AppGeneratedPlaylist") let response = try await request.response() if let existingPlaylist = response.items.first { if let tracks = existingPlaylist.entries, tracks.contains(where: { $0.id == song.id }) { print("Song is already in the playlist, so don't add again") return } else { try await MusicLibrary.shared.add(song, to: existingPlaylist) print("Added song to existing playlist: \(existingPlaylist.name)") print("Count of tracks: \(existingPlaylist.tracks?.count)") print("Count of entries: \(existingPlaylist.entries?.count)") print("Current tracks: \(existingPlaylist.tracks?.map(\.id))") print("Current entries: \(existingPlaylist.entries?.map(\.id))") } }

Due to hysterical raisins, our Apple Developer Account (2A...FW) has five FairPlay Streaming resources under https://developer.apple.com/account/resources/certificates/list Three of these are certificates (fairplay.cer) and two of them are provisioning packages (fps-bundle.zip). The three certificates all use 1024-bit RSA keys and have creation dates of: Oct 24 23:22:09 2016 (expired Oct 25 23:22:09 2018) 3J Mar 29 19:39:15 2018 (expired Mar 29 19:39:15 2020) 2N Feb 11 00:32:06 2026 (expires Feb 1 00:22:57 2027) LD (I've included the first two characters of the Apple resource ID to help keep these straight.) The key for the first two (same key for both) is lost to the mists of time. The third is a cert I created from a new key, so I have the key for it. (The developer portal will not let us create any more 1024-bit FairPlay certs.) The two FPS bundles each contain an fps_certificate.bin which itself contains a 1024-bit cert and a 2048-bit cert. Looking at this file in each bundle, the bundles include the same 1024-bit cert that I created on Feb 11, but two different 2048-bit certs with creation dates of: Feb 11 00:32:06 2026 (expires Feb 11 00:32:05 2028) YP Feb 11 00:56:22 2026 (expires Feb 11 00:56:21 2028) 9N Both 2048-bit certs use the same key (which I have). Finally, we use a third-party as our streaming provider. With them we shared the first FPS bundle (YP). So, this is a big mess. And I'm unable to delete any of these entries from our developer account. Questions: Does the expiration date on these certs matter or is it ignored for streaming purposes? How do we delete FP certs/bundles we no longer need/use/are expired? With respect to using third-party vendors for streaming (with whom we've shared an FPS bundle): Is it okay to re-use the same FPS bundle if we change vendors? Should we ask Apple to delete an FPS bundle once we stop using a vendor?

I have not seen any issues with didActivateAudioSession not getting called by iOS in many many years with many thousands of devices. However with iOS27 beta code I have seen a few times that when making an outgoing call it never gets called. All subsequent outgoing calls fail until I dismiss and relaunch the App.

An image file whose data is cut in half is accepted by insertOrUpdateAssets, produces no error, and is reported as an image containing zero faces. That result is indistinguishable from a photograph that genuinely has no people in it. In my measurement the intact file reported 4 faces and a copy truncated to half its bytes reported 0 faces — both without throwing. Why this is worse than an error. A client that receives "zero faces, no error" will record the asset as analysed, no people present. That is a permanent, silent, incorrect result: the file is never revisited, and the people in it are lost from the catalogue with no diagnostic anywhere. An error would have been recorded as a failure and retried later. Silence is the one outcome that cannot be recovered from. The failure mode is also inconsistent. Other kinds of damaged input do throw — a zero-byte file, a text file with a .jpg extension, and a file whose interior bytes have been destroyed all raise MediaIntelligenceError.faceGroupProcessing. Truncation is the case that silently succeeds, and truncation is precisely the damage that partial downloads, interrupted copies and failing disks produce — the most common form of corruption in a real photo archive, and the one I have to handle in 97 libraries of mixed provenance. My current workaround is to fully decode every image myself before handing it to the framework, purely to detect truncation. That means every file is decoded twice, which roughly doubles the I/O of the analysis pass. Feedback: FB24174749

If a single asset in the array passed to insertOrUpdateAssets cannot be read, the returned AsyncSequence throws and delivers zero elements — including for the valid assets that appear before the offending one in the array. In my measurement a batch of 5 — two valid photographs, one zero-byte .jpg, then two more valid photographs — delivered 0 of 5 elements and reported 0 faces. The framework's own stdout log shows it had already processed the valid photographs before failing, so the work was done and then thrown away. This is the behaviour I would expect from a function returning [Result] after processing everything, not from a streaming AsyncSequence. The whole reason to expose an async sequence is to deliver results as they are produced; here the sequence produces nothing at all, which makes the streaming shape actively misleading. Why this matters at library scale. I am cataloguing 97 photo libraries, many of them archives of scanned family photographs going back to the 1970s, where a handful of damaged files is normal rather than exceptional. As the API stands, the batch size I choose for throughput is also the amount of work a single corrupt file destroys — with a batch of 100, one bad file costs 100 images. The only safe strategy is to catch the failure and re-submit the batch one asset at a time to find the culprit, which turns a rare bad file into a full re-run of that batch and makes the worst case quadratic in the number of bad files. Note also that the error gives no indication of which asset failed (see the related enhancement request on error taxonomy), so isolating the culprit by re-submission is the only option available. Feedback: FB24174733

insertOrUpdateAssets(_:) is async throws and returns an AsyncSequence, so by the Swift Concurrency contract I expected it to observe cancellation of the enclosing Task and throw CancellationError. It does not. The call runs to completion and returns successfully, with the full result set, as though the cancellation had never happened. In my measurement the cancel was delivered at 2.7 s and the call returned successfully at 19.0 s, having processed all 150 assets and reported 550 faces. The practical consequence for an app is that a "Stop" button cannot stop work that is already in flight. The only way to get responsive cancellation is to slice the work into many small calls and check Task.checkCancellation() between them — which means the batch size, which should be tuned for throughput, ends up being dictated by how long a user is willing to wait after pressing Stop. For me that is the difference between a batch of 150 (≈19 s to react) and a batch of 25 (≈3 s). The store is left in a consistent state, which is good: the assets processed before cancellation remain, and state correctly becomes .stale. So this is specifically about the cancellation signal being ignored, not about data integrity. One detail worth knowing when reproducing this insertOrUpdateAssets is declared nonisolated(nonsending), so it executes on the caller's executor. My first attempt at this reproducer used a plain Task { } created from @MainActor top-level code — which inherits main-actor isolation — and the detection therefore ran on the main actor and starved the very code that was supposed to cancel it: a Task.sleep(2.5s) on the main actor did not resume until the 19-second call had already finished, so the cancel was not even delivered until 19.0 s. The attached reproducer uses Task.detached to avoid that confound, and the cancel is correctly delivered at 2.7 s. I mention it because anyone reproducing this from a @MainActor context will see a different and misleading timeline. Feedback: FB24174707

Constructing a second FaceGroupAnalyzer while a first one is still alive registers the framework's Core Data managed object model a second time. Core Data can then no longer resolve +[MIManagedFace entity], and the process is terminated with SIGTRAP (exit status 133). Three things make this worse than a normal API misuse: It happens with completely separate working directories. The two instances are logically independent — different directories, different stores, no shared state that the API surface exposes. Nothing in the signature of init(workingDirectory:) suggests that two of them cannot coexist, and the parameter's existence implies the opposite. There is no way to detect or prevent it from a library. FaceGroupAnalyzer is not a singleton and offers no way to ask whether an instance already exists in the process. Any two independent subsystems in an app — say, a background analysis service and a foreground preview — that each construct an analyzer will terminate the app. In my case the app must now enforce single-instance access through its own serial queue and lock, which is a constraint the framework imposes but does not state. Construction alone does not fail, so the problem surfaces later and elsewhere. Both instances construct successfully; Core Data only emits warnings at that point. The abort comes when both are alive and one of them does real work (update() and reading the grouping). So the crash lands far from its cause, in code that is individually correct. Feedback: FB24174678

MPVolumeView's showsRouteButton was deprecated (https://developer.apple.com/documentation/mediaplayer/mpvolumeview/showsroutebutton?language=objc). It's not clear how can we now hide this button without deprecation warning. The documentation is lacking. Please advise. Thank you!

visionOS 26.5, xcode26.5 - app terminated with exit code 9 then crashed and rebooted the entire device (Apple Vision Pro). I was connected to the Xcode debugger when this happened, and it didn't crash in any of our code. Memory and CPU usage was low at the time. Any idea what could be causing the issue? Some logs: << FigVideoTargetRemoteXPC >> signalled err=-15562 at <>:868 ... Call start on AVKSDockingService before making requests. <<<< FigPlayerInterstitial >>>> signalled err= 18,446,744,073,709,535,945 at <>: 10,773 <<<< FigPlayerInterstitial >>>> signalled err= 18,446,744,073,709,535,945 at <>: 10,773 << FigVideoTargetRemoteXPC >> signalled err=-15562 at <>:868 <<<< PlayerRemoteXPC >>>> signalled err= 18,446,744,073,709,538,756 at <>: 1,538 SessionCore_NotificationHandlers.mm : 73 Server returned an error:. Error Domain=NSOSStatusErrorDomain Code=-50 "Session lookup failed" UserInfo={NSLocalizedDescription=Session lookup failed} <<<< PlayerRemoteXPC >>>> signalled err= 18,446,744,073,709,538,756 at <>: 1,538 ... nw_read_request_report [C 1 ] Receive failed with error " No message available on STREAM " nw_protocol_socket_reset_linger [C1:2] setsockopt SO_LINGER failed 22 Debug session ended with code 9: Terminated due to signal 9 Program ended with exit code: 9 Thanks, bvsdev

We are testing an Osmo Mobile 8 through Apple's DockKit framework. Configuration: iPhone 15 Pro Max iOS 26.5.2 (23F84) DJI Osmo Mobile 8 DockKit model identifier: DS308 Firmware reported through DockKit: 1.0.0 Apple's official DockKit camera sample used as the test application We disabled DockKit system tracking and commanded yaw movement only: Vector3D(x: 0, y: 0.2, z: 0). The pitch component remained zero throughout the test. Short left and right movements worked and kept the reported tilt reasonably stable. We then performed a complete yaw rotation. Pan completed successfully, including the expected angle wrap from approximately +150° to -170°. However, DockKit's reported tilt changed from approximately -8° at the starting heading to approximately -37° around the rear of the rotation. It returned to approximately -7° when the gimbal completed the rotation and returned to its original heading. Selected telemetry (Pan / Reported tilt): -0.86° / -8.08° +94.48° / -21.20° +149.89° / -33.35° -169.88° / -36.96° -89.90° / -25.95° -5.67° / -8.59° +1.95° / -7.05° We also found that Apple's sample application's manual chevrons did not initially produce visible movement, although direct calls to the same setAngularVelocity API worked reliably. Questions: Should the Osmo Mobile 8 maintain its physical horizon during a DockKit yaw-only command? Does this model provide a horizon-lock or leveling mode that third-party DockKit applications need to select? Is firmware 1.0.0 the expected DockKit-reported firmware version for this model? Is the changing tilt related to the Osmo's gimbal geometry, firmware stabilization, or DockKit coordinate reporting? Is there newer firmware or a recommended DJI test application we should use for comparison? The change was also visible in the phone's physical orientation, so it does not appear to be telemetry-only.

Hello, I am developing BROXMEDIA Intercom, an iOS intercom application for live audiovisual production. The app uses a native Swift audio plugin, Google WebRTC, AVAudioSession, and a Capacitor user interface. The current TestFlight version is 2.0, build 17. Environment: iPhone 16 Pro Max iOS 26.5.2 TestFlight internal build AVAudioSession category: playAndRecord AVAudioSession mode: voiceChat Background audio capability enabled Bidirectional WebRTC audio between a web browser and the native iOS app Observed behavior: A remote web browser publishes WebRTC audio. The native iOS app receives and plays the audio correctly for approximately one hour. Wi-Fi disconnection/reconnection and airplane mode on/off initially recover correctly. After the prolonged session, the native app stops playing the remote audio. Signaling and participant presence remain connected. The remote participant is still shown as speaking. Completely closing and reopening the native app does not recover the remote audio. Safari on the same iPhone, connected to the same room and network, can still hear the same remote transmission. Restarting the remote web publication usually causes the native app to receive audio again. This suggests that the remote publication, network connection, signaling server, and device audio hardware are still operational when the native route fails. We are investigating whether: AVAudioSession or the underlying WebRTC audio unit has stopped rendering; the native RTCPeerConnection retains a stale receiver or audio track; inbound RTP has stopped even though the peer remains connected; an interruption, route change, or media-services reset has not been fully recovered. Our current recovery logic checks the peer connection state and whether a remote audio track object exists. However, we do not yet continuously verify that inbound RTP packets or bytes are increasing for each participant. Questions: Can AVAudioSession or its underlying audio unit stop rendering audio while RTCPeerConnection signaling remains connected? Which AVAudioSession or audio-unit callbacks should be monitored to distinguish an iOS audio-session failure from a WebRTC receiver or inbound-RTP failure? After AVAudioSession.mediaServicesWereResetNotification, should an app recreate the complete WebRTC audio engine, or is reactivating AVAudioSession normally sufficient? Is monitoring inbound RTP progression and audio energy the recommended way to detect a remote audio track that still exists but is no longer delivering usable audio? Are there any known considerations for prolonged bidirectional VoIP-style audio using playAndRecord, voiceChat, and background audio? We can add diagnostic logging and provide a Feedback Assistant report with sysdiagnose if the problem is reproduced again. Thank you.

So, in macos golden gate 27, there is this new live subtitles that happens in every video that i can't even turn off? (live captions is off) and also is there anyway from code we can turn this feature off, because making a background app, it exists whenever, and i can't seem to find a way to disable it from coding and the app.

I am testing SFSpeechRecognizer using the en_US locale. When the iPhone Simulator’s system language is set to Japanese, SFSpeechRecognizer.isAvailable returns false for en_US, so speech recognition is unavailable. As far as I have tested, this issue does not occur on iOS Simulator 26.2 or earlier. Is this a Simulator-specific issue, or is it a behavior change that could also occur on physical devices? Has any additional setup become necessary to use speech recognition in Simulator? I then changed the iPhone Simulator’s system language to English. After doing so, SFSpeechRecognizer.isAvailable returned true for en_US. However, starting a recognition task still failed immediately with kLSRErrorDomain Code=300, “Failed to initialize recognizer.” The following error was returned: Error Domain=kLSRErrorDomain Code=300 "Failed to initialize recognizer" UserInfo={ NSLocalizedDescription=Failed to initialize recognizer, NSUnderlyingError={ Error Domain=kLSRErrorDomain Code=300 "Failed to create recognizer from=/Users/<USERNAME>/Library/Developer/CoreSimulator/Devices/<DEVICE-UUID>/data/private/var/MobileAsset/AssetsV2/com_apple_MobileAsset_UAF_Siri_Understanding/purpose_auto/ c079bfa6b8856202dc8cb2135fef3b06229ced6e.asset/AssetData/mini.json" UserInfo={ NSLocalizedDescription=Failed to create recognizer from=/Users/<USERNAME>/Library/Developer/CoreSimulator/Devices/<DEVICE-UUID>/data/private/var/MobileAsset/AssetsV2/com_apple_MobileAsset_UAF_Siri_Understanding/purpose_auto/ c079bfa6b8856202dc8cb2135fef3b06229ced6e.asset/AssetData/mini.json } } } I have not observed either of these issues on iOS Simulator 26.2 or earlier: With the Simulator language set to Japanese, the en_US recognizer does not become unavailable. When SFSpeechRecognizer.isAvailable is true, recognition does not fail with kLSRErrorDomain Code=300. Environment Xcode: 26.6 (17F113) iOS Simulator 26.5 (23F77), iPhone 17 (A3258J/A) iOS Simulator 26.4 (23E244), iPhone 17 (A3258J/A)

I want to report a issue on PHAssetChangeRequest.deleteAssets Environment iOS 18.5, iOS 26.2.5, iOS 27.0 Steps to Reproduce Capture a 48MP ProRAW (DNG) photo with the Camera app. Open my app, call the following api to delete this photo: PHPhotoLibrary.shared().performChanges({ PHAssetChangeRequest.deleteAssets(assets) }, completionHandler: completionHandler) Expected The system delete-confirmation dialog appears; after the user confirms, the asset is deleted and the completionHandler is called or report error if it failed Actual Sometime the following issue happens: The confirmation dialog never appears and the completionHandler is never called no success, no error, no timeout. The built-in Photos app can delete the affected asset but API can't. The stuck request leaks permanently. Even after the same asset is subsequently deleted via the built-in Photos app, the pending completionHandler is still never invoked. Workaround for this issue When the issue happens, restarting the iPhone or reinstall app can not help to fix it But I found if I leave the device alone for an extended period (maybe 10 min~1 hour) and restart the iPhone, finally I found PHAssetChangeRequest.deleteAssets work again. It looks like some background task for 48MP RAW image in DNG format stuck delete API. I need to wait the task finished and restart device to reset stuck status. But I can not know when the DNG is ready to delete, it looks like my app hangs I think the better behavior is completion block should return a error to tell user what happens instead of not calling completion block.

Trivial pass-through compositor fails on Xcode 27 (beta 2, beta 3); error code -11800 underlying error -12784. Repro included https://github.com/BugorBN/avplayer-custom-compositor-repro It works well on Xcode26 and lower