In the WWDC talk: https://developer.apple.com/videos/play/wwdc2026/305/?time=350 "Enhance RAW image processing with Core Image" there is a section on the new RAW9 processing APIs and how to enable them. First off, the sample code compiles on iOS18 but causes a runtime exception because the .version9 symbol cannot be found, looks like the header definition is missing a version check for this value, so I'm not sure how to use this code if you need to support iOS18. Also on later dev betas (I tried the latest beta7) now trying to check if version9 is available the value is no longer present in the supported list: guard filter.supportedDecoderVersions.contains(.version9) else { ... There is another value .version9DNG that resolves to true but if I try to use that decoder the colors on the RAW image are wrong and the image becomes corrupted. How to use the RAW9 decoder in the latest dev betas, what should the final code before production because the WWDC sample now seems out of date and was always wrong wrt. iOS18.

Feedback Assistant Submission ID Reference : FB24634485 Attached is a sample code where after setting setlocale() to any of European languages or Russian language results in crash when calling NSAlert. Here is code snippet and crash log for reference. #import <Cocoa/Cocoa.h> int main(int argc, const char * argv[]) { @autoreleasepool { NSString* locale = @“fr_FR.UTF8"; setlocale(LC_ALL, locale.UTF8String); return NSApplicationMain(argc, argv); } } (IBAction)showAlertButtonTapped:(id)sender { NSAlert *alert = [[NSAlert alloc] init]; alert.messageText = NSLocalizedString(@"alert_title", nil); alert.informativeText = NSLocalizedString(@"alert_message", nil); alert.alertStyle = NSAlertStyleInformational; [alert addButtonWithTitle:NSLocalizedString(@"alert_ok_button", nil)]; [alert runModal]; } Crashlog

Adding an image or detail text to a CPListSection makes the whole header disappear. With no detailText or headerImage With detailText or headerImage FB24061858 open but no response.

I’m building a SwiftUI app that fetches public JSON data using URLSession.shared. The request works correctly in the iPhone 17 Pro Max Simulator, but fails on my physical iPhone 16 Pro Max running iOS 27 beta. Endpoint: https://api.jolpi.ca/ergast/f1/2026/driverstandings.json?limit=100 Error: NSURLErrorDomain Code=-1009 “The Internet connection appears to be offline.” NWPath: unsatisfied (Denied over Wi-Fi interface) Resolved 0 endpoints in 1ms The device can access the endpoint through Safari, and the same request works in Simulator. VPN, cellular permissions, Wi-Fi changes, and ATS settings have been checked. Could this be an iOS 27 beta networking regression affecting URLSession on physical devices? Are there recommended workarounds or diagnostics?

In Xcode's Settings → Intelligence section, there's no built-in AI agent/model available, only chat bots. I'm not able to download a model through the Components section as well, but no models are offered or downloadable there either. Environment: Xcode 26.6 and Xcode 27 beta 6 macOS 26.6.2 MacBook Pro (Apple M4 Pro)

Environment: Xcode 27.0 beta 6, Device Hub, tvOS 27.0 When focusing a TextField and using Device Hub to run on tvOS 27.0, I cannot type any text into the field. Focus moves to the TextField as expected, but keyboard input is not received. Has anyone else run into this? Any workaround would be appreciated.

