Signature & Verification + Secure Enclave

A digital signature is a guarantee to the receiver regarding the authenticity, integrity, and verification of the sender. To simply put, it’s equivalent to a handwritten signature. A digital signature is achieved using a different key pair than the one used for encryption/decryption.

Digital signatures are utilized in many electronic aspects, Xcode does digitally sign your code whenever you’re to submit your app for testing or to the app store. In general, this is how a sender signs the data to be sent:-

1. The sender encrypts his/her data with a specific hash algorithm (ex: sha256). The output of that hash algorithm is labelled as a “digest” (ex: 6e04f289)
2. The sender then encrypts the digest with his/her private key. The encrypted digest is known as the “digital signature” of the data.
3. The sender sends the original data + the encrypted digest. Notice that the encrypted digest is utilized only for verifying the sender but the message itself is not encrypted by the same private key utilized for signature and verification. It’s encrypted via the private key created as similar to the above section.

This how a receiver verifies the received data:-

1. The receiver receives the message alongside the digital signature.
2. The receiver decrypts the digital signature using the sender’s public key
   -> Output is the digest.
3. The receiver uses the same hashing algorithm similar to the one the sender used to hash the received plain data from the sender -> This will output a digest.
4. If the output digest from step 2 (digital signature) = output digest from step 3 (hash of the received plain data) -> The receiver can validate the integrity of the data.

For this tutorial, the private key to be used for digital signature is to be stored in the secure enclave while the public key is to be stored outside of it and to be shared with the receiver.

The secure enclave based on Apple’s documentation is “a hardware-based key manager that’s isolated from the main processor to provide an extra layer of security. When you store a private key in the Secure Enclave, you never actually handle the key, making it difficult for the key to becoming compromised. Instead, you instruct the Secure Enclave to create the key, securely store it, and perform operations with it. You receive only the output of these operations, such as encrypted data or a cryptographic signature verification outcome.”

It’s important to point out that iOS’s secure enclave supports 256-bit elliptic curve keys (ECC) only. Notice that the private key inside the secure enclave can also be used for data encryption but that is limited to symmetric encryption using the eciesEncryptionCofactorX963SHA256AESGCM algorithm.

Let’s get coding.

The first thing to do is to generate a new key pair for signing and verification. The process is as similar to the last section, but with an extra step regarding setting the attributes for the private key. That is specifying what is known as an “Access Control”.

The access control object is what defines the mechanism to access the private key inside the secure enclave in order to sign data. One rule setting the accessibility level required when accessing the private key inside the secure enclave (ex: when the device is unlocked or when there’s a passcode set).

//Creating the Access Control Object
let access =

SecAccessControlCreateWithFlags(kCFAllocatorDefault, //1

kSecAttrAccessibleWhenUnlockedThisDeviceOnly, //2

[.privateKeyUsage,.biometryAny], //3

nil)! //4

The access object is created by invoking the SecAccessControlCreateWithFlags security API.

1. The first parameter of the API is the allocator. Usually, this is set to the default allocator.
2. Afterwards, the level of protection required to access the private key inside the secure enclave. This is set to kSecAttrAccessibleWhenUnlockedThisDeviceOnly, which means that this item is to be only accessed on the device that created it and only when the device is unlocked.
3. An array of flags that are set to .privateKeyUsage which clearly defined that private key generated inside the secure enclave is to be used for signing and verification & .biometryAny that instructs the system to make the key only available when the system can authenticate the user with any available biometric authentication.
4. Last is an error object to hold any error that might occur, but it’s ignored for now.

Next step is to assemble the key pair attributes as done in the previous sections. First thing is to assemble the private key parameters dictionary (which will include the created access control object)

let secEnclaveTag = secureEnclaveKeyTag.data(using: .utf8)! //1
let privateKeyParams: [String: AnyObject] = [

kSecAttrIsPermanent as String: true as AnyObject, //2

kSecAttrApplicationTag as String: secEnclaveTag as AnyObject, //3

kSecAttrAccessControl as String: access //4

]

