Detecting backspace in a UITextField

I recently had need for a token field for iOS while implementing a “To:” field like the one in I ran into a problem, though. The token field consists of a label, some number of tokens, and a borderless UITextField at the end where the user can enter text for the next token. It looks something like this, if you’ll forgive the ASCII art:

| To: (token1) (token2) (token3) _____________ |
^ ^ ^ ^ ^
UILabel tokens UITextField

In, if you’re at the far left of the text field and hit the backspace key, the rightmost token will be highlighted. Another backspace deletes the token and puts focus back in the text field. But there’s a problem. UITextField provides no way to detect a backward delete at the beginning of the field.

Part 1: Discovery

You’d think this would be simple, but it’s not. Some of my early attempts included:

  • Implementing -textField:shouldChangeCharactersInRange:replacementString: in the text field’s delegate and looking for an attempt change the range at (0,0). No dice—it’s not called if the text isn’t actually going to change.
  • Subclassing UITextField and overriding the -deleteBackward method (part of the UIKeyInput protocol, which UITextField conforms to via UITextInput). -[UITextField deleteBackward] is never called when the backspace key is pressed. Update: As of iOS 6.0, this solution works. You don’t need any of the crazy stuff below. But feel free to read if you’re interested, or if you still need iOS 5 support.
  • Subclassing UITextField and overriding various methods declared in the UITextInput protocol, such as -replaceRange:withText:, -setSelectedTextRange:, etc. Surprisingly, none of these are called either—despite declaring conformance to the UITextInput protocol, it seems that UIKit doesn’t actually use any of those methods when handling keyboard input.

So, we’ve got a UITextField that claims to implement all these text-handling methods, and yet it doesn’t seem to use them when handling keyboard input. It’s probably forwarding them on to some other object, but how could we find out who that other object is?

DTrace, of course.

Using a boilerplate app containing a single UITextField, I pulled out Instruments and added a Trace instrument for -[* delete*].

That is, “Trace every ObjC call to any object where the selector starts with the word ‘delete’.” I launched the app and waited for things to quiet down, then tapped in the text field and hit the backspace key on the keyboard. Immediately, a few delete-related methods showed up, including this stack trace:

Why hello there, UIFieldEditor with a UITextInputAdditions category. We’ve been looking for you.

I love DTrace.

Part 2: Digging through the dump

Okay, so we know there’s something called a UIFieldEditor, and since UITextField wasn’t involved at all in the above stack trace, we can guess that the field editor may be doing all of the heavy lifting. So let’s look at UIFieldEditor a bit deeper.

If we class-dump UIFieldEditor in UIKit, we see that the first three methods in its method list are these:

+ (void)releaseSharedInstance;
+ (id)sharedFieldEditor;
+ (id)activeFieldEditor;

So it appears that the UIFieldEditor receiving keyboard input is likely a shared object that is reused whenever the first responder needs keyboard input. Since there can only be one first responder at a time, there’s probably no need for more than one UIFieldEditor.

Class-dump also tells us that UIFieldEditor is a subclass of UIWebDocumentView. This is interesting, because a bit of time in DTrace will also confirm that -[UITextField deleteBackward] calls down to [UIWebDocumentView deleteBackward]. It looks like the field editor is a view that gets overlaid on top of text input views, and probably handles most of the text editing experience.

So rather than subclassing UITextField, it looks like we really want to be subclassing UIFieldEditor if we want to do something special with -deleteBackward.

Part 3: Dark Runtime Magic

We’ve got two problems down the “Subclass UIFieldEditor” path, though:

  1. UIFieldEditor is a private class in UIKit, so we don’t have its headers. Without the headers, @interface MyFieldEditor : UIFieldEditor is going to cause a compiler error, since it won’t know how to inherit from UIFieldEditor.
  2. We don’t control the UIFieldEditor instance used by UIKit. Even if we could create our own MyFieldEditor, we still don’t know how to swap out the existing shared object for our own.

Fortunately, we can handle both of these problems with the same solution: dynamic subclassing. We’ll create our own subclass of UIFieldEditor at runtime and change the class of the existing field editor to be out new dynamic subclass. This sounds crazy—and it is. But it works1, and it allows us to add our own -deleteBackward functionality without having to swap out existing objects and somehow inform UIKit of what we’re doing.

