Hi everyone, I’m looking for guidance because I’m struggling to understand an App Review decision. My app, The Leaf Cellar, is a cigar companion app that includes cigar image scanning, humidor management, cigar journals, tasting notes, lounge discovery, and recommendations. My app was rejected, yet there are multiple applications currently on the App Store with substantially similar functionality, including: Ember: AI Cigar Companion (released this year) My Humidor – Cigar Journal Humidor Journal Pro ACJ These apps continue to receive updates and remain available on the App Store. I’m trying to understand what materially distinguishes my implementation from theirs. If Apple considers my app to violate a specific guideline, I would appreciate understanding what objective difference exists between my app and these already approved apps. Has anyone experienced a similar situation where comparable apps were approved but theirs was rejected? Were you able to resolve it through App Review or the App Review Board? Any advice on how to present the strongest case would be greatly appreciated. I’m not looking for speculation or opinions. I’m looking for a clear explanation of how the App Store Review Guidelines are being applied in this case, especially given that a competing app with substantially similar functionality was approved and released this year. From my perspective, the current outcome appears inconsistent, and I would appreciate any insight from developers who have successfully navigated a similar situation. Thank you.

Our app has been in review for over a month with no status change or communication from App Review. Typical reviews clear within 24–48 hours, so this is well outside the normal window. Can anyone from App Review advise on next steps or escalate? App details and submission ID available on request. Thanks.

The Deligate 'didFetchResult' method of fetching data past 24 hours from SensorKit is not being called. It is confirmed that you have already granted full access to the SensorKit and that data on the Ambient value in the device's personal information -> research sensor & usage data are recorded. It is possible to export to an lz4 file. I want to have the data after 24 hours called to the app, but other Deligate methods are called, but only Deligate that gets the illumination value is not called. Is it understood that only data past 24 hours can be imported after startRecoding() is called? If so, in order to receive data past 24 hours, do I have to continue to receive the illumination data value in the background for more than 24 hours to receive the Ambient value afterwards? import Foundation import SensorKit import UIKit final class SensorKitManager: NSObject, ObservableObject, SRSensorReaderDelegate { static let shared = SensorKitManager() private let ambientReader = SRSensorReader(sensor: .ambientLightSensor) var availableDevices: [SRDevice] = [] @Published var ambientLightData: [AmbientLightDataPoint] = [] var isFetching = false var isRecordingAmbientLight = false private override init() { super.init() setupReaders() checkAndRequestAuthorization() } private func setupReaders() { ambientReader.delegate = self } // MARK: - Permission Request func requestAuthorization() { SRSensorReader.requestAuthorization(sensors: [.ambientLightSensor]) { [weak self] error in DispatchQueue.main.async { guard let self = self else { print("Permission request aborted") return } if let error = error { print("Permission request failed: \(error.localizedDescription)") } else { print("Permission request succeeded") self.startRecordingAmbientLightData() } } } } func checkAndRequestAuthorization() { let status = ambientReader.authorizationStatus switch status { case .authorized: print("Ambient light sensor access granted") startRecordingAmbientLightData() case .notDetermined: print("Ambient light sensor access undetermined, requesting permission") requestAuthorization() case .denied: print("Ambient light sensor access denied or restricted") @unknown default: print("Unknown authorization status") } } // MARK: - Ambient Light Data Logic func startRecordingAmbientLightData() { guard !isRecordingAmbientLight else { print("Already recording ambient light data.") return } print("Starting ambient light data recording") isRecordingAmbientLight = true ambientReader.startRecording() fetchAmbientLightData() fetchAmbientDeviceData() } func fetchAmbientLightData() { print("Fetching ambient light data") let request = SRFetchRequest() let now = Date() let fromTime = now.addingTimeInterval(-72 * 60 * 60) let toTime = now.addingTimeInterval(-25 * 60 * 60) request.from = SRAbsoluteTime(fromTime.timeIntervalSinceReferenceDate) request.to = SRAbsoluteTime(toTime.timeIntervalSinceReferenceDate) print("Fetch request: \(fromTime) ~ \(toTime)") ambientReader.fetch(request) } private func displayAmbientLightData(sample: SRAmbientLightSample) { print("Ambient light: \(sample.lux.value) lux") print("Current ambientLightData content:") for data in ambientLightData { print("Timestamp: \(data.timestamp), Lux: \(data.lux)") } } // MARK: - Device Data Logic private func fetchAmbientDeviceData() { print("Fetching device information") let request = SRFetchRequest() let now = Date() let fromDate = now.addingTimeInterval(-72 * 60 * 60) let toDate = now.addingTimeInterval(-24 * 60 * 60) request.from = SRAbsoluteTime(fromDate.timeIntervalSinceReferenceDate) request.to = SRAbsoluteTime(toDate.timeIntervalSinceReferenceDate) if availableDevices.isEmpty { print("No devices available") ambientReader.fetchDevices() } else { for device in availableDevices { print("Starting data fetch (Device: \(device))") request.device = device ambientReader.fetch(request) print("Fetch request sent (Device: \(device))") } } } // MARK: - SRSensorReaderDelegate Methods func sensorReader(_ reader: SRSensorReader, didFetch devices: [SRDevice]) { availableDevices = devices for device in devices { print("Fetched device: \(device)") } if !devices.isEmpty { fetchAmbientDeviceData() } } func sensorReader(_ reader: SRSensorReader, fetching fetchRequest: SRFetchRequest, didFetchResult result: SRFetchResult<AnyObject>) -> Bool { print("sensorReader(_:fetching:didFetchResult:) method called") if let ambientSample = result.sample as? SRAmbientLightSample { let luxValue = ambientSample.lux.value let timestamp = Date(timeIntervalSinceReferenceDate: result.timestamp.rawValue) // Check for duplicate data and add it if !ambientLightData.contains(where: { $0.timestamp == timestamp }) { let dataPoint = AmbientLightDataPoint(timestamp: timestamp, lux: Float(luxValue)) ambientLightData.append(dataPoint) print("Added ambient light data: \(luxValue) lux, Timestamp: \(timestamp)") } else { print("Duplicate data, not adding: Timestamp: \(timestamp)") } // Output data self.displayAmbientLightData(sample: ambientSample) } return true } func sensorReader(_ reader: SRSensorReader, didCompleteFetch fetchRequest: SRFetchRequest) { print("Data fetch complete") if ambientLightData.isEmpty { print("No ambient light data within 24 hours.") } else { print("ambientLightData updated") for dataPoint in ambientLightData { print("Added ambient light data: \(dataPoint.lux) lux, Timestamp: \(dataPoint.timestamp)") } } } }

