Post

Replies

Boosts

Views

Activity

Apple Mail compose field becomes uneditable after using Apple Intelligence rewriting tools on macOS 27 Developer Beta 1
Apple Mail compose field becomes uneditable after using Apple Intelligence rewriting tools on macOS 27 Developer Beta 1 I am seeing a reproducible issue in Apple Mail on macOS 27 Developer Beta 1 where the compose body becomes locked/uneditable after using Apple Intelligence writing tools. Environment Mac: macOS: macOS 27.0 Developer Beta 1 Build: 26A5353q Device: MacBook Pro with Apple Silicon shouldSwitchToCampoMode: false (isEnhancedSiriAvailable=false) App: Apple Mail Compose window Apple Intelligence Writing Tools Summary When composing an email in Apple Mail, if I write some text and then use Apple Intelligence to rewrite it — for example using Friendly, Professional, or Concise — Mail replaces the original text with the rewritten version. After the rewritten text is inserted, the message body becomes unresponsive. I cannot continue typing, edit the rewritten text, delete text, select text normally, or add new content inside the email body. The Apple Intelligence button also becomes unresponsive after this happens. The only actions that still seem to work are sending the email, discarding the draft, or using some toolbar actions such as emoji insertion. Steps to Reproduce Open Apple Mail on macOS 27 Developer Beta 1. Create a new email. Type any text into the email body. Use Apple Intelligence Writing Tools. Choose a rewrite option such as: Friendly Professional Concise Let Apple Intelligence replace/update the email body text. Try to click back into the message body and continue typing or editing. Expected Result After Apple Intelligence rewrites the email body, the compose field should remain fully editable. The user should be able to: Continue typing after the rewritten text Edit or delete the rewritten text Select and modify text Use Apple Intelligence again on the updated content Continue composing the email normally Actual Result After Apple Intelligence inserts the rewritten text: The email body becomes uneditable. Typing no longer works inside the message body. Clicking inside the body does not restore normal editing. Existing text cannot be edited or changed. Apple Intelligence controls become unresponsive. The compose window itself does not fully crash, but the body editor appears stuck. Send and discard still appear to work. Reproducibility This appears to be reproducible after using Apple Intelligence rewriting tools inside Apple Mail’s compose window. It was working before, so this appears to be a regression in macOS 27 Developer Beta 1.
0
0
8
5h
iPhone Mirroring broken between macOS 27 Developer Beta 1 and iOS 27 Beta 1; later crash on iOS 26.5 with ScreenSharingKit assertion failure
I am seeing serious issues with iPhone Mirroring on macOS 27 Developer Beta 1. Environment Mac: MacBook Pro, Apple M4 Pro Model: Mac16,7 RAM: 24 GB macOS: macOS 27.0 Developer Beta 1 Build: 26A5353q SIP: Enabled Developer Mode: Enabled iPhone: iPhone 15 Pro Max Previously tested on: iOS 27 Beta 1 Currently restored to: iOS 26.5 Issue 1: iPhone Mirroring does not connect on iOS 27 Beta 1 and can leave the iPhone unusable When my iPhone 15 Pro Max was running iOS 27 Beta 1, iPhone Mirroring on macOS 27 Developer Beta 1 did not connect properly. I tried connecting multiple times. The iPhone appeared to think that the mirroring session had started successfully, because the iPhone screen turned off as expected for iPhone Mirroring. However, the Mac never actually completed the connection and never displayed the mirrored iPhone session. After this happened, the iPhone became completely stuck and unresponsive. The phone did not respond normally, and even force restart attempts were not working. The device remained unusable until the battery fully drained, which took about two days. After the battery was fully depleted, I was able to put the iPhone into DFU mode and restore it back to iOS 26.5. This suggests that something may be broken in the iPhone Mirroring / Continuity connection state between macOS 27 Developer Beta 1 and iOS 27 Beta 1. The iPhone seems to enter a state where it believes it is connected for mirroring, while the Mac never actually establishes the session. Issue 2: iPhone Mirroring crashes on macOS 27 Developer Beta 1 when used with iOS 26.5 After restoring the iPhone 15 Pro Max back to iOS 26.5, I was able to get a crash report from the Mac side. The iPhone Mirroring app crashed on macOS 27 Developer Beta 1 with the following details: Process: iPhone Mirroring Identifier: com.apple.ScreenContinuity Version: 2.0 Build Version: 114.38.15.1 OS Version: macOS 27.0 (26A5353q) Hardware Model: Mac16,7 Exception Type: EXC_BREAKPOINT (SIGTRAP) Termination Reason: Namespace SIGNAL, Code 5, Trace/BPT trap: 5 Triggered by Thread: 2 Dispatch Queue: com.apple.root.user-initiated-qos.cooperative The crashed thread shows a Swift assertion failure inside ScreenSharingKit.framework: Thread 2 Crashed: 0 libswiftCore.dylib assertionFailure(:_:file:line:flags:) + 216 1 ScreenSharingKit 0x29fbb60e0 2 libswiftCore.dylib _swift_release_dealloc + 64 3 libswiftCore.dylib RefCounts::doDecrementSlow 4 ScreenSharingKit 0x29fa894c0 5 ScreenSharingKit 0x29fb484d8 6 ScreenSharingKit 0x29fb48614 ... 15 libswift_Concurrency.dylib completeTaskWithClosure Relevant binary image: /System/Library/PrivateFrameworks/ScreenSharingKit.framework/Versions/A/ScreenSharingKit CFBundleIdentifier: com.apple.screensharing.ScreenSharingKit CFBundleVersion: 114.38.15.1 Crash interpretation The crash appears to be a first-party Apple framework crash inside ScreenSharingKit, caused by a Swift assertion failure. It does not appear to be caused by memory pressure, Rosetta, or third-party code injection. Relevant crash report details: External Modification Summary: task_for_pid: 0 thread_create: 0 thread_set_state: 0 System Integrity Protection: enabled Memory usage also does not look excessive: Writable regions: Total=251.0M MALLOC: 128.4M Expected behavior iPhone Mirroring should either connect successfully or fail gracefully. It should not: Leave the iPhone in a stuck/unresponsive state. Put the iPhone screen into mirroring mode while the Mac never completes the connection. Require the iPhone battery to fully drain before DFU restore is possible. Crash on macOS with an internal ScreenSharingKit Swift assertion failure. Actual behavior On iOS 27 Beta 1: iPhone Mirroring never completed the connection on the Mac. The iPhone behaved as if the session started. The iPhone screen turned off. The iPhone became completely unresponsive. Force restart did not work. Device only became recoverable after battery fully drained. I then restored the iPhone to iOS 26.5 via DFU. On iOS 26.5: iPhone Mirroring was able to run, but the Mac-side app later crashed. The crash occurred inside Apple’s ScreenSharingKit.framework. The crash type was EXC_BREAKPOINT (SIGTRAP) from Swift _assertionFailure. Reproducibility Partially reproducible. iOS 27 Beta 1 + macOS 27 Developer Beta 1: connection repeatedly failed and eventually left the iPhone stuck. iOS 26.5 + macOS 27 Developer Beta 1: iPhone Mirroring can connect, but the Mac app crashed with the attached report. Crash identifiers Incident Identifier: B6D4D86D-03C4-4466-B9D6-4CF70DF0B46F Crash Reporter Key: 8BD85D40-8AC8-E771-2D80-153D7C4C5366 Process: iPhone Mirroring [11429] Bundle ID: com.apple.ScreenContinuity The crash report points to ScreenSharingKit.framework, so this looks like a possible beta regression in the iPhone Mirroring / Continuity stack.
0
0
15
5h
Apple Mail compose field becomes uneditable after using Apple Intelligence rewriting tools on macOS 27 Developer Beta 1
Apple Mail compose field becomes uneditable after using Apple Intelligence rewriting tools on macOS 27 Developer Beta 1 I am seeing a reproducible issue in Apple Mail on macOS 27 Developer Beta 1 where the compose body becomes locked/uneditable after using Apple Intelligence writing tools. Environment Mac: macOS: macOS 27.0 Developer Beta 1 Build: 26A5353q Device: MacBook Pro with Apple Silicon shouldSwitchToCampoMode: false (isEnhancedSiriAvailable=false) App: Apple Mail Compose window Apple Intelligence Writing Tools Summary When composing an email in Apple Mail, if I write some text and then use Apple Intelligence to rewrite it — for example using Friendly, Professional, or Concise — Mail replaces the original text with the rewritten version. After the rewritten text is inserted, the message body becomes unresponsive. I cannot continue typing, edit the rewritten text, delete text, select text normally, or add new content inside the email body. The Apple Intelligence button also becomes unresponsive after this happens. The only actions that still seem to work are sending the email, discarding the draft, or using some toolbar actions such as emoji insertion. Steps to Reproduce Open Apple Mail on macOS 27 Developer Beta 1. Create a new email. Type any text into the email body. Use Apple Intelligence Writing Tools. Choose a rewrite option such as: Friendly Professional Concise Let Apple Intelligence replace/update the email body text. Try to click back into the message body and continue typing or editing. Expected Result After Apple Intelligence rewrites the email body, the compose field should remain fully editable. The user should be able to: Continue typing after the rewritten text Edit or delete the rewritten text Select and modify text Use Apple Intelligence again on the updated content Continue composing the email normally Actual Result After Apple Intelligence inserts the rewritten text: The email body becomes uneditable. Typing no longer works inside the message body. Clicking inside the body does not restore normal editing. Existing text cannot be edited or changed. Apple Intelligence controls become unresponsive. The compose window itself does not fully crash, but the body editor appears stuck. Send and discard still appear to work. Reproducibility This appears to be reproducible after using Apple Intelligence rewriting tools inside Apple Mail’s compose window. It was working before, so this appears to be a regression in macOS 27 Developer Beta 1.
Replies
0
Boosts
0
Views
8
Activity
5h
iPhone Mirroring broken between macOS 27 Developer Beta 1 and iOS 27 Beta 1; later crash on iOS 26.5 with ScreenSharingKit assertion failure
I am seeing serious issues with iPhone Mirroring on macOS 27 Developer Beta 1. Environment Mac: MacBook Pro, Apple M4 Pro Model: Mac16,7 RAM: 24 GB macOS: macOS 27.0 Developer Beta 1 Build: 26A5353q SIP: Enabled Developer Mode: Enabled iPhone: iPhone 15 Pro Max Previously tested on: iOS 27 Beta 1 Currently restored to: iOS 26.5 Issue 1: iPhone Mirroring does not connect on iOS 27 Beta 1 and can leave the iPhone unusable When my iPhone 15 Pro Max was running iOS 27 Beta 1, iPhone Mirroring on macOS 27 Developer Beta 1 did not connect properly. I tried connecting multiple times. The iPhone appeared to think that the mirroring session had started successfully, because the iPhone screen turned off as expected for iPhone Mirroring. However, the Mac never actually completed the connection and never displayed the mirrored iPhone session. After this happened, the iPhone became completely stuck and unresponsive. The phone did not respond normally, and even force restart attempts were not working. The device remained unusable until the battery fully drained, which took about two days. After the battery was fully depleted, I was able to put the iPhone into DFU mode and restore it back to iOS 26.5. This suggests that something may be broken in the iPhone Mirroring / Continuity connection state between macOS 27 Developer Beta 1 and iOS 27 Beta 1. The iPhone seems to enter a state where it believes it is connected for mirroring, while the Mac never actually establishes the session. Issue 2: iPhone Mirroring crashes on macOS 27 Developer Beta 1 when used with iOS 26.5 After restoring the iPhone 15 Pro Max back to iOS 26.5, I was able to get a crash report from the Mac side. The iPhone Mirroring app crashed on macOS 27 Developer Beta 1 with the following details: Process: iPhone Mirroring Identifier: com.apple.ScreenContinuity Version: 2.0 Build Version: 114.38.15.1 OS Version: macOS 27.0 (26A5353q) Hardware Model: Mac16,7 Exception Type: EXC_BREAKPOINT (SIGTRAP) Termination Reason: Namespace SIGNAL, Code 5, Trace/BPT trap: 5 Triggered by Thread: 2 Dispatch Queue: com.apple.root.user-initiated-qos.cooperative The crashed thread shows a Swift assertion failure inside ScreenSharingKit.framework: Thread 2 Crashed: 0 libswiftCore.dylib assertionFailure(:_:file:line:flags:) + 216 1 ScreenSharingKit 0x29fbb60e0 2 libswiftCore.dylib _swift_release_dealloc + 64 3 libswiftCore.dylib RefCounts::doDecrementSlow 4 ScreenSharingKit 0x29fa894c0 5 ScreenSharingKit 0x29fb484d8 6 ScreenSharingKit 0x29fb48614 ... 15 libswift_Concurrency.dylib completeTaskWithClosure Relevant binary image: /System/Library/PrivateFrameworks/ScreenSharingKit.framework/Versions/A/ScreenSharingKit CFBundleIdentifier: com.apple.screensharing.ScreenSharingKit CFBundleVersion: 114.38.15.1 Crash interpretation The crash appears to be a first-party Apple framework crash inside ScreenSharingKit, caused by a Swift assertion failure. It does not appear to be caused by memory pressure, Rosetta, or third-party code injection. Relevant crash report details: External Modification Summary: task_for_pid: 0 thread_create: 0 thread_set_state: 0 System Integrity Protection: enabled Memory usage also does not look excessive: Writable regions: Total=251.0M MALLOC: 128.4M Expected behavior iPhone Mirroring should either connect successfully or fail gracefully. It should not: Leave the iPhone in a stuck/unresponsive state. Put the iPhone screen into mirroring mode while the Mac never completes the connection. Require the iPhone battery to fully drain before DFU restore is possible. Crash on macOS with an internal ScreenSharingKit Swift assertion failure. Actual behavior On iOS 27 Beta 1: iPhone Mirroring never completed the connection on the Mac. The iPhone behaved as if the session started. The iPhone screen turned off. The iPhone became completely unresponsive. Force restart did not work. Device only became recoverable after battery fully drained. I then restored the iPhone to iOS 26.5 via DFU. On iOS 26.5: iPhone Mirroring was able to run, but the Mac-side app later crashed. The crash occurred inside Apple’s ScreenSharingKit.framework. The crash type was EXC_BREAKPOINT (SIGTRAP) from Swift _assertionFailure. Reproducibility Partially reproducible. iOS 27 Beta 1 + macOS 27 Developer Beta 1: connection repeatedly failed and eventually left the iPhone stuck. iOS 26.5 + macOS 27 Developer Beta 1: iPhone Mirroring can connect, but the Mac app crashed with the attached report. Crash identifiers Incident Identifier: B6D4D86D-03C4-4466-B9D6-4CF70DF0B46F Crash Reporter Key: 8BD85D40-8AC8-E771-2D80-153D7C4C5366 Process: iPhone Mirroring [11429] Bundle ID: com.apple.ScreenContinuity The crash report points to ScreenSharingKit.framework, so this looks like a possible beta regression in the iPhone Mirroring / Continuity stack.
Replies
0
Boosts
0
Views
15
Activity
5h