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

When interacting with RealityView’s realityViewCameraControls .orbit and setting a new RealityViewCameraContent .cameraTarget, the resulting camera target and camera orbit is incorrect. This can be demonstrated where one finger is orbiting the RealityView, and another pushes a button which changes the camera target. Instead of the camera facing the new target, some point in the scene is the new effective camera target and orbit point. This only occurs when an orbit interaction is currently taking place. If you stop interacting with the orbit, change target, then start orbit interacting again, everything works as expected. Though this example uses two-touches, any change of the camera target has this conflict with orbit interaction. This means interacting with orbit will result in the wrong camera view which is unexpected for users and difficult to reconcile or detect, for developers. Expected: Interacting (orbiting) the scene while setting a new camera target with the buttons on screen (at the same time), the camera’s new target shows centred in view the orbit revolves the new target and continues to match my gestures. Reality: Interacting (orbiting) the scene while setting a new camera target with the buttons on screen (at the same time), the camera’s new target is not centred in view, and camera is now orbiting an unexpected point in the scene, that is not my expected target. One imperfect workaround is to force a rebuild of the view after setting a new cameraTarget. This sets all targets correctly but results in a flicker, loss of orbit controls until re-touch and ultimately is a poor user experience, but is better than the wrong target being shown unexpectedly. Code Sample: import SwiftUI import RealityKit struct RKOribtTarget: View { @State private var target: Int = 0 @State private var rcContent: RealityViewCameraContent? @State private var rkID: UUID = UUID() let root = Entity() let center = ModelEntity(mesh: .generateSphere(radius: 0.05), materials: [UnlitMaterial(color: UIColor(.gray.opacity(0.5)))]) let red = ModelEntity(mesh: .generateBox(size: 0.1), materials: [SimpleMaterial(color: .red, isMetallic: false)]) let blue = ModelEntity(mesh: .generateBox(size: 0.1), materials: [SimpleMaterial(color: .blue, isMetallic: false)]) let green = ModelEntity(mesh: .generateBox(size: 0.1), materials: [SimpleMaterial(color: .green, isMetallic: false)]) var body: some View { VStack{ RealityView { content in red.position.x = 0.5 blue.position.z = 0.5 green.position.y = 0.5 center.position = .init(repeating: 0.25) content.cameraTarget = target == 0 ? root : blue root.addChild(red) root.addChild(blue) root.addChild(green) root.addChild(center) content.add(root) } update: { content in switch target{ case 0: content.cameraTarget = root case 1: content.cameraTarget = blue case 2: content.cameraTarget = red case 3: content.cameraTarget = green default: content.cameraTarget = root } } .id(rkID) .realityViewCameraControls(.orbit) VStack{ Text("Target") Button("Default") { target = 0 // Force rebuilding view resets orbit target and rotation // But shows a flicker, interaction requires touch reset // Not an ideal workaround // rkID = UUID() } .buttonStyle(.bordered) Button("Blue") { target = 1 // rkID = UUID() } .buttonStyle(.bordered) .tint(.blue) Button("Red") { target = 2 // rkID = UUID() } .buttonStyle(.bordered) .tint(.red) Button("Green") { target = 3 // rkID = UUID() } .buttonStyle(.bordered) .tint(.green) } } } } Xcode Version: Version 26.0 (17A324) iOS Version: iOS 26.5 (23F75) Tested on devices, iPhone 12 Pro, iPhone 15 Pro

Hello, my App DEBRIEF has now already for 15d the status „Waiting For Review“ and nothing is changing. I opened a support ticket under 102880278747 3d ago and got the reply that it should have been checked and it can’t take much longer. I am running ads already for the app and some partners are waiting for the launch. Any Ideas what I can do or is that normal ? What do I need to expect? Apple ID: 6762911498 Bundle ID: com.netcoresolutions.DE-BRIEF

Issue Description We noticed the app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences. Next Steps Since we do not accept spam apps on the App Store, we encourage you to review the app concept and submit a unique app with distinct content and functionality. Resources Some factors that contribute to a spam rejection may include: Submitting an app with the same source code or assets as other apps already submitted to the App Store Creating and submitting multiple similar apps using a repackaged app template Purchasing an app template with problematic code from a third party Submitting several similar apps across multiple accounts Learn more about our requirements to prevent spam in guideline 4.3.

Hello, I am investigating a recurring crash that appears to be originating within the system's network stack. OS Version: iPhone OS 26.1 (23B85) Role: Foreground Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 Triggered by Thread: 19 Description: The crash is triggered by Thread 19 and occurs deep within libquic.dylib during a QUIC recovery timer event. Based on the backtrace, the failure happens in quic_recovery_pto. The issue seems to occur when a protocol instance schedules a wakeup, leading to a null pointer dereference in the system library. Crashed Thread Backtrace snippet:Thread 19 Crashed: Thread 19 Crashed: 0 libquic.dylib 0x00000001a00a38cc quic_recovery_pto + 72 (quic_recovery.c:1259) 1 libquic.dylib 0x00000001a00a3390 quic_recovery_timer_fired + 132 (quic_recovery.c:1460) 2 libquic.dylib 0x00000001a00a1f8c quic_timer_run + 248 (quic_timer.c:210) 3 Network 0x000000018ec76cbc __nw_protocol_instance_schedule_wakeup_block_invoke + 76 (protocol_implementation.cpp:5847) 4 Network 0x000000018eba34e0 __nw_context_reset_timer_block_with_time_block_invoke + 268 (context.cpp:2224) 5 libdispatch.dylib 0x00000001c84727ec _dispatch_client_callout + 16 (client_callout.mm:85) 6 libdispatch.dylib 0x00000001c845d664 _dispatch_continuation_pop + 596 (queue.c:349) 7 libdispatch.dylib 0x00000001c8470528 _dispatch_source_latch_and_call + 396 (source.c:601) 8 libdispatch.dylib 0x00000001c846f1fc _dispatch_source_invoke + 844 (source.c:966) 9 libdispatch.dylib 0x00000001c8463288 _dispatch_workloop_invoke + 1612 (queue.c:4761) 10 libdispatch.dylib 0x00000001c846c3ec _dispatch_root_queue_drain_deferred_wlh + 292 (queue.c:7265) 11 libdispatch.dylib 0x00000001c846bce4 _dispatch_workloop_worker_thread + 692 (queue.c:6859) 12 libsystem_pthread.dylib 0x00000001ec0623b8 _pthread_wqthread + 292 (pthread.c:2696) 13 libsystem_pthread.dylib 0x00000001ec0618c0 start_wqthread + 8 (:-1) Can anyone provide insights into what might be causing libquic to access an invalid address in this context? Any help or suggestions for further diagnostics would be greatly appreciated.

Is there a safeAreaInsets equivalent that only tracks system bars (tab bars, status bars, side bars, toolbars, and navigation bars) and is not affected by notches? I'm asking this because the iPadOS tab bar can appear either on the top, bottom, or left (modally or non-modally) in various configurations, including sidebarAdaptable and when the window size is small on iPadOS; the tab bar's frame is not really reliable in this case, and while the safe area insets works, it also includes the notches / rounded window corners...

I'm distributing a Safari Web Extension iOS app via TestFlight (built from a Chrome MV3 extension via xcrun safari-web-extension-converter on Xcode 26.0.1). The extension installs and registers correctly, but its popup never opens when the toolbar item is tapped. The behavior is silent — no error, no flash of UI, no console output. The Safari "ᴀA" menu just closes and the user is back at the article. WHAT WORKS: Extension appears in Settings → Safari → Extensions, can be enabled Permissions can be granted ("Always Allow on Every Website") Extension appears as expected in Safari's "ᴀA" address-bar menu WHAT DOESN'T WORK: Tapping the extension item in the AA menu produces no popup, no error, no visible response of any kind. Same on iPhone and iPad, both on iOS 26. WHAT I'VE VERIFIED VIA IPA INSPECTION: Extension .appex contains: manifest.json, popup.html, popup.js, background.js, content.js, and images/ with all icons _CodeSignature/CodeResources files2 lists 11 entries — every web extension resource is signed manifest declares: "action": { "default_popup": "popup.html", "default_icon": {...} } Extension Info.plist has standard NSExtension dict: NSExtensionPointIdentifier = com.apple.Safari.web-extension NSExtensionPrincipalClass = (My)_Extension.SafariWebExtensionHandler ISOLATION TEST: To rule out my popup code, I replaced popup.html with a 506-byte file containing only a static green box and "Hello World" text — no scripts, no images, no external references. This minimal popup ALSO fails to open with the same silent behavior. So this is not a script error or content issue. MANIFEST DETAILS (relevant excerpts): { "manifest_version": 3, "action": { "default_popup": "popup.html", "default_icon": {...} }, "background": { "scripts": ["background.js"], "persistent": false }, "content_scripts": [{ "matches": ["<all_urls>"], "js": ["content.js"] }], "permissions": ["activeTab", "storage", "scripting"], "host_permissions": ["<all_urls>"] } I previously had "background": { "service_worker": "background.js", "type": "module" } and switched to scripts/non-persistent based on prior forum advice about iOS Safari incompatibility with module-type service workers. No change in behavior either way. ENVIRONMENT: iOS 26 (iPhone and iPad — both affected) Built on macos-15 GitHub Actions runner with Xcode 26.0.1 Distribution via TestFlight Manifest version 3 Extension target produced by xcrun safari-web-extension-converter I cannot easily provide a focused Xcode test project as my entire build pipeline runs on GitHub Actions (no local Mac access at this time). I can share the IPA, build pipeline configuration, and source repository. Has anyone else seen silent popup failures on iOS 26 from converter-built Safari Web Extensions? Is there an Info.plist key, build setting, or NSExtension attribute the converter is missing that's needed for popups to render on iOS 26? Thanks for any insight.

Hi everyone, We are investigating a possible iOS permission state issue after a device previously installed our app through TestFlight and later installed the production version from the App Store using the same Bundle ID. Environment: Device: iPhone 15 iOS version: 26.2.1 App distribution history: The app was previously installed through TestFlight and later installed from the App Store Permissions involved: Camera / Photos Issue: When the user opens the App Store version of the app and tries to access a feature that requires Camera or Photos permission, the iOS permission prompt does not appear as expected. Also, the app does not appear under: Settings > Privacy & Security > Camera or: Settings > Privacy & Security > Photos Because of this, the user cannot manually enable the permission. Another user on iOS was able to grant the permissions normally, so the issue appears to be isolated to the device that previously used the TestFlight build. Expected behavior: When the App Store version requests Camera or Photos permission, iOS should display the permission prompt, or the app should appear under Settings > Privacy & Security > Camera/Photos so the user can manage the permission manually. Actual behavior: The permission prompt does not appear, and the app does not appear in the corresponding privacy permission list. Possible cause: It seems like the device may be preserving or reusing a stale privacy permission state from the previous TestFlight installation, since both the TestFlight build and the App Store build use the same Bundle ID. Steps to reproduce: Install the app through TestFlight. Open the app and trigger a Camera/Photos permission request. Grant or deny the permission. Stop testing or remove the TestFlight version. Install the production version from the App Store using the same Bundle ID. Open the App Store version. Trigger the same Camera/Photos permission request flow. Go to Settings > Privacy & Security > Camera/Photos. The app does not appear, or the permission prompt does not behave as expected. Workarounds attempted or suggested: Close and reopen the app. Restart the iPhone. Delete and reinstall the app from the App Store. Stop testing the app from TestFlight. Reset Location & Privacy settings. Question: Has anyone experienced a similar issue where iOS does not show the permission prompt or does not list the app under Privacy & Security after switching from a TestFlight build to the App Store version with the same Bundle ID? Is there a recommended way to fully clear the previous TestFlight permission state, or should this be reported as a possible iOS/TestFlight permission state bug?

Hello, We are reaching out as a company providing Wi-Fi connectivity services through captive portals to report a potential issue identified after upgrading to iOS 26. Since the release of this version, we have received multiple reports from customers who are unable to complete the authentication process on captive portal networks. The observed behavior is as follows: The device correctly detects the Wi-Fi network. The connection is established at the link level, but after entering access credentials and proceeding to the next login step, an “error opening page” message is consistently displayed. When the user taps “OK,” the captive portal mini-browser closes. As a result, the user is unable to authenticate or gain internet access. We have verified that: Our network infrastructure and captive portals function correctly on other operating systems (Android, Windows, and previous iOS versions). No recent changes have been made to our platforms that could explain this behavior. The issue appears to be consistently reproducible on devices running iOS 26. Additionally, we have identified similar reports from users in public communities like reddit, suggesting this is not an isolated case. https://www.reddit.com/r/ios/comments/1no4vzt/switched_to_ios_26_and_now_i_cant_connect_to/ Given the direct impact on user experience and services relying on web-based authentication, we would appreciate any information on whether this behavior is being investigated or if there are any technical recommendations to mitigate the issue. Thank you for your attention.

Hi. I’d appreciate any advice regarding the issue described below. Steps to reproduce the problem: Access iCloud.com from Safari on my Mac mini using my account. Create and save a Numbers spreadsheet. Access iCloud.com from Safari on an iPhone SE (2nd generation) using the same Apple account. Tap the file icon of the saved Numbers spreadsheet. Safari navigates to “about:blank” and displays an error message. Error message: **This spreadsheet is unavailable. The owner stopped sharing, or you do not have permission to open this spreadsheet. ** I used to be able to view these files, but now none of the spreadsheets will open. Environment: Intel Mac mini (2018) macOS Sequoia 15.7.7 Safari 26.3 iPhone SE (2020) iOS 26.5 Beta 4 What I’ve tried: Suspecting a Safari issue, I installed Google Chrome on the iPhone and tried accessing iCloud.com, but encountered the same error. Installed the Numbers app on the iPhone and accessed the files on iCloud — they open successfully. Created and saved a new file using the Numbers app on the iPhone, then tried accessing it via Safari and Chrome through iCloud — the same error occurs. Additional information: Other files on iCloud (such as Notes) can be opened across devices without any issues. Installing the Numbers app on the iPhone allows me to view the files, but since I only need to view them (not edit or create new ones), I’d prefer not to install it if possible. This might be related to participating in the beta program (I’ve already submitted a report via Feedback Assistant). Would downgrading be advisable?

I am having an issue where my builds are marked green and ready for testing, but when I go to install from TestFlight I get the following message: "Could not Install X App" "The requested app is not available or doesn't exist" I've tried troubleshooting with information found online, tried different testing users. New builds. All result in the same message. Multiple support emails to Apple Developer. No response in 8 days.

Hey guys, I made a app that features push notificaions, and I keep having problems setting them up. It asks permissions, and then it says that it cannot get the APN token after 10 seconds, and I am positive that I have enabled Push Notificaions in the provisioning profile in Xcode. Can anyone help me fix this issue?