1. Create a tag for the private key.
2. kSecAttrIsPermanent: A key whose value is a boolean. If true, it indicates that the cryptographic key should be stored in the default keychain at creation time.
3. kSecAttrApplicationTag: A key whose value is an attribute with a unique NSData value so that you can find and retrieve the private key later on from the key chain. It’s constructed from a string and preferable to be in reverse DNS notation.
4. kSecAttrAccessControl: access control object generated to indicate how the key can be used.

Assemble the attributes dictionary that is to be utilized for generating the key pair as the last section.

let attributes = [
kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom, //1

kSecAttrKeySizeInBits as String: 256, //2

kSecAttrTokenID as String: kSecAttrTokenIDSecureEnclave, //3

kSecPrivateKeyAttrs as String: privateKeyParams] as CFDictionary //4

• kSecAttrKeyType: A key whose value indicates the type of cryptography algorithm used to produce the key pair (public and private keys). Set to ECC (since the secure enclave supports only ECC keys)
• kSecAttrKeySizeInBits: A key whose value indicates the size of the generated key pair. Set to 256 bits (since the secure enclave supports only 256-bit keys)
• ** kSecAttrTokenID: A key whose value is kSecAttrTokenIDSecureEnclave. This indicates that the generation operation for the private key should take place inside the Secure Enclave.
• kSecPrivateKeyAttrs: A key whose value is set to the created sub-dictionary that does contain the specifications of the private key of the pair (that includes the access control object)

The last step is to generate the key pair using the attributes dictionary via the SecKeyCreateRandomKey API.

var error: Unmanaged<CFError>?
guard let privateKey = SecKeyCreateRandomKey(attributes as CFDictionary, &error) else {

throw error!.takeRetainedValue() as Error

}

The generated key is a reference to the private key stored inside the secure enclave. You can always obtain a reference to it, but can never inspect its data because it’s inside the secure enclave.

You can generate the public key afterwards from that reference of the private key that is to be distributed.

guard let publicKey = SecKeyCopyPublicKey(privateKey) else {

print(“Public key generation error”)

return””

}

Digital Signature

let message = “4043 1710 2843 4577”

guard let messageData = message.data(using: String.Encoding.utf8) else {

print(“Invalid message to sign.”)

} //1

guard let signData = SecKeyCreateSignature(

privateKey,

SecKeyAlgorithm.ecdsaSignatureMessageX962SHA256,

messageData as CFData, nil) else {

print(“Signing Error”)

return nil

} //2

let signedData = signData as Data

let signedString = signedData.base64EncodedString(options: [])

print(“Signed String”, signedString) //3

1. Create/Retrieve the message required to sign and transform it into a Data object.
2. Sign the data via the SecKeyCreateSignature security API. It takes the following parameters

• The created private key via the secure enclave
• The hashing algorithm required for encryption (SecKeyAlgorithm).
• The message Data object.

3. In case you wanted to check the signed data, you can transform it to a Base 64 encoded string and print it.

Verification

let message = “4043 1710 2843 4577”

guard let messageData = message.data(using: String.Encoding.utf8) else {

print(“ECC bad message to verify”)

return false

} //1

guard let signedMessageData = signatureString.data(using: String.Encoding.utf8) else {

print(“Invalid message to verify.”)

} //2

let verify = SecKeyVerifySignature(

publicKey,

SecKeyAlgorithm.ecdsaSignatureMessageX962SHA256,

messageData as CFData,

signatureData as CFData,

nil) //3

1. Create/Retrieve the message required to sign and transform it into a Data object.
2. Get the signed string and transform it into “Data” object.
3. Verify the data via the SecKeyVerifySignature security API. It takes the following parameters

• The created public key via the private key in the secure enclave.
• The hashing algorithm (SecKeyAlgorithm) should be exactly the same as the one used for signing.
• The message Data object.
• The signature Data object.
• Error object.