I’m seeing a regression in Xcode 26.4 where Interface Builder will not allow connecting IBOutlets or IBActions. Symptoms: The usual gutter circle/dot does not appear next to IBOutlet / IBAction in the code editor Because of this, I cannot: drag from storyboard → code drag from code → storyboard The class is valid and already connected to the storyboard (existing outlets work) Assistant Editor opens the correct view controller file Important: The exact same project, unchanged, works perfectly in Xcode 26.3. I can create and connect outlets/actions normally there. ⸻ Environment Xcode: 26.4 macOS: 26.4 Mac Mini M4 Pro 64G Ram Project: Objective-C UIKit app using Storyboards This is a long-running, ObjC, project (not newly created) ⸻ What I’ve already tried To rule out the usual suspects: Verified View Controller Custom Class is correctly set in Identity Inspector Verified files are in the correct Target Membership Verified outlets are declared correctly in the .h file: @property (weak, nonatomic) IBOutlet UILabel *exampleLabel; Opened correct file manually (not relying on Automatic Assistant) Tried both: storyboard → code drag code → storyboard drag Tried using Connections Inspector Clean Build Folder Deleted entire DerivedData Restarted Xcode Updated macOS to 26.4 Ran: sudo xcodebuild -runFirstLaunch Confirmed required platform components installed Reopened project fresh ⸻ Observations In Xcode 26.4 the outlet “connection circles” are completely missing In Xcode 26.3 they appear immediately for the same code Existing connections still function at runtime — this is purely an Interface Builder issue ⸻ Question The gutter circles appearance has always been flaky in Xcode over the 13+ years I've been using it but now with 26.4 they have completely disappeared. Has anyone else seen this in Xcode 26.4, or found a workaround? At this point it looks like a regression in Interface Builder, but I haven’t found any mention of it yet.

