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.

Hello! I have experienced a weird bug in iOS 26 Beta (8) and previous beta versions. The safe area inset is not correctly aligned with the keyboard toolbar on real devices and simulators. When you focus a new textfield the bottom safe area is correctly placed aligned the keyboard toolbar. On real devices the safe area inset view is covered slightly by the keyboard toolbar, which is even worse than on the simulator. Here's a clip from a simulator: Here's the code that reproduced the bug I experienced in our app. #Preview { NavigationStack { ScrollView { TextField("", text: .constant("")) .padding() .background(Color.secondary) TextField("", text: .constant("")) .padding() .background(Color.green) } .padding() .safeAreaInset(edge: .bottom, content: { Color.red .frame(maxWidth: .infinity) .frame(height: 40) }) .toolbar { ToolbarItem(placement: .keyboard) { Button {} label: { Text("test") } } } } }

Hello, I filed FB23906760 requesting full Persian (fa-IR) system-language support across Apple platforms. A focused Swift/SwiftUI feasibility and QA sample is attached privately to that feedback report. Apple platforms already provide important building blocks for Persian, including Persian text input, Unicode rendering, locale-aware formatting, semantic right-to-left layout support, and Persian calendar APIs. However, Persian is not currently selectable as a complete system interface language on iOS, iPadOS, or macOS. The submitted app-level sample exercises: runtime RTL/LTR layout switching; canonical Persian Kaf (U+06A9) and Yeh (U+06CC); ZWNJ (U+200C) preservation; LRI/PDI isolation for mixed Persian and Latin content; Persian digits and numeric separators; Foundation Persian-calendar conversion and month names; English/Persian localization-key parity; and localized accessibility metadata. I want to clearly distinguish application localization from operating-system support: A Swift or SwiftUI app can provide its own Persian strings through String Catalogs or localized resources. SwiftUI and Foundation provide useful primitives for app-level Persian support and repeatable QA. An app or sample project cannot add Persian to the system-language selector, translate Apple system UI or first-party apps, or add Persian to Siri, Dictation, Translate, or other system services. Those capabilities require implementation and release by Apple. The submitted project is therefore reproducible feasibility evidence and a QA seed, not a patch to Apple-owned operating-system resources. Its Persian copy is an AI-assisted engineering draft and is explicitly marked as requiring native linguistic, terminology, accessibility, and in-context review. I would appreciate guidance from Apple engineers on the following: What is the recommended configuration for testing a fully Persian-localized SwiftUI app when Persian is not available as a system UI language? Are there documented best practices for testing fa-IR RTL behavior, bidirectional text, VoiceOver metadata, Persian numerals, and Persian-calendar formatting consistently across iOS, iPadOS, and macOS? Are there additional developer-specific Feedback Assistant categories that would help Apple evaluate missing Persian support in system services and developer-facing localization infrastructure? Would additional fixtures or platform-specific targets be useful as supplements to FB23906760? More specifically, is there an Apple-recommended way to provide additional technical fixtures, terminology data, or validation cases to the relevant internationalization teams for evaluation of Persian (fa-IR) system-language support? This is an enhancement request and a technical localization question, not a request for information about unannounced product plans. Thank you.

On iOS 18.0+ simulators, tap any share link button from any app, select "Save to Files", the "Save" button is disabled. In all previous simulator versions this works. This behavior even happens with default Apple apps like Photos. Simulator: Version 16.0 (1037) XCode: Version 16.1 beta (16B5001e) macOS: 14.6.1 (23G93)

When switching to a SwiftUI app (built with Xcode 26.5) from an app with an active keyboard, the target app's tab bar incorrectly floats above the keyboard safe area. This layout issue occurs even though the target app does not display a keyboard and contains only a tab bar and scroll views.

Every time I submit a new iOS build, I need to switch to each supported language and paste an update about what's new. This takes so long! Is there any way to speed up the process? Google Play translates everything automatically; why doesn't Apple do that? I hate to completely remove support for most languages but I feel like I must sacrifice user experience due to App Store Connect design.

Hello Apple Developer Community, My name is Chris, and I’m an independent developer building games, educational tools, and utility apps for Apple platforms. I’d like to share some of the applications I have released so far: ADVENT Text Game for Mac A retro-inspired text adventure designed specifically for macOS. View on the App Store ADVENT Text Game for iPhone and iPad Explore mysterious caves, discover hidden passages, collect treasures, and solve puzzles in a classic-inspired text adventure. View on the App Store iFrappe View on the App Store China Driving Exam Trainer A study and practice application for learners preparing for the Chinese driving licence theory examination. View on the App Store Ur: The Royal Game A digital interpretation of the ancient Royal Game of Ur. View on the App Store I’m also currently developing Steel Maze, a retro maze-based tank battle game for iPhone, iPad, and Mac. Each project has helped me explore different parts of Apple development, including SwiftUI, SpriteKit, Mac Catalyst, responsive layouts, Game Center, gameplay design, and App Store distribution. I would be happy to receive feedback from other developers and connect with people working on similar independent projects. You can find my current app portfolio here: CK My Apps Thank you for taking a look!

