We're working on an iOS app distributed through the App Store and installed on an MDM-enrolled device. Our MDM server uses InstallApplication to take management of the already-installed and running app. On iOS 27 betas 3 and 4, processing this command causes iOS to terminate the app and its extensions with SIGKILL. The same flow and MDM payload work without terminating the app on earlier iOS versions (iOS <=26). Environment OS: iOS 27 betas 3 and 4 Does not happen: iOS 26 or iOS 16.7.15 Device: iPhone SE 2nd Gen Enrollment: MDM-enrolled device Distribution: App Store app App state: Already installed and running when management is requested MDM command: InstallApplication Minimal MDM command The MDM server sends an InstallApplication command for the already-installed app: Attributes = { Removable = false; }; ChangeManagementState = Managed; Identifier = "APP_BUNDLE_ID"; InstallAsManaged = true; ManagementFlags = 1; RequestType = InstallApplication; We also tested the equivalent command using iTunesStoreID = APP_STORE_ID instead of Identifier, and removing InstallAsManaged. The targeted running app was terminated in the same way. Steps to reproduce Install and launch the App Store app as an unmanaged app. Enroll the iPhone in MDM. While the app is running, send the MDM InstallApplication command to take management of the existing installation. Observe the unified logs for mdmd, appstored, manageddeviced, installcoordinationd, and runningboardd. The issue can also be reproduced by initiating the same server-side flow while the app is already in the background. iOS 27 log sequence The command is accepted and appstored starts the managed-app tasks. manageddeviced then attempts to mark the app as managed using a null persona (this differs from iOS <26): The running app has a valid persona. After the failed mapping, installcoordinationd explicitly asks RunningBoard to terminate the app to disassociate that persona: After termination, removing the valid persona also fails. The managed-app task later reports success despite the mapping failures and termination. Earlier iOS comparison As an example, on iOS 16.7.15, using the same MDM command, **iOS routes the request through dmd with persona: default. The app remains alive and receives managed-app change notifications. Expected The existing installation becomes managed without terminating the running app, consistent with the behavior on earlier iOS versions. Actual manageddeviced tries to associate the app with persona (null) and fails with MIInstallerErrorDomain Code 191. That failure causes installcoordinationd to request termination of the app and its extensions to disassociate their valid persona. runningboardd terminates them with SIGKILL (isUserKill=0). The subsequent removal of the only valid persona fails with Code 242, although the managed-app task later reports success. Documentation checked The payload follows the documented InstallApplication flow for taking management of an existing app: Apple Docs WWDC26 app MDM updates We have not found a malformed field that explains the iOS 27-only failure. More info Detailed logs and additional info can be found on the Feedback report.