I can't seem to find information on this but this is causing a critical bug where the Strong Password suggestion sheet presents on any secure field (UIKit) and clears the others when closing it. This means the user cannot enter a password when there is a secure confirm password field because switching fields clears the other. This looks to be a recent issue but I can't tell when this was introduced or if this is SDK / OS version related. I am finding it in both Xcode 26.2 and 16.4 when running on device (iOS 26.2.1 and XC 26 simulators). Code to reproduce: class ViewController: UIViewController { override func loadView() { let v = UIStackView() v.axis = .vertical v.layoutMargins = .init(top: 16, left: 16, bottom: 16, right: 16) v.isLayoutMarginsRelativeArrangement = true view = v let t1 = UITextField() t1.textContentType = .username t1.placeholder = "Username" v.addArrangedSubview(t1) let t2 = UITextField() t2.isSecureTextEntry = true t2.textContentType = .newPassword t2.placeholder = "Password" t2.clearsOnInsertion = false t2.clearsOnBeginEditing = false t2.passwordRules = nil t2.clearButtonMode = .always v.addArrangedSubview(t2) let t3 = UITextField() t3.isSecureTextEntry = true t3.textContentType = .newPassword t3.placeholder = "Confirm Password" t3.clearsOnInsertion = false t3.clearsOnBeginEditing = false t3.passwordRules = nil t3.clearButtonMode = .always v.addArrangedSubview(t3) v.addArrangedSubview(UIView()) } } No matter what textContentType is used the strong password still forcefully breaks the flow and blocks the user.

We are developing an iOS application that uses the MobileVLCKit framework (version 3.7.3) for RTSP video streaming. We have encountered a critical performance issue that directly affects user experience. Problem Description When the app is granted the Local Network permission (the switch in Apps → OurApp → Local Network), the VLC media player takes 10–15 seconds to start playback after calling play(). If the user manually disables this permission, playback starts immediately (within 1 second). The issue is 100% reproducible on real devices and does not appear on the simulator. What we have tried Adjusting VLC options (network-caching, rtsp-tcp, clock-synchro, etc.) — no effect. Using different RTSP streams (both local and public) — same delay. Checking network logs: the delay occurs before any actual RTSP handshake (DESCRIBE/SETUP), suggesting the system is waiting for something network-related. Why this is critical We cannot instruct our users to turn off Local Network access, because the app also needs this permission for legitimate features (e.g., discovering cameras on the local network). Disabling it permanently is not a viable solution. Request We kindly ask for your guidance: Is there a recommended way to configure the app or the VLC instance to avoid this delay while keeping Local Network permission enabled? Could this be a bug in the permission-handling layer that causes unnecessary timeouts? Are there any entitlements, plist keys, or runtime flags we should use to optimise network access in this scenario? We are happy to provide detailed logs, a sample project, or any other information that could help identify and resolve this issue. Environment iOS: 16.0+ Device: Physical (all) VLCKit: 3.7.3 (integrated via CocoaPods) Xcode: 26.5 Thank you for your time. We look forward to your response.

Hello, Our GAKO Business update has been repeatedly delayed in “Waiting for Review,” despite multiple contacts with Apple Developer Support and an approved expedited review request. App: GAKO Business Version: 1.3.1 Current submission date: July 3, 2026 Current status: Waiting for Review Expedited review: Approved This issue has been ongoing across multiple submissions for approximately one month. We have contacted Apple Developer Support several times and followed up repeatedly under the same support case. However, the current submission has still not entered review. The update contains critical production fixes affecting existing App Store users. GAKO Business is used by real businesses to manage appointments, employees, schedules, services, and customer records. The currently published version contains issues affecting essential business workflows, while the corrected version remains unavailable. Apple has confirmed that the application was placed in the expedited review queue. However, it remains in “Waiting for Review.” We are not asking Apple to bypass the App Review Guidelines. We would like Apple to verify whether the submission is affected by an internal routing issue, technical hold, or another submission-level problem. Has anyone experienced the same situation where expedited review was approved, but the application remained in “Waiting for Review”? If Apple staff sees this post, we would greatly appreciate assistance in checking the submission. Thank you.

