Log Comparison Details for Bug Report
Detailed Log Analysis: iOS 18.4 vs iOS 26 RC
Complete Test Scenario Log Comparison
Test Case: Type "あ" → Press Enter → Type "あ" → Delete → Type "A"
iOS 18.4 / Xcode 16 (Correct Behavior)
// Step 1: Type first "あ"
=== stringRange: 0[any]..<0[any], currentText: , replacementText: a changedText: a, allowChange: true ===
// Note: IME shows "a" first, then converts to "あ"
// Step 2: IME converts "a" to "あ"
=== stringRange: 0[utf16]..<1[utf16], currentText: あ, replacementText: あ changedText: あ, allowChange: true ===
// Result: Text = "あ", Count = 1 ✓
// Step 3: Press Enter (No additional delegate call - composition confirmed correctly)
// Result: Text = "あ", Count = 1 ✓
// Step 4: Delete "あ"
=== stringRange: 0[utf16]..<1[utf16], currentText: あ, replacementText: changedText: , allowChange: true ===
// Result: Text = "", Count = 0 ✓
// Step 5: Type "A"
=== stringRange: 0[any]..<0[any], currentText: , replacementText: A changedText: A, allowChange: true ===
// Result: Text = "A", Count = 1 ✓
Final State iOS 18.4: Text = "A", UTF16 Count = 1 ✅
iOS 26 RC / Xcode 26 (Incorrect Behavior)
// Step 1: Type first "あ" (DIFFERENT: No initial "a" shown)
=== stringRange: 0[any]..<0[any], currentText: , replacementText: あ changedText: あ, allowChange: true ===
// Result: Text = "あ", Count = 1
// Step 2: Press Enter (BUG: Triggers duplicate character insertion)
=== stringRange: 1[utf16]..<1[utf16], currentText: あ, replacementText: あ changedText: ああ, allowChange: true ===
// Result: Text = "ああ", Count = 2 ❌ (Should be 1)
// Step 3: Type another "あ" (continues from duplicated state)
=== stringRange: 2[utf16]..<2[utf16], currentText: ああ, replacementText: あ changedText: あああ, allowChange: true ===
// Result: Text = "あああ", Count = 3 ❌ (Should be 2)
// Step 4: Delete (deletes from position 1, leaving first character)
=== stringRange: 0[utf16]..<1[utf16], currentText: あ, replacementText: changedText: , allowChange: true ===
// Result: Text = "", Count = 0
// Step 5: Type "A"
=== stringRange: 0[any]..<0[any], currentText: , replacementText: A changedText: A, allowChange: true ===
// Result: Text = "A", Count = 1
Final State iOS 26: After first "あ" + Enter = "ああ", UTF16 Count = 2 ❌
Key Differences Summary
1. IME Composition Behavior
Aspect
iOS 18.4
iOS 26 RC
Initial character input
Shows "a" → converts to "あ"
Directly shows "あ"
Range for conversion
0..<1 (replacement)
0..<0 (insertion)
Enter key behavior
No delegate call
Triggers duplicate insertion
2. Critical Bug Pattern
// iOS 26 Bug - When pressing Enter after first character:
Range: NSRange(location: 1, length: 0) // Appending at position 1
CurrentText: "あ" // Already has the character
ReplacementString: "あ" // Same character again
Result: "ああ" // Duplication occurs
3. Range Index Notation Differences
iOS 18.4: Uses [any] for ASCII, [utf16] for IME characters
iOS 26: Uses [any] for initial IME input, [utf16] for subsequent operations
4. Delegate Call Sequence
iOS 18.4 - Correct Flow:
Type "あ": 2 calls (a → あ conversion)
Press Enter: 0 calls ✓
Total: 2 delegate calls
iOS 26 RC - Incorrect Flow:
Type "あ": 1 call
Press Enter: 1 call (duplication bug) ❌
Total: 2 delegate calls (but wrong parameters)
Impact Visualization
iOS 18.4 (Expected):
Type "あ" → [あ] (count: 1)
Press Enter → [あ] (count: 1) ✓
Type "い" → [あい] (count: 2) ✓
iOS 26 RC (Actual):
Type "あ" → [あ] (count: 1)
Press Enter → [ああ] (count: 2) ❌
Type "い" → [ああい] (count: 3) ❌
Root Cause Analysis
The iOS 26 RC appears to have changed how IME composition confirmation works:
iOS 18.4: When focus is lost, the IME silently confirms the composition without triggering the delegate
iOS 26 RC: When focus is lost, the IME triggers the delegate with incorrect parameters, treating the confirmation as a new character insertion
This suggests a regression in the IME state machine where the "composition confirmation" event is incorrectly mapped to a "character insertion" event.
This detailed log comparison clearly demonstrates the regression and should help Apple engineers quickly identify and fix the issue.