The returned value is a boolean value that indicates whether the received data is verified or not.

Summary

In this tutorial you’ve learned:

1. Symmetric vs Asymmetric Encryption & Decryption.
2. How to apply Asymmetric Encryption in iOS apps using Swift Security APIs.
3. iOS Secure Element/Enclave.
4. Digital Signature and Verification.
5. How to digitally sign and verify data via the secure enclave.

References

1. Storing Keys in Secure Enclave.
2. Signing and Verifying.
3. Generating New Cryptographic Keys.
4. iOS 10: How to Use Secure Enclave and Touch ID to Protect your Keys

On March 25th 2019, Apple announced its new consumer U.S. credit card issued by Goldman Sachs “Apple Card”. They pointed out that for every Apple Card, there’s a unique per device card number that is created and stored safely in the device’s secure element & that every purchase is authenticated with Touch ID or Face ID.

The purpose of this tutorial is to further elaborate what is the iOS device’s secure element Apple pointed out during their new Card announcement and how developers can utilize it for purposes that have to do with their applications.

First, let’s go through some base concepts to establish the purpose of this tutorial.

Symmetric and Asymmetric Encryption

Generally, encryption is some way to conceal messages between two parties to prevent unauthorized access to these messages. In other words, consider you’re sending a message to a friend and you don’t want an outsider to read that message, so you scramble it in some way that only both of you and your friend know how to read/decipher it.

One way to conceal that message is for the sender to add a password to it and provide the receiver with that password. This happens to be of certain threat because there’s a high chance that whatever method the sender uses to send the password to the receiver, it’s going to be compromised. This method is called Symmetric Encryption and proved to be inefficient and for that Asymmetric Encryption was introduced.

Asymmetric encryption mainly relies on cryptographic keys. “In cryptography, a key is a string of characters used within an encryption algorithm for altering data so that it appears random. Like a physical key, it locks (encrypts) data so that only someone with the right key can unlock (decrypt) it.”

In Asymmetric Encryption, both the sender and the receiver, have a key pair. That is a public key and a private key. Both parties share their public keys to one another and keep the private key only a secret to themselves. Whenever the sender (A) wants to send a message to the receiver (B), (A) encrypts the message using (B)’s public key, and for (B) to read the message, they have to decrypt the message using their very own secret private key.

A key pair can be generated using numerous cryptography algorithms (RSA algorithm, ECC algorithm .. etc). As a result, both generated keys are linked together but still can’t be derived from each other.

Asymmetric Encryption in Swift

For asymmetric encryption in iOS, here are the requires steps :

1. Create an attributes dictionary that would define the specifications of the asymmetric key pair to be generated. Specifications like the keys’ size in bits and the algorithm used to generate the pair. These specifications are defined via dedicated iOS Security “Key generation attributes”.
2. Passing the attributes dictionary to a dedicated Swift API to generate both the public and private keys.
3. Encrypting a message using the public key.
4. Decrypting the message using the private key.

Let’s get ourselves coding.

Attributes Dictionary

The attributes dictionary define properties for both the public and private keys. It’s done over two steps.

The first step is to create a Dictionary object that will act as a sub-dictionary in the main attributes dictionary. It defines the specifications of the private key.

let privateKeyTag = “com.security.tutorial”.data(using: .utf8)!

let privateKeyParams: [String: Any] = [

kSecAttrCanDecrypt as String: true,

kSecAttrIsPermanent as String: true,

kSecAttrApplicationTag as String: privateKeyTag]

• kSecAttrCanDecrypt: A key whose value indicates that the cryptographic private key can be used for decryption.
• kSecAttrIsPermanent: A key whose value is a boolean. If true, it indicates that the cryptographic key should be stored in the default keychain at creation time.
• kSecAttrApplicationTag: A key whose value is an attribute with a unique NSData value so that you can find and retrieve the private key later on from the key chain. It’s constructed from a string and preferable to be in reverse DNS notation.

The second step is to create the main attributes dictionary object.

let attributes = 
[kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom,

kSecAttrKeySizeInBits as String: 256,

kSecPrivateKeyAttrs as String:

privateKeyParams] as CFDictionary

• kSecAttrKeyType: A key whose value indicates the type of cryptography algorithm used to produce the key pair (public and private keys). Set to elliptic curve algorithm (ECC).
• kSecAttrKeySizeInBits: A key whose value indicates the size of the generated key pair. Set to 256 bits.
• kSecPrivateKeyAttrs: A key whose value is set to the created sub-dictionary that does contain the specifications of the private key.

2. Key Pair Generation

The first thing to do is to create two variable objects of type “SecKey” to hold references to the generated key pair (public key and private key).

//Variables to store both the public and private keys.
var publicKeySec, privateKeySec: SecKey?

Second thing is to call the SecKeyGeneratePair API to generate the public and private keys using the created attributes dictionary.

//Generating both the public and private keys via the SecGeneratePair APIs.

SecKeyGeneratePair(attributes, &publicKeySec, &privateKeySec)

3. Encryption

Let’s assume the message to be encrypted is a credit card number string.

let message = “4043 1710 2843 4577” //1

guard let messageData = message.data(using: String.Encoding.utf8) else {

print(“Bad message to encrypt”)

} //2

guard let encryptData = SecKeyCreateEncryptedData(

publicKey,

SecKeyAlgorithm.eciesEncryptionStandardX963SHA256AESGCM,

messageData as CFData,

nil) else {

print(“Encryption Error”)

}

The steps for generating an encrypted string are as follows:-

1. Set/Get the message to be encrypted.
2. Set the message to be of type Data.
3. Utilize the SecKeyCreateEncryptedData security API to encrypt the message data. You pass public key and the encryption algorithm (SecKeyAlgorithm) for it to be utilized.

4. Decryption

guard let messageData = Data(base64Encoded: encryptedString, options: []) else {
print(“Bad message to decrypt”)

return nil

} //1

guard let decryptData = SecKeyCreateDecryptedData(

privateKey,

SecKeyAlgorithm.eciesEncryptionStandardX963SHA256AESGCM,

messageData as CFData,

nil) else {

print(“Decryption Error”)

return nil

} //2

let decryptedData = decryptData as Data

guard

let decryptedString = String(data: decryptedData, encoding: String.Encoding.utf8) else {

print(“Error retrieving string”)

}

The steps for decrypting an encrypted string are as follows:

1. Get the encrypted message string & transform the encrypted message to be of type Data.
2. Utilize the SecKeyCreateDecryptedData security API to decrypt the encrypted message data. You pass to it the created private key and the encryption algorithm (SecKeyAlgorithm) used before for encryption
3. You can transform the data back to a string and print it

Where to go?

Check out the second and final part of this tutorial to learn about Digital signature and verification and how to achieve it through the ios devices’ secure enclave.

I developed a demo project with several intentional bugs to elaborate on how to use different types of breakpoints alongside the LLDB to fix bugs in your project/application.

If you didn’t go through part 1 and part 2 of this tutorial, it’s crucial to check them before proceeding with this final part.

One last time, the golden rule of this tutorial:
You’re not to stop the compiler or re-run the application after running it for the very first time. You’re fixing the bugs at runtime.

Symbolic Breakpoints 🔶

How are we doing so far?

4. The left navigation bar label that indicates how many times the user did load posts is not being updated.

Here are the steps to reproduce the last bug you’re to deal with:

✦ Scroll to the top of the table view, and pull down to refresh.
✦ Scroll to the bottom of the table view to load new posts. [for 7 times 😉]
✦ The left label is not being updated for every time new posts are successfully retrieved.