I have filed a bug report for this (FB17734946), but I'm posting it here verbatim in case others have the same issue and in hopes of getting attention from an Apple engineer sooner. When calling setNeedsDisplayInRect on a CATiledLayer - or a UIView whose backing layer is CATiledLayer - one would expect to re-draw only a region identified by the rect passed to the method. This is even written in the documentation for the class: "Regions of the layer may be invalidated using the setNeedsDisplayInRect: method however the update will be asynchronous. While the next display update will most likely not contain the updated content, a future update will." However, upon calling this method, CATiledLayer redraws whole contents instead of just the tile at the specified rect, and it flashes when doing so. It behaves exactly the same as if one had called setNeedsDisplay without passing any rect; all contents are cleared and re-drawn again. I'm 100% sure I've passed in the correct rect of the exact tile that I need to redraw. I have even tried passing much smaller rects, but still the same. (And yes, the rect I've passed accounts for the current level of detail.) I have found this GitHub repo https://github.com/frankus/NetPhotoScroller, which based on discussion from here https://forums.macrumors.com/threads/catiledlayer-blanks-out-tiles-when-redrawing.1333948/ aims at solving these issues by using two private methods on CATiledLayer class: (void)setNeedsDisplayInRect:(CGRect)r levelOfDetail:(int)level; (BOOL)canDrawRect:(CGRect)rect levelOfDetail:(int)level; I have explored the repo in detail, however I wasn't able to test exactly this code from the GitHub repo. I have tried using those two private methods myself (through an Objective-C class that defines the methods in the header file and then a swift class which inherits it), but I couldn't solve the issue; the flashing and the full re-draw is still there. After doing a lot of research, the conclusion seems to be that one cannot use CATiledLayer with contents that are downloaded remotely, on demand, as tiles are being requested. I have, however, found one interesting thing which seems to work so far: before calling setNeedsDisplayInRect (or just setNeedsDisplay, as they behave the same for CATiledLayer in my testing), cache the current layer's contents, and after calling setNeedsDisplay (or setNeedsDisplayInRect), restore the contents back to the layer. This prevents flashing and preserves any tiles that were drawn at the time of the re-draw. let c = tiledLayer.contents tiledLayer.setNeedsDisplay(tileRect) tiledLayer.contents = c However! Docs clearly state the warning: Do not attempt to directly modify the contents property of a CATiledLayer object. Doing so disables the ability of a tiled layer to asynchronously provide tiled content, effectively turning the layer into a regular CALayer object. I believe this message implies modifying the contents property with some raw content, like image data, and that it may be safe to re-apply the existing contents (which are in my testing of type CAImageProvider) -- but I can't rely on an implementation detail in my production app. I have tested this and confirmed that the bug appears on: iPhone 14 Pro, iOS 18.5 iPhone 13 Pro, iOS 17.5.1 iPhone 5s, iOS 15.8.3 iPad Pro 1st gen, iPadOS 18.4.1 a couple simulator versions I can also confirm that the fix (to re-apply contents property) is also working properly on all these versions. Is this expected behavior, that tiled layer redraws itself entirely instead of redrawing specific tiles? Is it safe to modify contents of a CATiledLayer by re-applying the existing contents? If not, is there an alternative to avoid flashing?

Has Apple ever offered the final public release of an OS to a limited group of Developer Beta users before the official public rollout? I've also heard claims that these early releases or invitations are only sent to owners of Pro models (for example, iPhone Pro models). Is there any official information confirming this, or is it just a rumor? I'd appreciate clarification from anyone familiar with Apple's release process.

