{"id":43414,"date":"2024-05-28T14:03:38","date_gmt":"2024-05-28T18:03:38","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=43414"},"modified":"2025-12-15T23:37:24","modified_gmt":"2025-12-16T04:37:24","slug":"dynamic-swift-predicates-in-macos-14-and-ios-17","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/05\/28\/dynamic-swift-predicates-in-macos-14-and-ios-17\/","title":{"rendered":"Dynamic Swift Predicates in macOS 14 and iOS 17"},"content":{"rendered":"

Helge Heß<\/a>:<\/p>\n

The new Foundation\/#Swiftlang Predicate<\/code>s (and its expressions) seem a little weird because they can’t be constructed dynamically?<\/p><\/blockquote>\n\n

Fly0strich<\/a>:<\/p>\n

\n

However, when I try to use that method inside of a #Predicate<\/code> closure, it gives an error saying that the method is not supported by this predicate.<\/p>\n<\/blockquote>\n\n

Debbie Goldsmith<\/a>:<\/p>\n

\n

If you want to construct a Predicate<\/code> dynamically, you need to build it up from PredicateExpression<\/code> pieces rather than use the #Predicate<\/code> macro (similar to building an NSPredicate<\/code> from NSExpression<\/code>). Expand the macro in Xcode and you can see how the pieces are put together.<\/p>\n<\/blockquote>\n\n

It’s a lot more complicated than NSPredicate<\/code> due to the static typing, and there’s no way to convert between the two types if you’re using both Core Data and SwiftData.<\/p>\n\n

Fatbobman<\/a>:<\/p>\n

\n

NSCompoundPredicate<\/code> allows developers to combine multiple NSPredicate<\/code> objects into a single compound predicate. This mechanism is particularly suited for scenarios that require data filtering based on multiple criteria. However, in the new Foundation framework restructured with Swift, the direct functionality corresponding to NSCompoundPredicate<\/code> is missing. This change poses a significant challenge for developers who wish to build applications using SwiftData. This article aims to explore how to dynamically construct complex predicates that meet the requirements of SwiftData, utilizing PredicateExpression<\/code>, under the current technical conditions.<\/p>\n

[…]<\/p>\n

The issue lies in the expression<\/code> property being of the type any StandardPredicateExpression<Bool><\/code>, which doesn’t contain sufficient information to identify the specific PredicateExpression<\/code> implementation type. Since Conjunction<\/code> requires the exact types of the left and right sub-expressions for initialization, we are unable to use the expression<\/code> property directly to dynamically construct new combined expressions.<\/p>\n

[…]<\/p>\n

Although we cannot directly utilize the expression<\/code> attribute of Swift Predicate, there are still alternative ways to achieve the goal of dynamically constructing predicates. The key lies in understanding how to extract or independently create expressions from existing predicates and utilize expression builders such as build_Conjunction<\/code> or build_Disjunction<\/code> to generate new predicate expressions.<\/p>\n<\/blockquote>\n\n

Jeremy Schonfeld<\/a>:<\/p>\n

\n

If you need to dynamically create a predicate while analyzing what should go into the predicate, you can do so by manually constructing the expression tree. Unfortunately, since this is a more advanced use case you wouldn’t be able to use the macro to help here, but you could write something along the lines of the following[…]<\/p>\n

[…]<\/p>\n

In short, we create a list of the conditions that need to be met and build up the list based on which parameters are specified to the makePredicate<\/code> function. We can then reduce<\/code> this array into a single tree of conjunctions to ensure that all of the conditions are met. There are a few small hoops to jump through here in order to satisfy the type-checker with the use of generics such as the closure<\/code> and separate buildConjunction<\/code> function, but this allows you to just append to conditions<\/code> for each new property rather than needing to work with a combinatorial explosion of conditions using the macro.<\/p>\n<\/blockquote>\n

Noah Kamara<\/a>:<\/p>\n

\n

CompoundPredicate aims to improve the Predicate<\/code> system to enable combining multiple predicates after constructing them[…]<\/p>\n<\/blockquote>\n\n

This looks like a huge improvement. It’s not clear to me whether there are still limitations compared with NSPredicate<\/code>.<\/p>\n\n

Fatbobman<\/a>:<\/p>\n

\n

This new strategy abandons the previous reliance on a custom StandardPredicateExpression<\/code> implementation, opting instead for a type-casting strategy that effectively concretizes the information of expression<\/code>. This improvement means developers can avoid the cumbersome process of manually extracting and combining expressions.<\/p>\n

[…]<\/p>\n

This method enables the automatic acquisition of the exact type of expressions inside the Predicate<\/code> during the predicate combination process, facilitating an automated and efficient combination of predicates.<\/p>\n<\/blockquote>\n\n

Helge Heß<\/a>:<\/p>\n

You know how Foundation (in part to support SwiftData) now has the Predicate<\/code> macro? Well, RealityKit has its own generic QueryPredicate<\/code> And guess what, they don’t need a macro to build them, looks like overloading the operators ||<\/code> and &&<\/code> is fine there.<\/p><\/blockquote>\n\n

Debbie Goldsmith<\/a>:<\/p>\n

\n

Operator overloads not only cause longer build times for Predicate<\/code>, but for other<\/em> uses of that operator.<\/p>\n<\/blockquote>\n\n

But even with macros<\/a>:<\/p>\n

\n

In this example, even minor code changes can cause the compilation time for this file to exceed 10 seconds. This delay can also occur when generating expressions using closures.<\/p>\n<\/blockquote>\n\n

Andy Finnell<\/a>:<\/p>\n

\n

Using generics to create SwiftData Predicate<\/code>s leads to crashy times.<\/p>\n

[…]<\/p>\n

FYI, I solved this by writing another macro.<\/p>\n

This is my new mantra: code not working? You don’t have enough macros.<\/p>\n<\/blockquote>\n\n

\nJeremy Schonfeld<\/a>:<\/p>\n

\n

Since Predicate<\/code> is both Codable<\/code> and Sendable<\/code>, it requires that everything the predicate captures (i.e. all instances captured by the closure) are also Codable<\/code> and Sendable<\/code>.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n