I have so far been unable to enrol a macOS 27 beta VM in to Jamf since initial beta release. Is this by design? I can’t find any documentation or posts on apple developer forums about this anywhere. My agentic coding session has done some probing around in the VM and it thinks something is going wrong with Secure Keychain within the VM. Everybody on my team is observing the same behaviour as this, and I’ve had it happening across two different laptops (one of them which is, itself, running the latest macOS 27 Beta, and the other which I created a Beta VM by installing Tahoe in the VM, logging in to iCloud, and enabling Beta channel updates) The only thing we’ve found we can do so far is to join to Jamf in Tahoe first, but the problem I have there is, often times the option for Beta channel updates just doesn’t present itself in System Settings -> Software Update after signing in to iCloud, and I don’t know why it sometimes does but often doesn’t. Logs from agentic coding session below: The core log evidence This is the whole causal chain, from the 27 guest's unified log, inside 370 microseconds. Innermost failure first: 05:24:04.967316 apsd: (CryptoTokenKit) [com.apple.CryptoTokenKit:sepkey] <sepk:* kid=0000000000000000>: (apsd) unable to generate key: error e00002e2(-536870174) ACL=<SecAccessControlRef: dk;ock(true);odel(true);osgn(true);oa(true);okd(true)> 05:24:04.967433 apsd: (Security) [com.apple.security:seckey] SecKeyCreateRandomKey_ios failed: NSOSStatusErrorDomain Code=-25308 "Failed to generate keypair" (errSecInteractionNotAllowed / Interaction is not allowed with the Security Server.) 05:24:04.967574 apsd: (DeviceIdentity) com.apple.MobileActivation.ErrorDomain Code=-1 "Failed to create reference key." 05:24:04.967600 apsd: [com.apple.apsd:courier] APSBAAClientIdentityProvider failed to obtain a BAA cert, error: com.apple.MobileActivation.ErrorDomain Code=-1 "Failed to create reference key." 05:24:04.967686 apsd: [com.apple.apsd:courier] <APSCourierConnectionManager; production>: Stream error occurred for : APSErrorDomain Code=1 "Told not to connect after fetching server bag: (null) - closing stream" Read bottom-up: Secure Enclave key generation fails, so MobileActivation cannot create the reference key, so apsd cannot obtain its BAA device-identity certificate, so APNs tells it not to connect. kid=0000000000000000 means there is no key id at all. Then every courier line reports Connected on 0 interfaces, and mdmclient sets its PushWakeTopics only to get Connection Invalid for service com.apple.apsd and tear down. The command to regenerate it: log show --predicate 'process == "apsd"' --last 60m --info | grep -iE 'BAA|unable to generate key|server bag'. New control, collected just now mac26 happened to be running, so I got the comparison. macOS 26.6 (25G72) guest, same host, same network, 3 days uptime: BAA_FAILURES: 0 SEPKEY_FAILURES: 0 APNS_SOCKETS: 192.168.64.8.52286 -> 17.57.146.7.443 ESTABLISHED 192.168.64.8.52285 -> 17.253.77.203.443 ESTABLISHED (+ 3 more into 17.0.0.0/8) No BAA or courier complaints at all over 6 hours, and live connections into Apple's network. So a virtualised guest per se is fine; the 27 guest specifically cannot mint the key. The physical host, also on macOS 27.0, likewise logged zero of both failures over 3 hours.

Summary On iOS 27 the top scroll edge effect of a UITableView is sized around the UIRefreshControl as an edge element, but appears to key on the control's presence in the scroll view rather than its current height. After endRefreshing(), the control collapses to zero height but stays attached, and the effect region keeps reserving a refresh-control's worth of space. The first row stays blurred and dimmed even though it is scrolled fully clear of the navigation bar. Environment iOS 27 (beta), iPhone Xcode 27.0.0 Beta 4 UIKit, UITableView inside a UINavigationController Reproduces with the default edge effect style and with an explicit .soft Steps to reproduce Push a UITableViewController with a UIRefreshControl onto a navigation stack. Ensure content extends under the navigation bar (default for UITableViewController). Pull to refresh and let the refresh end. Observe the first row after the refresh control has retracted. Expected Once the control retracts, the edge effect returns to its pre-pull height and the first row renders crisply. Actual The region stays roughly one refresh-control height too tall and the first row stays blurred. Row positions are unaffected — content offset and adjustedContentInset are correct. Only the extent of the effect is wrong. It corrects itself on the next push/pop. Two probes that isolate it These narrow the cause to the control's presence rather than a general staleness: Re-assigning tableView.topEdgeEffect.style after endRefreshing(), including on a later runloop turn, does NOT correct the region. The style is not what is stale. Detaching the control DOES correct it immediately: tableView.refreshControl = nil So the region is measured from the control being in the hierarchy, and is never re-measured when the control merely collapses. Secondary issue A UIRefreshControl that has been detached is inert if the same instance is re-assigned: tableView.refreshControl = nil tableView.refreshControl = sameInstance // never triggers again A freshly constructed UIRefreshControl must be assigned instead. This is not documented and looks like a second bug. Minimal sample Attached. A UITableViewController with a refresh control and a "Push" bar button that pushes and pops an empty view controller, so the incorrect region and the post-navigation correction can be compared in one run. Related FB20756572 reports the same "edge-effect extent is stale until the next navigation" behaviour for UIScrollEdgeElementContainerInteraction sizing, and notes a change in iOS 27 seed 1. That report received no reply.

Filed as FB24619522 — sysdiagnoses from both devices and the live logs are attached to the report. We ship WidgetKit complications, and on the watchOS 27 betas (24R5360a, paired with iOS 27 24A5430a) they die every time the app gets updated while they're on the active face. Within seconds they turn into empty placeholders and never come back on their own — opening the app, switching faces or reloading timelines from the app does nothing. The watch logs show the extension being killed during the install (normal), and after that watchOS simply can't launch the new copy any more: runningboardd: <OSLaunchdJob | handle=…>: start succeeded, info=spawn failed, error=111: Invalid or missing Program/ProgramArguments chronod(ChronoKit): Reload failed; 0 retries remaining: … "Unknown extension process" Only two things fix it, and both restart chronod: rebooting the watch, or switching the watch language and back (iPhone › Watch app › General › Language & Region, then give it a couple of minutes). Our second extension in the same bundle, which wasn't running during the install, came back fine — so this looks like an OS bug rather than something we can work around in code. iOS 27 widgets seem to have the same problem (this thread, and iPhone in Canada wrote it up on beta 4), and someone posted the identical log lines back in March. FB24619522 — the full story, both sysdiagnoses and the live logs are in the Feedback.

