Hello, I'm hitting a persistent CKQuerySubscription save failure on the public database in my Production CloudKit container. I want to flag this is NOT the iOS 26.4 silent-push regression resolved in 26.4.1 (I've confirmed it manifests differently and on devices that predate that bug). App: Win 10 Min (com.luiz.PandaApp) Container: iCloud.com.luiz.PandaApp Current shipping version: 3.2.1 build 420 (approved 2026-05-19) Public database THE ERROR (captured from CKError.userInfo) CKErrorCode 12 (badRequest) CKInternalErrorDomain code 2006 ("BadSyntax") ServerErrorDescription: "attempting to create a subscription in a production container" Execution time per failed attempt: 45-90ms (gateway-level rejection, not data validation). CODE let subscription = CKQuerySubscription( recordType: "GuardianRequest", predicate: NSPredicate(format: "guardianRecordName == %@", me), subscriptionID: "guardian-incoming-(me)", options: [.firesOnRecordCreation] ) let info = CKSubscription.NotificationInfo() info.shouldSendContentAvailable = true subscription.notificationInfo = info try await container.publicCloudDatabase.save(subscription) The .save() throws every time. REPRODUCES ACROSS iPhone on iOS 26.4.2 (i.e., has the 26.4.1 CloudKit regression fix) iPhone on iOS 18.6.x (predates the 26.4 regression entirely) Multiple distinct Apple IDs / userId hashes Fresh installs via TestFlight Updated installs from production CONSISTENTLY: USER_ERROR / BAD_REQUEST. Same error every time. WHY THIS ISN'T THE iOS 26.4 REGRESSION (Thread 820562) That regression caused silent notifications to be DROPPED client-side AFTER successful subscription creation. Our failure is SubscriptionCreate itself being rejected by the CloudKit server before any subscription exists. Different layer, different symptom. iOS 18.6.x devices also fail (they never had the 26.4 token-validation regression code). CLOUDKIT CONSOLE LOGS (sample request UUIDs Apple engineers can lookup) EB30E9D0-8C97-4685-BD16-3E79B3328D6F (2026-05-17 8:08 UTC) EEAA0606-5B50-4640-A950-EEA33B790B8E (2026-05-17, captured in-app) EB4C90CE-9172-4942-B00F-DE4A28388FBA (2026-05-19 7:18 UTC, iOS 18.6.x) F2DF69D9-2339-437A-B59B-7FBD4D57442F (2026-05-19 7:51 UTC, iOS 26.4.x) CloudKit Console → Production → Subscriptions: 0 entries despite 70+ attempts since 2026-05-11. WHAT I'VE VERIFIED / TRIED Schema: GuardianRequest.guardianRecordName and GuardianResponse.requesterRecordName both have QUERYABLE indexes in the Production schema (confirmed in Console). Field types: all STRING. aps-environment entitlement: "production" (changed from "development" in build 420; no change in error pattern). Push Notifications capability: enabled on App ID in Developer Portal AND in Xcode Signing & Capabilities for the main app target. UIBackgroundModes: includes "remote-notification". Re-deployed Production schema from Development on 2026-05-19 (Console reported "no changes"; failure pattern unchanged). Tried with and without info.desiredKeys = []. RecordQuery operations on the same fields and record types in the same container succeed consistently. QUESTIONS Is there a known infrastructure issue affecting public database CKQuerySubscription creation that is distinct from the iOS 26.4 regression (thread 820562)? Is there a per-container configuration that may be in an unexpected state, and if so what should I check? Are there workarounds beyond schema redeployment that have helped other developers in similar situations? Thanks for any guidance.