Our company enrolled in the Apple Developer Program as an Organization. Apple successfully created our D-U-N-S Number, but our enrollment has remained "Being Processed" for an extended period. I have contacted Apple Developer Support three times regarding this issue. Each time, I received only the automated acknowledgment email, and the same Case ID was referenced every time. However, I have never received any response from a support representative. At this point, our company is completely blocked from publishing our iOS application. Has anyone experienced the same issue recently? If so, how was it resolved? If an Apple Developer Support representative sees this post, I would sincerely appreciate it if you could review my case or advise on the next steps. Thank you.

Since iOS 27 beta we are seeing a behavior change in our video streaming app and I would like to know whether others can reproduce it. Behavior on iOS 27 beta: Fully opening the Notification Center pauses playback. Audio continues for about 5 more seconds, then the app is suspended. Closing the Notification Center leaves the player paused. On iOS 26 the same build keeps playing in this situation. Setup: AVQueuePlayer playing video with audio, not muted audiovisualBackgroundPlaybackPolicy = .automatic (default) AVAudioSession category .playback, UIBackgroundModes: audio entitlement AVPictureInPictureController attached with canStartPictureInPictureAutomaticallyFromInline = true Filed as FB23893965 Questions: Can anyone reproduce this on iOS 27 beta? Is this intentional or a regression?

Hello everyone, I'm looking for some advice because I'm not sure if this is normal or if there is currently a delay with App Review. Here is my situation: My app was initially rejected under Guideline 5.6. The issue was fixed immediately. The fix only required changing my Firebase Remote Config (no code changes or new binary were necessary). I replied to the App Review message explaining the fix and resubmitted the same version for review. Since then, the app has been stuck in "Waiting for Review" for more than 72 hours. I have already: Requested an expedited review. Contacted Apple Developer Support. Received no response so far. My questions are: Is anyone else currently experiencing unusually long "Waiting for Review" times? Does replying to a rejection with the same build place the submission in a different review queue? Would submitting a new build (with a higher build number) help, or would that simply restart the waiting time? Is there anything else I can do to get the review moving? For those who have experienced this before: How long did your review stay in "Waiting for Review"? What ultimately resolved the situation? Any advice or recent experiences would be greatly appreciated. Thank you!

Issue Description: On iOS 26 and later, a CoreGraphics crash occurs when rendering images using -[UIImage drawInRect:blendMode:alpha:]. Based on the call stack, the crash happens inside CoreGraphics. Under what circumstances does the function upscale_provider_get_bytes_at_position_inner in the stack get called? When attempting to reproduce locally, this code path is never reached even when scaling images. Steps to Reproduce: There are a large number of crash reports in production, but the issue cannot be reproduced locally/offline. Expected Results: Explain under what conditions calling -[UIImage drawInRect:blendMode:alpha:] will reach the upscale_provider_get_bytes_at_position_inner logic. Ideally, provide a code example or demo. Provide the root cause of the crash and a workaround/mitigation. Current Behavior: Calling -[UIImage drawInRect:blendMode:alpha:] causes intermittent crashes in production. Xcode Version Used: Xcode Version 26.0 (17A324)

