Device: iPhone 17 Pro 256GB Affected builds: • iOS 27 RC — 24A435 • iOS 27 public release — 24A437 Known working version: • iOS 26.7 DESCRIPTION I am seeing a reproducible total loss of touchscreen input on this specific iPhone 17 Pro when running iOS 27. Before today's test, the device was running iOS 26.7 and the touchscreen was working normally. On September 14, I updated through the official OTA Software Update to iOS 27.0 public release, build 24A437. Beta Updates were disabled. After the update completed, the iPhone booted normally and reached the Hello screen. The display renders normally. Physical buttons respond normally. However, all touchscreen input is completely unavailable. No taps or swipes are recognized anywhere on the display, so it is not possible to proceed past the Hello screen. REPRODUCIBLE ON IOS 27 RC The exact same behavior previously occurred on iOS 27 RC build 24A435. To eliminate backup corruption, user data, apps and settings as possible variables, I performed a complete clean restore of 24A435 using Apple Configurator. No backup was restored. No apps were installed. No user data was restored. No previous settings were restored. Immediately after the clean restore, at the initial Hello screen, touchscreen input was still completely unavailable. Restoring the same device back to iOS 26 immediately restored touchscreen functionality. REPRODUCTION HISTORY iOS 26.7 → Touchscreen works normally iOS 27 RC 24A435 → Touchscreen completely unresponsive after boot Clean restore of 24A435 → Touchscreen still completely unresponsive at the initial Hello screen Restore back to iOS 26 → Touchscreen functionality returns iOS 27 public 24A437 → Touchscreen completely unresponsive again after boot DIAGNOSTICS Apple has already performed: • Remote diagnostics — passed • MRI — passed • Multi-Touch diagnostic — passed None of these diagnostics detected a hardware failure. The issue was reported through Feedback Assistant before the public release: Feedback ID: FB24728805 I also have an active Apple Support case, and the device is being evaluated by an Apple Authorized Service Provider. QUESTION / TECHNICAL OBSERVATION The particularly unusual aspect is the repeatability across OS versions on the same physical device: iOS 26 → touch works iOS 27 → touch does not work iOS 26 → touch works again iOS 27 → touch does not work again I am not assuming that the root cause is purely software or purely hardware. I am interested in whether this could involve touchscreen/HID initialization, digitizer-related firmware, or an interaction between iOS 27 and a particular hardware/display/controller revision. Has anyone observed a similar condition where: • the display continues rendering normally; • physical buttons continue working; • all touchscreen input is lost immediately after booting iOS 27; • a clean restore of iOS 27 does not resolve it; and • restoring the same device to iOS 26 restores touchscreen functionality? If anyone has reproduced this on another iPhone 17 Pro or 17 Pro Max, the exact model and iOS build would be particularly useful. RELATED PUBLIC DISCUSSIONS Apple Support Community: https://discussions.apple.com/thread/256356702 MacRumors: https://forums.macrumors.com/threads/iphone-17-pro-touchscreen-completely-dead-on-ios-27-public-24a437-same-issue-on-rc-24a435.2489323/

I am trying to understand one supported iOS lifecycle guarantee. Consider a generic app that stores a single SQLite database in its private Library/Application Support directory and keeps one SQLite connection open while its process is alive. During a supported platform operation such as iCloud restore that continues after setup, Finder or Apple Devices restore, Quick Start direct transfer, Quick Start using iCloud, reinstall or offload recovery, or an app update, can the app become or remain running, background executing, or suspended while iOS restores, replaces, or rebinds its data container or a file within it? More specifically, can an existing open file descriptor or SQLite connection continue to reference an old filesystem object while a later lookup of the same Application Support path resolves to a restored or replacement object? If iOS does not permit that condition, what supported lifecycle invariant prevents it? For example, does iOS terminate the app before restored data becomes visible, gate launch until the complete per-app restored container is finalized, or keep the container binding stable for the lifetime of the process? If the behavior differs by mechanism, please distinguish iCloud restore after setup, Finder or Apple Devices restore, Quick Start direct transfer, Quick Start using iCloud, reinstall or offload recovery, and app update. • Does the platform's restore ordering depend on SQLite locks? • Does NSFileCoordinator participate when platform services restore private Application Support files? • Is there Apple documentation or an Apple-staff explanation that defines this ordering, including supported versions, conditions, or exceptions? The POSIX issue is that an open descriptor may continue to reference an old object after pathname replacement while a new lookup reaches a different object. SQLite also documents risks when an open database file is renamed or unlinked. I am not treating a raw rename or unlink test as equivalent to an Apple restore. I am explicitly excluding arbitrary unlink, rename, overwrite, or other direct same-container filesystem attacks. My question is only whether Apple's supported restore and container services can create an equivalent old-open-object versus newly-resolved-path condition while the same app process survives.