Our organization is attempting to retrieve the External Version Identifier (EVID) history for all published versions. This data is required so that we can pass the exact externalVersionIdentifier integer to our deployment framework to pin specific app versions on our managed devices. We currently have an active App Store Connect account, but our attempts to fetch this data via standard publishing APIs return a 401 Unauthorized error. To help us resolve this technical blocker, please provide explicit engineering guidance on the following four points: API Endpoint Architecture: Is the enterprise Apps and Books for Organizations API (apple.com) the only platform that exposes the externalVersionId history for all versions? If so, what is the exact endpoint path we must call to return the full version-based EVID array? Account Requirements: Can these version-specific EVIDs be retrieved using our existing App Store Connect developer credentials, or is an Apple Business Manager (ABM) account strictly mandatory to bypass the 401 gate? ABM Portal Setup for EVIDs Only: If an ABM account is mandatory, what are the minimum technical steps required inside the ABM dashboard to fetch only the EVID data? Specifically, do we need to "purchase" a volume license for the target app to make its version history accessible via the API? Authentication Parameters: What is the correct token structure for this endpoint? Do we need to pass a specific location server token (sToken / itvt cookie) generated inside ABM alongside our signed developer JWT header? Thank you for your time and technical guidance. We look forward to your engineering team's response.

Hello Apple Developer community, I am seeking help with a recurring App Store rejection under Guideline 2.1(a) - Performance - App Completeness. My app crashes on launch specifically on iOS 26.4.2 and I have confirmed this is a platform-level bug in React Native — not an issue with my application code. BACKGROUND My app is Highway Exit Food Finder — a navigation utility built with Expo SDK 55 / React Native 0.83. It has been in review for several weeks and has been rejected multiple times due to a crash on launch on iPad Air M3 and iPhone 17 Pro Max running iOS 26.4.2. THE CRASH Every crash log shows the same signature: Exception: EXC_CRASH (SIGABRT) Location: ObjCTurboModule::performVoidMethodInvocation Thread: com.meta.react.turbomodulemanager.queue The crash occurs during TurboModule initialization — BEFORE any JavaScript code runs. This means no application-level code change can fix it. CONFIRMED PLATFORM BUG This crash is documented in: github.com/facebook/react-native/issues/54859 github.com/expo/expo/issues/44680 These issues confirm that React Native's New Architecture TurboModule system throws an NSException during async void method invocation on iOS 26 that cannot be caught, causing SIGABRT. WHAT I HAVE TRIED Removed expo-notifications (possible crash source) Removed react-native-maps Simplified all screens to static components Set newArchEnabled: false in app.json Upgraded to Expo SDK 55 Submitted 17+ builds attempting to fix this Despite all these changes the crash signature remains identical across all builds because the crash happens at the platform level. MY QUESTIONS Has anyone successfully gotten a React Native Expo app approved on App Store Review while running iOS 26.4.2 on review devices? Is there a known working configuration for Expo SDK 55 that avoids the TurboModule crash on iOS 26? Has anyone successfully appealed a 2.1(a) rejection caused by a platform bug rather than app code? Can Apple review devices be updated to use a stable iOS version for reviewing React Native apps while the iOS 26 compatibility issues are resolved? DEVICE AND BUILD INFO Review device: iPad Air 11-inch M3 OS: iPadOS 26.4.2 Framework: Expo SDK 55 / React Native 0.83 Build tool: EAS Build All crash logs reference the identical TurboModule crash signature Any help or guidance from the community or Apple engineers who monitor these forums would be greatly appreciated. Thank you.