We root-caused a launch crash that only affects ARCHIVED builds (Run/Debug works, simulator works) and filed it as FB23528109. Posting the details here because the crash signatures are hard to search for and other teams are likely to hit this as they adopt Swift 6.3 toolchains. SYMPTOM The archived app crashes before main() on device, on every launch. Depending on which orphaned pointer gets read first, the crash looks like one of these: EXC_BREAKPOINT, "pointer authentication trap DA", inside swift_conformsToProtocolMaybeInstantiateSuperclasses / _searchConformancesByMangledTypeName (often with a Firebase or other +load frame below it; that frame is just the first conformance scan at launch, not the cause) EXC_BAD_ACCESS KERN_INVALID_ADDRESS at a small, raw unslid address (e.g. 0xc118), inside dyld: resolveRebase <- objc_visitor::forEachClass <- dyld4::PrebuiltObjC::make Debug builds, simulator builds and Xcode Run builds are all fine, because the corruption happens in the Strip build phase, which only runs for Archive/install builds. ROOT CAUSE (two defects combine) strip -S -T (what Xcode runs on embedded frameworks during Archive when STRIP_SWIFT_SYMBOLS = YES) corrupts dyld chained fixups. When strip removes a Swift weak-definition symbol that has a GOT bind, it converts the bind into a rebase to the local definition (correct) but writes the converted entry with next = 0 (incorrect). That terminates the 16 KB page's fixup chain early, and every fixup after the converted slot in the same page is orphaned: dyld never processes it, so raw chain-encoding bytes get read as pointers at launch. The bug is present in every strip we tested: Xcode 26.3, 26.4, 26.4.1, 26.5, 26.6 and 27.0 beta 2. strip -S and strip -S -x (without -T) do not corrupt. Starting with Swift 6.3.0 (Xcode 26.4.0), the compiler emits the trigger pattern for ordinary code: cross-module references to a non-final class's stored-property accessors become weak-def-coalesce binds (Swift 6.2.4 emits none). So apps that embed a multi-module Swift dynamic framework (e.g. an SPM package built as one dynamic framework) started getting corrupted by their own default Archive pipeline when they moved past Xcode 26.3. HOW TO CHECK IF YOU ARE AFFECTED Compare the fixups of a framework binary inside your archive against a Run build of the same code: xcrun dyld_info -fixups YourApp.app/Frameworks/YourKit.framework/YourKit If fixups that exist in the Run build are missing after the archive's strip step (in particular __got slots and anything after them in the same 16 KB page), you are affected. Also: any GOT bind of a Swift ($s...) symbol in the pre-strip binary is a red flag. WORKAROUND Set STRIP_SWIFT_SYMBOLS = NO (optionally STRIP_STYLE = non-global, i.e. strip -S -x, which kept the size cost to about +4% for us). Important: if the affected framework is a Swift package product, these must be passed as xcodebuild command-line overrides (e.g. xcodebuild ... STRIP_SWIFT_SYMBOLS=NO STRIP_STYLE=non-global); xcconfig files do not apply to package targets. REPRO FB23528109 contains a complete minimal reproducer (4 small C files + 1 trivial Swift file, no proprietary code): a 30-second CLI script whose host binary segfaults through an orphaned pointer, and a default-settings Xcode project whose Run build works while its archived build crashes pre-main on device, identically for archives produced by Xcode 26.3.0, 26.4.0 and 26.6 (crash logs for each attached in the FB). Happy to share more details from the investigation if anyone is debugging the same signatures.

On the IOS 27.0 on my IP 16PM, I see it reduce heat significantly and after the next update, I see many bugs like keyboard stuck on tiktok app and heat more than 27.0. May I know it is the tiktok app issue or bug?

I create a Live Activity remotely via push-to-start, then use its per-activity token (Activity.pushTokenUpdates) so my server can send update/end pushes. To make sure I'm not missing tokens, I observe Activity.activityUpdates and prime from the Activity.activities snapshot at launch and on sceneWillEnterForeground, then subscribe each activity's pushTokenUpdates and POST the token to my server. This works reliably while the app is running or backgrounded/suspended — the system wakes it and I capture the token. The problem is the user force-quit case (swiped from the App Switcher, never reopened): Push-to-start still creates the Live Activity and it renders correctly on the Lock Screen. But pushTokenUpdates never fires, so my server never receives the per-activity token and can't update or end that activity. A backgrounded (not force-quit) app, as a control, captures the token every time. So it seems specific to user-termination rather than all "not running" states. I understand force-quit apps generally aren't granted background runtime — I'm trying to confirm whether that applies here and what the right pattern is. What's the recommended approach? Specifically: Is there any supported way to get the per-activity token to my server while the app stays force-quit — e.g. from the widget extension (does it have any access to Activity.pushToken, or only ActivityViewContext?) or a Notification Service Extension? 2. If not, is setting stale-date on the start push the intended way to let the card expire gracefully when it can never be ended via push? 3. Is there a better pattern for keeping a push-started Live Activity correct when the app is never relaunched?