I want to use features described in the background assets WWDC22 session (https://developer.apple.com/videos/play/wwdc2022/110403/). In earlier versions of Xcode 14 beta there used to be a background asset extension target type, however this got removed in beta 5 and has still not been put back even though Xcode 14 RC is released. With Xcode 14 beta 4, if the background asset target was chosen then a bunch of template code was created, same as happens with any extension type. But if the background asset extension target type isn't even present in the Xcode 14 RC, how is one supposed to create an extension and use this new feature?

We are building a KPI(Telemetry) analytics reporting feature in our iOS app that requires recording and publishing reliable timestamps back to our backend server. Standard system time (Date()) is not suitable for our use case because it is susceptible to manual user changes (system clock manipulation) as well as clock drift over time. We are considering clock_gettime_nsec_np(CLOCK_MONOTONIC_RAW ) as a potential solution for iOS 10+. However, we want to confirm: Is clock_gettime_nsec_np a reliable, drift-free source for this purpose? Does the underlying OS handle NTP synchronization for these clocks, or can user-level time changes still impact them? Additionally, we recently came across Apple's official swift-ntp client library to fetch true NTP time directly. For production KPI reporting, is relying on an NTP library like swift-ntp the recommended approach, or is clock_gettime_nsec_np sufficient on modern iOS? We’d appreciate any insights or past experiences from the community. Thanks!

Hi everyone, I'm exploring an app idea that would help users organize their Home Screen, the app would move or rearrange other apps' icons on the user's behalf (for example, auto-grouping apps or repositioning them based on how often they're used). My question is twofold: Is there currently any entitlement, API, or permission that lets an app programmatically move or rearrange other apps' icons on the Home Screen? From what I can tell, the sandbox model prevents an app from touching anything outside its own container, so I suspect this isn't possible today but I'd be glad to be corrected if I've missed something. If it genuinely isn't possible, is this something Apple would consider adding? For instance, a user-granted permission (similar to how Notifications, Screen Time, or Accessibility permissions work) that the user could explicitly enable to let a trusted app manage their Home Screen layout. The user would stay in full control and could revoke it at any time. I understand there are solid privacy and security reasons behind the current restrictions, so I'm not looking for a workaround, I'm asking whether a supported, user-consented path could exist. Has anyone run into this or found any official guidance? And if this is better filed as a feature request through Feedback Assistant, I'm happy to do that too. Thanks!

Dear Apple Developer Support, I am requesting assistance regarding my Organization enrollment, which has been stuck in "Being Processed" for an extended period. I have already contacted Apple Developer Support three times through the Contact Us page. Each time, I received only the automatic acknowledgment email with a Case ID. Unfortunately, I have never received any follow-up from a support representative. Because of this, our company is currently unable to complete Organization Verification and cannot publish our iOS application on the App Store. Could you please: Check the status of my enrollment. Confirm whether my previous support requests were actually received by the Enrollment team. Escalate this case to the appropriate team if necessary. For your reference, my previous Case IDs are: Case ID: 102916885584 If you require any additional information or documentation from our company, please let me know. I will provide it immediately. Thank you for your time and assistance. I would greatly appreciate any update regarding the status of our Organization Verification. Kind regards, Dev UXUI Enrollment ID: WDF7RSUZ7P Company: Patana Intercool Company Limited

Hello - My new Build Version keeps entering on its own into an old Build Version Build Box under DISTRIBUTION. So I cannot add the new Build version to my New Build Version under Distribution. I tried to delete the older Build version so no mix up but ASC will not allow this to happen. Any way to clear this mess up? Nobody to call either so have written many emails to Support but I cannot wait for a month as this app is for the summer season which is NOW.

We are developing a system consisting of two iOS apps from the same developer (same Team ID): ・App A acquires data from an external accessory. For regulatory/compliance reasons that we cannot detail here, App A must have no networking capability at all. ・App B is intended to receive data from App A and upload it to a server. Two important environmental constraints: ・The deployment environment is a closed local network. The server App B talks to is on the local network, and Internet access is not guaranteed. Therefore, any APNs-dependent approach (silent push, etc.) is not viable. ・Latency requirement: near-real-time is ideal, but a delay of up to a few minutes is acceptable. What we have considered: 1.App Groups shared container — App A can write data, but there is no way to wake App B in the background when new data is written. 2.URL schemes — can launch App B reliably, but bring it to the foreground, which disrupts the user's workflow. 3.BGTaskScheduler — rejected; execution timing is entirely at the system's discretion. 4.Silent push — rejected; requires APNs / Internet connectivity, which we cannot assume (see above). Our current leading candidate is a combination of (1) and (2): App A writes data to the App Groups container, then opens App B via a URL scheme; App B reads the container and uploads. This works, but the foreground app switch on every hand-off is far from ideal. We are aware that some apps abuse background modes (e.g., playing silent audio) to stay resident. We assume this violates App Review Guideline 2.5.4 and is not an option for us — please correct us if there is any legitimate variant of this approach. Questions: 1.Is there any supported mechanism to keep App B running (or reliably woken) in the background, so that it can receive data from App A and upload it — without user interaction and without Internet access? 2.If not, is there any way to mitigate the foreground switch in our current App Groups + URL scheme approach (e.g., returning to App A automatically after the hand-off)? Or would that ping-pong pattern itself be an App Review concern? Any guidance would be appreciated.

Currently developing a vehicle rental App in flutter for iOS/Android. Our business has an affiliate system whereby affiliates are assigned a unique QR Code for app downloads. When a new user scans QR Code, the system needs to not only direct/attribute that App Store download to the affiliate, but also any rentals the user makes should attribute a % of rental fees to the affiliate. How exactly can this be done? How can we link that user’s app/purchase activity to the affiliate? i should say these aren’t exactly ‘In-App’ purchases. Any rental transaction is routed through a stripe-like payment processor.