Hi, I have a SwiftUI "work time" screen with a rotating ring (60 tick marks, Canvas-based). While the app stays in foreground, rotation is fine. After the app is in background for a while and comes back to foreground, I consistently see one visual glitch: the ring makes one very short step in the opposite direction once then continues rotating clockwise normally So this is not a crash, only a visual reverse tick on resume. What I expect: no direction change after foreground resume continuous clockwise motion What I already tried: withAnimation(.linear(...).repeatForever(...)) + restart on scenePhase TimelineView (.animation and .periodic) with time-based angle angle with and without modulo wrapping wall-clock and monotonic time sources rotation via rotationEffect and also via Canvas geometry warmup delays after resume restoring original ring visuals (long/short tick marks) The effect is still reproducible. Question: What is the correct SwiftUI approach to implement a continuously rotating ring that stays direction-stable across background/foreground transitions, with no one-frame reverse step on resume? Any pattern that is robust on current iOS versions and avoids visual artifacts on scene phase changes would be appreciated. Minimal repro: import SwiftUI struct ReproClockView: View { @Environment(\.scenePhase) private var scenePhase private let tickCount = 60 private let rotationDuration: Double = 120 @State private var rotationDegrees: Double = 0 @State private var hasAppeared = false var body: some View { ZStack { Canvas { context, size in let center = CGPoint(x: size.width / 2, y: size.height / 2) let radius = min(size.width, size.height) / 2 - 8 for index in 0..<tickCount { let angle = Double(index) * (360.0 / Double(tickCount)) - 90 let radians = angle * .pi / 180 let isLongTick = index % 5 == 0 let length: CGFloat = isLongTick ? 22 : 14 let outerRadius = radius let innerRadius = radius - length let startPoint = CGPoint( x: center.x + cos(radians) * outerRadius, y: center.y + sin(radians) * outerRadius ) let endPoint = CGPoint( x: center.x + cos(radians) * innerRadius, y: center.y + sin(radians) * innerRadius ) var path = Path() path.move(to: startPoint) path.addLine(to: endPoint) context.stroke( path, with: .color(.red), style: StrokeStyle(lineWidth: 2.5, lineCap: .round) ) } } .rotationEffect(.degrees(rotationDegrees)) .drawingGroup() } .frame(width: 340, height: 340) .onAppear { guard !hasAppeared else { return } hasAppeared = true startRotation() } .onChange(of: scenePhase) { oldPhase, newPhase in if oldPhase == .background && newPhase == .active { withAnimation(.linear(duration: 0)) { rotationDegrees = 0 } DispatchQueue.main.asyncAfter(deadline: .now() + 0.05) { startRotation() } } } } private func startRotation() { rotationDegrees = 0 withAnimation(.linear(duration: rotationDuration).repeatForever(autoreverses: false)) { rotationDegrees = 360 } } }

Hi all, Technical architecture question for those experienced with iOS background audio / microphone constraints. I’m exploring an app concept where: the user explicitly starts a temporary active session during that session, on-device wake-word / keyword detection runs locally no audio is stored or transmitted during passive monitoring monitoring stops when the user ends the session The intended UX is that the user may then lock the phone or place it away while the active session remains in progress. Question: Is there any App Store-compliant architecture that would allow local keyword / wake-word detection to continue while the device is locked or the app is backgrounded during that active session? Or would iOS lifecycle / background execution rules make this infeasible for custom wake-word detection? Interested in practical experience around: AVAudioSession background audio modes on-device speech processing App Review acceptability Thanks in advance.

Hi everyone, I’m looking for guidance from developers who have dealt with App Review for health-related apps. I have an app that presents users with a questionnaire using images and multiple-choice answers. Based on the responses, the app categorizes the user into a general diabetes risk category. A few important points about the app: The app does NOT provide a diagnosis. The app clearly states that it is informational/advisory only. We added disclaimers throughout the app. We included references to published research papers the methodology is based on. The app does not connect to medical devices or Apple Health. No treatment or medication recommendations are provided. However, the app keeps getting rejected during App Review. Apple is asking us to provide documentation/approval from health regulatory authorities for every country where the app will be distributed. This is where I’m confused: Is this actually required for apps like this? Are reviewers classifying this as a regulated medical device? How are similar diabetes risk / health risk apps on the App Store handling this? Is there a recommended way to position the app as wellness/educational instead of diagnostic? We’ve already tried: strengthening disclaimers, clarifying that it is not a diagnosis, removing strong medical claims, submitting from both personal and organization accounts. Still receiving the same type of rejection. Would really appreciate advice from anyone who has successfully navigated this type of review process. Thanks!