Dynamically creating classes at runtime isn’t something you’re likely to do very often, but it’s fairly well documented, and there have been some great posts about it in the community. I won’t bother going into more detail here—it’s enough to know that the dynamically-created class works just like any other, once you get it all set up. You just need to allocate a new class pair, register the new class, and add the methods we want to override to the new class. (One caveat of note: calls to objc_allocateClassPair() and objc_registerClass() fail under ARC, so if you’re using ARC you’ll have to do those in a file that’s not using ARC.) You can see how this works in my sample implementation, linked at the end of this post.

Once we’ve created our MyFieldEditor class, though, we still have to actually change the class of the existing UIFieldEditor. This requires using the runtime function object_setClass(id object, Class newClass). The newClass parameter is easy enough, but what are we going to pass it for the object? We know there’s a UIFieldEditor out there, but we still don’t have a reference to it.

Let’s go back to class-dump for a moment. Looking through the method list on UITextField, you’ll see a -(id)_fieldEditor method. Sounds like exactly what we want. Unfortunately, we can’t just toss that method declaration in a category and then call it directly; that’s sure to fail App Store validation for using private API. So we need some way of calling that method without making it look like we’re using that method.

We could probably do it with -(id)performSelector:, but we clearly can’t just create the selector with @selector(_fieldEditor); that will fail App Store validation just as quickly as calling it directly. We could construct it dynamically from a string, but ARC introduces some caveats when calling -performSelector: with a dynamically-constructed selector because it can’t guarantee to get the memory management right. It would be nice to have something that would work correctly without a lot of overhead.

Key-Value Coding to the rescue! Key-Value Coding is built around the idea that if you know the name of a property, Cocoa can figure out what the appropriate getters and setters should be. So, rather than trying to figure out the exact method we want to call, let’s just ask Cocoa to get the fieldEditor for us:

id fieldEditor = [someTextField valueForKey:@"fieldEditor"];

It’s as easy as that.

Part 4: Making the call

At this point, we have a reference to the field editor, and we’ve created a dynamic UIFieldEditor subclass that we can use to customize its behavior. We never actually added any methods, though; MyFieldEditor doesn’t do anything differently from UIFieldEditor yet. We’ll need to dynamically add a method to MyFieldEditor, but before we can do that, we need to write the method.

Our needs are actually quite simple; when -[MyFieldEditor deleteBackward] is called, we want to call a method letting someone know that a backward deletion happened. Ideally, that “someone” would be the text field itself. Then we want to call through to the superclass implementation.

Here’s my implementation:

- (void)fieldEditor_deleteBackward {

MyTextField *textField = objc_getAssociatedObject(self, BackwardDeleteTargetKey);
[textField my_willDeleteBackward];

// Call through to super
Class superclass = class_getSuperclass([self class]);
SEL deleteBackwardSEL = @selector(deleteBackward);
IMP superIMP = [superclass instanceMethodForSelector:deleteBackwardSEL];
superIMP(self, deleteBackwardSEL);

It’s really quite simple. We get a reference to the text field using ObjC associated objects, and call -my_willDeleteBackward on it. Then we pass the -deleteBackward method up to the superclass, UIFieldEditor. We have to use the runtime methods to do the superclass call because of the dynamic subclassing game; otherwise, we’d get the wrong superclass.

I’m a little nervous about unilaterally changing the behavior of UIFieldEditor, because it seems likely that every text input area in your app uses the same instance of the field editor. So we do a little dance in MyTextField‘s implementations of -becomeFirstResponder and -resignFirstResponder. It looks like this:

- (BOOL)becomeFirstResponder {
BOOL shouldBecome = [super becomeFirstResponder];
if (shouldBecome == NO) {
return NO;

Class myFieldEditorClass = objc_lookUpClass([SubclassName UTF8String]);
if (myFieldEditorClass == nil) {
myFieldEditorClass = registerMyFieldEditor();

id fieldEditor = [self valueForKey:@"fieldEditor"];

if (fieldEditor && myFieldEditorClass) {
object_setClass(fieldEditor, myFieldEditorClass);
objc_setAssociatedObject(fieldEditor, BackwardDeleteTargetKey,

return YES;

- (BOOL)resignFirstResponder {
BOOL shouldResign = [super resignFirstResponder];
if (shouldResign == NO) {
return NO;

id fieldEditor = [self valueForKey:@"fieldEditor"];

if (fieldEditor) {
objc_setAssociatedObject(fieldEditor, BackwardDeleteTargetKey,
Class uiFieldEditorClass = objc_lookUpClass("UIFieldEditor");
if (uiFieldEditorClass) {
object_setClass(fieldEditor, uiFieldEditorClass);
return YES;

With this implementation, the shared UIFieldEditor instance will only be of class MyFieldEditor while the text field is actively the first responder. As soon as the text field resigns, it goes back to being a regular old UIFieldEditor. No other text field in the app will be affected, and this text field will hear about all the backward deletion calls as soon as they come in.

This is about the point where everyone working on UIKit starts squirming vigorously. If you’d like people to not do this kind of stuff (which I’d heartily agree with), then let me direct your attention to Radars #10265826 and #10377565.

In the meantime, use with caution. I haven’t tried it in the App Store, but I suspect it will pass validation as there are no symbols referencing any private API in this implementation.

The code is on GitHub.

  1. This is actually the same mechanism Cocoa uses to implement Key-Value Observing; when you start observing a property of some object, Cocoa generates a new subclass of that object’s class and implements a setter method that wraps your own with calls to -willSetValueForKey: and -didSetValueForKey:. When all observers on an object are gone, its class is set back to the original class.  

9 responses to “Detecting backspace in a UITextField”

  1. I'm not sure I understand why you are using a dynamic subclass instead of just swizzling -[UIFieldEditor deleteBackward]. It seems overcomplicated to me, a simple method_getImplementation + method_setImplementation or method_exchangeImplementations would be just fine IMHO.Also, you should wrap [someTextField valueForKey:@”fieldEditor”]; inside a @try/@catch to be safe.


  2. Swizzling feels far more fragile to me than subclassing. Even though UIFieldEditor doesn't currently appear to have any implementation of -deleteBackward (other than the inherited one), that's not an assumption I want to rely on. You can make it call the original implementation when you exchange implementations, but it makes your replacement method falsely look recursive.In general, subclassing is the standard approach for overriding method behavior in an object-oriented paradigm, so I went with that. I also like that this approach allows me to remove all customization of the field editor when I'm done. Since the field editor is a shared object, permanently altering its behavior makes me nervous. There's no method_removeImplementation, so once you've added a method on the class, it's stuck there. (I suppose you could do the exchange implementations dance every time it becomes or resigns first responders, but that seems like a house of cards.)In short, you probably could do it that way, but I chose not to. :)You're absolutely right about about @try/@catch, though. I'll make that change on github.


  3. This saved me man. Great post. Also, I didn't realize that dtrace was also useful for iOS. I had previously only used it for OSX debugging.


  4. Yeah, DTrace is pretty great. Though I should note that it currently only works in the iOS simulator. DTrace probes on iOS devices currently fail.


  5. A much easier solution is to simply ensure the text field has at least a single space in it (@” “). You can then always detect the backspace and it's trivial to make sure the extra space is ignored when you process the user's input.


  6. @Adam, that can often work, and that's what a lot of the open-source solutions out there do. However, this fails if the user drags the cursor back to the beginning of the field. If that happens, they're likely to end up with the insertion point *before* the sentinel space, and you end up unable to detect the backspace.I needed something more reliable, which was the impetus for this research.


  7. @BJ, it's pretty easy to solve that (rare) edge case by implementing textViewDidChangeSelection: and changing the cursor index to 1 when the user tries to make it 0. Note that this necessitates using a UITextView instead of a UITextField (which I'd recommend anyway so that you can dynamically grow your text entry area to multiple lines as in the way, thanks for the interesting post. You used lots of cool debugging techniques here.


  8. @Adam, Your solution its useful when your UITextField's are not using the password format style (Secure text input). Because using an Space or the ghost character (textField.text = @”\u200B”;) the UITextField will detect it and place a visible secure character (*), so you'd have to figure out how to overcome this another way around. @BJ Thanks for this post man.


  9. Man, thanks a lot for sharing! Helped me a lot! Great approach.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: