## Introduction
In [Part 1 of this series](blog-post/an-ios-developers-perspective-on-react-native/)  I compared native iOS development to React Native after briefly researching it. In Part 2 I will compare aspects of creating an app with basic UI and a native technology specific to iOS with both methods. For a real world comparison and context I will be recreating the Touch ID login experience from the Bank of America Mobile Banking application.

## The Login Process
The overall navigation in the Bank of America iOS app is based on the hamburger or drawer navigation paradigm. In the case of the login process certain top level features are available at all times like ‘Help & Support’ and other privileged features like ‘Accounts’ are redirected to ‘Login’ because they are only available after a user is logged in. On the ‘Login’ screen the user can either enter their username and password or use Touch ID after enrolling to login. If the user tries to login with Touch ID and fails the user can then fallback to logging in with their username and password. After the user logs in they can view their accounts and other options on the ‘Accounts’ screen.

## Native Development
To create the hamburger navigation I played with customizing a `UISplitViewController` but ultimately ended up using [SWRevealViewController](https://github.com/John-Lluch/SWRevealViewController). `SWRevealViewController` was simpler to use than other hamburger navigation libraries I’ve used in the past. Just create a `SWRevealViewController` and give it an initial front view controller and either an under left or under right view controller. It even supports setting up your view stack in a storyboard which I used in this exercise. Our initial front view controller is the ‘Login’ screen. The way this is setup in the storyboard is by connecting the ‘Reveal View Controller’ storyboard scene (highlighted in blue in the image below) to the ‘Login’ scene with a relationship segue (also in blue). The initial under right view controller is the ‘Menu’ screen, also connected with a relationship segue. On the ‘Menu’ screen I’ve added the ‘Login’, ‘Accounts’, ‘Bill Pay’, and ‘Help & Support’ items in a static table view and their corresponding segues to their related screens. Note that ‘Bill Pay’, and ‘Help & Support’ scenes are not shown in the storyboard below.

![image Screenshot](https://cdn.levvel.io/blog_content/Screen-Shot-2016-04-04-at-4.09.04-PM.png) 

To enable the redirection of selected privileged features while the user is logged out I added a flag to the `MenuViewController` to keep track of the login state. In order to intercept the segue attempted to be performed when a user taps on a menu item I also overrode the `shouldPerformSegueWithIdentifier` method in `MenuViewController`. There I check if the user isn’t logged in and trying to access a privileged screen in which case I perform a different segue to the ‘Login’ screen and return `false` to cancel the current segue.

```swift
override func shouldPerformSegueWithIdentifier(identifier: String, sender: AnyObject?) -> Bool {
    if isLoggedIn == false && privilegedSegueIdentifiers.contains(identifier) {
        let navigationController = self.storyboard?.instantiateViewControllerWithIdentifier("navSignIn")
        self.revealViewController().pushFrontViewController(navigationController, animated: true)
        return false
    } else {
        return true
    }
}
```

On the ‘Login’ screen I simply dragged out two text fields and a button and setup their constraints. I skipped the enrollment process for Touch ID so that the Touch ID prompt will be shown when the login button is pressed. Implementing Touch ID is as simple as importing `LocalAuthentication`, creating a context and evaluating the `DeviceOwnerAuthenticationWithBiometrics` policy in that content. On success the flag in `MenuViewController` is toggled to `true` and the segue to the Accounts screen is performed.

```swift
context.evaluatePolicy(LAPolicy.DeviceOwnerAuthenticationWithBiometrics,
                       localizedReason: "Logging in with Touch ID",
                       reply: { (success : Bool, error : NSError? ) -> Void in
                        
                        dispatch_async(dispatch_get_main_queue(), {
                            if success {
                                let menuVC = self.revealViewController().rearViewController as? MenuViewController
                                menuVC?.isLoggedIn = true
                                let navigationController = self.storyboard?.instantiateViewControllerWithIdentifier("navAccounts")
                                self.revealViewController().pushFrontViewController(navigationController, animated: true)
                            }
                            // Handle errors here
                        })
                        
})
```

![image native1](https://cdn.levvel.io/blog_content/native1.gif)

## React Native Development
To implement hamburger navigation on React Native I used the [react-native-side-menu](https://github.com/react-native-fellowship/react-native-side-menu) library. It abstracts the hamburger navigation to a Menu component and handy props for customizing its behavior through offset amounts and gesture settings. It works with React Native’s one-way data binding so that changing the side menu’s `isOpen` state through `setState` triggers a re-render.
Similarly, adding a `selectedItem` state allows for communication between the menu and the front view when a user selects a menu item.

I filled out the ‘Login’ screen by creating some styles for the `TextInput` views and put them inside a Flexbox container that uses the default column layout and is aligned to center. The Menu is similar except the items are left aligned by default.

For adding Touch ID functionality I found [react-native-touch-id](https://github.com/naoufal/react-native-touch-id) library to work fairly simply. I just connect my login button to the `_pressHandler` function which calls `TouchID.authenticate(‘String to show the user on Touch ID prompt’)` which returns a promise. When the promise is fulfilled the `selectedItem` is changed to `Accounts` which triggers a re-render to show a `ListView` of accounts. One thing to note is that in `_pressHandler` to correctly bind `this` an arrow function expression is needed (my example is in ES6). This tripped me up for a moment as I wasn’t getting any errors when calling `setState` on the incorrectly bound `this`.

  
 ```javascript
 _pressHandler = () => {
    TouchID.authenticate('String to show the user on Touch ID prompt')
    .then(success => {
      this.setState({
        isOpen: false,
        selectedItem: 'Accounts',
      })
    })
    .catch(error => {
    });
  };
```

![image alt text](https://cdn.levvel.io/blog_content/react1.gif) 

## Comparison
Given my experience with building native iOS apps, the native app was easier for me to build. The hardest part was the hamburger navigation since it isn’t a standard container view controller and container view controllers can get quite complicated on iOS. Thankfully `SWRevealViewController` handles the easy cases of view controller containment.

On the react native side I learned a lot about laying out views with Flexbox. Flexbox may not be able to handle complicated circular layouts like `UICollectionView` can but when is the last time you saw a circular layout in an app? For most designs Flexbox is able to handle layout just fine. I would say that it is more complicated and more powerful than springs and struts but less so than Autolayout. Even though Autolayout is more complicated, I find it is easier to learn and use especially for simpler layouts. This partly stems from the ability to use Autolayout in at least 3 different ways and one of those ways is with a visual editor which generates XML layout code which looks like React Native Flexbox code if you squint whereas Flexbox on React Native can only be used one way I believe.

When it comes to updating the layout for a data change React Native’s one-way data binding is simpler to understand. Just update your state and wait for the re-render. A bigger change than layout is the declarative style of programming with React Native. This coupled with learning some Javascript was probably the biggest hurdle for me. I’m still wrapping my head around when to use props or context, converting older examples to ES6, and learning the JSX syntax.

Overall I’m very glad I did this experiment and I don’t think that if the entire Bank of America login experience was written using React Native that a user would notice any large differences between it and fully native app. With that said there are other places in the app where a user might notice a difference such as when searching transactions since React Native doesn’t natively have access to a `UISearchController`. Of course there are always compromises and if an app is already straying from platform conventions in major ways such as using hamburger navigation and non-standard back buttons and gestures then building it with React Native shouldn’t be a problem if the trade offs are understood by everyone involved.

An iOS Developer’s Perspective on React Native – Part 2

Comparing the aspects of creating an app with basic UI and a native technology specific to iOS with native iOS development and React Native.

An iOS Developer’s Perspective on React Native – Part 2

An iOS Developer’s Perspective on React Native – Part 2

Read the Blog