I’m trying to understand which storage capacity key is the correct one to use when deciding whether my app can start downloading offline video content. I read the documentation here: https://developer.apple.com/documentation/foundation/checking-volume-storage-capacity but I still don’t fully understand the intended usage difference between: volumeAvailableCapacityKey volumeAvailableCapacityForImportantUsageKey My app allows users to download videos for offline viewing. These downloads may remain on the device for a long time (days or even months), so they are not just temporary cache files. On one hand, this seems to match the description of “storing data based on a user request”, which suggests using volumeAvailableCapacityForImportantUsageKey. On the other hand, my understanding is that this value may assume the system is willing to aggressively purge caches and reclaim space for this “important usage”. I’m worried this could lead to unexpected or unpleasant side effects for the user if my app relies on that space. What confuses me even more is that the values are significantly different on my device: iPhone Settings reports about 142 GB free volumeAvailableCapacityKey returns only ~56 GB volumeAvailableCapacityForImportantUsageKey returns ~132 GB So my question is: For an app that downloads videos for offline playback — where the user explicitly requested the download, but the content may stay on device for a long time — which value is the recommended one to use when deciding whether there is enough free space to start the download? Should offline media downloads generally be treated as “important usage” in the sense intended by this API?

Hi all, I've hit a reproducible issue where the presence of the SwiftUI instrument in a template prevents any data from being recorded, including from the other instruments in the same template. Removing the SwiftUI instrument immediately restores normal recording. Environment Host: macOS 26.4.1 (25E253), Mac mini Xcode / Instruments 26.4.1 (17E202) Device: iPhone 17, iOS 26.4.2 (23E261) (physical device, USB-attached) Symptom Recording the same app, same device, same session, only varying the template contents: SwiftUI template (as-is) => All lanes empty across the entire recording Same template with the SwiftUI instrument removed => Data collected normally (Time Profiler samples, Hangs, etc.) So it seems not an issue with the SwiftUI lanes specifically being empty — including the SwiftUI instrument appears to silence the entire recording. Steps to reproduce Open Instruments → pick the SwiftUI template (or build a custom template that includes the SwiftUI instrument alongside, e.g., Time Profiler). Target the device, attach to the running app. Record for ~10s, interact with the app. Stop. Result: every lane is empty. Edit the template, remove the SwiftUI instrument, re-record with no other changes. Result: normal data appears in the remaining instruments. Questions Is this a known regression in Instruments 26.4.1 on iOS 26.4.x? Is there a workaround to use the SwiftUI instrument on this OS combo (different Xcode build, runtime flag, entitlement)? Does it work for anyone on iOS 26.4.x + Xcode 26.4.1, or is everyone seeing this? I can file a Feedback if confirmed as a bug — wanted to check here first in case I'm missing a setup step. Thanks!

Markup Tool: Support for persistent tool presets (color, stroke, fill settings) I use Markup heavily for work — up to 20 images per day, always with the same settings: red arrow or rectangle, no fill, specific stroke width. The problem has two parts: Part 1 – Markup resets everything: Every time Markup is opened, all settings reset: tool, color, fill, stroke width. This means 3–4 manual steps per image, adding up to 80 unnecessary interactions per day. Part 2 – The default red is unusable: The red in Apple’s color palette is muted and too pale for clear, high-contrast annotations. I have to open the color wheel every single time to manually select a proper, vivid red. The copy/duplicate workaround only helps within one image — as soon as a new photo or screenshot is opened, everything starts over from scratch. Markup has no memory between different images. Switching to a third-party annotation app is not a solution — the entire advantage of Markup is its native integration directly within the Photos app, without switching apps. And Markup cannot be configured in depth through Shortcuts either — color, fill, and stroke width are not controllable there. The attached images: Image 1 shows the entry point in the Photos app. Image 2 shows Markup open with the current color palette. The blue-outlined fields do not indicate colors to be replaced — they mark the position where personally configured tool presets should appear: not individual colors, but fully pre-configured tools with color, stroke width, and fill setting already saved, ready to use with a single tap. My suggestion: Tool presets — configure once, saved permanently, available directly in the Markup toolbar. No need to re-configure color, fill, or stroke width for every new image. iOS already remembers last-used settings in many areas: camera mode, emojis, colors in Notes, Pages, and Keynote. Markup behaves as if it’s being opened for the first time, every time. This inconsistency costs me measurable time every single day.