It’s important to point out that the integer pageNumber property answers the question, how many times the user did load posts..? (i.e. the left label on the navigation bar should be updated by the value of the pageNumber property). We’re quite sure from the previous fixes that the pageNumber property is updated properly, hence the problem is with setting its value to the dedicated label on the navigation bar.

In such cases, symbolic breakpoints strike in. Think of symbolic breakpoints as if the debugger is playing treasure hunt and you’re providing it with clues to get to that treasure. In your case, that happens to be the piece of code that updates the left label on the navigation bar.

Let me show you how to do that.

Show the breakpoint navigator, and click on the + button on the bottom left corner. Select symbolic breakpoint.

Add the following symbol

[UILabel setText:]

Don’t check the “Automatically continue after evaluating actions” box.

What we’re simply doing here is informing the debugger that whenever the setText function of any UILabel is called, it should pause. Notice that after creating the symbolic breakpoint, a child has been added.

It’s a feedback from the debugger that it was able to resolve the created symbolic breakpoint to a specific location inside UIKitCore framework. In other cases, the debugger might resolve the symbolic breakpoint to multiple locations.

Now you’re all set, pull down to refresh the posts table view. As soon as you release, the debugger will pause, and you’ll be seeing something like this:

At this point, you’re looking at some assembly code of the UIKitCore framework and on the left side is the stack trace that did cause the debugger to pause. The next thing we want to do is to inspect the arguments passed into the Objective-C message the debugger did pause at. In the lldb console, type the following:

po $arg1

This does point out to the register that holds the first argument. We can clearly see that the receiver of that Objective-C message is a UILabel instance. The UILabel instance has a text value that refers to a post label. It’s not what we are interested in, but let’s proceed with the registers inspection.

In the lldb console, type the following:

po $arg2

The $arg2 does always refer to the selector of the Objective-C message. In some cases, the lldb doesn’t implicitly know the types of the arguments, and hence we need to do some typecasting.

In the lldb console, type the following:

po (SEL)$arg2

Now, we can clearly see the selector of the current Obj-c message.

In the lldb console, type the following:

po $arg3

The $arg3 does always refer to the first parameter passed into the method. In our case, that is the string that is passed to the setText method.

Continue the execution of the program. The debugger will pause again. Repeat the above steps and eventually, you’ll figure out that the objective-c message belongs to another label of a post in the table view. It’s quite nonsense to keep doing this over and over again till we reach the UILabel instance that we are interested in. Things can definitely be better.

One thing you can do is to set a condition for the symbolic breakpoint to pause the debugger upon the success/fulfilment of that condition. This can be checking on a boolean value or waiting for a specific state to be reached .. etc.

However, we’re going for a different approach.

One Shot!

Disable the symbolic breakpoint you’ve created.
Logically speaking, the left navigation bar label that indicates how many times the user did load posts is updated after the posts are successfully retrieved via the HTTP GET request. Navigate to the section with the pragma mark Networking. Place a breakpoint inside the success completion handler of loadPosts. It should be below:

Objective-C

[self.tableView reloadData];

Swift

self.tableView.reloadData()

This will assure that the symbolic breakpoint will get triggered only after the table view has been reloaded and all of its equivalent labels have been updated.

Don’t check the “Automatically continue after evaluating actions” box. Add the following debugger command action:

breakpoint set --one-shot true -name '-[UILabel setText:]'

🤨🧐🤔

Let’s break that command:

1. breakpoint set --one-shot true does create a “one-shot” breakpoint. A one-shot breakpoint is a type of breakpoint that only exists till it’s triggered then it gets automatically deleted.
2. -name ‘- [UILabel setText:]’ does set a symbolic name to the created one-shot breakpoint. It’s quite similar to the one you created in the last section.

Let me recap this part. Here’s what you did:

1. Adding a breakpoint (A) in the success completion handler of the function that executes the posts GET request.
2. Adding a debugger command action to create a symbolic breakpoint (B) similar to the one you created the last section. Its symbol is the UILabel setText function.
3. Setting the symbolic breakpoint (B) you created to be a one-shot breakpoint. It’s guaranteed that the symbolic breakpoint will pause the debugger only once since a one-shot breakpoint gets deleted automatically after it has been triggered.
4. Breakpoint (A) is located after reloading the table view so that the created symbolic breakpoint (B) doesn’t pause the debugger for any of the labels related to the table view.

Now pull down the table view to refresh. Here’s what you’ll get:

The debugger did pause at the breakpoint (A) and hence setting the one-shot symbolic breakpoint.

Continue the program execution.

You’re back to the assembly code of the UIKitCore framework.

Let’s inspect the Objective-C message of the symbolic breakpoint arguments.

In the lldb console, type the following:

po $arg1

WELL WELL WELL, looks like you finally found your treasure !! 🥇🏆🎉

Time to shift our sights to the stack trace. Step to point 1.

It led you to the piece of code that is updating the pageNumberLabel text. It’s quite obvious that the text is always set to a string with a format of integer value 0 rather than the pageNumber property. Let’s test it before we make actual changes to our code.

You’re an expert now 🧢

Add a breakpoint in a separate line below the marked line of code. Add the following debugger command action:

Objective-C

expression self.pageNumberLabel.text = [NSString stringWithFormat:@"Page %tu", self.pageNumber]

Swift

expression pageNumberLabel.text = String(format: "Page %tu", pageNumber)

Remove/Disable breakpoint(A), accordingly, this will disable breakpoint(B)

Now pull to refresh and scroll to load more posts. The left navigation bar label is being updated. 🎉

Mission Accomplished !! 💪 💪

You can now stop the compiler and add the fixes we discussed in your code.

Summary

In this tutorial, you’ve learned

1. How to use breakpoints alongside debugger action expression statements to manipulate existing values/properties.
2. How to use breakpoints alongside debugger action expression statements to inject lines of code.
3. How to set watchpoints to certain properties to monitor their values when being updated.
4. How to use symbolic breakpoints to pause the debugger based on defined symbols.
5. How to use one-shot breakpoints.
6. How to use one-shot breakpoints alongside symbolic breakpoint.

Happy Debugging!! 😊

Third-party tools

I’ve used the following third-party tools for the convenience of this tutorial

• typicode/json-server

I developed a demo project with several intentional bugs to elaborate on how to use different types of breakpoints alongside the LLDB to fix bugs in your project/application.

If you didn’t go through part 1 of this tutorial, it’s crucial to check it before proceeding with this part.

Let me remind you of the golden rule of this tutorial:
You’re not to stop the compiler or re-run the application after running it for the very first time. You’re fixing the bugs at runtime.

Watchpoints 👀

Let’s march to our next enemy.

3. The user is allowed to load posts more than 7 times.

Here are the steps to reproduce this one:

✦ Turn your iPhone’s/Simulator’s internet connection on.
✦ Scroll to the bottom of the table view to load more posts.
✦ Scrolling/loading more posts is valid for more than 7 times. (Bear in mind that for the current application, the user is only allowed to load posts for 7 times only)

One approach to consider this bug is to figure out how the pageNumber integer property is being updated since it’s passed to the networking manager to retrieve new posts objects for a specific page. In a code base that you’re still unaware of, it would take you some time and effort to figure out where exactly this is happening.

Worry not! Let’s do some magic 🎩

From part 1 of this tutorial, you learned that the GET HTTP request is executed in the section with the pragma mark Networking. It only includes one function which is loadPosts. Place a breakpoint on the first line of this function and pull down to refresh to reload new posts objects. This will trigger the breakpoint you’ve just added.

In the bottom debugger window, tap on the “Show variables view button”. This will slide a new view that includes all of the properties for PostsTableViewController.

Head to the pageNumber property, right-click, and select “Watch _pageNumber” / “Watch pageNumber”.

That resulted in creating what is so-called a “Watchpoint” to the pageNumber property. A watchpoint is a type of breakpoint that pauses the debugger the next time the value of the property it’s set to get changed.