Hi, I'm trying to figure out what is true here - if I am not in the correct forum please direct me :-) A. It is not possible to test a QR code scan that contains a deeplink into my iOS app from an XCoode build test run. In other words, The build must be published to Test Flight for the iOS's QR code scan sub-system to be able to process the deeplink into my app? If I am wrong about this, it sure would help with testing to be able to test directly from the local XCode build test. If so, can someone point me in the direction of what I would need to do for that? Thanks for your input either way!

Hi everyone, I've been working on an application that provides different subdomains for different customers, so we need to support app linking with all of them. However, using wildcard notation like applinks:*.domain.com doesn't work, while hardcoding applinks:subdomain.domain.com works fine. The association file is being served from both the main domain and subdomains. It used to work fine about a month ago, and I can't find any recent breaking changes on Apple's side . Any ideas why this could happen. ?

Im unable to deploy Xcode 27 beta code to an iPhone 17 pro The build is successful but its not loading

I’m debugging a custom BLE HID device on iPhone. It is a composite HID mouse + keyboard dongle. Setup: Hardware: Seeed XIAO nRF52840 Firmware: Adafruit Bluefruit Arduino / BLEHidAdafruit BLE HID report map: stock Adafruit composite HID with keyboard, consumer, and mouse reports GAP/advertising appearance: HID_MOUSE iOS adopts the device as an AssistiveTouch pointer Mouse movement and clicks work correctly Keyboard symptom: Lowercase/unshifted characters type correctly. Shifted characters lose the Shift modifier during text input: - A -> a - T -> t - DoorDash -> doordash - ! -> 1 - @ -> 2 - # -> 3 - { -> [ - } -> ] Confirmed: The iOS app sends the exact intended string to the dongle. Firmware receives the exact string. Firmware computes and sends the expected HID modifier/keycode: A sends modifier 0x02 + HID_KEY_A ! sends modifier 0x02 + HID_KEY_1 A lone isolated "A" still lands as "a", so this does not appear to be a timing or repeated-key issue. Cmd+Space works from the same HID keyboard report path and opens Spotlight. Full Keyboard Access is off. Turning AssistiveTouch off does not fix it. The iPhone never shows "Hardware Keyboard" settings for this device, even when searching Settings. Question: Is there a documented distinction on iOS between accepting BLE HID keyboard reports for global shortcuts, such as Cmd+Space, and admitting the same device as a full Hardware Keyboard for text composition? In particular: Does the absence of Hardware Keyboard settings mean iOS has not classified the device as a real external keyboard? Can a composite BLE HID device advertised as HID_MOUSE be accepted for pointer input but have Shift ignored for text input? Does iOS require a different GAP appearance, HID report-map structure, report ordering, or separate keyboard identity for Shift/modifier text composition to work? Is there a recommended way to build a BLE HID device that preserves AssistiveTouch pointer behavior while also being treated as a full external keyboard?

Dear Apple Developer Support, I am developing and maintaining an iOS application. In iOS 26, we understand that setting UIDesignRequiresCompatibility to true in the Info.plist file allows an app to opt out of the Liquid Glass design. However, we also understand that during WWDC25 Platforms State of the Union, Apple stated: "We intend this option to be removed in the next major release." We would appreciate clarification on the following points. Questions Should the phrase "next major release" be interpreted as iOS 27? Is it currently Apple's plan to make UIDesignRequiresCompatibility unavailable or remove it in iOS 27? Or is the statement above only an intended direction, with the actual removal schedule still subject to change? If there is any publicly shareable information regarding the future availability or deprecation timeline of UIDesignRequiresCompatibility, could you please provide it? Background We develop and maintain a business application that contains a large number of custom screens and UI components. Adapting the entire application to the Liquid Glass design system will require significant design review, implementation effort, and testing. As a result, the future availability of UIDesignRequiresCompatibility is a critical factor in our development planning and resource allocation. For this reason, we would greatly appreciate any guidance you can provide regarding Apple's current plans for this compatibility option. Thank you for your time and assistance. Best regards, Toshiyuki