According to our crash analytics, the application crashes when trying to share a PDF file in the UIDocumentInteractionController. This crash takes place on iOS 26+ only. Based on analytics, user sessions end when the pdf file is opened in the UIDocumentInteractionController. We couldn't reproduce it on a physical device or a simulator. Can you please help with a fix or at least workaround for this issue? What's your opinion for bug localization (application or framework)? Crash log is attached below. CoreFoundation __exceptionPreprocess + 164 libobjc.A.dylib objc_exception_throw + 88 CoreFoundation -[__NSArrayM insertObject:atIndex:] + 1276 ShareSheet __79-[SHSheetActivityItemsManager loadItemProvidersForRequest:activity:completion:]_block_invoke + 972 ShareSheet __79-[_UIShareServiceActivityProxy _loadItemProvidersFromActivityItems:completion:]_block_invoke + 88 ShareSheet __74+[UIActivity _loadItemProvidersFromActivityItems:withCacheURL:completion:]_block_invoke_4 + 352 libdispatch.dylib _dispatch_call_block_and_release + 32 libdispatch.dylib _dispatch_main_queue_drain.cold.5 + 812 libdispatch.dylib _dispatch_main_queue_drain + 180 CoreFoundation __CFRunLoopRun + 1944

I’m seeing a reproducible system-level Camera crash/termination on iPhone Air running iOS 26.4.2. Steps to reproduce: Press Camera Control to launch the Camera app. Tap the lower-left thumbnail to enter the recent photo view. Browse photos, or tap Edit and start cropping a photo. The Camera/Photos flow unexpectedly exits and returns to the Home Screen or widget view. Additional detail: The issue can happen whether or not a new photo is taken after launching Camera with Camera Control. In other words, using Camera Control as a shortcut into Camera, then tapping the lower-left thumbnail to browse photos, can trigger the issue. Sometimes it happens while only browsing photos, without entering Edit. Expected result: The photo viewer/editor should stay open and allow normal browsing or cropping. Actual result: The flow exits unexpectedly. Mac Console evidence: Around 2026-05-12 21:53:59-21:54:00, Console showed SpringBoard/RunningBoard terminating com.apple.camera. Relevant log excerpt: Capture Application Requirements Unmet: "AVCaptureEventInteraction not installed" reportType: CrashLog ReportCrash Parsing corpse data for pid 94087 com.apple.camera: Foreground: false Storage is sufficient. Restart/reset-style support steps have already been tried and did not resolve the issue. This appears specific to the Camera Control launch path, not normal Photos app browsing. Has anyone else seen this on iOS 26.x, or is this a known Camera Control / AVCaptureEventInteraction regression? Already Filed as FB22766094.

Hi everyone, I’d appreciate guidance on a 2.5.2 rejection. My app was rejected with this message: “During review, the app installed or launched executable code. Specifically, the app allows users to install apps created by other users.” What my app actually does: Users create/share tool templates (not binaries/plugins). A template contains only: form configuration (text fields, dropdowns, checkboxes, sliders, etc.) At runtime, placeholders like #TextField are replaced with user input, then the final prompt is sent to a server for AI response. *The iOS app does not download/install/execute native code, scripts, frameworks, or dynamic modules on-device. I suspect review interpreted the word “install” in my UI as real app/code installation anyone knows what can i do to fix this problem. thank you,

