27

I am wondering if this is intended by Apple that these lifecycle methods are called upon using TouchID functionality.

Is there any possibility to check if the touchID process is calling these methods (I want to avoid things like a BOOL in app delegate which is set if touchID input is currently shown or not..)

br

2 Answers2

54

Im guessing the problem you're having is that you have code in applicationWillResignActive and applicationDidBecomeActive that affects the view controller that requests Touch ID-validation and that it sets off a tricky loop.

What you need to do is move those calls to applicationDidEnterBackground and applicationWillEnterForeground, because they're not invoked when the Touch ID-mechanism is called.

To explain the sequence, when your app starts the following sequence executes:

  1. applicationDidBecomeActive
  2. ..other stuff your app does
  3. Your app invokes Touch ID, which fires:
  4. applicationWillResignActive

... Your app is disabled until the user verifies fingerprint (fails or succeeds) ...

  1. applicationDidBecomeActive

If you have code in applicationDidBecomeActive -or- applicationWillResignActive that affects Touch ID, you will create an endless loop or worse, you will create code that is riddled with flags and special cases.

Instead you should invoke Touch ID in two cases:

  • When your app starts (usually in didFinishLaunchingWithOptions)

  • When your app's applicationWillEnterForeground is called.

dandan78
  • 13,328
  • 13
  • 64
  • 78
Mani
  • 1,597
  • 15
  • 19
  • How do you suggest implementing a Touch ID check in applicationWillEnterForeground? i.e. so when returning to your app, it prompts the user and doesn't let them use anything until they verify their fingerprint. – user3246173 Mar 31 '16 at 01:40
4

You can create a static bool in your login script that you can check from your AppDelegate! 

static var isShowingTouchID = false

Then before your context.evaluatePolicy call, you can set it to true, and in the callback function, set it to false. I believe you use the reply argument to set a callback to this.

Then in your AppDelegate, check the status of this bool.

Originally I was using a public variable in AppDelegate and setting that, but I feel similarly in that I didn't want to do that. Frankly, I don't like this solution either, but it was the only one I could come up.

I even tried overriding viewDidDisappear in my login script, but I quickly found out that it was not being called even when I tapped "Cancel" on the touch ID prompt.

If anyone has a better solution, I would love to know.

Kimeiga
  • 137
  • 1
  • 5
  • 2
    This is a good solution. Just beware, the didBecomeActiveNotification isn't always called before the `reply` callback. I've seen there be a 1-2 second delay. – Elijah Mar 01 '19 at 01:50