ubject: Walkie-Talkie App Not Working After Updating to iOS 27 Developer Version Dear Support Team, I am experiencing an issue with the Walkie-Talkie app after updating my device to the iOS 27 Developer Version. Since the update, the app is not functioning properly, and I am unable to connect or communicate with my contacts using Walkie-Talkie. I have already tried several troubleshooting steps, including restarting the device, checking my network connection, and verifying that both FaceTime and Walkie-Talkie are enabled. However, the issue still persists. Could you please help identify the cause of this problem and advise on any available solutions or known issues related to the iOS 27 Developer Version? Device Model: [IPHONE 17] iOS Version: iOS 27 Developer Version Issue Started: Immediately after updating to iOS 27 Developer Version Thank you for your assistance. I look forward to your response.

While testing the watchOS 27 beta, I noticed that the standalone Walkie-Talkie app has been removed from the system. Walkie-Talkie has always been a great, lightweight way to stay connected. Much like Digital Touch, it’s one of those quick, low-friction features that makes the watch feel uniquely personal for communication throughout the day. I am really hoping its absence is just a temporary beta omission rather than a permanent retirement of the feature. I have already submitted a request via Feedback Assistant asking the engineering team to consider keeping it in the final release. If you also rely on this app for quick wrist-to-wrist updates, I highly recommend submitting your own feedback ticket to let the team know there is still an active user base for it. (FB23040695) Has anyone else ran into this or found an official note from Apple regarding its removal in the release notes? Hopefully, we will see it return before the public release this fall. Over and out!

For the life of me, I cannot find how to bring up the Siri Remote in the Apple TV Simulator in Xcode 27 Device Hub (Beta). Is it no longer available? I have always seem to have had issues using the computer's keyboard for navigating my tvOS apps. Maybe it's me, but the Siri Remote always worked perfectly fine. I hope the remote will make a reappearance in the next beta... ?

Xcode 27.0: Apple TV Simulators fail to navigate to some buttons in a UIViewController via keyboard arrows. Works fine with Xcode 26 (Siri Remote) simulator and also works as expected on an actual Siri Remote for Apple TV device running tvOS 27 Beta. Anyone else experience issues with navigating their app's UI using the Mac keyboard in Device Hub? Any tips for tracking this down?

My phone no longer shows the waitlist for Siri and has the option to "Try New Siri." I select it, continue, continue and the settings change to "Siri (Beta)" and the waitlist option is no longer there, but when using Siri it's the old pre-Apple Intelligence Siri that activates (little bubble at the bottom) and it does not work. Going to Safari and typing "Siri://" opens the New Siri App, but it says "Siri Update in Progress; Adding support for Siri hasn't completed. Open Settings to check the status." The app does not show up in Spotlight. My phone is done Indexing and all signs point to my phone being enrolled to use the New Siri, but it isn't working at all and still has not shown up. I've tried restarting a few times. Anyone experiencing this too?

I am testing out the new auto-generated subtitles feature on iOS 27 and tvOS 27. It works on iOS, but not on tvOS. Very same HLS videos. Anyone have any experience with auto-generated subtitles on tvOS 27? AFAICT, there is no special code needed to enable this feature for our apps, correct?

with some devices or apps for better programmes and less issues

Every macOS update fails during preflight personalization on my MacBook Pro (Mac15,6, Apple Silicon), currently on 27.0 build 26A5378j. It's failed on every build from beta 5 (26A5406e) through beta 7. Identical failure via Software Update and via startosinstall. It fails LOCALLY, before contacting Apple (gs.apple.com and gdmf.apple.com are both reachable with valid certs). Error (install.log + unified log): reaches PREFLIGHT_PERSONALIZE (~0.15), then aborts MobileSoftwareUpdateErrorDomain Code=1259 "failed to copy firmware identity" "could not obtain device identity information through SFR installer" SUMacControllerErrorPreflightPersonalizeFailed=7723 Root cause I've traced: an orphaned volume-group boot-policy directory in /System/Volumes/iSCPreboot/. ls shows two volume-group UUID dirs — the live one (matches diskutil info /) and an orphan (3D3287DE-...) with no corresponding APFS volume group (diskutil apfs list shows only one live group). Both date to Feb 2024. The preflight can't reconcile the System Recovery boot policy in the orphaned dir. Note: NOT caused by Erase All Content and Settings (unlike the commonly reported case). The orphan predates the beta, so any pre-existing second volume-group boot-policy directory reproduces it. It was harmless for ~2 years; macOS 27's stricter preflight rejects it. Ruled out (no effect): disk space, VPN, DNS, clock, Apple Account, refreshing the beta seed entitlement, reboot, Time Machine, re-downloading the installer, and Recovery reinstall (same 1259). Filed as FB24342236 — no response across beta 5, 6, 7. Questions: Is this a known issue with a planned fix, and in which build? Any supported recovery path that does NOT require a second Mac? (Recovery reinstall fails the same way.) Or is DFU Revive/Restore the only option? Will the public 27.0 release install on this machine, or hit the same preflight?

I've basically run the entire Apple website and couldn't find this information.

I’m seeing a repeatable first-party cameracaptured crash on an iPhone 14 Pro (iPhone15,2) running iOS 27 beta 5 (24A5424a). The single-camera AVCaptureSession configuration is: Front wide camera 3840×2160 at 30 fps, SDR/420f Two AVCaptureVideoDataOutput connections: Main recording output: 3840×2160 Auxiliary preview output: approximately 2096×1178 Both connections request and activate .standard video stabilization Within roughly two minutes, cameracaptured crashed three times—once during recording and twice during idle preview. The application receives AVErrorMediaServicesWereReset (-11819) after each crash. All three reports have the same faulting queue and underlying stack: com.apple.coremedia.capture.videodata-stabilization.front FigCFDictionaryGetCGRectIfPresent -[BWVISNode _transformRectanglesInMetadata:pts:] -[BWVISNode _stabilizeMetadataForSampleBuffer:] -[BWVISNode _tallyAndEmitSampleBuffer:] VideoStabilizationV2 The first two crashes are: EXC_BAD_ACCESS / EXC_ARM_PAC_FAIL address: 0x00000000dac11a30 termination: PAC_EXCEPTION, code 261 The third reaches the same stabilization stack but terminates with: EXC_BAD_ACCESS / SIGSEGV KERN_INVALID_ADDRESS at 0x30 App-side frame analytics were disabled, system pressure remained nominal, and neither audiomxd nor bluetoothd restarted. The first crash report also shows two front- stabilization worker threads, consistent with the two stabilized video outputs. I have filed Feedback Assistant report FB24553011 with the complete log archive and all three cameracaptured reports. With the iOS 27 public release approaching, waiting for an OS-side fix is not a viable shipping strategy; an app-side workaround is effectively the only option available for our release. Is this a known issue? In particular: Is it safe to leave .standard stabilization on the main recording connection while forcing the auxiliary preview connection to .off? Would disabling/removing the auxiliary AVCaptureVideoDataOutput reliably reduce this to one stabilization pipeline? If a single stabilized front output remains affected, is disabling front-camera stabilization entirely the only supported containment? Is there any public API for disabling the rectangle-metadata processing performed by BWVISNode? The current field workaround is to use the front camera with stabilization Off, or use a rear camera when stabilization is required.

Hello Apple Developer Community, I am experiencing a TestFlight issue with my iOS app and would appreciate any guidance. App Information: App ID: 6801854699 Bundle ID: az.idrak.liseyi App Version: 1.0.9 (14) Platform: iOS Team ID: W24294ZD96 Apple Developer Program membership: Active until December 11, 2026 Free Apps Agreement: Active Paid Apps Agreement: Active Issue: I uploaded build 1.0.9 (14) to App Store Connect using Codemagic. The build processes successfully and appears in the internal testing group. However, when an internal tester opens TestFlight and attempts to install the app, TestFlight displays: “The requested app is not available or doesn't exist.” At the same time, Codemagic reports the following API error: POST betaAppReviewSubmissions returned 422: Beta contract is missing for the app App Store Connect also previously displayed a message saying that I needed to renew my Apple Developer Program membership when attempting to create an external testing group. However, my membership is active until December 11, 2026, and all required agreements are active. Steps to reproduce: Upload build 1.0.9 (14) to App Store Connect using Codemagic. Wait for the build to finish processing. Add/select the build for TestFlight internal testing. Open TestFlight on an iPhone using an internal tester account. Attempt to install the app. TestFlight displays: “The requested app is not available or doesn't exist.” Codemagic reports: “Beta contract is missing for the app.” This issue appears to be related to a backend synchronization or Beta Contract problem. Apple Developer Support has already escalated this case to their technical team under case number 20000139248466. Has anyone experienced the same Beta Contract / TestFlight availability issue, or knows how this can be resolved? Thank you.