Hi everyone, I'm experiencing an unusually long wait time for my TestFlight external build review and wanted to see if others are facing similar issues in 2026. Current Status: Platform: iOS App Version: 1.2.90 (Build 24) Build Type: TestFlight External Testing Current Status: In Review - not "Waiting for Review" Time in Current Status: Over 2 weeks Submission Timeline: Current Submission: Wednesday at 9:49 AM (iOS 1.2.90 Build 24) Previous Submission: March 9, 2026 at 2:20 PM (iOS 1.2.90 Build 11) - Status: Completed (Rejected) Full History: March 9, 2026 2:20 PM - Initial submission (Build 11) March 15, 2026 5:25 AM - Rejection from Apple March 24 - April 15, 2026 - Multiple back-and-forth communications (5 messages total) April 15, 2026 2:22 PM - Last response from Apple Recent (Wednesday 9:49 AM) - Resubmitted new build (Build 24) Current - Still "In Review" after 2+ weeks What I've Tried: ✅ Addressed all rejection issues from the previous review ✅ Submitted a new build with higher build number (11 → 24) ✅ Submitted expedited review request through App Store Connect ✅ Contacted Apple Developer Support via email ✅ Requested phone callback for escalation What Concerns Me: The build has been stuck in "In Review" status for over 2 weeks This is AFTER already going through a full review cycle (rejection + resubmission) Normal review times are supposed to be 24-48 hours, even with the 2026 backlog The previous review cycle took over 1 month (March 9 → April 15) This is completely blocking our beta testing program Questions for the Community: Is anyone else experiencing 2+ week "In Review" times for TestFlight external builds in 2026? Does a previous rejection cause indefinite review delays on resubmission? Has anyone successfully resolved this by canceling and submitting a brand new build? Are there effective escalation paths beyond standard support channels? Could this indicate an account-level review issue? What I Understand: Review times have increased in 2026 due to higher submission volumes Previous rejections can lead to more thorough reviews However, 2+ weeks "In Review" (not even "Waiting") seems abnormal This delay is severely impacting our development timeline and beta testing plans. Any advice or shared experiences would be greatly appreciated! Thanks in advance for your help.

I'm trying to update the iCloud data handling in our app, and I'm running into an issue with a particular file on one particular device. This file never downloads & I haven't been able to pinpoint what's off about it. Right now we just have 2 iCloud accounts & a handful of devices, so I haven't been able to narrow it down yet, but in most cases, all the cloud files download as expected. However, whether or not the file eventually downloads, the NSURLUbiquitousItemDownloadRequestedKey key seems to be completely useless. For the following code: NSError *error = nil; BOOL success = [[NSFileManager defaultManager] startDownloadingUbiquitousItemAtURL:self.fileURL error:&error]; if (!success) { NSLog(@"error downloading %@ : %@", self.fileURL, error); } else { NSDictionary *resourceValues = [self.fileURL resourceValuesForKeys:@[NSURLUbiquitousItemDownloadRequestedKey, NSURLUbiquitousItemIsDownloadingKey, NSURLUbiquitousItemDownloadingErrorKey, NSURLUbiquitousItemDownloadingStatusKey] error:&error]; if (!error) { NSString *downloadStatus = resourceValues[NSURLUbiquitousItemDownloadingStatusKey]; bool downloadRequested = [resourceValues[NSURLUbiquitousItemDownloadRequestedKey] boolValue]; NSLog(@"download requested: %d", downloadRequested); } // ... } downloadRequested is always false, regardless of whether or not the cloud file eventually downloads. I have 2 questions: is there a way to actually check if a download has been requested for a file? what could be preventing this file from downloading? -startDownloadingUbiquitousItemAtURL:error: doesn't report an error, NSURLUbiquitousItemDownloadingErrorKey is always nil, and no error is reported in the NSMetadataQuery observer.

Hi everyone, I'm developing an iOS app using Swift (Foundation, Network, and Combine) that communicates via TCP with a weighing scale. The scale uses an internal ESP32 module acting as a Wi-Fi Access Point (no internet access) specifically for data transmission. The app connects to this network and opens a socket to receive weight data and send command strings. I’m currently facing two main issues: Socket Management: The socket isn't closing properly. Occasionally, the app opens multiple simultaneous connections instead of maintaining a single one. Since the ESP32 has a client limit, these ghost connections eventually hang the communication module. Invalid Outbound Data: The connection drops frequently because the scale receives invalid strings from the app. My logs show strange character sequences (like "gggggggggfdhj" or "vfgdddddddddddtty") being sent involuntarily. I haven't programmed these strings, and they cause the scale to terminate the session due to protocol violations. How can I ensure proper socket closure and prevent these random data packets? Additionally, a technical question: Is it possible to keep this TCP connection active in the background indefinitely on iOS while the user interacts with other apps?