. The three entries LastMDMMigratedBuild Build identifier Records the last iOS build associated with an MDM migration. MDM means Mobile Device Management, a system organisations can use to configure and manage devices. LastMigratedBuild Records the last build associated with a migration. It matches the MDM migration build recorded above. StopFilteringGrandfatheredRestrictions This is a Boolean setting. Its name suggests it controls filtering of older, existing restrictions. file system xml version="1.0" encoding="UTF-8"?> ANYTHOUGHTS OF WHAT THIS IS.

Hello everyone! I'm just starting with iOS. I've been browsing through all the videos, but it's a bit overwhelming because there are just so many. Does anyone have a must-watch video recommendation? I'm looking for one of those mind-blowing videos that makes you think, 'I wish I had watched this sooner because it makes everything so much easier!

We can reproduce an AlarmKit audio failure on iPhone 16 Plus / iOS 26.6.2 (23G90) with a reduced SwiftUI app using fixed-date alarms and .default sound: Schedule three alarms at +60, +180 and +300 seconds. Leave the app visible and the phone untouched. The first alarm sounds. When the +180 alarm triggers, the +60 alarm is silenced (but still active). When the +300 alarm triggers, all three alarms will remain silent, however alarmUpdates reports one, then two, then three .alerting IDs. A single alarm in the same binary sounded continuously for at least 3 minutes 30 seconds. The reduced app has no custom intents, widget, countdown/snooze, audio session, background modes, notifications, packages or automatic cancellation. This exact reduced binary has one recorded comparison; earlier harness configurations also exhibited the failure. Sound was observed by the tester, separately from API logs. When +180 mutes +60, stopping the +60 alarm causes the +180 alarm banner to present itself and become audible. +300 triggering will then mute the +180 alarm. Likewise, stopping the +180 alarm will cause the +300 alarm to present itself and become audible. If you allow +60, +180, and +300 alarms to trigger without touching the screen, all three alarms will be silent at this point. Pressing "Stop" on +60 will cause the +180 banner to present itself and become audible, "Stop" on +180 will cause +300 alarm to then present and become audible. It is for these reasons that I believe there is a bug that occurs when an additional queued alarm transitions from "scheduled" to "active" status that causes the present active alarm to silence. In a foreground harness run, programmatically cancelling the +60 alarm's alerting ID caused the +180 alarm to sound. However that requires app execution and does not establish a background solution. The snooze/coincident-time report looks like it could be related. The FAQ's same-time scheduling answer also seems to describe a different case. What is the supported audio behavior when a later alarm becomes due while an earlier one remains alerting? Is there a scheduling or handoff pattern that preserves audible delivery without requiring the app to execute at each arrival? If overlap is unsupported, which documented constraints should applications follow? If anyone else has experienced this issue and has found a technical workaround I would appreciate hearing about it. For any Apple staff reading this, there is more information on this issue in Feedback Assistant ID FB24757864.

Hi, for anyone who is working with LiveActivities and is running a beta of iOS 27, has apple made the ability for LiveActivities to be vertically larger and display more content as they appear in some of the demo images, or are these LiveActivities like the ones in the pictures above just system specific that is only available to apple.