Continue the program execution. The debugger will pause and you’ll see something like this:

Objective-C

1. Logs of the old and new values of the pageNumber property.
2. The stack trace of the code that resulted in the change of the pageNumber property.
3. The current point that is causing the actual change of the pageNumber property. That is the setter method of the property.

If you fall back to point 1 in the stack trace, it will lead you to the following piece of code:

Swift

1. Debugger console informing you that the watchpoint you did set got hit.
2. The stack trace of the code that resulted in the change of the pageNumber property.
3. The current point that is causing the actual change of the pageNumber property. That is the updateForNetworkCallEnd function.

It’s obvious to conclude that for every time the HTTP GET request succeeds, the pageNumber property will increment by 1 as long as the state enum property is active. The state enum property can be one of two values either “active” or “inactive”. An active state refers that the user is able to load more posts (i.e didn’t reach the load limit [7]). The inactive state is the mere opposite to that. In conclusion, we need to implement some logic inside the updateForNetworkCallEnd that checks on the pageNumber property and sets the state enum property accordingly.

As you’ve learned, it’s quite better to test the hypothesis first and then make actual changes to your code without stopping the compiler.

You’ve guessed it right 😉

It’s important to note that there’s an already implemented function under the section with the pragma mark Support that does set the state enum property to inactive. That is setToInactiveState.

Add a breakpoint one line above the if condition. Add a debugger command action. Add the following debugger command.

Objective-C

expression if (self.pageNumber >= 7) {[self setToInactiveState]}

Swift

expression if (self.pageNumber >= 7) {setToInactiveState()}

After doing that, you need to deactivate the very first breakpoint you did utilize to set the watchpoint. Disable the watchpoint as well.

Now get back to the top of the table view, pull down to refresh, and then start scrolling down.

Don’t party yet, we still have one more bug to kill 😄⚔️

Where to go?

Check out the third and final part of this tutorial to fix the last bug and learn about a new type of breakpoints that is symbolic breakpoints.

In this 3 parts tutorial, I’ll walk you through most of what has been concluded in that WWDC session. I created a demo project specifically to elaborate on how to use different types of breakpoints alongside the LLDB to fix bugs in your project/application.

Demo Project

I developed a project of conventional tasks that most of the iOS developers out there have definitely dealt with at some point. It’s important to learn about its features/rules before proceeding with this article. Here’s what the demo project is all about:

1. A table view controller that loads a list of posts when opened for the first time.
2. The table view controller supports loading more posts when reaching the bottom end of the table view.
3. The number of times the user is allowed to load posts is restricted to 7.
4. The user is able to reload new posts via a refresh controller (pull down to refresh).
5. There are two labels on the navigation bar that do indicate how many posts have been retrieved (right label) and how many times have the user loaded posts (left label).

You can download it from here if you’re an Objective-C player.
Swift player? Download it from here.
Xcode and run it! 😉

Bugs to Fix!

Now that you’re ready with your project, you might have noticed the following bugs:

1. Pull down to refresh does not reload new posts.
2. The user is not receiving an alert (via an alert controller) whenever the HTTP request fails due to connection problems.
3. The user is allowed to load posts more than 7 times.
4. The left navigation bar label that indicates how many times the user did load posts is not being updated.

Golden Rule: For the rest of this article, you’re not to stop the compiler or re-run the application after running it for the very first time. You’re fixing the bugs at runtime.

The Power of Expression

Let’s tackle the first bug.

1. Pull down to refresh does not reload new posts.

Here are the steps to reproduce it:

✦ Run the application → the first 10 posts are loaded.
✦ Scroll down to load more posts.
✦ Scroll up to the top of the table view, and pull down to refresh.
✦ New posts are not reloaded and the old posts still exist & the posts count is not reset.