Hello everyone, We are encountering a critical regression introduced in iOS 26.4 that results in permanent workout data loss for users. When invoking HKWorkoutBuilder.finishWorkout(completion:) while the iOS device is locked, the save operation fails completely. However, it fails silently: the completion handler executes but returns both a nil workout and a nil error. Expected Behavior: Before iOS 26.4 finishWorkout resulted in a workout id, and correctly stored the workout data in HealthKit. According to HealthKit data protection documentation, saving data when the device is locked should either succeed (writing to a temporary journal file to be merged upon unlock) or explicitly throw an error such as HKError.Code.errorDatabaseInaccessible. Actual Behavior: Because the framework returns nil for both the object and the error, the application has no way to detect that the save failed. We cannot implement a retry mechanism or queue the save, resulting in silent data loss. Steps to Reproduce: We have built a Minimal Reproducible Example (MRE) that reliably triggers this: Initialize an HKWorkoutBuilder and call beginCollection(withStart:) followed by endCollection(withEnd:). Wrap the finishWorkout call in a short 5-second asynchronous delay, protected by a UIBackgroundTask to prevent app suspension. Lock the physical device during this 5-second window. The finishWorkout completion handler will execute while the device is locked, returning workout == nil and error == nil. Existing Reports: We have filed this via Feedback Assistant (a month ago) and opened a TSI (a week ago), providing the MRE project and a sysdiagnose captured at the time of failure: Feedback ID: FB22396180 TSI Case-ID: 19755043 As we have not yet received a response or a suggested workaround through these official channels, we are reaching out to the community. Has anyone else encountered this silent failure with HKWorkoutBuilder recently? Any insights or escalation help would be greatly appreciated.

I'm facing a persistent location error on real iOS device: Error Domain=kCLErrorDomain Code=1 The operation couldn’t be completed. (kCLErrorDomain error 1.)

