I’m seeing what appears to be a Core Data regression on iOS 27 when using an IN %@ predicate with a Transformable attribute containing String values. Before iOS 27, the following predicate worked correctly regardless of the number of values in the array: [NSPredicate predicateWithFormat:@"field IN %@", valuesArray] On iOS 27, I get different results depending on the number of items in valuesArray: valuesArray.count <= 100 → works correctly and returns the expected objects. valuesArray.count > 100 → returns an empty result, even though matching objects exist in the Core Data database. Reproduction Create a Core Data entity with a Transformable attribute containing String values. Store objects with values in this attribute. Create an array containing matching values. Execute a fetch using: [NSPredicate predicateWithFormat:@"field IN %@", valuesArray] Test with 100 values and then with more than 100 values. The issue is consistently reproducible on iOS 27. Interestingly, I also tested manually transforming the values in the array to the same representation used by the Transformable attribute. When doing this, the predicate works correctly even with more than 100 values. This makes me suspect that iOS 27/Core Data may not correctly transform the values supplied to the IN predicate when the array contains more than 100 items. Has anyone else observed this behavior on iOS 27? Is there a known limitation or change in Core Data predicate handling for Transformable attributes in iOS 27? The same Core Data model and predicate worked correctly on previous iOS versions.

I’m working with the Push-to-Talk (PTT) framework and observing a consistent delay when starting audio capture. Scenario: A PTT call is already active The AVAudioSession is fully configured I request beginTransmission on the PTT channel I start my Audio Unit for recording (AudioOutputUnitStart) Observed behavior: AudioOutputUnitStart takes ~500 ms This happens whether I start the Audio Unit: after didBeginTransmission, or after AVAudioSession didActivate Comparison: Using the same Audio Unit, same format, and same configuration Without the PTT framework, AudioOutputUnitStart takes ~200 ms Additional notes: I am not modifying or reconfiguring AVAudioSession when requesting beginTransmission The audio session is already set up when the PTT call starts There are no interruptions or route changes at the time of starting the Audio Unit Impact: This extra latency is significant for Push-to-Talk use cases where fast transmit start is critical.