I’m seeing inconsistent right-to-left behavior when using the new SwiftUI swipeActionsContainer() API with a ScrollView. The swipe-action buttons are positioned correctly according to the layout direction, but the gesture direction itself is not mirrored. Minimal reproducible example: import SwiftUI struct ContentView: View { var body: some View { ScrollView { LazyVStack { Text("Hello, World!") .padding() .frame(maxWidth: .infinity) .background(.blue.quinary) .swipeActions { Button(role: .destructive) { // Delete action } label: { Label("Delete", systemImage: "trash") } } } .padding() } .swipeActionsContainer() } } Steps to reproduce: Run the example using a left-to-right language such as English. Swipe the row from right to left. The trailing swipe actions appear correctly. Change the app language to Arabic. Swipe the row from left to right, which should reveal the trailing actions in an RTL layout. Nothing happens. Swipe from right to left instead. The actions appear, but from the correct visually mirrored edge. Expected behavior: Because the default swipe-action edge is .trailing, both the action placement and the gesture direction should follow the current layout direction: English/LTR: swipe from right to left. Arabic/RTL: swipe from left to right. Actual behavior: The action buttons visually respect the RTL layout, but the gesture recognizer still requires the LTR swipe direction. Environment: Xcode: 27.0 RC iOS: 27.0 RC Device: iPhone 17 Swift language version: Swift 6

Symptom: chart (bar chart at least) doesn't snap to beginning of a bar mark when specified with chartScrollTargetBehavior. It could stop anywhere in a bar mark. In the following reproduction, I'm using a bar chart with x values being Date objects, and y values being Double. I attached a ProbeBehavior which runs ValueAlignedChartScrollTargetBehavior(matching: DateComponents(hour: 0), majorAlignment: .page)'s updateTarget, but with some debug info printed out. So essentially, I'm running .chartScrollTargetBehavior(.valueAligned(matching: DateComponents(hour: 0), majorAlignment: .page)). Minimal reproduction import SwiftUI import Charts @main struct ChartSnapApp: App { var body: some Scene { WindowGroup { TestChart() } } } private struct TestChart: View { let calendar: Calendar = .current @State private var scrollX = Date.now var body: some View { let half = 42 let today = calendar.startOfDay(for: .now) let start = calendar.date(byAdding: .day, value: -half, to: today)! let end = calendar.date(byAdding: .day, value: half, to: today)! VStack { Text("Scroll: \(scrollX.formatted(.iso8601)) | secondsFromMidnight: \(scrollX.timeIntervalSince(calendar.startOfDay(for: scrollX)), specifier: "%.3f")") .font(.caption).accessibilityIdentifier("scrollReadout") Chart { ForEach(0 ..< half * 2, id: \.self) { offset in let date = calendar.date(byAdding: .day, value: offset, to: start)! BarMark(x: .value("Date", date, unit: .day), y: .value("Value", 1.0)) } } .chartXScale(domain: start ... end) .chartXVisibleDomain(length: 7 * 24 * 3600) .chartYScale(domain: 0 ... 3) .chartScrollableAxes(.horizontal) .chartScrollTargetBehavior(ProbeBehavior()) .chartScrollPosition(x: $scrollX) .onChange(of: scrollX) { _, new in print("SCROLL \(new.formatted(.iso8601)) secondsFromMidnight=\(new.timeIntervalSince(calendar.startOfDay(for: new)))") } .environment(\.calendar, calendar) .padding(.all, 12) .accessibilityIdentifier("chart") } } } private struct ProbeBehavior: ChartScrollTargetBehavior { func updateTarget(_ target: inout ScrollTarget, context: ChartScrollTargetBehaviorContext) { let before = target.rect let orig = context.originalTarget.rect let beforeDate: Date? = context.chartProxy.value(atX: before.minX) let origDate: Date? = context.chartProxy.value(atX: orig.minX) ValueAlignedChartScrollTargetBehavior(matching: DateComponents(hour: 0), majorAlignment: .page).updateTarget(&target, context: context) let afterDate: Date? = context.chartProxy.value(atX: target.rect.minX) let domain = context.chartProxy.xDomain(dataType: Date.self) let zero = context.chartProxy.value(atX: 0, as: Date.self) let todayPosition = context.chartProxy.position(forX: Calendar.current.startOfDay(for: .now)) let line = "PROBE calendar=\(Calendar.current.identifier) timezone=\(Calendar.current.timeZone.identifier) plotSize=\(context.chartProxy.plotSize) xDomain=\(domain) valueAtZero=\(String(describing: zero)) todayPosition=\(String(describing: todayPosition)) velocity=\(context.velocity) originalRect=\(orig) beforeRect=\(before) afterRect=\(target.rect) originalDate=\(String(describing: origDate)) beforeDate=\(String(describing: beforeDate)) afterDate=\(String(describing: afterDate))\n" print(line) let url = URL.documentsDirectory.appending(path: "probe.log") if !FileManager.default.fileExists(atPath: url.path) { FileManager.default.createFile(atPath: url.path, contents: nil) } if let handle = try? FileHandle(forWritingTo: url) { handle.seekToEndOfFile() handle.write(Data(line.utf8)) try? handle.close() } } } Comparing video, left iOS 26.5 simulator, right iOS 27.0 simulator https://jumpshare.com/s/SVdDV27qHlXdbxMp8mWA

Will iOS 27 still communicate with Mac Ventura (like iOS 26 does)? I am wondering if someone knows and can give first hand knowledge from beta on this issue in regards to iOS 27 that should come out later this year. Thank you.

Feedback submitted: FB24460699 The sample projects are attached to the feedback report. Environment:iOS27 Beta6; iPhone 17Pro Problem:I have encountered a consistently reproducible third-party custom keyboard layout issue in iOS 27.0 beta 1 through beta 6. The custom keyboard initially appears correctly. If I switch apps while the text input remains focused and the keyboard remains visible, and then return to the host app, the system adds a 17-point area above the custom keyboard extension. Steps to reproduce Install and enable a third-party custom keyboard. Switch to the sample custom keyboard and open the host app so that the text editor in the center receives focus. Do not dismiss the keyboard or remove focus from the editor. Return to the Home Screen or switch to another app. Return to the host app. A new blank area now appears above the custom keyboard content. I tested both a system-determined extension view height and an extension view explicitly constrained to 180 points. Both configurations produce exactly the same change. After the foreground transition, the following extension-side values remain unchanged: view.bounds inputView.bounds extension.window.bounds view.safeAreaInsets, which remains {0, 0, 0, 0} The requested 180-point extension height Only the system keyboard frame received by the host app increases by 17 points. I also drew a rounded pink boundary inside the transparent extension root view. When the issue occurs, the new area appears outside that boundary. I tested several third-party keyboards and reproduced the issue with all of them. This suggests that the behavior is caused by iOS rather than by my app. Questions On iOS 27, is it expected behavior for a custom keyboard to gain a 17pt top area after its host app returns from the background? If this is a system issue, is there any workaround that can be used until it is fixed?

I’m seeing a layout issue in SwiftUI on iOS 26 that only reproduces with specific Accessibility Motion settings. Steps to reproduce 1. Open Settings → Accessibility → Motion. 2. Enable Reduce Motion and Prefer Cross-Fade Transitions. 3. Launch an app with a SwiftUI TextField. 4. Tap the field to show the keyboard. 5. Dismiss the keyboard (tap outside, swipe down, etc.). Expected: After the keyboard is dismissed, the view’s bottom safe area / layout should return to normal. Actual: The view continues to reserve space equal to the keyboard height — as if the keyboard were still visible. UI anchored to the safe area remains shifted upward until the view is reloaded.

Hello, Apple! I accidentally uploaded a version with a critical bug. Apple, please accept my new version—it’s urgent. Thank you very much.

I found a SwiftUI presentation bug with multiple alerts and sheet presentations. I submitted a Feedback Assistant report too: Feedback ID: FB24621651 The issue is that a native SwiftUI alert dismisses immediately after appearing when it is presented from a view inside a nested sheet. Minimal hierarchy: TabView -> NavigationStack -> outer sheet -> NavigationStack -> detail view -> inner sheet -> alert The inner sheet contains a normal button: struct InnerSheetRoot: View { @State private var showAlert = false var body: some View { Button("Show Alert") { showAlert = true } .alert("Alert from inner sheet", isPresented: $showAlert) { Button("OK") {} } message: { Text("This alert should remain visible.") } } } Steps to reproduce Open the attached sample project. Select the Storage tab. Tap any storage row. In the outer sheet, tap Open Inner Sheet. In the inner sheet, tap Show Alert. Actual result The alert appears briefly and dismisses immediately. It may disappear before OK can be tapped. Expected result The alert should remain visible until the user taps OK. The issue disappears when I remove either the root TabView or the second NavigationStack. It also disappears when the inner sheet is removed. Environment: Xcode: Xcode 26.6 macOS: macOS 26.6.2 iOS: iOS 26.5 Device or simulator: iPhone Simulator Deployment target: iOS 26.0 Swift version: Swift 6 The example project and a screen recording are attached to the Feedback Assistant report, but they can also be found here. I would appreciate confirmation of whether this is a known SwiftUI presentation-host issue and whether there is a recommended way to present alerts from content inside nested sheets.

Inquiry) A Linux-based embedded device is connected to an iPhone using a USB-C cable. The device operates as a USB device and presents a standard CDC-ECM Ethernet interface. The iPhone operates as the USB host. When the iPhone screen is on: 以太网接口被正确识别。 分配IPv4和IPv6地址。 互联网接入正常。 大约在 iPhone 被锁定 30 秒后，USB 连接进入暂停状态，以太网数据传输停止。 我们启用了USB远程唤醒。定期触发它有助于保持以太网接口的可用，当 iPhone 屏幕开启时网络会恢复。然而，屏幕关闭时以太网数据仍然无法保持活跃状态。 问题） 这在iOS上是正常的行为吗？ 有没有支持的方法可以在 iPhone 锁定时保持 USB 以太网数据活跃？ USB远程唤醒是否支持输入网络流量？ 助理在恢复后是否需要发送任何CDC链接通知？ 这需要支持MFi还是特定的iOS权限？ 谢谢。

I am using an 11-inch M4 iPad Pro. I first noticed severe battery drain while the iPad was idle. After checking the device, I found that several unrelated functions had stopped working at the same time: Front and rear cameras show a black screen Face ID does not work LiDAR does not work Flashlight does not work Apple Pencil is not detected, paired, or charged through the magnetic charging area Apple Diagnostics at the Genius Bar also reported failures involving the front camera, rear camera, Face ID, and LiDAR. I was told at the Genius Bar that, because the device is outside the standard warranty period, it would be treated as an out-of-warranty hardware failure and would not qualify for free repair. There has been no drop or liquid damage. I have already performed multiple force restarts, updated iPadOS, and factory-reset the device several times, but the symptoms remain unchanged. What seems unusual is that several functionally separate systems became unavailable at nearly the same time, together with severe standby battery drain. Because of that, I am wondering whether this could be related to embedded software, firmware, power management, or low-level hardware control rather than several independent hardware components coincidentally failing at once. Has anyone seen a similar issue on an M4 iPad Pro, or is there any known firmware or system-level failure that could cause this pattern?

Hello, I am very new to programming for iPhone, so please excuse me if this question is ignorant and I'm missing something silly. I am trying to build an app for my phone (iPhone SE 3rd gen) using my Macbook Air (same Apple Account). I downloaded XCode and started with the default "Hello World!" template. I created a personal team and figured out all the settings on my phone (trusted the computer, turned on developer mode, trusted the account). However, after uploading, I get the following error: The weird part is that I have a stable internet and cell connection. Following the instructions given to me in the similar error on my Mac, I head to General -> VPN and Devices -> my account and click "Verify App". This gives me a pop-up: Clicking Verify, it loads for a second and absolutely nothing happens. Not sure how to proceed or what's wrong.

Hi everyone, I’m looking for external TestFlight testers for Personal Finance, a SwiftUI app for managing accounts, payment cards, investments, and personal budgets in one place. The app does not connect to banks. Users enter and manage their financial information manually, and the data remains on the device. The current beta includes: • Account, card, and investment balance tracking • Personal budget calculations with recurring and one-time items • Automatic balance updates for card payments • Home Screen widgets for balances and budgets • Direct links from widgets to the relevant editing views • Optimized layouts for both iPhone and iPad • Finnish and English language support I would especially appreciate feedback on: • Overall usability and clarity • Calculation accuracy • Adding and editing financial information • Widget installation and behavior • iPad layouts in portrait, landscape, and Split View • Missing features or confusing workflows • Crashes, data issues, and visual bugs Public TestFlight link: https://testflight.apple.com/join/BZgZNnhn Feedback can be submitted directly through TestFlight. Thank you to anyone willing to try it and share their experience.

I'm encountering an issue with front camera video recordings via browser (Safari/Chrome) on devices running iOS/iPadOS 18 and above: On iPad, the recorded video appears upside down. On iPhone, the recorded video is rotated 90 degrees. The rear camera functions correctly without orientation issues. This problem seems specific to browser-based recordings, as the native Camera app records videos with the correct orientation. Has anyone else experienced this behavior? Is there a known workaround or fix? The preview while recording is fine, the recorded video is oriented incorrectly.

I’m building a SwiftUI app that fetches public JSON data using URLSession.shared. The request works correctly in the iPhone 17 Pro Max Simulator, but fails on my physical iPhone 16 Pro Max running iOS 27 beta. Endpoint: https://api.jolpi.ca/ergast/f1/2026/driverstandings.json?limit=100 Error: NSURLErrorDomain Code=-1009 “The Internet connection appears to be offline.” NWPath: unsatisfied (Denied over Wi-Fi interface) Resolved 0 endpoints in 1ms The device can access the endpoint through Safari, and the same request works in Simulator. VPN, cellular permissions, Wi-Fi changes, and ATS settings have been checked. Could this be an iOS 27 beta networking regression affecting URLSession on physical devices? Are there recommended workarounds or diagnostics?

Feedback: FB24659815. I have submitted a screen recording and screenshot through Feedback Assistant. In GGame, quickly swiping back after opening a game home page with the system SwiftUI zoom transition leaves the destination navigation title, back button, settings button and history button over the visible lobby for about one second. During that interval, lobby content does not respond to taps or scrolling, while the tab bar still works. Steps to reproduce: Open the game lobby. Tap a game icon to enter its home page using zoom. Immediately swipe right to return, attempting to interrupt the incoming animation. When the lobby reappears, immediately try to tap or scroll its content and observe the navigation controls. Expected: once the return transition finishes, the destination controls disappear and the visible lobby accepts taps and scrolling. Interrupted entry and cancelled interactive return should remain supported. Current investigation environment: iPhone 16 Pro, iOS 27.0 Seed 7 (24A5430a), Xcode 27 beta 4. The supplied owner recording shows the visual symptom across Connect Four, Chinese Chess and Chess; the exact build used in those original attachments has not been independently verified. The app uses NavigationStack, matchedTransitionSource and navigationTransition(.zoom(...)). It also has application-side navigation-bar visibility, transition-state and gesture coordination. We have not isolated the exact symptoms in a minimal project without that logic, so the root cause remains unconfirmed. Potentially related discussions: https://developer.apple.com/forums/thread/796805 https://developer.apple.com/forums/thread/802908 Those reports primarily describe disappearing source views that remain tappable. Our issue involves lingering destination controls and temporarily unresponsive root content. I am opening a separate thread to track these differences. Has anyone observed this specific combination? Could the SwiftUI/navigation team check FB24659815 and advise whether this is a framework issue or an application-side lifecycle/gesture interaction? We would appreciate a fix or supported workaround that preserves the system zoom animation and interactive cancellation. The temporary loss of lobby interaction makes this especially disruptive.