VoiceOver speaks aloud the text on the screen, app names, icons, buttons, menus, links, and notifications and alerts.

These accessibility features are crucial for users who may be blind, have low vision, or have reading differences.

As a developer, it's always important to manually test your website for accessibility. A screen reader is one of the most important tools to add to your testing process. Even small issues, like a button with no label or an image with no alt text, can make a page completely unusable for someone relying on VoiceOver.

As you test on an actual device with VoiceOver, you may find accessibility issues you didn’t know you had. In this tutorial, we'll cover how to turn VoiceOver on, the basic gestures to know, and how to adjust its settings to fit your needs.

What We'll Cover:

• How to turn on VoiceOver

  • Option 1: Use Settings

  • Option 2: Use Siri

  • Option 3: Set up the Accessibility Shortcut

• Basic Gestures to Know

• How to Adjust VoiceOver Settings

  • Change the Speaking Rate

  • Change the Voice

• Conclusion

How to Turn On VoiceOver

There are a few ways to turn VoiceOver on or off. As you practice, you might lean toward one option over the others.

Option 1: Use Settings

1. Open the Settings app.

2. Tap Accessibility.

3. Tap VoiceOver.

4. Toggle it on or off.

In the Accessibility Settings section, you can also find other accessible settings to explore — including Display & Text Size, Motion, and Spoken Content. It's worth browsing through to understand what tools are available to users.

Option 2: Use Siri

To turn on VoiceOver using Siri, say: "Hey Siri, turn on VoiceOver."

To turn it off, say: "Hey Siri, turn off VoiceOver."

Using Siri might be the easiest way to turn VoiceOver on or off for beginners. If you accidentally turn VoiceOver on and don't yet know any shortcuts or gestures, just ask Siri. Siri works independently of VoiceOver gestures, so it's a reliable fallback when you feel stuck.

Option 3: Set Up the Accessibility Shortcut

If you find yourself turning VoiceOver on and off frequently, setting up the Accessibility Shortcut makes sense. This is the quickest method for developers who are regularly switching VoiceOver on to test and off to work. It lets you toggle VoiceOver by pressing the side button three times.

1. Go to Settings > Accessibility.

2. Scroll down and tap Accessibility Shortcut.

3. Select VoiceOver.

After that, press the side button (or Home button on older iPhones) three times to toggle VoiceOver on or off. If you have more than one accessibility feature enabled in the shortcut, your iPhone will show a menu to pick from instead of toggling automatically.

Basic Gestures to Know

When VoiceOver is on, the way you touch the screen changes what the phone interprets. The same swipe or tap that normally opens an app does something different with VoiceOver active.

Here are the five core gestures every developer should learn first:

• Swipe right: Move to the next item on screen

• Swipe left: Move to the previous item on screen

• Swipe up or down with three fingers: Scroll up or down the page

• One tap: Hear VoiceOver read the item aloud

• Double-tap: Open an app or activate a button

Tip: When you first tap an item, VoiceOver reads it to you. Then you can double-tap to actually open or activate it. This two-step process helps you confirm you're on the right element before you act. This is especially useful when testing unfamiliar interfaces.

These five gestures are the foundation. As you use VoiceOver more frequently, they'll become second nature. Once you're comfortable, you can explore more advanced gestures like the VoiceOver rotor, which lets you navigate by headings, links, form fields, and more.

For the time being, if you're comfortable with these five gestures, you’ll be able to test mobile accessibility issues for your products.

How to Adjust VoiceOver Settings

You can change how VoiceOver sounds and behaves to better suit your testing workflow or personal preferences.

Change the Speaking Rate

1. Go to Settings > Accessibility > VoiceOver.

2. Use the Speaking Rate slider to make it faster or slower.

You can also adjust the speaking rate with the VoiceOver rotor. Rotate two fingers on the screen until you hear “Speaking Rate,” then swipe up or down with one finger to make VoiceOver faster or slower.

This changes the rate on the fly without going into Settings. It's handy when you want to slow down while exploring a complex page or speed up when navigating familiar content.

Experienced VoiceOver users often run the speaking rate very fast. Don't be surprised if the default speed feels quick. You can always slow it down while you're learning.

Change the Voice

If you want to change the voice or language, Go to Settings > Accessibility > VoiceOver > Speech. From there, you can choose a different VoiceOver voice, add rotor voices for other languages, or enable language detection.

Apple offers multiple voice options across many languages. This is useful when testing multilingual content, but make sure your site also uses correct lang attributes so screen readers can switch pronunciation appropriately.

Conclusion

As a developer, it's always important to manually test your website for accessibility. Testing it with the accessibility features your users use is crucial to access the product through their lens and fix accessibility bugs the product might have.

Simply turning the VoiceOver on and learning about these five simple gestures will give you the tools to audit and test your website for accessibility issues.

Is there a built in recording option?

There is no built in option on iPhone to record your phone calls.

In most areas around the world, it is illegal to record someone without their expressed permission.

There are other apps and devices that you can use to record your phone calls, but always remember to ask for permission first.

It is also best to check the laws in your area concerning recording phone calls.

How to use a separate device to record calls on iPhone

One of the simplest ways to record a phone call is to use another device like a tablet, recorder, or computer. Once you have permission, hit record on the other device.

One you are done recording, then you can save that recording to the device or upload it to the iCloud.

Using Google Voice

Google Voice has an option to record phone calls, but there are a few restrictions.

The first thing to consider is that Google Voice will only record incoming phone calls to your Google Voice number. This will not work for outgoing phone calls.

It is free to get a Google voice number and download the app to your phone.

You will need to login to your account and follow the directions on how to setup your Google voice number. You can then go to the app store and search for the Google voice app.

Once you are set up with your new Google Voice number, then you can start receiving incoming calls. When someone calls you, press the number 4 on your keypad to start recording the call.

Remember to ask for permission from all participants on the call before you start recording.

To stop the recording, press the number 4 on your keypad again.

How to use other third party apps to record calls on iPhone

There are other apps you can use that will record your phone calls. Some of these options include Call Recorder or TapeACall.

A lot of these apps will be free to download, but will charge you per minute for the phone calls. Some apps will have free trial periods but it is really important to read the fine print before downloading the apps.

What is the best option?

If you are looking for an easy hassle free option, then using another device to record your phone calls is the way to go.

If you don't mind paying for an app to record your phone calls, then research through reviews in the app store to choose an application that suits your needs.

If you want to access the Downloads folder, you can find it inside the Files app. In this article, I will show you how to access the Files app and the Downloads folder.

How to locate the Files App on iPhone and iPad

If you have an iPhone and iPad running iOS 11 or later, the Files app is automatically loaded into your device.

You can also use the search feature to find the Files app.

How to locate the Downloads folder on iPhone and iPad

Step 1: Open the Files app

Step 2: Click on the Browse

Step 3: Click On My iPhone under Locations

Step 4: Click on the Downloads folder

Then you can see all of your downloaded files.

If you hold your finger down on the file you want to select, then you can see a list of available options.

Now you can copy, delete, share, rename, and perform many other options on those files.

Thanks for reading, and happy browsing!

In this short article, I will walk you through the six steps to delete an album from your iPhone.

Step 1: Go to the Photos app on your phone

First, you need to open the photos app.

Step 2: Go to Albums

Next, go to the "Albums" tab in Photos.

Step 3: Click "See All"

To see all your albums, you'll need to click the "See All" button located at the top right hand corner

Step 4: Edit the Albums

Then you'll click on Edit located at the top right hand corner.

Step 5: Select the album(s) you want to delete

Click on the red circled dash on the album you want to delete. This will select it.

Step 6: Delete the album(s)

Click the red Delete Album text and the album will be deleted.

It is important to note that if you delete an album it does not delete the photos from your phone.

If you want to delete a photo, then you will need to choose the photo from the library and click on the trash can icon on the bottom right hand corner.

Why can't I delete all of the albums from my phone?

There are certain albums on the iPhone that you cannot remove. If you followed the steps above, you will notice that there is no red dash above the Recents or Favorites albums.

Those are the default albums that already come on the iPhone. Other default albums like Screenshots and Selfies cannot be deleted, either.

You can only delete albums that you have created on your phone yourself.

This is the second part of an article on building a Spotify UI clone with autoLayout programmatically. If you missed the first part, no worries - just please go and check it now.

In this article, we are going to add some mocked pictures and try to make the UI look the same as Spotify's.

This is what we are going to do today ?

This is were we left off in the first part:

The next step is to create customized cells. So let's start by creating one with the name SubCustomCell.

First, create a new Swift file inside the project folder and name it SubCustomCell.swift. This file will contain our custom cell that will represent the Playlist. After creating the file, try to add in the code below and initialize the cell, maybe with backgroundColor, to see the UI changes when we register the cell with the collectionView.

import UIKit

class SubCustomCell: UICollectionViewCell {
        override init(frame: CGRect) {
        super.init(frame: frame)
        backgroundColor = .red
    }

    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

Then we register the SubCustomCell inside CustomCell.swift within the init block. Replace UICollectionViewCell.self with SubCustomCell like below.

 collectionView.register(SubCustomCell.self, forCellWithReuseIdentifier: cellId)

Also we need to make a modification on the cellForItemAt method and make it conform to SubCustomCell like the following.

 func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(withReuseIdentifier: cellId, for: indexPath) as! SubCustomCell
        // cell.backgroundColor = .yellow