A typical approach to fix this bug is to investigate what happens inside the selector method that is assigned to the dedicated UIRefreshControl of the table view controller. Head to PostsTableViewController and navigate to the section with the pragma mark Refresh control support. We can deduce from thesetupRefreshControl function that the selector dedicated for the refresh control is the reloadNewPosts function. Let’s add a breakpoint at the first line of this function and debug exactly what’s going on in there. Now scroll to the top of the table view and pull down to refresh it.

The debugger has paused at the breakpoint you did set once you have released the refresh control. Now to further explore what happens next, tap on the debugger step over button.

Now we have a clear idea what wrong is going on !!

The if statement condition is not satisfied (i.e theisPullDownToRefreshEnabled boolean property is set to NO) and hence the equivalent code for reloading the posts is not executed.

The typical approach to fix this is to stop the compiler, set the isPullDownToRefreshEnabled property to YES/true and that would do it. But it’s more convenient to test such a hypothesis before implementing some actual changes to the code and without the need to stop the compiler. Here come the breakpoint debugger command actions of expression statements really handy.

Double tap on the set breakpoint, or right click, edit breakpoint and tap on the “Add Action” button. Select “Debugger Command” action.

Now what we want to do is set the isPullDownToRefreshEnabled property to YES/true. Add the following debugger command.

Objective-C

expression self.isPullDownToRefreshEnabled = YES

Swift

expression self.isPullDownToRefreshEnabled = true

The next thing you should do is checking the “Automatically continue after evaluating actions” box. This will cause the debugger not to pause at the breakpoint for each and every-time it gets triggered and automatically continue after evaluating the expression you just added.

Now scroll to the top of the table view and pull down to refresh.
voilà new posts have been retrieved, replacing the old ones, and hence the posts count got updated.

As you’ve just resolved the first bug, pick up your anti-bugs weapons and proceed to the second one.

2. The user is not receiving an alert (via an alert controller) whenever the HTTP request fails due to connection problems.

Here are the steps to reproduce this one:

✦ Turn off your iPhone’s/Simulator’s internet connection.
✦ Scroll to the top of the table view, and pull down to refresh.
✦ No new posts are loaded due to network error.
✦ A network error alert controller is not presented to the user.

Head to PostsTableViewController and navigate to the section with the pragma mark Networking. It only includes one function which is loadPosts. It utilizes a shared instance of a networking manager to execute a GET HTTP request that returns an array of posts object via a “success” completion handler or an instance of NSError via a “failure” completion handler.

What we want to do is to add some code inside the failure completion handler to present a networking error alert controller. If you navigated to the section with the pragma mark Support, you’ll find that there’s an already implemented function presentNetworkFailureAlertController that does handle the presentation of the required alert controller. All that we need to do is to call that function inside the loadPosts failure completion handler.

The conventional way is to stop the compiler, add the required line of code and you’re done. Let’s go for the unconventional!

Add a breakpoint inside the failure completion handler below the line

Objective-C

[self updateUIForNetworkCallEnd];

Swift

self.updateUIForNetworkCallEnd()

Double tap on the set breakpoint, tap on the “Add Action” button. Select debugger command action. Add the following debugger command

Objective-C

expression [self presentNetworkFailureAlertController]

Swift

expression self.presentNetworkFailureAlertController()

Check the “Automatically continue after evaluating actions” box.

With your internet connection disabled, scroll to the top of the table view and pull down to refresh or you can scroll down to the bottom of the table view in an attempt to load more posts. Here’s what you get 🎉🎉

What you just did was “injecting” a line of code with an expression statement implemented as a debugger command action inside a dedicated breakpoint.

Recap

Let me just recap what we did with breakpoints debugger command action expression statements:

1. Manipulate an existing property value.
2. Injecting a new line of code.

Both tasks were achieved at runtime. We didn’t really need to stop the compiler, modify things and then re-run the application.

Where to go?

Check out the second part of this tutorial to fix extra bugs and learn about a special type of breakpoints, that is watchpoints.