Perplexity macOS crashes with both Apple built-in Chinese IME and third-party IME

Bug Reports
1

Hi Perplexity Support,

I’m seeing a reproducible crash in Perplexity for macOS while entering Chinese text using an IME.

Importantly, I originally reproduced the crash with the third-party WeType input method, but I have now reproduced what appears to be the same crash using Apple’s built-in Chinese input method (com.apple.inputmethod.TCIM / TCIM_Extension).

This suggests the issue is not specific to WeType and may instead be related to IME composition / marked-text handling in Perplexity’s text input implementation.

Environment:

  • Perplexity: 26.34.0 (87)

  • macOS: 26.6.2 (25G83)

  • Hardware: Mac15,10 / Apple M3 Max

  • Architecture: ARM64

  • SIP: enabled

The Apple built-in IME crash occurred on September 1, 2026 at 17:15:02 +0800.

The crash report identifies the triggering input method as:

com.apple.inputmethod.TCIM

and the voucher information identifies:

TCIM_Extension

The relevant exception stack is:

NSConcreteMutableAttributedString replaceCharactersInRange:withString:
→ NSConcreteTextStorage replaceCharactersInRange:withString:
→ NSTextView _insertText:replacementRange:
→ NSTextInputContext insertText:replacementRange:
→ IMKInputSession_Modern insertText:replacementRange:

The application then terminates due to an uncaught Objective-C exception (EXC_BREAKPOINT / SIGTRAP).

The same general input path also appeared in the crash I previously reproduced with WeType.

Because both a third-party IME and Apple’s built-in TCIM trigger the issue, this appears more consistent with an IME composition / replacement-range handling issue in the Perplexity Mac app rather than a vendor-specific input-method problem.

A possible failure mode is that the text storage or selection changes while an IME marked-text session is active, leaving replacementRange stale when AppKit commits the composed text.

I can provide both complete .ips crash reports.

Please investigate the query/input editor’s handling of:

  • NSTextInputClient

  • marked text / composition state

  • replacementRange

  • selection updates during composition

  • programmatic mutations of NSTextStorage while an IME session is active

Incident ID for the Apple TCIM crash:

7DFA4439-7830-4381-ABAD-073989EEECAD

Thanks.

2

have the same problem , same version, really frustrated

3

Same crash here, with a third input method — RIME / Squirrel (im.rime.inputmethod.Squirrel, 1.1.2). With WeType, Apple’s TCIM and RIME all hitting it, your read looks right: this sits in Perplexity’s text input rather than in any one IME.

Environment:

  • Perplexity: 26.34.0 (87)
  • macOS: 26.6.2 (25G83)
  • Hardware: Mac17,6 / Apple M5 Max, ARM64
  • SIP: enabled
  • Input method: Squirrel 1.1.2 (RIME)

Reproduction is 100%: type any code in the query box and commit it — the app dies the moment the composed text is committed. Earlier builds were fine for me, so this looks like a regression in 26.34.0.

Exception path is identical to yours:

-[NSTextView _insertText:replacementRange:]
  -[NSConcreteTextStorage replaceCharactersInRange:withString:]
    -[NSConcreteMutableAttributedString replaceCharactersInRange:withString:]  → uncaught NSException

Two details from my crash report that may help narrow it down:

  1. Directly above handleTSMEvent:completionHandler: is -[NSTextInputContext tryHandleTSMEvent_HasMarkedText_withDispatchCondition:dispatchWork:continuation:], so there was an active marked-text session at commit time. That fits the stale replacementRange theory.

  2. The termination path runs through SentryUncaughtNSExceptions swizzleNSApplicationReportException → NSApplicationUncaughtExceptionHandler → +[NSApplication _crashOnException:]. AppKit would normally log this exception and keep the app alive; NSApplicationCrashOnExceptions (or the Sentry equivalent) is what turns it into a hard SIGTRAP. Might be worth treating as a separate hardening item — even once the range bug is fixed, that setting means any stray exception on the main event loop takes the whole app down.

Incident Identifier: FE031204-2ED1-48E4-86A6-E8F87F23ABD4

Happy to attach the full .ips if that helps.