I am experiencing random Wi-Fi and Bluetooth disconnections while using iOS 27. Both Wi-Fi and Bluetooth disconnect unexpectedly, then reconnect automatically a few seconds later. I have seen many similar reports on Reddit, so this does not seem to be an isolated issue. I have already submitted a report through Feedback Assistant with the feedback ID FB23121586. I hope this issue can be fixed soon, because it is really stressful when playing online games on my iPhone and worrying that the connection might suddenly drop. :(

It has been approximately three weeks since we submitted our app for review via App Store Connect, but it remains "In Review" and the review process has not been completed. For this reason, we also requested an expedited app review to the App Review Team last week. Will the review proceed if we simply wait? Is there any way to check the detailed status of this app review?

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!

Hello everyone, I am experiencing a similar issue to the one reported by aarshps: "I hope someone has encountered this specific pattern and resolved it, or can point me in the right direction to escalate the issue." In my case, my iOS Apple Developer account (Case ID: 102929769930) has been pending for 40 days. I have met all of Apple's requirements, but support staff stated they could not verify my subscription or enrollment. The only potential detail on my end is that the payment was made using my son's credit card (Felipe Silva Ferraz), while the developer account was registered under my own name (Ademir Gomes Ferraz). I have sent multiple emails through the support portal, and my account still hasn't been approved. If anyone has faced this pattern or knows how to properly escalate it, please let me know.

I previously asked in the Network Extension forum about the supported architecture for local, user-controlled domain blocking on unmanaged consumer iPhones. Apple Developer Technical Support explained that using NEPacketTunnelProvider for a purpose other than a VPN is not a DTS-supported use case. DTS also noted that App Review has the final say regarding what may or may not be distributed through the App Store and directed me to App Review for clarification. URL Filters do not provide the intended device-wide domain visibility and user-controlled blocking. At the same time, the deployment restrictions described in TN3134 prevent the use of the relevant content-filtering provider types on unmanaged consumer iPhones. The proposed app is a consumer privacy and security app. It would use NEPacketTunnelProvider to identify destination domains locally and allow the user to block selected domains. The app would not provide a remote VPN service. Network traffic would not be routed to a remote VPN endpoint, and the app would not offer location changing, anonymous browsing, IP address masking, or access to a private network. My questions are: Would this use of NEPacketTunnelProvider be eligible for distribution on the App Store, even though DTS does not support this packet tunnel use case? Would App Review classify this as a VPN service, or could it be classified as a security or content-blocking app under App Store Review Guideline 5.4? If it is classified as a security or content-blocking app rather than a VPN service, may it be submitted by an individual Apple Developer Program member, or is enrollment as an organization required? I understand that a forum response cannot guarantee approval of a future submission. I am trying to clarify the likely classification and account requirement before proceeding with further development.

Super noob here 😅 is there a way to work with the “Xcode” development app on IOS. Any advice or input is welcome.

[SKStoreReviewController requestReviewInScene:] no longer displays the review prompt in debug/development builds on iOS 26.5 beta (23F5043k and 23F5043g). According to Apple's documentation, the review prompt should always appear in debug builds to facilitate testing. This was working in previous iOS versions (iOS 26.4 and older). Steps to reproduce: Run app from Xcode in debug configuration on a device running iOS 26.5 beta (23F5043k or 23F5043g) Call [SKStoreReviewController requestReviewInScene:windowScene] with a valid, foreground-active UIWindowScene Observe that the method executes without error (scene is valid per NSLog) but no review prompt appears Expected: Review prompt should display in debug builds Actual: No prompt appears, despite the scene being valid and foreground-active This worked correctly on previous iOS versions (26.4) so looks like this bug was introduced in 26.5 Beta versions. I have already filed a bug report in Feedback Assistant with number: FB22445620

I am planning an iOS security and content-blocking app for unmanaged consumer iPhones. The app would not provide a traditional VPN service. It would not offer: Remote VPN servers Geographic location switching Access to a private corporate network IP-address masking as a service Anonymous browsing Instead, the app would allow the user to: View destination domains contacted by the device Classify destinations such as trackers, advertising, analytics, or potentially malicious domains Manually block selected domains Keep connection history and filtering decisions on the device I understand that NEFilterDataProvider and NEFilterControlProvider are the APIs intended for network content filtering. However, according to TN3134, these providers are not generally deployable for an unmanaged adult consumer iPhone. I also understand that TN3120 says NEPacketTunnelProvider should not be used as a general-purpose local content filter. This appears to leave a gap for an unmanaged consumer security app whose core feature is user-controlled, system-wide domain blocking. I am considering whether NETunnelProviderManager with an NEPacketTunnelProvider could support the feature, but I do not want to use the packet-tunnel API outside its supported purpose. My questions are: Is there currently a supported Network Extension architecture for system-wide, user-controlled domain blocking on an unmanaged adult consumer iPhone? Can an app with this purpose use NEPacketTunnelProvider, or would that necessarily be considered the unsupported general-purpose filtering use described in TN3120? If such an architecture is supported, could an app with this purpose be treated as an approved security or content-blocking provider under Guideline 5.4 rather than as an app offering a traditional VPN service? App Review Guideline 5.4 states that apps offering VPN services must be submitted by developers enrolled as organizations. It also states that parental-control, content-blocking, and security apps from approved providers may use NEVPNManager. For an app that does not provide a remote VPN service but uses Apple’s VPN configuration infrastructure only for local security and user-controlled blocking, must the developer still enroll as an organization, or may an individual Apple Developer Program member submit it?

Summary xcrun simctl install <valid.app> fails even though the app's Info.plist contains a correct, well-formed CFBundleIdentifier — verified independently with plutil -p. The app builds successfully via xcodebuild twice, under two different signing configurations. This is purely an install-time failure. ERROR · EVERY ATTEMPT An error was encountered processing the command (domain=IXErrorDomain, code=13): Simulator device failed to install the application. Missing bundle ID. Underlying error (domain=IXErrorDomain, code=13): Failed to get bundle ID from /QuestionsWeCarry.app Missing bundle ID. Environment MACOS 26.5.2 · Build 25F84 XCODE 26.6 · Build 17F113 SIMULATOR RUNTIME iOS 26.5 (23F77) HARDWARE Apple M5 KERNEL Darwin 25.5.0 arm64 XCODE.APP / SIMULATOR PLATFORM both freshly installed Xcode.app and the iOS Simulator platform were both freshly installed immediately before this was discovered — this may be a first-run / first-boot issue specific to this Xcode 26.6 + iOS 26.5 combination. Project being built A SwiftUI iOS app target generated via XcodeGen from project.yml, depending on a local Swift Package with four library products. Nothing exotic — no third-party SDKs, no CocoaPods, no entitlements file. PROJECT.YML — RELEVANT TARGET BLOCK PROJECT.YML targets: QuestionsWeCarry: type: application platform: iOS deploymentTarget: "17.0" sources: - path: App/Sources - path: App/Resources type: folder buildPhase: resources info: path: App/Info.plist properties: CFBundleDisplayName: "Questions We Carry" UILaunchScreen: {} ITSAppUsesNonExemptEncryption: false UIApplicationSceneManifest: UIApplicationSupportsMultipleScenes: false settings: base: PRODUCT_BUNDLE_IDENTIFIER: com.brodywolfstudio.questionswecarry MARKETING_VERSION: "1.0.0" CURRENT_PROJECT_VERSION: "1" SWIFT_VERSION: "5.10" TARGETED_DEVICE_FAMILY: "1,2" CODE_SIGN_STYLE: Manual CODE_SIGN_IDENTITY: "-" CODE_SIGNING_REQUIRED: NO CODE_SIGNING_ALLOWED: YES dependencies: - package: QWCKit product: QWCCore - package: QWCKit product: QWCEngine - package: QWCKit product: QWCStore - package: QWCKit product: QWCUI BUILD COMMAND THAT SUCCEEDS SHELL xcodebuild -project QuestionsWeCarry.xcodeproj -scheme QuestionsWeCarry -configuration Debug -destination "platform=iOS Simulator,id=" -derivedDataPath DerivedData build Result: BUILD SUCCEEDED, produces DerivedData/Build/Products/Debug-iphonesimulator/QuestionsWeCarry.app. INFO.PLIST INSIDE THE BUILT .APP (VIA PLUTIL -P) INFO.PLIST { "BuildMachineOSBuild" => "25F84" "CFBundleDevelopmentRegion" => "en" "CFBundleDisplayName" => "Questions We Carry" "CFBundleExecutable" => "QuestionsWeCarry" "CFBundleIdentifier" => "com.brodywolfstudio.questionswecarry" "CFBundleInfoDictionaryVersion" => "6.0" "CFBundleName" => "QuestionsWeCarry" "CFBundlePackageType" => "APPL" "CFBundleShortVersionString" => "1.0" "CFBundleSupportedPlatforms" => [ 0 => "iPhoneSimulator" ] "CFBundleVersion" => "1" "DTCompiler" => "com.apple.compilers.llvm.clang.1_0" "DTPlatformBuild" => "23F81a" "DTPlatformName" => "iphonesimulator" "DTPlatformVersion" => "26.5" "DTSDKBuild" => "23F81a" "DTSDKName" => "iphonesimulator26.5" "DTXcode" => "2660" "DTXcodeBuild" => "17F113" "ITSAppUsesNonExemptEncryption" => false "MinimumOSVersion" => "17.0" "UIApplicationSceneManifest" => { "UIApplicationSupportsMultipleScenes" => false } "UIDeviceFamily" => [ 0 => 1 1 => 2 ] "UILaunchScreen" => { } } CFBundleIdentifier is present, correctly formed, and matches PRODUCT_BUNDLE_IDENTIFIER. file confirms this is a valid Apple binary property list, not corrupted. CODESIGN -DV ON THE BUILT APP CODESIGN -DV Executable=/QuestionsWeCarry.app/QuestionsWeCarry Identifier=QuestionsWeCarry-******* Format=bundle with Mach-O thin (arm64) CodeDirectory v=20400 size=338 flags=0x2(adhoc) hashes=3+3 location=embedded Signature=adhoc Info.plist=not bound TeamIdentifier=not set Sealed Resources version=2 rules=13 files=4 Internal requirements count=0 size=12 Note Info.plist=not bound — unclear whether this is expected for an ad-hoc-signed bundle app (as opposed to a framework), or is itself a symptom of the underlying problem. Reproduction Minimal, reproducible with the plain command-line tool — no Claude tooling involved in this step: SHELL xcrun simctl install "iPhone 17 Pro" "/DerivedData/Build/Products/Debug-iphonesimulator/QuestionsWeCarry.app" Result (100% reproducible, every attempt): STDERR An error was encountered processing the command (domain=IXErrorDomain, code=13): Simulator device failed to install the application. Missing bundle ID. Underlying error (domain=IXErrorDomain, code=13): Failed to get bundle ID from /QuestionsWeCarry.app Missing bundle ID. Also reproduced with xcrun simctl launch, which fails as a consequence: Isolation steps taken All of the following were tried, and none changed the outcome — the exact same "Missing bundle ID" error occurs every time: 01 Two signing configurations — unsigned/linker-signed (Sealed Resources=none) vs. proper ad-hoc sign (Sealed Resources version=2 rules=13 files=4), plus a manual codesign --force --deep --sign - re-sign pass. Same failure every time. 02 Two simulator destinations — generic/platform=iOS Simulator and a concrete device id for iPhone 17 Pro. 03 Two never-before-used simulator devices — iPhone 17 Pro and iPhone Air — ruling out per-device CoreSimulator state corruption. 04 Erase + cold boot — simctl shutdown, erase, boot immediately before a fresh install attempt. 05 Real Simulator.app GUI running — not just a headless simctl boot — ruled out a CoreSimulatorService/GUI dependency. 06 Path with no spaces — copied the .app out of a path containing "Application Support" — ruled out a path-quoting issue. The build itself is never in question — xcodebuild reports BUILD SUCCEEDED every time; only the subsequent simctl install step fails. What I'd like feedback on Is this a known issue with this specific Xcode 26.6 / iOS 26.5 Simulator runtime combination — both very recently installed, so possibly a fresh-install/first-boot bug? Is there a required build setting for this Xcode version not yet reflected in commonly-documented XcodeGen/xcodebuild recipes — e.g. an entitlements file now required even for simulator-only, no-team builds, or a different expected code-signing identity/format? Is Info.plist=not bound in the codesign -dv output actually abnormal for an app bundle (as opposed to a framework), and could that be the root cause simctl is choking on?

We are seeing a startup issue with in-house enterprise iOS apps on iOS 27 Developer Beta. We would like to understand whether this could be related to changes in iOS 27 Developer Beta startup validation, code signing validation, provisioning profile validation, certificate chain validation, entitlements, embedded frameworks, enterprise developer trust state, or device-specific launch behavior. This issue blocks our enterprise app compatibility validation on iOS 27 Developer Beta, especially on iPhone 11 and iPhone 12 devices. If this is a known beta issue, we would appreciate confirmation from Apple and any available fix plan or workaround. Symptoms: After installing the same enterprise app, some iPhone 11 / iPhone 12 devices running iOS 27 Developer Beta cannot launch it correctly. There are two visible behaviors: When launched from the Home Screen icon, the app stays on the Launch Screen. The normal app UI never appears. When launched from Spotlight/Search, the app crashes immediately. Additional observations: iPhone 13 and later devices do not show this issue. Other enterprise apps distributed with the same provisioning profile or provisioning setup show the same behavior. This makes the issue look less like a single app's business logic problem and more like an iOS 27 Developer Beta validation, trust, or launch-time behavior difference on specific device models. We added logs and breakpoints at the earliest possible app startup points, including main, AppDelegate, SceneDelegate, and before crash-reporting SDK initialization. On affected devices, none of these logs are printed. Based on this, it appears that our app code is never reached. The failure seems to happen before iOS transfers control to the app, possibly while launching the process or loading the app binary/frameworks. Our current suspicion is that the failure may happen during one of these system-level steps: Enterprise code signing validation embedded.mobileprovision validation Certificate chain validation Enterprise developer certificate trust validation Mach-O / embedded frameworks / dynamic libraries loading Entitlements validation Bundle ID / App ID / provisioning profile matching Reuse of stale local enterprise trust, provisioning, or signing validation state on the device Temporary workaround observed: We found a temporary workaround on affected devices: Completely uninstall the existing enterprise app from the device. Download and install the app again. Trust the enterprise developer certificate again in Settings. Launch the app again. After doing this, the app can start normally on the affected iPhone 11 / iPhone 12 devices running iOS 27 Developer Beta. The Launch Screen hang and Spotlight/Search crash no longer reproduce. This suggests that the IPA itself may not be permanently invalid, and the issue may not be caused by app business logic. It may instead be related to stale or invalid local enterprise trust, provisioning profile, certificate chain, or signing validation state after upgrading to iOS 27 Developer Beta. Questions: Does iOS 27 Developer Beta introduce any new restrictions or behavior changes for enterprise in-house app launch validation, code signing validation, enterprise developer trust state, embedded frameworks loading, entitlements, or provisioning profile validation? Are there any known differences in this area between iPhone 11 / iPhone 12 and iPhone 13 or later devices on iOS 27 Developer Beta? If multiple enterprise apps distributed with the same provisioning profile or provisioning setup fail before app code runs, does that point more strongly to a provisioning profile, certificate chain, enterprise trust state, or system validation issue? Given that completely uninstalling the old enterprise app, reinstalling it, and trusting the enterprise developer certificate again fixes the issue, could this be caused by stale trust, provisioning profile, certificate, or code-signing validation state cached on the device after upgrading to iOS 27 Developer Beta? For an enterprise app that stays on the Launch Screen before app code runs, or crashes immediately when launched from Spotlight/Search, what are the most common signing, certificate, provisioning profile, entitlement, or enterprise trust problems to check? Which system logs or crash log fields should we focus on for this kind of pre-main launch failure? For example: device console, crash log, Termination Reason, dyld message, Code Signature Invalid, profile validation, or trust evaluation messages. Are there recommended commands or checks to verify that the IPA's code signature, certificates, entitlements, embedded.mobileprovision, and embedded frameworks are all valid and consistent? If this is an iOS 27 Developer Beta regression, is there any known workaround until the issue is fixed? Environment: Distribution type: Apple Developer Enterprise Program / In-House distribution Affected OS: iOS 27 Developer Beta Affected devices: iPhone 11 / iPhone 12 Unaffected devices: iPhone 13 and later Same provisioning profile or provisioning setup: other enterprise apps show the same behavior Behavior 1: stuck on Launch Screen when launched from Home Screen Behavior 2: crashes immediately when launched from Spotlight/Search App code execution: not reached main/AppDelegate/SceneDelegate logs: not printed Crash SDK initialization: not reached Temporary workaround: completely uninstall the old enterprise app, reinstall it, and trust the enterprise developer certificate again. After that, the app launches normally. Impact: blocks enterprise app compatibility validation on iOS 27 Developer Beta for affected devices Suspected area: iOS 27 Developer Beta startup validation / code signing / provisioning profile / certificate / enterprise developer trust state / entitlements / embedded frameworks / device-specific validation behavior We are looking for guidance on how to confirm whether this is caused by an iOS 27 Developer Beta signing, provisioning profile, or enterprise developer trust validation change on iPhone 11 / iPhone 12, rather than an app-level crash. If this is a system issue in iOS 27 Developer Beta, we hope Apple can provide a fix or a practical temporary workaround as soon as possible.

Hello, I am currently developing call-related features for our app, and I have a question regarding one of the APIs. When the app is launched from the Recents list by selecting a recent call, the activityType of the userActivity is provided as either INStartAudioCallIntentIdentifier or INStartVideoCallIntentIdentifier. However, I understand that these identifiers have been deprecated since iOS 13, and the documentation recommends using INStartCallIntentIdentifier instead. The issue is that when the app is launched from the Recents list, INStartCallIntentIdentifier is never provided. Instead, the deprecated identifiers (INStartAudioCallIntentIdentifier and INStartVideoCallIntentIdentifier) continue to be delivered. I have reviewed the available documentation, but it is not clear how developers are expected to handle this situation. Could you please advise on the recommended approach for supporting this flow? Is it expected that applications continue to handle the deprecated identifiers in this case, or is there another recommended implementation? I would greatly appreciate any guidance you can provide. Thank you.

Hi everyone, I submitted an app update for review on July 16, and the status has been stuck at "Waiting for Review" for a full week now (7 days and counting). The app is not in a sensitive category (not health, finance, VPN, or gambling related), and there are no legal or export compliance issues that I'm aware of. A bit of background: App type: update (not a new app) Submission date: July 16, 2026 Apple Developer Program membership: active and in good standing No messages in Resolution Center or App Store Connect inbox No changes made to the submission during this period (no metadata edits, no new builds uploaded) I understand review times can fluctuate, but 7+ days in "Waiting for Review" — not even "In Review" — without any communication seems unusually long, especially for a routine update. Has anyone else experienced similar delays recently? Is there anything suggested beyond withdrawing and resubmitting (which I'd like to avoid)? Thanks in advance!

Hi Team, I'm trying to understand the behavior of the following API: HTTPCookieStorage.shared.setCookies(_:for:mainDocumentURL:) Specifically, does this API persist cookies synchronously, or does it perform the storage asynchronously in the background? Our use case is storing FCAP (frequency capping) cookies so they persist across app sessions. We call setCookies(_:for:mainDocumentURL:) and want to know whether the cookies are guaranteed to be written before the method returns, or if the actual persistence happens asynchronously. I couldn't find documentation describing the persistence semantics of this API, so I'd appreciate any clarification or guidance from Apple or anyone familiar with its implementation. Thanks

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 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.