Hi Team, We are facing issue in testing the Age verification using Sandbox Account for your test environment. We tried to create region-specific sandbox test accounts as mentioned in the link (https://developer.apple.com/documentation/storekit/testing-age-assurance-in-sandbox) but we dont see an option to select Date of Birth and App Store Territory. After navigating to sandbox apple account setting and we tried to login with created sandbox test accounts(with gmail.com / qa.com/ test.com), its asking for two factor authentication. So, question here is which account should i use, sandbox account / real apple id? To overcome point 2, we created a gmail account and same is created as Sandbox test account, so that we can overcome two factor authentication. Now when we try to click on manage, nothing is happening. As per the link, it should show and option for select Age Assurance or Revoke App Consent. So if you can guide me with exact steps to follow on how to use the Sandbox account, that would be helpful for our app development. Thanks

Hello, I'm a bit new to iOS development, so this could be something I've overlooked, but I've tried a bunch of things on my own and with the help of Copilot, as well as some senior engineers here at my company. I let AI summarize what the problem is, what I've tried, what doesn't work, and also some information on the system: Problem: UITabBarAppearance Custom Colors Ignored - All Diagnostics Show Correct Configuration Environment: iOS Deployment Target: 13.4 Xcode: Latest (26.4.1 as of writing) Device/Simulator: Both affected Language: Swift UI: UIKit with Storyboards Description: Tab bar selected item displays system default colors (gray in light mode, white in dark mode) instead of my custom named color from asset catalog. System colors like .systemBlue work correctly, but custom asset catalog colors are completely ignored. Expected behavior: Selected tab bar item should display BlueTVColor2 (RGB 0, 0.173, 0.38 in light mode; RGB 0, 0.569, 1.0 in dark mode) Actual behaviour: Selected tab bar item displays gray/white/black system defaults What I've Verified Works Correctly: Color resolution: let color = UIColor(named: "BlueTVColor2") print(color) // Resolves correctly print(color?.resolvedColor(with: .init(userInterfaceStyle: .light))) // RGB(0, 0.173, 0.38) print(color?.resolvedColor(with: .init(userInterfaceStyle: .dark))) // RGB(0, 0.569, 1.0) Asset Catalog Configuration: BlueTVColor2.colorset has both light and dark variants template-rendering-intent: template set on all tab bar images All images use .alwaysTemplate rendering mode (verified at runtime) UITabBarAppearance Configuration (Although I've also tried just directly in the storyboard, it didn't work, the below is in code-behind): override func viewDidLoad() { super.viewDidLoad() let selectedColor = UIColor(named: "BlueTVColor2")!.resolvedColor(with: traitCollection) let normalColor = UIColor.redTVColor.resolvedColor(with: traitCollection) let appearance = UITabBarAppearance() appearance.configureWithOpaqueBackground() let itemAppearance = UITabBarItemAppearance() itemAppearance.selected.iconColor = selectedColor itemAppearance.selected.titleTextAttributes = [.foregroundColor: selectedColor] itemAppearance.normal.iconColor = normalColor appearance.stackedLayoutAppearance = itemAppearance appearance.inlineLayoutAppearance = itemAppearance appearance.compactInlineLayoutAppearance = itemAppearance tabBar.isTranslucent = false tabBar.standardAppearance = appearance if #available(iOS 15.0, *) { tabBar.scrollEdgeAppearance = appearance } tabBar.tintColor = selectedColor tabBar.unselectedItemTintColor = normalColor } Runtime Diagnostics Confirm Everything is Set Correctly: Appearance selected iconColor: RGB(0, 0.569, 1) // Correct Tab bar standardAppearance selected iconColor: RGB(0, 0.569, 1) // Correct Tab bar tintColor: RGB(0, 0.569, 1) // Correct Tab bar unselectedItemTintColor: RGB(1, 0.259, 0.271) // Correct All tab bar item images: Rendering mode = 2 (.alwaysTemplate) // Correct Settings persist through viewDidAppear // Correct Yet the UI displays system default gray/white/black colors. What I've Tried (All Failed): Deprecated selectedImageTintColor property (returns nil when standardAppearance is set) Both configureWithDefaultBackground() and configureWithOpaqueBackground() Dynamic colors vs resolved fixed colors Configuring all layout appearances (stacked, inline, compactInline) Setting isTranslucent = false Re-applying appearance in viewDidAppear with delayed dispatch Manually re-applying template rendering mode to images at runtime Removing storyboard color configuration entirely Changing global accent color build setting System colors (.systemBlue) work fine; only custom asset catalog colors fail Additional Context: This is a legacy project originally created around 2013-2015, migrated to modern Swift/iOS (not everywhere, major parts are still using objc, UIKit/Storyboard) When I set tabBar.tintColor = .systemBlue it works perfectly The color BlueTVColor2 is used successfully elsewhere in the app (also if setting it as the background of the UITabBar, it works, just not as a tint for the icons/text) Storyboard has no selectedImageTintColor set (removed during debugging) No UITabBar.appearance() proxy calls anywhere in codebase Deployment target is iOS 13.4 (when UITabBarAppearance was introduced) Pre iOS 26.0, the adding of the tint color to the UITabBar worked as intended, so this has come as a result of the update to iOS 26.0 in some way Comparison with Working Test Project: Created a fresh iOS project with same setup - custom asset catalog colors work perfectly in tab bar with identical UITabBarAppearance configuration. Question: Why would UITabBarAppearance properties show correct colors in diagnostics but render with system defaults? Is there a known issue with asset catalog named colors in UITabBarAppearance on iOS 13.4+? Could legacy project settings interfere with modern appearance API? Any insights would be greatly appreciated. I'm running out of ideas and this seems like either a framework bug or some undocumented interaction between asset catalogs and tab bar appearance. Code Sample: I can't release much code besides just things I've worked on, so hopefully this full description of the problem and everything I've tried can help illuminate the issue at hand. I've tried all of the above and probably more the past week and can't make heads or tails of where the issue is located. The best I can come up with right now is some sort of compatibility issues but I have no way of determining where it is that I should investigate and fix.

I'm keeping most information in an actor and I would like to save also a closure in it that I get from func application( _ application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: @escaping () -> Void) Task.init{ await GeoreferenceQueue.shared.setBackgroundCompletionHandler(completionHandler) } } where GeoreferenceQueue is and actor, while the caller is a class. yet I receive error: Passing closure as a 'sending' parameter risks causing data races between code in the current task and concurrent execution of the closure and Sending task-isolated 'completionHandler' to actor-isolated instance method 'setBackgroundCompletionHandler' risks causing data races between actor-isolated and task-isolated uses