

Requirement 7: leading and/or trailing spaces in the search string should be ignored.

Requirement 6: longer search tokens should be matched first. This is important and subtle behaviour but is actually easy to implement. In combination with requirement 4 (each search token matches a separate data token), this avoids giving different results depending upon the order of tokens in the strings. longer) search token “pe” must match person, allowing "p" to match plus. In this example, the “p” could be considered to match either person or plus, but “pe” can only match person. A search for “p pe” should match (among others).Requirement 5: the order of the tokens in the search string and data do not need to be the same. A search for “fill circle sq” should match, , and .circle.fill.Requirement 4: each token in the search string must match a separate token in the data. A search for “up up” should only match symbol names which have two (or more) tokens beginning with “up”.Requirement 3: each token in the search string must match a token in the data. The matches should not be a union of the matches of separate searches for “x” and “bin”. A search for “x bin” should match xmark.bin,, , and.Requirement 2: matches only occur on token prefixes. A match should not occur for a symbol that only has the two letters “he” somewhere within a token (e.g. A search for “he” should match symbol names which contain a token that begins with “he” (e.g.Requirement 1: search strings with no tokens match everything. A search for the empty string should match all symbols.Replacing periods with spaces transforms the symbol names into a form that is suitable for the algorithm (which expects whitespace-separated tokens). is effectively three tokens: heart, circle, and fill. Symbol names can be considered to be lists of tokens separated by periods, e.g. To understand my requirements for how the search algorithm should work I will describe some use cases using the SF Symbol names as an example. I prefer to use the slightly more abstract term “tokens” instead of “words”: groups of characters separated by whitespace. It can be used when the data to be search is structured as a list of words. SmartSearchExample sample app for browsing SF Symbols on iOS 14 The AlgorithmĪt its heart, the algorithm works by matching word prefixes. The rules defining how matching occurs are the heart of the algorithm and this article. A search bar can be used to filter the list of names. This data is hopefully familiar to most iOS developers and works well as an example because there are lots of occurrences of some words (such as “arrow”, “circle” and “fill”). The app shows an alphabetical list of the 2,612 SF Symbols available in iOS 14. You will need to configure your development team in the app target’s “Signing & Capabilities” tab in order to run it on a real device. You can download SmartSearchExample from GitHub and should be able to run it in the iOS simulator without changes. The simplest way to describe the features of the algorithm and see it in use is with a sample project. If the data to be searched in your app is representable as a list of one or more words, the algorithm might be a good way to allow its users to quickly find relevant matches when searching. It doesn’t understand English or alternate word forms. The algorithm is smarter than a trivial substring match but not as complex as something like Xcode’s fuzzy matching of method names. This article describes a simple, smart search algorithm that I have used in several iOS apps. A Simple, Smart Search Algorithm for iOS in Swift Introduction