        return cell
    }

You should see the backgroundColor changed to red .

Swift CustomCell

Up until this point everything should be straightforward and clear.

Now we're going to fill the cells with some mocked pictures and create an ImageView inside each cell. I already downloaded some random pictures from pexels.com, but feel free to use any pictures you like (including these). You can find them in the project files on Github.

Let's create the UIImageView inside SubCustomCell.swift and make some constraints.

    let ImageView : UIImageView = {
       let iv = UIImageView()
        iv.backgroundColor = .yellow
        return iv

    }()

And add it to the view within the init block using addSubView.

 override init(frame: CGRect) {
        super.init(frame: frame)
        addSubview(ImageView)

    }

Now let's make the ImageView take up all the space within the cell with the constraints below.

 ImageView.translatesAutoresizingMaskIntoConstraints = false
            ImageView.topAnchor.constraint(equalTo: topAnchor).isActive = true
            ImageView.leftAnchor.constraint(equalTo: leftAnchor).isActive = true
            ImageView.rightAnchor.constraint(equalTo: rightAnchor).isActive = true
            ImageView.bottomAnchor.constraint(equalTo: bottomAnchor).isActive = true

• LeftAnchor represents the left anchor of the cell
• rightAnchor represents the right anchor of the cell
• bottomAnchor represents the bottom anchor of the cell
• topAnchor represents the top anchor of the cell

And by making ImageView 's top anchor equal to the cell's top anchor (and doing the same for ImageView 's left, right, and bottom anchor) it makes the ImageView take up all the space of the SubCustomCell (cell).

Note: first you need to use translatesAutoresizingMaskIntoConstraints to be able to apply the constraints to the elements. Also don't forget to call isActive property and assign it to true – without doing that the constraints won't work and nothing will change.

The ImageView should have an image, so let's add one.

 let ImageView : UIImageView = {
       let iv = UIImageView()
        iv.backgroundColor = .yellow
        // we have >image1< file inside the project 
        iv.image = UIImage(named: "image1")
        iv.contentMode = .scaleAspectFill
        iv.clipsToBounds = true

        return iv

    }()

And if you build and run the app, you should see the results and picture we added to the SubCustomCell.

Cool ?. Now there is an element we should add to the SubCustomCell to finish up. We need a title that will represent the title of the playlist: UILabel.

For the title it will be like this:

 let TitleLabel : UILabel = {
        let lb = UILabel()
        lb.textColor = UIColor.lightGray
        lb.font = UIFont.systemFont(ofSize: 16)
        lb.font = UIFont.boldSystemFont(ofSize: 20)
        lb.text = "Evening Music"

        return lb
    }()

I just put some random text there – you can put whatever you like. The next step is to add the element to the view and give it some constraints. The title will be placed at the bottom of the ImageView.

Add to view:

addSubview(TitleLabel)

Applying the constraints for both the ImageView and the TitleLabel

 ImageView.translatesAutoresizingMaskIntoConstraints = false
            ImageView.topAnchor.constraint(equalTo: topAnchor).isActive = true
            ImageView.leftAnchor.constraint(equalTo: leftAnchor).isActive = true
            ImageView.rightAnchor.constraint(equalTo: rightAnchor).isActive = true
            ImageView.heightAnchor.constraint(equalToConstant: 240).isActive = true
            ImageView.bottomAnchor.constraint(equalTo: TitleLabel.topAnchor).isActive = true



            TitleLabel.translatesAutoresizingMaskIntoConstraints = false
            TitleLabel.topAnchor.constraint(equalTo: ImageView.bottomAnchor,constant: 10).isActive = true
            TitleLabel.leftAnchor.constraint(equalTo: leftAnchor, constant: 5).isActive = true
            TitleLabel.rightAnchor.constraint(equalTo: rightAnchor, constant: -5).isActive = true

And here we go!

We made the picture take up most of the space in the cell, and the rest is taken up by the title. As you can see, you can scroll horizontally in each section and also vertically in the entire screen.

Now we are put some mock data into the cells to make it feel like it's real. For that I created a JSON file that contains some random data for sections and playlists.

First let's create a two structs, Section and Playlist . We create a separate file for each struct.

section.swift

import Foundation
struct Section {
    var title : String
    var playlists : NSArray
    init(dictionary:[String : Any]) {
        self.title = dictionary["title"] as? String ?? ""
        self.playlists = dictionary["playlists"] as? NSArray ?? []

}
}

playlist.swift

//
//  playlist.swift
//  spotifyAutoLayout
//
//  Created by admin on 12/6/19.
//  Copyright © 2019 Said Hayani. All rights reserved.
//

import Foundation
struct PlayList {
    var title: String
    var image : String
    init(dictionary : [String : Any]) {
        self.title = dictionary["title"] as? String ?? ""
        self.image = dictionary["image"] as? String ?? ""
    }

}

And then inside ViewController.swift we create a function that fetches the JSON for us and stores the results in an array.

        print("attempt to fetch Json")
        if let path = Bundle.main.path(forResource: "test", ofType: "json") {
            do {
                  let data = try Data(contentsOf: URL(fileURLWithPath: path), options: .mappedIfSafe)
                  let jsonResult = try JSONSerialization.jsonObject(with: data, options: .mutableLeaves)
                if let jsonResult = jsonResult as? [ Any] {
                            // do stuff
                    jsonResult.forEach { (item) in

                        let section = Section(dictionary: item as! [String : Any])
                       // print("FEtching",section.playlists)
                        self.sections.append(section)
                    }


                  self.collectionView.reloadData()
                  }
              } catch {
                   // handle error
              }
        }
    }

The fetchJson function is called within the ViewDidLoad method. We also have a variable called sections where we store the results:

 var sections = [Section]()

The next step is to pass the data from ViewController to CustomCell. For that we create a variable inside CustomCell which will receive the data for each section:

 var section : Section?{
        didSet{
            print("section ✅",self.section)
        }
    }

We use cellForItemAt inside the ViewController method to pass the data directly to the CustomCell .

override func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(withReuseIdentifier: cellId, for: indexPath) as! CustomCell

        cell.section = sections[indexPath.item]

        return cell
    }

Note: we always call self.collectionView.reloadData() every-time fetchJson is called so the block below, inside CustomCell, will be called as well. Check the console, shift + command + C:

 var section : Section? {
        didSet{
            print("section ✅",self.section)
        }
    }

The first thing we change is to set the the section title:

 var section : Section? {
        didSet{
            print("section ✅",self.section)
            guard let section = self.section else {return}
            self.titleLabel.text = section.title
        }
    }

And then you should see that each section has a specific title on the screen ?.

Now it's time to pass the data down to SubCustomCell. We do the same thing as we did above. We need to pass the playlists array, so we create a variable named playlists inside CustomCell.

 var playlists : [PlayList]() //empty

First, we map through the playlists from the JSON. Then we add each playlist with the playlists var.

 var section : Section? {
        didSet{
            print("section ✅",self.section)
            guard let section = self.section else {return}
            self.titleLabel.text = section.title
            // append to playlists array
             self.section?.playlists.forEach({ (item) in
                let playlist = PlayList(dictionary: item as! [String : Any])
                self.playlists.append(playlist)

            })
            self.collectionView.reloadData()
        }
    }

Attention! If you try to run the app it may crash. This is because we forgot to set the number of sections. Since we are now receiving the data from JSON, the number should be dynamic based on the number of sections we have. The number of sections should be equal to the number of sections inside the JSON, so we need to modify numberOfItemsInSection inside ViewController to the below :

   override func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int {
        return sections.count
    }

We do the same thing with the same method inside CustomCell.swift – but here we consider the number of the playlists instead.

func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int {
        return  self.playlists.count
    }

The last step we have to complete is to pass each single playlist Object to SubCustomCell within cellForItemAt in CustomCell.swift.

 func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(withReuseIdentifier: cellId, for: indexPath) as! SubCustomCell
        // here ?
        cell.playlist = playlists[indexPath.item]
        return cell
    }

And we are going to get that data inside SubCustomCell via the playlist variable and finally display the title and image of the playlist.

var playlist : PlayList? {
           didSet{
               print("Playlist ?",self.playlist)
            guard let playlist = self.playlist else {return}
            // The Image ?
            self.ImageView.image = UIImage(named: playlist.image)
            // the playlist title ?
            self.TitleLabel.text = self.playlist?.title

           }
       }

I think everything should work fine now, just as below ?

One last update to the UI: we have to add some padding and margins to the section and playlist titles and make the playlist a little bit smaller.

Let's first add some padding for the section titles. To do that, we need just to give the constant property some number value inside the section cell CustomCell and within setupSubCells:

 collectionView.topAnchor.constraint(equalTo: titleLabel.bottomAnchor,constant: 15).isActive = true

And if you see the entire collectionView come in at the bottom of the titleLabel, all we need to do is add more space by adding 15:

Next we come to the title of the playlist. This will be inside SubCustomCell, and we just need to add more space at the bottom of the ImageView.

 ImageView.bottomAnchor.constraint(equalTo: TitleLabel.topAnchor,constant: -15).isActive = true

We already have the constant there. In order for it to work, the value should be -15

Finally the playlist needs to be a little bit smaller. This is easy: we just make the playlist cell's height and width equal to the section cell's height divided by 2, just like below:

CustomCell.swift

 func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAt indexPath: IndexPath) -> CGSize {

        let width = frame.height / 2
        let height = frame.height / 2

        return CGSize(width: width, height: height)

    }

Make the ImageView's height equal to 150 as well.

  //SubCutomCell.swift
  ImageView.heightAnchor.constraint(equalToConstant: 150).isActive = true

And here we go ?.

Perfect! I think that's enough for today – I don't want to make this article too long. So we will have another part where we will add the TabBar and the description, as well as some icons for the playlist.

View the Full source code on GitHub?.

Thanks for your time. I hope I haven't missed anything. If I did please @mention me on Twitter, or if you have any questions or an addition to this post the doors are always open to anyone. Thanks??.

Subscribe to my email list to be notified when the third part of this tutorial is published.

By the way, I’ve recently worked with a strong group of software engineers for one of my mobile applications. The organization was great, and the product was delivered very quickly, much faster than other firms and freelancers I’ve worked with, and I think I can honestly recommend them for other projects out there. Shoot me an email if you want to get in touch — said@devsdata.com.

Do you use Apple Pay? Have you ever wondered how an Apple Pay transaction goes through? In this post, you will learn how Apple Pay works end to end.

Mobile payments have become very popular due to the convenience and the security they offer. No more plastic cards to carry around, and you do not have to worry about losing them (what a relief!).

In this article, I am going to discuss how Apple Pay works in general and how it works when it is used at a physical POS terminal, specifically. I’ll briefly discuss the security benefits as well.

Before diving in, let’s get familiar with some basic terminology.

Secure Element

A secure element (SE) is something that is mentioned when talking about Apple Pay, so we need to understand what it is.

According to Global Platform:

A Secure Element (SE) is a tamper-resistant platform (typically a one chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (e.g. key management) in accordance with the rules and security requirements set forth by a set of well-identified trusted authorities.

Apple Pay uses SE to store secret information associated with tokenized cards (we will talk about this later).

In the iPhones after iPhone 6, and in Apple Watch, an SE is embedded into the device’s near-field communication (NFC) chip. This is used at payment terminals to perform transactions over NFC. SE emulates a payment card during an Apple Pay transaction.

Tokenization

Tokenization as a process is being adopted more and more in the payments industry. Here we’ll try to understand the basics of Tokenization.

The following is a concise description from Wikipedia on Tokenization technology:

Tokenization, when applied to data security, is the process of substituting a sensitive data element with a non-sensitive equivalent, referred to as a token, that has no extrinsic or exploitable meaning or value. The token is a reference (i.e. identifier) that maps back to the sensitive data through a tokenization system. The mapping from original data to a token uses methods which render tokens infeasible to reverse in the absence of the tokenization system

In the context of credit cards and Apple Pay, tokenization is used to replace the Primary Account Number (PAN, or the credit card number) with a token. A token looks like a normal credit card number, but it’s not the original PAN. Tokenization stops the original card number from being used during transactions.

Tokens have no meaning by themselves and are worthless to criminals if a token is stolen. There is no algorithm to derive the Primary Account Number if you have a token. This makes it impossible for criminals to reverse engineer the Primary Account Number from a token.

Click here for the Wikipedia article on tokenization if you want to learn more.

The following diagram describes the transaction flow of Apple Pay. We will discuss these step by step in the coming sections.

ymedialabs.com

Adding a Card to Apple Pay

_[http://www.iphoneincanada.ca](http://www.iphoneincanada.ca" rel="noopener" target="blank" title=")

A card can be added to Apple Pay by either scanning the card or by submitting the card information. Then this information is submitted to Apple servers.

Apple sends the received card information to the relevant card network (Visa, MasterCard, AmericanExpress, Discover, and so on). Then the card network validates the card information with the issuing bank.

After the validation, the card network acting as a TSP (Token Service Provider) creates a token (which is called a DAN or a Device Account Number in the context of Apple Pay) and a token key. This DAN is generated using tokenization and is not the actual card number.

Afterward, this information is sent back to Apple servers. After the device receives this information from Apple servers, it is saved in the device’s secure element (SE).

Initiating a Transaction Using Apple Pay

support.apple.com

When you use your Apple device at a POS terminal to make a payment, the device communicates with the terminal to initiate a transaction. Apple Pay uses EMVCO’s contactless specification to communicate with the terminal. If the terminal does not support EMV contactless, Apple Pay falls back to use contactless MSD (magnetic stripe data) mode.

EMV Contactless mode

When EMV contactless mode is used, the Apple device communicates with the terminal according to the EMV contactless specification. The secure element on the device generates a dynamic cryptogram for each transaction using the token, token key, amount, and other information related to the transaction. This dynamic cryptogram is then sent to the payment processor along with the token (DAN), transaction amount, and other required information to process the transaction.

Contactless MSD mode

Contactless MSD exists to support terminals which are still not able to process using EMV contactless mode. Most of the terminals are still operating using contactless MSD mode. Let’s take a deeper look at how a transaction goes through using contactless MSD mode.

MSD, or Magnetic Stripe Data, is how older cards store card details. Data is stored as tracks in magnetic stripe cards. Magnetic stripe cards can have up to 3 tracks, and each track (track1, track2, track3) has a different format. Please click here for additional information on track data.

In Apple Pay contactless MSD mode, the track2 data format is used to transfer the card data to the payment processor which then communicates with the card network.

Let’s take a look at some example track data sent from a terminal to the processor for an Apple Pay transaction.

370295292756481=220672716078290600047

Above is an example of track data received from a terminal which was captured at a payment gateway.

Let’s understand this data segment by segment,

• Highlighted in yellow - This is the Device Account Number or the DAN (The example DAN here is from an AmericanExpress card. You can validate the bank identification number (BIN), or initial 6 digits in the credit card number, here).
• Highlighted in blue - This is the credit card expiry year and month(yy/mm)
• Highlighted in pink - This is the service code. Click here to understand more about this.
• Highlighted in purple - This part of data is discretionary to the card network. In case of Apple Pay, this is used as a dynamic card verification value (CVV).

We learned that in the EMV mode a dynamic cryptogram is generated. Here the dynamic CVV plays the role of the cryptogram. This is generated using the token key and other transaction-related data (similar to the generation of a dynamic cryptogram).

The track data shown above is sent to the acquirer along with the transaction amount. The acquirer forwards this information to the relevant card network (Visa, MasterCard, and so on ) based on the BIN.

Completion of an Apple Pay Transaction

When the card network receives the transaction request, it identifies whether it’s an actual card number or a tokenized card number. If it is tokenized (which is the case for Apple Pay transactions), the card network validates the cryptogram (or dynamic CVV) using their copy of the token key (the card network is acting as a TSP here).

After some other additional validations, the card network de-tokenizes the DAN and obtains the original PAN (primary account number).

This transaction request is sent to the issuer (the bank or the financial institution who issued the credit card) along with the original PAN. The issuer authorizes the transaction and sends back the response which eventually reaches the POS terminal.

Yay! Transaction complete!

support.apple.com

Replaying Transaction Requests

One of the biggest problems with the traditional card transactions is the ability to replay past transaction requests (replay attack). If you resend the same transaction request, another transaction would be done with the same data.

With Apple Pay, this does not happen (also when using EMV cards directly on the terminal as well). Every transaction request can only be used once. The dynamic cryptogram (dynamic CVV in MSD mode) ensures this. For each transaction, a new cryptogram is generated which can only be used once (and is only valid for a certain time period).

Conclusion

In this article, we have gone through an overview of the Apple Pay transaction flow. I will discuss Google Pay in a coming article.

References

• http://www.gmarwaha.com/blog/2015/01/03/apple-pay-an-attempt-to-demystify-take-2/
• https://www.emvco.com/emv-technologies/contactless/
• http://msrtron.com/blog-headlines/blog-card-data
• https://www.slideshare.net/bellidcom/what-is-a-token-service-provider-52887269

Before you go!

If you have enjoyed this article, claps are welcome!

At Mobile World Congress 2018, something strange and interesting happened. No, I’m not talking about Samsung’s new S9 and S9+ phones (though they are interesting, all right).

I’m referring to the weird phenomenon of Android phone makers copying one of the iPhone X’s worst features—its wildly controversial notch.

To provide some background, the iPhone X, released in late 2017, features an all-screen design except for a notch, a cut-out at the top of the screen, that houses all the sensors required for FaceID, its new facial authentication method.

At its worst, the notch represents a compromise that Apple took in its attempt to push for an all-screen design while requiring a set of sensors for facial authentication.

iPhone X’s notch houses a whole array of sensors that enable FaceID

Many of the new Android phones released in MWC2018 (as well as those slated to be released later in the year) feature a notch at the top of their screens. Asus’ Zenfone 5, Huawei’s P20, Oppo’s R15, and Ulefone’s T2 Pro all seemed to have jumped on the bandwagon and decided on a top-notch design. Heck, even LG’s rumoured G7 is likely to feature a cut-out at the top of its screen.

If you need more proof that notches are going to be a thing in Android smartphones, look no further than Android P’s beta, which has now added official support for displays with a cutout at the top.

The worst part? None of these phones house additional sensors in their notches to offer accurate facial recognition. In other words, these notches are purely cosmetic copies of the iPhone X’s design.

This brings to mind a quote popularised by Steve Jobs:

Good artists copy, great artists steal.

To which I would like to make the following amendment, if just to add a little dramatic flair:

Bad artists copy, great artists steal

The difference between copying and stealing

So what’s the difference between copying and stealing? After all, both acts sound equally unethical.

To understand this often-repeated quote, let’s trace it back to one of its earliest sources. In 1920, the famous poet T. S. Eliot made this remark in an essay on poetry:

Immature poets imitate; mature poets steal; bad poets deface what they take, and good poets make it into something better, or at least something different. The good poet welds his theft into a whole of feeling which is unique, utterly different from that from which it was torn; the bad poet throws it into something which has no cohesion.

In other words, the difference is in the intent.

When you copy something, you’re imitating its features for the sake of creating resemblance. On the other hand, when a thief breaks into your home, he/she doesn’t steal the floor mat. Your floor mat is worthless. The thief steals your jewelry.

Copying is mindless and is about creating resemblance; stealing is done with intent and recognizes the value of something else

Stealing happens when you recognise the value in something, and apply it to your designs. It’s done with intention, with the purpose of making your design even better than it was. And most times, stealing also comes with the improvement of that which you’ve stolen, if only to make it fit perfectly within the context of your own designs.

Don’t copy. Steal.

Copying is when Asus, Huawei, and Ulefone looked at the iPhone X and decided that their new flagships would also come with a notch at the top of their screens.

Copying is when Samsung observed Apple’s Animoji—a feature Apple built into the iPhone X to make its new 3D facial recognition technology seem friendly and fun—and decided to build its own AR Emoji despite the fact that the S9 lacks sensors to track 3D movement in real time.

_Apple’s Animoji humanises facial recognition, a potentially scary piece of technology ([source](https://giphy.com/gifs/producthunt-apple-event-animated-emoji-3ohhwJ2v6v1bHegoKY" rel="noopener" target="blank" title="))

_Samsung’s version is… a little less refined ([source](https://youtu.be/8GdA4z9G4Qg" rel="noopener" target="blank" title="))

Stealing, on the other hand, is when Google realized the value of using a two-lens camera system to simulate the shallow depth of field effect found in professional SLR cameras. Google then went ahead and improved it after realizing that it could recreate the effect of having two lenses by using minuscule differences in the two halves of each pixel captured on a single lens. Thus, the Pixel 2 and 2XL phones have just one camera, but with the help of a superior algorithm they’re able to reproduce simulated depth of field photos.

Stealing is when Apple saw the promise of the Kinect’s 3D motion-sensing technology and decided to incorporate an improved version of that technology into the iPhone X to enable accurate 3D facial recognition.

Stealing is also when Japanese train designers saw the aerodynamic superiority of birds’ smooth beaks, and decided to apply this feature to create faster and quieter bullet trains.

So don’t copy — steal.

Don’t blindly emulate design patterns just because they worked for a product or service. See the value of what was done—understand the reasons for its success—and then think about how you can improve it when you apply it to your designs.

This way, you can become a great designer. Because you’re not just throwing a copied feature into your product. Instead, you’re adding value and making an idea your own. And this way, your inspirations will come not just from designs you find in your industry—they’ll come from everywhere.

More than two months after the iPhone X launch, it remains a conundrum for some to put a finger on exactly which features might justify the $1000+ price Apple has given its flagship phone.

Some might wager on the virtually edge-to-edge OLED display, which for the first time on an iPhone, does away with the tactile home button and prominent top and bottom bezels of every previous model. It is admittedly gorgeous.

As it turns out, however, the iPhone X’s most groundbreaking feature is not even discernible at first glance, even though it literally stares you in the face.

Meet the TrueDepth IR Camera

Apple has been dogged by perceptions that the company’s product roadmap has grown conservative and predictable in the six years following Steve Jobs’ passing. The new TrueDepth IR camera, as Apple calls the iPhone X’s secondary front-facing camera, could well help Apple dispel those rumors of complacency.

New to the iPhone X and housed in the black notch at the top of the display, the technology includes a number of high tech components such as a “flood illuminator,” infrared (IR) camera, and an infrared emitter. The latter emits 30,000 infrared dots in a known pattern when a face is detected, enabling the iPhone X to generate a 3D map of a user’s face. Notably, the TrueDepth IR camera can do this fast enough to support the creation of 3D motion data as well.

TrueDepth IR can create a 3D map of your face using an infrared camera and emitter. (Photo credit: Apple)

At present, there are currently two supported use cases for the new TrueDepth IR camera on the iPhone X:

• Animoji, or animated emoji — the camera animates a 3D emoji with your captured facial expressions, which you can then send via Messenger or SMS.
• Face ID — the camera uses a locally stored 3D image of your face to authenticate and unlock your iPhone X. Because it uses 3D image data, it’s much harder to trick than previous mobile face recognition systems that used a 2D image and therefore could be fooled with a photo.

Animojis are certainly fun, but they only scratch the surface of what’s possible. (Photo credit: Apple)

“What — that’s it?”

Admittedly, the current use cases for this technology are limited.

Animoji are just emoji with a fun twist, and unlocking phones hasn’t exactly been a pain point for modern smartphone users, with the prevalence of fingerprint sensors on many phones and pattern drawing as an adequate secondary option.

What’s incredibly intriguing is that the TrueDepth IR camera technology can and will have much stronger applications in the very near future. As with the iPhone’s previous Touch ID (fingerprint sensor), an iOS SDK makes it easy for app developers to use Face ID and the TrueDepth IR camera for a myriad of other more compelling use cases. In fact, Face ID uses the exact same API as Touch ID, making implementation into mobile apps incredibly simple.

Here are some of the areas where the TrueDepth IR camera could spawn useful or interesting mobile applications:

Financial Services and Internet Banking

For more than a decade, the gold standard in Internet banking authentication has been two-factor authentication. One of the most common forms of two-factor authentication has involved sending a verification code sent to your phone or email address, which must then be manually entered along with your password to access your account.

In the past few years, mobile banking apps have been quick to add support for fingerprint-based authentication. This has made it easier than ever to access your bank accounts online using your mobile phone. For the banks, this means customers have easier access to their services, resulting in increased revenues.

Why, given the already enhanced convenience of fingerprint-based authentication, would banks care about implementing face recognition into their mobile apps? To understand why, let’s consider false positive rates — the rate at which any given authentication protocol provides a false authentication. Apple claims that Touch ID, its fingerprint based authentication, has a false positive rate of 1 in 50,000. Compare that to the chance of guessing a four-digit PIN, 1 in 10,000.

Now, let’s look at the iPhone X’s new Face ID feature. Apple claims Face ID has a false positive rate of approximately 1 in 1,000,000. If true, this represents a 20-fold improvement in accuracy compared to fingerprint based authentication and 100-fold improvement over a four-digit PIN.

That’s sure to get the attention of the banks offering Internet banking, as well as of the consumers who also benefit from enhanced fraud protection. In fact, many banks have already implemented Face ID support into their iOS apps. Chase, for example, added Face ID support within two weeks of the iPhone X’s launch.

Entertainment and Fun

iOS 11 introduced ARKit, a new framework that allows developers to easily create unparalleled augmented reality experiences for iPhone and iPad. Combined with the iPhone X’s TrueDepth IR camera, ARKit opens up a revolutionary capability for robust face tracking across multiple app categories.

Imagine:

• Entering the character creation screen for Assassin’s Creed: Identity and being able to not only choose your assassin’s class but also their visual identity, using your own face in place of the default character model’s
• Having a more accurate view of a prospective match’s face before you choose to swipe left or swipe right on Tinder, Bumble, or POF
• Being able to skip a trip to Sephora or ULTA and experiment with new makeup without shelling out for everything up front

A few years ago, virtual reality (VR) technology was in the same place that the technology behind TrueDepth IR is now: a promising technology needing stronger applications in video games and entertainment.

Oculus, a virtual reality company, was founded in 2012 and ran a successful Kickstarter campaign that year, raising $2.5 million. Just two years later in 2014, Oculus was acquired by Facebook for $2 billion, or nearly one thousand times the initial financing round. Could companies that invest in entertainment applications using TrueDepth IR technology find a similar trajectory?

There are already precedents in the space, too. Two years ago — when face tracking was still based on two-dimensional images — Facebook purchased (for an undisclosed amount) Masquerade, a startup whose MSQRD app lets users create self-altered images and video using face tracking technology.

Medical and Fitness

Imagine being able to have a medical examination at any hour of the day, on-demand, from the convenience of your bed, sofa, or office chair. With the help of the iPhone X’s TrueDepth IR camera, this could become a reality.

TrueDepth IR technology has the potential to be used for medical imaging, because it can create detailed 3D maps of your face, including the surface of your skin. Notably, it can also capture 3D movement, including subtle changes in facial expression.

Consider the following potential medical use cases:

• Have a dermatologist examine an abnormal skin growth, with the ability to rotate the image for a better look at the structure of a potential tumor, for example.
• Have your phone automatically alert you when it notices facial cues or subtle movements that could be associated with the onset of a stroke, seizure, or heart attack.
• For recovering stroke patients, you might have an app that tracks any muscular degeneration over time and provides your doctors with this detailed 3D image data on demand.

While these use cases would certainly not replace the need to have in-person examinations, regular screening via phone camera could play a supporting role in enabling early detection or regular monitoring of known medical conditions.

Consider also that Apple has published a software development kit (SDK) called Apple Healthkit, which allows app developers API access to rich health and fitness information across a variety of sources: fitness wearables, health devices, and software applications. New or updated mobile apps might combine health vitals from Apple Healthkit with 3D facial image data to offer a more complete assessment of users’ health or fitness.

Apple Healthkit integrations will allow TrueDepth IR to be used for health and fitness assessments. (Photo credit: Apple)

The Future is Here

The iPhone X is the first phone to offer depth-sensing IR cameras, but it certainly won’t be the last.

“With the wide spectrum of new use cases that the technology makes possible, the impetus is now on software developers and bold businesses to bring these applications to life,” said Harry Lee, CEO of CitrusBits. Based in Los Angeles and San Francisco, CitrusBits is a mobile app development agency that designs and develops award-winning mobile apps for some of the world’s best known brands, including Burger King, Symantec, and Quiksilver.

“Those that do embrace the technology now can enjoy first mover advantages such as the ability to build a sizable market share and enjoy strong network effects that discourage future market entrants — not to mention the opportunity to get bought up by Facebook, Microsoft, or another titan of industry,” Lee explains.

To see more stories like this one, subscribe to CitrusBits’ newsletter, Bits & Bytes.

When I first started building apps with Xcode, I thought Storyboards were magic. Dragging and dropping subviews into place was so simple, I never understood how people built views without them.

Eventually, I decided that to become a “master programmer,” I would need to learn how to construct views programmatically. One problem, writing constraints in code is a pain.

let horizontalConstraint = NSLayoutConstraint(   item: newView,    attribute: NSLayoutAttribute.centerX,    relatedBy: NSLayoutRelation.equal,    toItem: view,    attribute: NSLayoutAttribute.centerX, multiplier: 1, constant: 0)

That’s a horizontal constraint that will center a subview on the X axis of its superview. Not so easy to read not to mention writing that for every constraint gets old fast. Still, I wanted to ditch storyboards so I searched for an alternative. That’s when I found SnapKit.

SnapKit has a clear and concise API that makes writing constraints in the code a breeze. I’m going to go through a few really basic examples of what can be done in SnapKit.

I’ll be going over:

1. Laying out a subview in its superview
2. Laying out subviews relative to each other
3. Updating and animating constraints

Getting started

Make sure you download SnapKit in your project. I use Cocoapods for 3rd party libraries.

Add pod 'SnapKit' to your Podfile and run pod install. Now write import SnapKit at the top of the file you want to use it in.

Laying out a subview in its superview

First off I’ll pin a subview to the edges of its superview:

let subview = UIView()view.addSubview(subview)

subview.snp.makeConstraints { (make) in    make.top.equalTo(view)    make.bottom.equalTo(view)    make.left.equalTo(view)    make.right.equalTo(view)}

This will set constraints for the top, bottom, left, and right edges of the subview to the corresponding edges of its superview with a constant of 0.

The subview pinned to its superview’s edges with a constant of 0

Notice that I add the subview to the superview before I setting the subview’s constraints. If you write constraints for views that aren’t already added to the superview, it will throw a fatal runtime error when the view loads.

The SnapKit syntax is already a lot more readable than the standard library but it can be shortened. SnapKit provides an even more concise way to constrain a view to the edges of its superview:

let subview = UIView()view.addSubview(subview)

subview.snp.makeConstraints { (make) in    make.top.bottom.left.right.equalTo(view)}

This will layout my subview the same way as the code above, but with one line instead of four.

I can also constrain the size of my subview. Below, I’m going to set the height and width of the subview and set it to the center of its superview:

subview.snp.makeConstraints { (make) in    make.width.equalTo(200)    make.height.equalTo(200)    make.centerX.equalTo(view)    make.centerY.equalTo(view)}

That example is pretty simple, but I repeated myself a lot. When setting constraints that have the same values, SnapKit allows me to chain constraints together like so:

subview.snp.makeConstraints { (make) in    make.width.height.equalTo(200)    make.centerX.centerY.equalTo(view)}

This block will result in the same constraints as the one above. Just another way SnapKit helps to write cleaner code.

Laying out subviews relative to each other

When adding many subviews to a single view, it’s likely that you’ll want to layout subviews in relation to each other. In this example, I will:

1. Add subview1 and constrain it to the left edge its superview
2. Add subview2 and constrain it to the right edge of the subview1

let subview1 = UIView()let subview2 = UIView()view.addSubview(subview1)view.addSubview(subview2)

subview1.snp.makeConstraints { (make) in    make.width.height.equalTo(100)    make.left.equalTo(view)}

subview2.snp.makeConstraints { (make) in    make.width.height.equalTo(subview1)    make.left.equalTo(subview1.snp.right)}

Up until now, I’ve wanted my constraints to be equal to the corresponding constraint for the relative view. For example, in make.left.equalTo(view)SnapKit sets the left of subview1 to the left of view. SnapKit will automatically match the constraint I set if I do not specify otherwise.

For the left constraint of subview2, I want to set it to the right edge of subview1. If I wrote make.left.equalTo(subview1) SnapKit would set the left edge of subview2 to the left edge of subview1. Instead, I use the right edge of subview1 which I grab by writing subview1.snp.right.

I can access any constraint of a view’s layout by adding snp as seen above.

subview 2 is constrained to the right of subview 1 with a constant of 0

Now that I have subview2 to the right of subview1, I’ll create some space between them by adding an offset to subview2.

subview2.snp.makeConstraints { (make) in    make.width.height.equalTo(subview1)    make.left.equalTo(subview1.snp.right).offset(50)}

An offset can be appended at the end of any equalTo() to change the constant of that constraint. Now subview2 will have a constant of 50 on its leftconstraint.

subview 2 is now constrained to subview 1 with a constant of 50

Updating and animating constraints

If you want your app to be the #NextBigThing everyone knows you’ll need to add a little flair! SnapKit provides a way to easily update constraints to create dynamic views.

Updating a constraint with SnapKit is almost identical to adding a new one. Here, I’ll update the constraint for subview1 from the previous example by changing the left edge constraint’s constant from 0 to 50:

subview1.snp.updateConstraints { (make) in   make.left.equalTo(50)}

And that’s it! My subview will update to the new constraints when the code block is run.

Clicking the button updates subview1’s constraints

You probably noticed that subview2 moved when I updated subview1 even though I didn’t update its constraints.subview2 is constrained to the right edge of subview1. When subview1 gets moved, subview2 will continue to honor the left constraint it has with subview1.

Now I’ll add an animation to smooth out the transition. If you’ve ever animated a view before, this syntax will be familiar:

UIView.animate(withDuration: 0.3) {    subview1.snp.updateConstraints { (make) in        make.left.equalTo(50)    }        self.view.layoutIfNeeded()}

When animating updates on my constraints, I need to call layoutIfNeeded()on the subview’s parent. If I’m animating more than one view at once, I will need to call layoutIfNeeded() on the subview’s closest common superview.

updateConstraints() can only update existing constraints. Attempting to update a constraint that isn’t already in place will result in a fatal run time error.

If you want to add new constraints to your subview, use remakeConstraints(). **remakeConstraints()** will remove any existing constraints you have set on that subview and allow you to add new ones.

You can also use deactivate() to remove a constraint. Below I create, set, and them remove a constraint using deactivate():

var constraint: Constraint!let subview = UIView()

subview.snp.makeConstraints { (make) in    constraint = make.height.equalTo(100).constraint}

constraint.deactivate()

You can also animate the removal of a constraint by deactivating it inside of an animation block.

So now you are a master of writing constraints programmatically. Storyboards seem like a joke now and there’s no reason to ever go back to them, right?

How it feels building storyboards after reading this guide

Not really. Storyboards and nibs are still the fastest way to put together a view controller, and, if you are working with non-developers, they are the best way to show what the app will look like without sending a beta version.

Personally, I use both. In the last app I built, I added constraints both in code with SnapKit and using Auto Layout on storyboards and nibs, sometimes on the same view. In the end, you’ll have to decide which works best for the view you are building.

Thanks so much for reading! If you liked this story, follow me on Twitter where I post articles about product management, engineering, and design.

I noticed an unusual behavior of the iPhone X home indicator while working on my most recent app. The app’s background near the home indicator is purple. When the app launches, the home indicator is very light gray.

But something odd happened when I pressed the app’s “share” button, which opened a default iOS activity view (aka “share sheet”). When I hit the “cancel” button to close the activity view, the home indicator animated to a dark gray color.

Home indicator starts light, then a share sheet passing makes it dark.

Even though the background color was exactly the same, the light-colored activity view passing underneath caused the home indicator to change color. The only way to get the home indicator back to its original color was to leave the app and come back.

I had never seen this before, and it prompted my curiosity.

What determines the color of the home indicator and why it does it behave like this? The answer is surprisingly complex. Let’s take a deep dive and see what we can learn!

Home Indicator Basics

In September 2017, Apple introduced its newest iteration of mobile phone: iPhone X. The new design replaced the iconic home button with on-screen gestures. To go home, the user simply swipes up from the bottom of the screen.

_[https://www.apple.com/iphone-x/](https://www.apple.com/iphone-x/" rel="noopener" target="blank" title=")

The Home Indicator’s Purpose

To create the affordance of being able to swipe up from the bottom of the screen, Apple added a small horizontal bar known as the home indicator. The home indicator is always present except for the home screen and in any apps that request it to be temporarily hidden (full-screen video, games, etc.).

The home indicator serves another purpose: protecting the bottom edge of the screen from conflicting user interface elements and gestures. Because the user needs to be able to swipe up from the bottom of the screen at any time, best practices now dictate that developers should avoid place conflicting gestures or buttons in the bottom edge of the display.

By placing a bar at the bottom, user interface elements in the same location look wrong—there’s a visual conflict between the bar and other elements. In this sense, the home indicator “protects” this region of the screen from designers or engineers that are unaware of the functionality of the iPhone X.

It doesn’t take a UI designer to see something is wrong here.

Now that we’re all on the same page, let’s get back to our original question: “What color is the home indicator?”

Part 1 — The Beginning

On September 13, 2017, I answered a Stack Overflow question asking how to change the color of the home indicator.

At the time, the iPhone X hadn’t been publicly released, but the latest version of Xcode included an iPhone X simulator. Running a simple test app in the simulator revealed that the home indicator’s color was based on the color of the content below it.

The new APIs for the iPhone X were released alongside this same version of Xcode, and there was no public API available to modify the color of the home indicator (which is still the case at the time of writing this post, and probably will always be the case).

This made my Stack Overflow answer simple and straightforward: it is not possible to modify the color, and you shouldn’t worry about it, since it’s out of your control and guaranteed to be visible.

Because I anticipated this to be a common question, I included some screenshots of the home indicator on top of various background colors.

Some home indicator color examples from my Stack Overflow answer.

This was good enough for me. The home indicator maintains its visibility by sampling the color of the view below it, and picking a gray color that provides sufficient contrast.

Part 2 — The Plot Thickens

It turns out the home indicator’s color is not that simple. Some further observations poked holes into my “solid-color function” theory.

Observation #1: Multiple Colors

The first observation is that the home indicator can have multiple colors, similar to a gradient. In the following example, the left side of the screen is black, and the right is white. The home indicator adjusts for this by adopting a lighter color over the dark background, and a darker color over the light background.

If you look close enough, you can see the transition from gray to black. (iOS simulator)

The home indicator can be multiple colors at the same time, and smoothly transitions between them. This smooth transition is updated in real time if any of the views behind the home indicator change.

Watch the home indicator’s color change as the white view passes underneath. (iOS simulator)

In the example above, a small white view is moving back and forth behind the home indicator. The section of the home indicator that covers the white view becomes pure black and smoothly transitions to gray.

This behavior is similar to a UIVisualEffectView, which applies a blur over existing content. The home indicator is most likely taking a sample of the nearby colors in order to get the blend effect seen in the image above.

(Besides looking good, this functionality might help prevent burn-in on the OLED display.)

Observation #2: Same Background, Different Home Indicator Color

As I mentioned at the beginning of this post, I noticed an unusual behavior when a share sheet passed beneath the home indicator.

Home indicator starts light, share sheet passing makes it dark. (real iPhone X)

This was the most surprising observation — there is not a simple 1-to-1 mapping between background colors and home indicator colors. At this point I was determined to learn more via experimentation.

Part 3 — The Investigation Begins

My first order of business was to determine the formula for the home indicator color on the iOS simulator. From my previous observations, the iOS simulator’s behavior was more predictable than a real device.

I created a new iOS app as a laboratory for my future experiements. The app was simple—all I needed was an easy way to change the background color behind the home indicator. A slider and stepper control the background color’s gray value, which is displayed as a large number in the center of the screen.

The app created for testing the home indicator.

My goal was to determine the home indicator color for every possible gray background color. I could graph this data and see if a formula applied to it. Since there were only 256 possibilities, I took the manual approach, using macOS’s built-in “Digital Color Meter” app to get the home indicator color for each value.

I graphed the results. It was not a linear function, an exponential function, or any kind of “nice” function you might see in math class.

The graph was … odd.

This was not what I was expecting.

It was a step function but with uneven steps. It had a few distinct sections: a period of (relatively) light gray, two big steps, a series of small steps, steps in the reverse direction, and a period of pure black.

The most unusual part was that the home indicator color was not always decreasing. There was a period (around rgb 170–190) where it became lighter as the background became lighter.

Why did the graph look like this? What would the same experiment have similar results on a real device? I needed to know.

Part 4 — The Investigation Continues

My next task was to perform the same experiment on a real device. It was immediately obvious that the results were going to be dramatically different.

To collect data on a real device, I used the same app from before. I streamed a live preview of the iPhone screen to my computer via QuickTime. This removed any discoloration from the True Tone display, as well as allowed me to use the Digital Color Meter app to easily inspect the colors.

Another factor added to the complexity on a real device—the red, green, and blue values were not always the same. On the simulator, the RGB values were identical, resulting in colors like RGB(54, 54, 54). On a real device, they were almost never the same, but were very close, resulting in colors like RGB(211, 209, 212). When recording the results, I took the average of the individual RGB values.

Here are the results, compared with the previous simulator data.

The colors on a real device (red line) follow a similar trend to those on the simulator (blue line), except offset by a significant margin. The simulator home indicator is always very dark, while the device home indicator is either very light or very dark.

The graph for the real device is noisy. Overall it follows a smooth trend, but jumps up and down and looks rough. This is more than just a side-effect of my averaging, and the noise is consistent. If the experiment is repeated, the noise follows the exact same pattern.

However, the graph above doesn’t tell the whole story.

The values presented above were gathered by starting the background completely black and incrementing the RGB values one at a time (going from 0 to 255). When the values are gathered in the opposite direction, the results are different.

At a certain point, the home indicator color “falls off the cliff” in its transition from light to dark or dark to light, and animates for a brief period of time, as shown in the previous gif with the purple background color. Depending on whether the background starts light or dark, the cliff occurs in a different place.

Let’s take a look at a new graph comparing the results from “going up” (black to white) and “going down” (white to black).

The blue line above is the same as the previous graph’s red line. Its data points were collected left to right (0 to 255, “going up”). The orange line is the same data, but collected in the opposite direction (255 to 0, “going down”). The red line represents the points where the home indicator and the view background are the same color.

The “going up” and “going down” lines follow a similar path, but have a different noise pattern. Interestingly, they have the exact same noise pattern in the darkest range (0–80).

From this graph we can tell that the “cliffs” occur when the color of the home indicator is coming too close to the color of the background. It even appears as if the “going up” and “going down” lines are being pushed away by the red line, actively trying to resist becoming exactly the same color as the background. At a certain point, the home indicator flips to being very dark or very light.

This explains the shift in color in the app with the purple background. The purple color must be in a region between the two cliffs. Based on the previous color of the home indicator, it could either be light or dark. When the white activity view animates behind the home indicator as it is dismissed, the home indicator transitions from its light state to its dark state, and re-settles at the dark-equivelevnt value for the purple background color.

Part 5 — The Investigation Becomes Colorful

All the tests up to this point have used grayscale backgrounds. How would the results differ if we used colored backgrounds instead?

I repeated the same experiment, but instead of modifying the gray color, I modified the hue on an HSB color scale. I kept the saturation (S) and brightness (B) at their maximum values to get the most vibrant and distinct colors. I only tested these colors “going up”, which in this case means from hue 0 (red) to hue 255 (red) in rainbow order.

The first observation is that there are two cliffs — once when the color becomes yellow, and again when the color becomes dark blue. This occurs because of the relative “brightness” of the colors.

The next observation is the difference between the simulator and a real device. The colors follow the same general trends, but the real device’s home indicator color is noisier and can reach brighter values.

These are fascinating findings so far. Aside from testing every possible background color, there’s not much else we can discover from observation alone. Now I was curious exactly how the home indicator is implemented—is it a UIView? CALayer? UIVisualEffectView? Something else? What is making it behave in this way?

Let’s find out.

Part 6 — We Need to Go Deeper!

At this point I turned to my friend and iOS expert Ian McDowell. He was able to point me in the right direction—using the iPhone X Simulator and Xcode’s debugging tools to find the home indicator.

The iOS “home screen” is actually an app called SpringBoard. We can attach a debugger to the Springboard app running in the iPhone X simulator and use the “Debug View Hierarchy” option in order to inspect the views that make up the home screen, including the home indicator.

If you want to follow along at home, here is the process:

1. Launch an iPhone X simulator.
2. In Xcode, select Debug > Attach to Process… > SpringBoard.
3. When SpringBoard is running, select the Debug View Heirarchy button.

Deep in the view hierarchy we find an MTLumaDodgePillView which is a subview of an SBHomeGrabberView. Sounds like we found the home indicator!

We found the home indicator!

The name MTLumaDodgePillView makes sense. It confirms our observed behavior of the home indicator, that its color contrasts the background based on its current brightness.

Can we go deeper yet?

SpringBoard has another cool feature: a hidden debug menu. It turns out there’s an entire section for modifying properties of the home indicator. In this debug menu, the home indicator is called a “grabber”.

So many fun sliders to play with. ?

This debug menu mainly contains visual and animation settings. It is most likely used to collaborate between design and engineering within Apple. Engineering builds the home indicator, provides hooks to all the internal parameters, lets designers fiddle with them until they are content, and then engineers use the settings for the final product.

Luckily for us, we can access this menu and see the results in the simulator.

I first played around with the visual appearance of the home indicator. There are sliders for the width and height in various states.

Some alternate home indicator sizes.

The other settings are more difficult to test, as they don’t seem to apply to the simulator. There are settings for a “luma threshold” for light and dark, as well as parameters for the animation between states. This confirms the “cliffs” where the color would dramatically animate between light and dark—there are pre-defined thresholds based on the luminosity of the background.

I was unable to determine why the simulator behaves so differently from a real device. My guess is that the simulator is using a different combination of settings, or that certain settings only take effect on real hardware.

Want to learn more about reverse engineering on iOS? Sash Zats posted an amazing in-depth article about the home indicator. Check it out if you want to dive into more code!

This marks the end of the adventure of home indicator discovery. I hope it was as educational for you as it was for me!

High-level Takeaways

1. The home indicator’s color is determined by the system and cannot be modified directly.
2. The home indicator’s color is determined by the content underneath, and it is not always a solid color.
3. The home indicator on the simulator is not an accurate representation of the home indicator on a real device.
4. The home indicator animates to its new color(s) when the content underneath changes.
5. The home indicator is either in a “light” or “dark” state.

But… Why?

Why bother investigating the home indicator if its appearance is out of our control?

There is a practical application for these learnings: If a screen in your app has a background color in the middle range where the home indicator could be either light or dark, you may prefer one style over the other. If the status bar is white, for example, it may look more visually balanced if the home indicator is white as well. Being aware of the home indicator’s nuanced behavior can help ensure that it doesn’t accidentally animate between light and dark when it could be distracting to the user.

Prefer one over the other?

In a previous example, the white share sheet animating behind the home indicator was enough to change the home indicator’s style.

If I wanted to prevent this, I could pin a view behind the home indicator between the safe area and the bottom edge of the display. When the share sheet is dismissed, I could give it a darker background color (maybe black with 40% alpha) and add a fade animation so it’s less noticeable.

This same tactic could be used to set the color of the home indicator—forcing it over one of the “cliffs”. In the vast majority of cases, the home indicator should be left alone to do what it wants. Most iPhone X users have probably already forgotten it’s even there.

The Real Lesson

Hopefully this brief investigation into the color of the home indicator helps us appreciate the complexity of simple design. “It’s just a black/white bar!” is far from the truth. The amount of care and attention to detail that went into the home indicator is worth appreciating.

Taking something simple, investigating its internal complexities, and pondering its design helps us learn about the creative process. By combining design and engineering, we can make better products that are simple and delightful to use.

Enjoyed the story? Leave some claps ? here on Medium and share it with your iOS design/dev friends. Want to stay up-to-date on the latest in mobile app design/dev? Follow me on Twitter here: https://twitter.com/nathangitter

Thanks to Ian McDowell and David Okun for helping revise previous drafts of this post.

As a user and fan of the iPhone, I filmed a spoof video for an imaginary product called The iPhone X3.

Let’s discuss the ideas presented in it, and explore the likelihood we’ll get these technologies in the future.

Solar Charging

Wireless Qi charging is finally here on the newest iPhones! This would otherwise be impressive, had I not been jealous of my friend’s wireless charging Microsoft Lumia phone — half a decade ago.

_“Solar Charging” Image: [benjamin bannister](http://www.benjaminbannister.com/" rel="noopener" target="blank" title=")

But what about the future of charging? What other power sources could we rely on? Something Apple, something technology forward.

What about solar energy? There are currently solar solutions like portable batteries, solar roofs, and solar panels.

The main hurdle behind solar is it’s not as efficient as we would like it to be. Harnessing the sun’s energy still has a ways to go. Also, the sun can’t be relied on 100% of the time, so if solar charging is implemented, it would have to be supplemental to whatever the main source of power is.

Technology forecast: Until solar capturing efficiency is significantly increased along with miniaturizing it in a small form factor, we have a long wait for this.

Wireless Transactions

In the video, a male character enters the New York City Subway by scanning his phone using NFC (near field communication) technology. He then proceeds to order movie tickets (to a fictional future “The First Annual Hunger Games” prequel/sequel), which Siri purchases automatically based on his buying habits.

_“Wireless Transactions” Image: [benjamin bannister](http://www.benjaminbannister.com/" rel="noopener" target="blank" title=")

Surprisingly, the NYC Subway has yet to catch on to wireless transportation entry, while cities like London have had it for over a decade (using RFID).

NFC is already is here with Apple Pay with more and more vendors supporting it for purchases and transactions.

Technology forecast: People are already using wireless transactions. It’s just a matter of implementation.

Augmented Navigation

Apple Maps and Google Maps have increasingly gotten better over time. We’ve seen streamlined graphics, to satellite imagery, to knowing your location and orientation, to 3D mapping entire cities, to Street View, to choosing methods of transportation, to being able to choose departure and arrival times.

Imagine your phone showing a holographic projection in front of you that overlays your surroundings along with clear directions to guide you to your destination.

_“Augmented Navigation” Image: [benjamin bannister](http://www.benjaminbannister.com/" rel="noopener" target="blank" title=")

We’ve seen this special effect in Hollywood movies, but never in real life. It can’t exist for the same reason lightsabers can’t exist: because you can’t just stop light in midair; it has to project onto some type of surface.

Technology forecast: Improbable.

Security Word

I had my phone stolen one time from a very bold pickpocket. It was in a crowded subway. I had a dark jacket on, with my iPhone in a bright orange case sticking out like one big target saying “steal me.” The subway came to a an abrupt stop and a guy pushed up against me a little too much. It was only when I went to reach for my phone later did I realize it was gone, and the guy that bumped into me was gone.

_“Security Word” Image: [benjamin bannister](http://www.benjaminbannister.com/" rel="noopener" target="blank" title=")

It was at this moment I thought of a “Security Word” as a deterrence mechanism. Imagine saying a word or phrase matched to your voice which activates an electric shock to whoever has it. Imagine! “I know who the killer is! Let’s ring this phone and find out!”

This will never happen mainly because it can be used in ways that would stir up a whole bunch of lawsuits.

Technology forecast: We could make a miniature taser, but should we put it into a phone?

Projector

In the video, we see a woman giving a presentation. We initially assume the projector feature is projecting the PowerPoint presentation behind her, but the twist is: she’s the projection.

_“Projector” Image: [benjamin bannister](http://www.benjaminbannister.com/" rel="noopener" target="blank" title=")

This is an extension of the Augmented Navigation idea. Think of it as 3D Facetime. Again, while it’s nice to imagine, you still need to project light onto a surface.

Take something as cool as these Halloween projection effects. They all look awesome, but require a surface like a wall or a sheer curtain to be seen.

There are mini projector these days but they lack resolution and brightness.

Technology forecast: Advances in projection technology could make this a reality some day. The only caveat is you need a surface to project your images on.

Adaptive LiquidMetal Shell

I was just having fun with this feature. Past news report that Apple bought an exclusive license to Liquidmetal technology. My guess is they did this so no one else would have it while testing the waters with what could be done with it. So far, only a SIM ejector pin has been made of it.

_“Adaptive LiquidMetal Shell” Image: [benjamin bannister](http://www.benjaminbannister.com/" rel="noopener" target="blank" title=")

In the video, the LiquidMetal borders the entire phone and its color can be personalized in iOS based on your preference. This was purely fiction when I made it up, something I wanted, but not something I could see happening. The whole point of this segment was to allow customization.

How could this technically happen if it could? Maybe a screen that wraps around the phone, which lights up in a color of your choosing when there is a notification. Maybe color e-ink technology could be wrapped around the phone that would maintain its color while the main screen is off.

Technology forecast: Possible, in the very distant future.

Meow To Unlock©

Apple likes to sell you on emotions. Does it make you smile? Does it delight?Live Photos (Harry Potter photos) are one such feature. I don’t know about you, but when I take the right Live Photo, I treasure it in my phone.

With the iPhone X, we have Animojis, animated emojis that can replicate our facial features onto an emoji, along with an audio recording of what we want to say. It seems… amusing, and the jury will be out until people have the iPhone X in their hands.

What else could Apple have done to make us smile? I decided everyone likes kittens, 98% of people do (I just made that statistic up). Instead of numbers to unlock our phones, why not have pictures of cute kittens? I’ll tell you now: all my friends want this feature.

_“Meow to Unlock”© Image: [benjamin bannister](http://www.benjaminbannister.com/" rel="noopener" target="blank" title=")

But wait! We now have facial unlocking. However, Apple still requires a 4–6 digit code from time to time as a backup to authenticate who you are.

Could they add an optional feature like picture unlock? Or a Meowcode© to unlock? It would only require a software update.

Technology forecast: It’s highly unlikely Apple would implement this after they’ve stuck with numbers and now facial recognition to unlock your phone. But, if any other companies wants to license this idea from me…

That concludes my insights. Sometimes it takes visualizing an idea on screen to inspire someone to make it a reality.

Let me know your thoughts on the technology, and The iPhone X3 video (give it a thumbs up on YouTube if you enjoyed it).

BONUS CONTENT: Behind-the-Scenes Storyboards

Here are scans of the original storyboards used for filming. As with most things in life, most of the work is in the preparation and planning stages, while the easiest part is the execution.

_“Solar Charging” Image: [benjamin bannister](http://benjaminbannister.com/" rel="noopener" target="blank" title=")

_“Wireless Transactions” Image: [benjamin bannister](http://benjaminbannister.com/" rel="noopener" target="blank" title=")

_“Augmented Navigation” Image: [benjamin bannister](http://benjaminbannister.com/" rel="noopener" target="blank" title=")

_“Projector” Image: [benjamin bannister](http://benjaminbannister.com/" rel="noopener" target="blank" title=")

_“Security Word” Image: [benjamin bannister](http://benjaminbannister.com/" rel="noopener" target="blank" title=")

_“Adaptive LiquidMetal Shell” Image: [benjamin bannister](http://benjaminbannister.com/" rel="noopener" target="blank" title=")

_“Meow to Unlock” Image: [benjamin bannister](http://benjaminbannister.com/" rel="noopener" target="blank" title=")

_“[benjamin bannister](https://youtu.be/QRDl_UypTx4" rel="noopener" target="_blank" title="">The iPhone X3” Image: <a href="http://benjaminbannister.com/" rel="noopener" target="blank" title=")

Show your support by clapping this article, tweeting it, sharing it, and follow me to discover new things.

_[benjaminbannister.com](http://www.benjaminbannister.com/" rel="noopener" target="blank" title=")

Also by benjamin bannister:

• SEO Secrets: Reverse-Engineering Google’s Algorithm
• What Would an Apple MacPad Pro Look Like?
• Why Typography Matters — Especially At The Oscars

Pause. Rewind. Deep dive in the design process.

Two weeks ago I posted about the possibility of an iPhone that has no Home button at all.

With iOS 11 on an iPad you enjoy a whole new app switcher. As a little design challenge, I study how this UI could work on the imminent ‘iPhone 8’, and whether it could cater for the absence of Home button.

Today I’ve paused the exploration, and I’m walking you through the design process. We’ll review my sketches in detail, see what they reveal about the train of thought (ouch!), and look at a couple of prototype variants that you’ll be able to download and try.

Being process-oriented, not product-driven, is the most important and difficult skill for a designer to develop.

Matthew Frederick

Sketches and prototypes below are provided as is, they haven’t been modified at all for the sake of this article. I include raw scans of my large sketch boards, so the post is probably best viewed on desktop or tablet.

Sketching

I always keep my sketches and notes. They’re useful to review in slow motion what has happened in the mind, assess the reasoning, and have a fresh look at germinating ideas that were forgotten on the road side.

For this project I used two A3 sheets. Let’s comment the key screens:

1. Trying to force-fit the iPad design. In that first attempt, everything is on a single horizontal scroll view. And there’s a Home button! False start.

2. Trying again. But stopping fast since clearly, it’s not going to work. My proportions are completely unrealistic. Lack of discipline.

3. A more realistic ratio. I finally acknowledge it’s a very long phone I’m dealing with (6/13 ratio). I’m going to need my imagination. The whole view now scrolls vertically, with apps on 2 columns. An accident happens here: my focus has now shifted to the iPhone’s Control Centre (that I’m probably examining on my iOS 11 phone, as a model for the sketch). I’m misled and add the little chevron at the top, meaning “swipe down to close”.

Sheet 1 of 2

4. A potential conflict. Because I now wrongly assume the UI can be swiped down, I worry this is going to interfere with my vertical scroll. I capture this in a side note: “KO since swipe needed to close overlay”. I swap things, move apps to the top, as if it could help, but finally plant the seed of an alternative idea: “Recent apps @ top but as horiz. carousel”.

5. One last shot at the vertical scroll. Here, I guess I’m seeking confirmation that the vertical approach is flawed... But my mind forks again as I notice a new issue! Controls and recent apps compete for visibility: Scroll to view one and the other is pushed out of bounds. They’re part of the same strap. At that point I decide to try decoupling them.

Sheet 2 of 2

6. Recent apps as horizontal carousel. That looks more familiar for an app switcher. Controls still scroll vertically, though — so how does that work as a whole? Doesn’t feel right. I appear distracted again between 6 and 7 but let’s skip that.

7. Two parallel scroll views. The control group and the app carousel are now free to move without running into each other. Space is shared equally. I annotate some elements with “Size?”: Can I afford that layout on the real device? Only one way to know: Increase fidelity. But overall I sense I’ve got a candidate solution I can work with.

Observations

I don’t state my goal. That’s a pity because something as simple as “Adapt the new iPad switcher to the iPhone 8” (even if obvious) would have focused me sooner on the actual issues.

I don’t have a very clear logic in mind. Evidence of confusion: The fallacy that the UI is an overlay that can be swiped down, and the Home button that I remove then for some reason bring back (don’t ask!).

I seem mainly concerned by a layout problem. Apparently I don’t worry much about how to access the home screen. Yet that’s very key in my experiment! I do leave a shy trace at step 3: “Lacks obvious way to go to HS”, and then stick a Home button everywhere. This is embarrassing (given the experiment is all about button-less!) — I’m probably aware that at some point I need to find empty space so the background can be tapped, like on the iPad switcher, but I wouldn’t swear. The Home button looks more like a mechanically applied FIX-ME label, something I don’t want to deal with yet.

Being process-oriented means: [Long list that includes:] Working fluidly between concept-scale and detail-scale to see how each informs the other.

Matthew Frederick

My drawing and handwriting look awful. But somehow that’s positive. In the process of doing these sketches it never occurred to me that I would share them later; in the moment, the absence of aesthetic requirements actually did reinforce focus.

Side notes help inform my next steps. Sketch, evaluate, note issues, and try addressing them in a future iteration. Any change can bring new problems, and the sooner I capture them, the better. It’s just so easy to spot and forget. I’ll take side notes more systematically in the future.

Prototyping

You can try the prototypes below if you use Principle, on a Mac or an iPhone directly. Click the movie captions to download the Principle .prd files. To learn more check Principle’s docs, and my tips at the end of the post.

_[Download v8](https://www.dropbox.com/s/i8lsat5mq5w9x8i/homeless%20v8.prd?dl=1" rel="noopener" target="blank" title=")

An early version (v8 above) features the chevron at the top and a discreet Home button at the bottom. Tapping the chevron re-opens the current app (what else could it do?) but so does a tap on the app miniature already.

So this chevron based interaction looks silly, in hindsight. Pay attention to the animation it triggers: While it does the right thing (zooming in the app correctly represents the action of bringing it to the foreground), it is disconnected from the chevron object itself. The chevron, on one hand, is doing what you want (dismiss switcher and return to app) but on the other hand it does not behave as you’d expect (slide down). Prototyping instantly trapped the contradiction here. I should have caught the flaw much earlier, but that’s ok — there are many things in my life that I should’ve done earlier.

_[Download v11](https://www.dropbox.com/s/6dsveqoqusqam8g/homeless%20v11.prd?dl=1" rel="noopener" target="blank" title=")

The chevron is gone (v11 above) but I now experiment with a home screen miniature (like in iOS 10's switcher). This is efficient for the home screen use case, but it pushes the previous app (green) too far left for a right-hander. And there’s duplication again: the Home button becomes redundant, but if I remove it then the user can only rely on the miniature to go to home screen, which is too far right for left-handers! They could scroll but in this particular case I certainly don’t want them to have to.

There’s another aspect: this model is inconsistent with my target one, whereby only a tap on the background should take you home. This is key for the coherence of the whole, and central to the beauty of the new iOS 11 switcher. Why? Because the blurred background behind the switcher is the home screen. Any specific affordance to access the home screen (such as a Home button or my miniature) is superfluous (not to say incoherent) when you can interact with the home screen directly. Depth is one of the core design principles in iOS — with Clarity and Deference — and Apple beautifully builds on it here.

Main mental model layers in iOS 11

_[Download v14](https://www.dropbox.com/s/9p5zon3u8kfkjru/homeless%20v14.prd?dl=1" rel="noopener" target="blank" title=")

In the final v14 iteration above I clean up and more strictly align with the iPad switcher. That’s the version I present in part 1. A further improvement could be to enlarge the empty area at the bottom, for instance by limiting the Control Centre grid to 3 rows.

One last quote from Matthew Frederick’s excellent 101 Things I Learned in Architecture School:

Properly gaining control of the design process tends to feel like one is losing control of the design process […] Accept uncertainty. Recognize as normal the feeling of lostness that attends to much of the process.

On my journey I drifted away from my initial goal several times and accidentally glimpsed at different possibilities. Some may be worth revisiting later, some opened my eyes to new pitfalls. The wandering isn’t waste, it is the essence of exploration. At the same time one can’t keep opening boxes and adding todos forever; it’s also important to deliver reasonably stable and presentable solutions as you go along. The challenge is to strike a balance between breadth and depth.

Tips – if you try the prototypes

• Interactions are limited to: swipe up, scroll horizontally, tap the blue app miniature, tap the switcher’s background. In the home screen, tap the blue icon only.
• The intermediate Dock state that I describe in the previous post is not supported by the prototypes I share here. In order to create the Dock state movie I made a temporary modification.
• The prototypes are designed for the ‘iPhone 8’ itself, at 375 * 812 points (145 pt taller than an iPhone 6/7). So if your test device, like mine, is a 6/7 series, Principle scales down the UI a bit so that it fits your display: Everything looks a bit smaller than it should be. And positioned a bit higher too, due to the bottom area on the 6/7 (no such chin on the future edge to edge display).
• However, if you open this image on a 6/7 you get a much better idea of the expected ‘iPhone 8’ feel. Just imagine the phone is taller and that you can tap the bottom area anywhere. You may need to first save the image to your photo library. It’s supposed to fill the entire screen and look like this: