Sketch showing how pull-to-search works.
Pull-to-Search: a proposal for iOS

iOS Pro: Pull-to-Search

Sam Dods
Kin + Carta Created

--

Motivation for this series

Apple has done a lot recently to make the iPhone easier to use one-handed. However, since upgrading to the iPhone 11 Pro, I have been disappointed by the lack of 3D Touch text editing. They promote all the things they do to make one-handed use easier, but never mention the fact that they’ve removed what I consider one of the real “pro” features of iOS. With the lack of 3D Touch, I want to explore further lengths Apple could go to, to improve the one-handed experience.

Inspiration for this article

The pull-to-search feature of the iOS home screen is great. I use it all the time. I have so many apps cluttering several pages of my home screen that the easiest way to open an app is to “pull down” on the home screen and start typing (or tapping a Siri suggestion). I feel this pull-to-search feature could be rolled out across the system and in third-party apps, as a “pro” feature.

What is pull-to-search?

When you pull down on the home screen of iOS, the search bar appears and immediately has focus. The keyboard appears at the same time and you can start typing quickly to find whatever you’re looking for on your device.

Within apps the search bar always appears at the top of the screen and forces the user to reach awkwardly to initiate a search and reveal the keyboard. (An exception to this is Apple’s Maps app, which makes the search field much more reachable at the top of a sliding “card” style modal.)

I envision the same pull-to-search functionality from the home screen could be used in apps. The user would pull down on the content beneath the search field and pulling beyond some threshold would trigger the search field to become focused.

This feature would compete with pull-to-refresh. You couldn’t have both. However, given the fact that even the inventor of pull-to-refresh wants his own idea to die, I think we can all feel comfortable with a more useful feature replacing it. (Live content should be updated automatically without having to pull!)

Take the iOS Phone app. The Contacts tab has a search feature, but when using my phone one-handed, I’m reluctant to use it. It forces me to reach awkwardly to the top of the screen to begin typing. Wouldn’t it feel “pro” if you could just swipe down to begin searching? I’ve imagined it working like this:

As the user drags the table down beyond an initial threshold, I begin drawing a border around the edge of the text field to indicate that something is happening. Dragging beyond another threshold—indicated by the border joining up—triggers the search field to become focused.

With a quick and intentional swipe down, the user wouldn’t necessarily see the border being drawn, but with a slower scroll, the border would highlight to the user that continuing past the threshold will initiate the search.

Once the search field is focused, tapping anywhere outside of it dismisses the search controller (this comes for free). With these interactions, my thumb doesn’t need to leave the bottom portion of the screen to begin or cancel searching.

Clash with pull-to-dismiss

Pull-to-dismiss is a new feature of iOS 13 that allows the user to pull a modally presented view down to dismiss it (a.k.a. swipe to dismiss). This would clash with pull-to-search.

I’ve witnessed Apple prioritising a completely pointless pull-to-refresh over the intuitive and practical pull-to-dismiss (iOS App Store app, Account screen). It’s a shame when iOS introduces a great feature like this but fails to adopt it consistently.

The solution I propose means that pull-to-search and pull-to-dismiss can coexist harmoniously.

Apple has given developers the ability to detect when pulling to dismiss, in order for us to perform some other action instead. For instance, in the case of adding a Calendar event, pulling down could either (a) cancel and discard changes or (b) save changes. In this case, when the user pulls down to dismiss the Add Event view, the view is not dismissed and instead the app shows an action sheet for possible actions. (Apple has apparently decided not to give the complete set of actions which would have included the Add (Save) action.)

Screenshot of iOS Calendar app, New Event screen. Showing action sheet to avoid ambiguity over dismiss action.
Pull-to-dismiss in the iOS Calendar app, New Event screen. Showing action sheet to avoid ambiguity.

I envision this could be extended in the case that a search field is present at the top of the modal. For example, the Add Invitees modal in the Calendar app has a search field as well as two distinct navigation bar buttons (Cancel on the left; Done on the right). Pulling down to dismiss could trigger an action sheet to give the user complete control without having to reach their thumb uncomfortably.

Animation showing proposal for pulling to dismiss and seeing the option to begin a search.
Pull to perform action!

Pull to perform action

The animation above shows what is essentially a “pull to perform action” feature. The set of actions available depends on the context.

With this in mind, we could provide this user experience regardless of whether we have a search field.

Implementing this is fairly straightforward:

  1. Set isModalInPresentation = true for the modally presented view controller.
  2. Set the relevant presentation controller’s delegate and implement the presentationControllerDidAttemptToDismiss method of UIAdaptivePresentationControllerDelegate.
  3. In the delegate method, instantiate and present a UIAlertController with style .actionSheet.

The code looks like this as a starting point:

“Hold up! This is just weird and unintuitive!”

Don’t forget pull-to-refresh is a hidden and unintuitive feature too! In fact, if you think my proposed feature is bad, you must think pull-to-refresh is much worse because it’s often the only way to refresh, which is a major Accessibility fail!

I’m not proposing pull-to-search is the only way to initiate a search. No way! Of course you can still interact with the search field. Just like you can still explicitly tap the Cancel or Done buttons in the navigation bar. I’m just proposing that “pulling down” on the content seems like a sensible way to trigger functionality without having to extend your thumb awkwardly and risk dropping your phone.

My proposed feature is “discoverable” just like pull-to-refresh. But when a feature like this becomes commonplace, users expect it. Users will soon become familiar with pull-to-dismiss and the “pull to perform (otherwise ambiguous) action” functionality provided in Apple’s apps. Pull-to-search is just an extension of that.

Many users may never discover it, which is what makes it a “pro” feature!

That’s it!

Although you could take it further still! Imagine a page of a form that has several text fields, the first of which is at the top of the screen. In order to begin filling out the form, the user must reach to the top of the screen to interact with the first text field. You could extend my proposed pull-to-search feature to “pull-to-begin”.

Now that would feel really pro!

Follow me on Twitter for random updates, or just say hi. 👋

TAB is hiring! iOS engineers of all levels in London and now in Edinburgh! Head over to theappbusiness.com/careers for more info!

--

--

Sam Dods
Kin + Carta Created

Tech Lead and Mobile Evangelist based in Edinburgh, Scotland