Hello App Review Team, I'm hoping someone can take a manual look or point me in the right direction. The iOS build of my app has been sitting in "Waiting for Review" with no status change, while the macOS and tvOS builds of the exact same version have already been reviewed and released. App: VixioTV - IPTV & M3U Player App ID: 6763137740 Platform: iOS (iPhone/iPad) Current status: Waiting for Review Most recent submission: [June 24, 2026] Time in queue: ~24 days with no status change Related case IDs: [your expedited review / Developer Support case numbers] Context I'd like to share proactively: This is an update to an app that is ALREADY LIVE on the App Store (current iOS version 1.2). It is not a new app. The macOS and tvOS versions of this same update have already passed review and are live — only the iOS build is stuck. VixioTV is a bring-your-own-content player: it provides no broadcasts or content of its own. Users connect their own IPTV subscription (API credentials or an M3U URL). There is no registration, subscription, or content sale inside the app. I have submitted expedited review requests and contacted Developer Support, but I've only received generic/automated replies with no change in status. I would really appreciate it if someone could: Confirm whether there is any issue with the build, metadata, agreements, or account that requires action on my side. Indicate whether this is queue congestion or a submission-specific hold. If possible, escalate or trigger a manual review. Thank you very much for your help. Selcuk Kaymaz

My iPhone 14 Pro (running iOS 27 beta 1) is not booting after discharge of battery (due to not being used for about 10 days). How to restart and update to beta 2 or use it otherwise? I have kept it connected to wall outlet charger for the past 2 hours, and have tried Forced restart (press and quickly release the Volume Up button, press and quickly release the Volume Down button, then press and hold the Side (Power) button until the screen goes black and the Apple logo appears). But nothing works, and the iPhone remains dead.

I’m seeing a Bluetooth call audio routing issue on a new iPhone 17 Pro running iOS 26.5.1, build 23F81. Bluetooth media audio works normally. Music and video audio stay on Bluetooth headphones without issues. The problem appears only when the device switches into call audio / HFP mode. Tested with multiple earbuds: Samsung, OPPO, Huawei and CMF Buds Pro 2. The behavior is similar with all of them. There are no other Bluetooth devices connected. Call Audio Routing is already set to Bluetooth Headset in Accessibility settings. The issue affects cellular calls, FaceTime Audio, Telegram and Signal. In some cases the earbuds seem to switch into call mode, but the call audio route falls back to the iPhone receiver or speaker instead of staying on the Bluetooth headset. After the call ends, Bluetooth media audio returns normally. I captured a sysdiagnose right after reproducing the issue. Relevant observations from the logs: Device: iPhone18,2 iOS: 26.5.1 Build: 23F81 Sysdiagnose time: 2026-06-03 11:22:03 +0300 In Bluetooth/CoreCapture/bluetooth_status.txt, Bluetooth was ON 3 paired devices were present 1 device was connected Connected device at the time: CMF Buds Pro 2 So the headset was not simply disconnected from the phone. In the powerlog, before the call the audio route was HeadphonesBT for media playback. Around the FaceTime Audio test, HeadsetBT / PhoneCall appeared, but then the route moved to ReceiverAndMicrophone / Speaker instead of staying on HeadsetBT. During a later cellular call, the active PhoneCall route was also ReceiverAndMicrophone rather than HeadsetBT. After the call ended, the route returned to HeadphonesBT for media playback. This looks like the Bluetooth connection remains alive, but call audio / HFP routing fails. The same sysdiagnose also contains CentauriFirmwareEvent entries under crashes_and_spins from the previous day. They show: subsystem = BT host-reason = firmware crash BTMAIN panic faulting_task = link_manager_thread LMAC_5G watchdog expired SCAN watchdog expired These firmware crash events do not happen at the exact same timestamp as the call test, so I’m not claiming that every call directly crashes Bluetooth firmware. But the sysdiagnose shows both incorrect Bluetooth call audio routing and separate BT firmware crash events. Has anyone seen similar behavior on iPhone 17 / iOS 26 with Bluetooth HFP call audio? Could this be a known iOS 26 / Apple N1 / Bluetooth firmware issue, or does it look more like a hardware defect of this particular device?