Programmatically detect whether iOS passcode is enabled or not

Question

Rather than build a passcode directly into my app and potentially require the user to enter a passcode twice (once for the device and again for my app); I thought I might out-clever myself and do something along the lines of:

if (device has passcode)
    continue into my app
else
    make user enter my app passcode

I don't want to set the device passcode, I don't want to force a screen lock, not encrypting anything - all I really want is an API just to detect if a device passcode is in effect. Something like:

BOOL notReally = [UIDevice isUserSlightlyMoreSecureBecauseTheySetDeviceLockOn];

or maybe if I'm feeling lucky:

BOOL isPasscodeEnabled = [UIDevice isPasscodeEnabled];
BOOL isSimplePasscode = [UIDevice isSimplePasscode];
NSInteger minutes = [UIDevice requirePasscodeAfter];

I'm guessing not based on this question (but is a few years old) "programmatically check for iPhone's Passcode in settings bundle" or this might be the answer; "Lock Unlock events iphone" which isn't exactly what I want but might work "after the fact".

Imperturbable

Nothing has changed. Still can't be done. – Dolomite

Don't worry about it. Give the user the option to set a passcode in your app. Let the user decide if they want to use it or not, regardless of whether the user has a device-level passcode or not. – Dolomite

Wouldn't UIApplication.protectedDataAvailable give you what you want? developer.apple.com/library/ios/DOCUMENTATION/UIKit/Reference/… – Statue

For me this is true if I don't have a passcode set and true if I do. – Wards

Answer 1

Update

As of iOS 9, you can achieve this using the LocalAuthentication.framework. If targeting iOS 9+ read the comments here or look at this answer.

If you still need to target iOS 8 then continue reading :)

---

Starting in iOS8, you can!
I've put together a simple category to easily check the status: https://github.com/liamnichols/UIDevice-PasscodeStatus

How it Works

This category works by using the new accessControl features added to the Security.Framework in iOS 8. It attempts to add an item to the keychain using the kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly protection level.

The documentation states the following:

Item data can only be accessed while the device is unlocked. This class is only available if a passcode is set on the device. This is recommended for items that only need to be accessible while the application is in the foreground. Items with this attribute will never migrate to a new device, so after a backup is restored to a new device, these items will be missing. No items can be stored in this class on devices without a passcode. Disabling the device passcode will cause all items in this class to be deleted.

Because of this, an error is returned when you attempt to add or read an item in the keychain with this level of accessControl. If we see this error, the passcodeStatus returns as LNPasscodeStatusDisabled. If we can successfully read or write to the keychain with this level of accessControl then we return LNPasscodeStatusEnabled.

If the device is unsupported or an unrelated error with the keychain is returned, we return LNPasscodeStatusUnknown.

Brooklyn

Is there a way on previous versions, though? – Bretbretagne

@Bretbretagne Unfortunately not – Brooklyn

@Federico not tested it so I have no idea... Apparently it doesn't work in extensions but if the iOS/watchOS APIs are the same then I don't see why not.. It would be if the actual Watch has its passcode enabled rather than the iPhone though. – Brooklyn

I think it is not working on IOS9, when it is enabled the code works well, but it's always unknown when it is not... – Answerable

Answer 2

For iOS 9+ you can detect it using the new LocalAuthentication class, and it works on Simulator as well as devices:

import LocalAuthentication

private func devicePasscodeSet() -> Bool {
    //checks to see if devices (not apps) passcode has been set
    return LAContext().canEvaluatePolicy(.deviceOwnerAuthentication, error: nil)
  }

Sholom

Answer 3

I'm not aware of any way of getting this information directly, however I think you can probably achieve the result you are after by using side-effects of Apple's support for disk encryption. See Protecting Data Using On-Disk Encryption for details.

However this is a hack rather than designed behaviour, and there are some corner-cases it won't be aware of. I'd recommend making this feature something that's explicitly under the control of the user rather than something you enable with heuristics.

Theoretical