Forem: TJ Maynes

Finding and Reporting a SwiftUI bug

TJ Maynes — Mon, 25 Oct 2021 00:35:01 +0000

TL;DR: There is a bug in SwiftUI 2.0, that occurs in iOS versions 14.5 and up, where your NavigationLink logic will start to redirect in an unexpected way when you have more than two NavigationLinks in the same SwiftUI view.

Introduction

Recently, my pair and I were tasked with building a user onboarding experience in our internal iOS application. The requirements for this experience included enabling the user to navigate back and forth, and due to API calls, double popping (back to parent's parent view).

Since a majority of the UI development in our iOS application is built using SwiftUI, we thought that we could easily use SwiftUI's programmable NavigationLinks to build this experience out.

In this blog post, I'm going to document how to reproduce a bug my pair and I found in SwiftUI 2.0, where having more than two NavigationLinks (a common workflow) will break navigation logic in iOS 14.5+, and how to report this bug to Apple.

**BTW* if you'd like to follow along with code by your side, I've made the source code for this project available on GitHub.*

The Setup

To reproduce this bug, let's begin by following red-green-refactor and writing our first failing XCUITest test in Xcode, as seen below:

import XCTest

class AwesomeAppUITests: XCTestCase {

  func test_whenUserTapsThroughMoreThanTwoScreens_itShouldTakeThemToLastScreen() {
    let app = XCUIApplication()
    app.launch()

    XCTAssertTrue(app.staticTexts["First screen"].exists)
    app.buttons["Tap me!"].tap()

    XCTAssertTrue(app.staticTexts["Second screen"].exists)
    app.buttons["Tap me, again!"].tap()

    XCTAssertTrue(app.staticTexts["Third screen"].exists)
    app.buttons["One more time..."].tap()

    XCTAssertTrue(app.staticTexts["Final screen"].exists)
  }
}

In our UI test we expect to be able to tap through four different screens ("First screen", "Second screen", "Third screen" and "Final screen"). After running the UI test, we expect to see our UI test fail because we have not implemented the code to make this UI test pass. Now that we're red we can move on to writing our implementation code to make our UI test green.

Enter NavigationLinks

We decided to use SwiftUI NavigationLinks because it enables developers to programmatically navigate between multiple SwiftUI views. There are multiple ways to use NavigationLinks including:

using a NavigationLink like a button (non-programmatically)
using NavigationLink's isActive to programmatically control one navigation link
using NavigationLink's tag and selection to programmatically control more than one navigation link

For our particular use-case it makes sense for us to make our UI tests pass by using the tag and selection feature of NavigationLinks. So, we start writing our implementation.

First, we added a new Scene for our AwesomeApp to load on startup.

@main
struct AwesomeApp: App {
  var body: some Scene {
    WindowGroup {
      MainView()
    }    
  }
}

Next, in a file called ContentView.swift, we'll create a reusable View called ButtonView, which contains a Text title and a tappable button, so that the user can to navigate to the different screens.

import SwiftUI

struct ButtonView: View {
  let message: String
  let buttonTitle: String
  let onTap: () -> Void

  var body: some View {
    VStack {
      Text(message).padding()

      Button(action: { onTap() }) {
        Text(buttonTitle)
      }
    }
  }
}

Next, we created our ContentView, which will be responsible for orchestrating the navigation flow between ButtonViews via NavigationLink. To accomplish this, we setup a State variable called selection that we'll update as the user taps through each screen (thus updating state to show the next view) and then assigned each NavigationView a tag so when selection is updated SwiftUI should redirect the user to the correct NavigationLink destination based on it's tag.

...

struct ContentView: View {
  @State private var selection: String?

  var body: some View {
    NavigationView {
      VStack {
        ButtonView(
          message: "First screen",
          buttonTitle: "Tap me!",
          onTap: { self.selection = "view-2" }
        )

        NavigationLink(
          destination: ButtonView(
            message: "Second screen",
            buttonTitle: "Tap me, again!",
            onTap: { self.selection = "view-3" }
          ),
          tag: "view-2",
          selection: self.$selection
        ) { EmptyView() }

        NavigationLink(
          destination: ButtonView(
            message: "Third screen",
            buttonTitle: "One more time...",
            onTap: { self.selection = "view-4" }
          ),
          tag: "view-3",
          selection: self.$selection
        ) { EmptyView() }

        NavigationLink(
          destination: Text("Final screen"),
          tag: "view-4",
          selection: self.$selection
        ) { EmptyView() }
      }
    }
  }
}

We should be in a good place now to run our UI tests. As seen in the below gif.

We find that our UI Test is passing, and after a sanity checking by opening the app in the simulator and seeing everything work accordingly, we're ready now to push to pipeline. Eventually, we find that everything passed in our pipeline! So, we're done here...right?

The Bug

We let out Project Manager know our story was ready to be QA'd and that they could download the latest iOS QA build from AppCenter. Less than five minutes later, we get a message from Product saying the story was getting restarted (our backlog is in Pivotal Tracker) because the experience didn't work. Our PM even included a screen-recording of what they experienced and as you'll guess, it wasn't the same experience we were seeing locally in our iOS simulator.

After going back and forth with our PM we discover that our PM is running the latest iOS version (currently iOS 14.7.1), so we download the latest version of Xcode (due to client constraints we were unable to do this on client machines easily), and ran the app on an iOS 14.5 simulator. And like magic we were able to reproduce the bug and see our UI tests do not pass either! Below is a screen-capture of the failure occurring in an iOS 14.5 simulator:

We even get a bug report from Apple in the console window:

We were able to turn the bug "on and off", when we commented out the third NavigationLink, which means that in order to control the flow of multiple views in SwiftUI, and support iOS devices 14.5 and higher, we'd need to break out our NavigationLinks into subviews.

Opening a bug report

To disclose our bug to Apple, let's first sign into Apple's Feedback Assistant portal. Next, in the top-left corner, we'll tap the "New Post" icon. Next, we'll choose "Developer Tools" from the predefined list of "Feedback starting points". After this, we'll have a new "Feedback form" to fill out.

For us we'll input the following for our Feedback form:

A "descriptive title" for this bug will be "SwiftUI - Unable to use more than two NavigationLinks in the same SwiftUI View".
The "area" we are seeing this issue is in the "SwiftUI Framework".
We are reporting "Incorrect/Unexpected Behavior" from the SwiftUI Framework

Next, we'll add a helpful description. Helpful descriptions come in many shapes and sizes, so it's best to have some structure to help assist an Apple Developer on the issue you report. Below is an example format you can follow:

# Expected behavior:
I should be able to...
# Unexpected behavior:
It is doing this instead...
# Reproducible steps:
1. Step 1
2. Step 2

Try to put yourself in the Apple support teams' shoes...what all would you need to reproduce the bug?

For us, let's include the following as our helpful description to the Apple support team:

Reproducible builds:
The bug exists in iOS 14.5+ simulators and devices.

Expected behavior:
I should be able to programmatically control the flow of multiple NavigationLinks destinations (within the same View) using `selection` and `tag`.

Unexpected behavior:
When a third NavigationLink is added to a SwiftUI View, the second NavigationLink will redirect back to the NavigationView root and not to the third NavigationLink destination.

Notes:

I've included a SwiftUI test that should fail (thus reproducing) the bug when running the XCUITest suite in an iOS 14.5 simulator. This XCUITest suite passes when running in an iOS 14.3 simulator.

--- ApplicationTest.swift
import XCTest

class AwesomeAppUITests: XCTestCase {

  func test_whenUserTapsThroughMoreThanTwoScreens_itShouldTakeThemToLastScreen() {
    let app = XCUIApplication()
    app.launch()

    XCTAssertTrue(app.staticTexts["First screen"].exists)
    app.buttons["Tap me!"].tap()

    XCTAssertTrue(app.staticTexts["Second screen"].exists)
    app.buttons["Tap me, again!"].tap()

    XCTAssertTrue(app.staticTexts["Third screen"].exists)
    app.buttons["One more time..."].tap()

    XCTAssertTrue(app.staticTexts["Final screen"].exists)
  }
}
---

--- ContentView.swift
import SwiftUI

struct ButtonView: View {
  let message: String
  let buttonTitle: String
  let onTap: () -> Void

  var body: some View {
    VStack {
      Text(message).padding()

      Button(action: { onTap() }) {
        Text(buttonTitle)
      }
    }
  }
}

struct ContentView: View {
  @State private var selection: String?

  var body: some View {
    NavigationView {
      VStack {
        ButtonView(
          message: "First screen",
          buttonTitle: "Tap me!",
          onTap: { self.selection = "view-2" }
        )

        NavigationLink(
          destination: ButtonView(
            message: "Second screen",
            buttonTitle: "Tap me, again!",
            onTap: { self.selection = "view-3" }
          ),
          tag: "view-2",
          selection: self.$selection
        ) { EmptyView() }

        NavigationLink(
          destination: ButtonView(
            message: "Third screen",
            buttonTitle: "One more time...",
            onTap: { self.selection = "view-4" }
          ),
          tag: "view-3",
          selection: self.$selection
        ) { EmptyView() }

        NavigationLink(
          destination: Text("Final screen"),
          tag: "view-4",
          selection: self.$selection
        ) { EmptyView() }
      }
    }
  }
}
---

This description includes expected and unexpected behavior, notes and some reproducible Swift test cases and code. Finally, let's upload our video recordings (the animated gifs) to the Feedback form too.

You can find the bug I reported in the OpenRadar portal here.

Conclusion

If you happen to come across a bug in SwiftUI, or in any standard library and/or dependency you rely on, try to take the time to document the bug in a blog post. This helps grow a deeper understanding of your toolchain, improves your communication skills and you may be helping another lone wanderer with the same problem they are facing. Also, reporting the bug in the appropriate issue tracking portal would be extremely helpful too.

Implementing the Health Check API Pattern with Rust

TJ Maynes — Mon, 25 Oct 2021 00:29:32 +0000

This week while I was preparing a Rust-based backend service to be deployed to a Kubernetes cluster, I realized I hadn't yet configured my backend service to be probed by kubelet for liveness and readiness checks. I was able to accomplish this requirement by adding a /health API endpoint that responds with an Ok or ServiceUnavailable HTTP status based on the current state of your service.

This /health API endpoint solution is an implementation of the Health Check API pattern, a pattern for checking the health of your API service. In web frameworks like Spring a drop-in solution like Spring Actuator is available for you to integrate into your Spring project. However, in many web frameworks you have to build this Health Check API behavior yourself.

In this blog post, we are going to implement the Health Check API pattern using the actix-web web framework that uses sqlx to connect to a local PostgreSQL database instance.

Prerequisites

Before getting started make sure that you have Cargo and Rust installed on your machine. The easiest way to install these tools is to use rustup.

Also have Docker installed on your machine so we can easily create and connect to a PostgreSQL database instance.

If this is your first time seeing the Rust programming language, I hope this blog post inspires you to take a deeper look into an interesting statically typed language and ecosystem.

If you'd like to follow along with code by your side, I've made the source code for this project available on GitHub.

Creating a new Actix-Web project

Let's go ahead and open your favorite Command-line terminal and create a new Cargo project via cargo new my-service --bin.

The --bin flag will tell Cargo to automatically create a main.rs file to let Cargo know that this project is not a library but will produce an executable.

Next, let's check that we are able to run the project by running the command: cargo run. After you've run this command, you should have something printed like the text below.

    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/health-endpoint`
Hello, world!

Easy-peezee, right?

Next, let's get our PostgreSQL instance up and running.

Running PostgreSQL

Before we create our PostgreSQL instance with Docker Compose, we need to create an initial SQL script that create our database. Let's add the following into a SQL file called init.sql in a directory called db in the root of the project.

SELECT 'CREATE DATABASE member'
WHERE NOT EXISTS (SELECT FROM pg_database WHERE datname = 'member')\gexec

This script will check to see if a database called "member" already exists and if not it will create the database for us. Next, let's copy the following YAML into a docker-compose.yml file and run docker compose up.

version: '3.1'

services:
  my-service-db:
    image: "postgres:11.5-alpine"
    restart: always
    volumes:
      - my-service-volume:/var/lib/postgresql/data/
      - ./db:/docker-entrypoint-initdb.d/
    networks:
      - my-service-network 
    ports:
      - "5432:5432"
    environment:
        POSTGRES_HOST: localhost
        POSTGRES_DB: my-service
        POSTGRES_USER: root
        POSTGRES_PASSWORD: postgres

volumes:
  my-service-volume:

networks:
  my-service-network:

After some colorful text has 🌈 printed down your console window, you should have PostgreSQL up and running.

Okay now that we have confirmed our service runs and we have an instance of PostgreSQL running locally, let's open up your favorite text editor or IDE and add our project dependencies to our Cargo.toml file.

[dependencies]
actix-web = "4.0.0-beta.8"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
sqlx = { version = "0.5.7", features = [ "runtime-actix-native-tls", "postgres" ] }

For sqlx, we want to make sure we include the "postgres" feature during compilation, so we have PostgreSQL drivers to connect to our PostgreSQL database with. Next, we'll want to make sure we have the runtime-actix-native-tls feature included so that sqlx can support the actix-web framework which uses the tokio runtime. Finally, let's include serde and serde_json for serializing our Health Check API response body for later in the post.

**Note:* For newcomers to Rust, you may be thinking to yourself, "what the heck? Actix runtime? I thought actix-web was just a web framework for Rust." Well it is and it's much more. Since Rust was not designed to with any specific runtime in mind, a specific runtime is needed for the problem domain that you are currently in. There are runtimes specifically for handling client/server communication needs such as Tokio, a popular event-driven, non-blocking I/O runtime. Actix, the underlying runtime behind actix-web, is an actor-based messaging framework built on-top of the tokio runtime.*

So, now that we've added our dependencies, let's go ahead and create our actix-web service. To do this let's replace the content in the src/main.rs file with the following Rust code:

use actix_web::{web, App, HttpServer, HttpResponse};

async fn get_health_status() -> HttpResponse {
    HttpResponse::Ok()
        .content_type("application/json")
        .body("Healthy!")
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .route("/health", web::get().to(get_health_status))
           // ^ Our new health route points to the get_health_status handler
    })
    .bind(("127.0.0.1", 8080))?
    .run()
    .await
}

The code above gives us an HTTP server running on port 8080 and a /health endpoint that always returns an Ok HTTP Response status code.

Back in your terminal, run cargo run to see the service up and running. In a new tab, go ahead run curl -i localhost:8080/health and see that you receive a response like below:

$ curl -i localhost:8080/health
HTTP/1.1 200 OK
content-length: 8
content-type: application/json
date: Wed, 22 Sep 2021 17:16:47 GMT

Healthy!%

Now that we have basic health API endpoint up and running, let's change the behavior of our health API to return an Ok HTTP Response status code when the connection to our PostgreSQL database is alive. To do this, we'll first need to establish a database connection using sqlx.

Creating the database connection

Before we can establish a database connection using sqlx's connect method, we'll need to create a database connection string, formatted as such <database-type>://<user>:<password>@<db-host>:<db-port>/<db-name>, that matches our local PostgreSQL setup.

Also, instead of hardcoding our database connection string, let's make it configurable through an environment variable called DATABASE_URL and prepend the variable before each of our cargo run calls, as seen below:

DATABASE_URL=postgres://root:postgres@localhost:5432/member?sslmode=disable cargo run

With the DATABASE_URL environment variable available to us, let's add a line to our main function to fetch our newly exported environment variable.

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let database_url = std::env::var("DATABASE_URL").expect("Should set 'DATABASE_URL'");
    ...

Next, let's write some more code to create a database connection in our main function.

    ...
    let db_conn = PgPoolOptions::new()
        .max_connections(5)
        .connect_timeout(Duration::from_secs(2))
        .connect(database_url.as_str()) // <- Use the str version of database_url variable.
        .await
        .expect("Should have created a database connection");
    ...

Before we can pass our database connection to our health endpoint handler, we'll first need to create a struct that represents our service's shared mutable state. Actix-web enables us to share our database connection between routes, so that we don't create a new database connection on each a request which is an expensive operation and can really slow down the performance of our service.

To accomplish this, we'll need to create a Rust struct (above our main function) that we'll call AppState containing our db_conn reference.

...
use sqlx::{Pool, Postgres, postgres::PgPoolOptions};
...

struct AppState {
    db_conn: Pool<Postgres>
}

Now, underneath our db_conn instantiation, we're going to create an AppState data object that is wrapped in a web::Data wrapper. The web::Data wrapper will allow us to access our AppState reference within our request handlers.

    ...
    let app_state = web::Data::new(AppState {
        db_conn: db_conn
    });
    ...

And finally, let's set the App's app_data to our cloned app_state variable and update our HttpServer::new closure with a move statement.

    ...
    let app_state = web::Data::new(AppState {
        db_conn: db_conn
    });

    HttpServer::new(move || {
        App::new()
            .app_data(app_state.clone()) // <- cloned app_state variable
            .route("/health", web::get().to(get_health_status))
    })
    .bind(("127.0.0.1", 8080))?
    .run()
    .await

If we don't clone the app_state variable Rust will complain that our app_state variable was not created inside of our closure and there is no way for Rust to guarantee that app_state won't be destroyed when called upon. For more on this, checkout Rust Ownership and the Copy trait docs.

So far our service code should look like the following:

use actix_web::{web, App, HttpServer, HttpResponse};
use sqlx::{Pool, Postgres, postgres::PgPoolOptions};

async fn get_health_status() -> HttpResponse {
    HttpResponse::Ok()
        .content_type("application/json")
        .body("Healthy!")
}

struct AppState {
    db_conn: Pool<Postgres>
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let database_url = std::env::var("DATABASE_URL").expect("Should set 'DATABASE_URL'");

    let db_conn = PgPoolOptions::new()
        .max_connections(5)
        .connect_timeout(Duration::from_secs(2))
        .connect(database_url.as_str())
        .await
        .expect("Should have created a database connection");

    let app_state = web::Data::new(AppState {
        db_conn: db_conn
    });

    HttpServer::new(move || {
        App::new()
            .app_data(app_state.clone())
            .route("/health", web::get().to(get_health_status))
    })
    .bind(("127.0.0.1", 8080))?
    .run()
    .await
}

Now that we have passed our app_state object, containing our database connection, into our App instance, let's go ahead and update our get_health_status function to check whether our database connection is alive and well.

The database connection check

To capture our AppState data from our get_health_status function, we need to add an Data<AppState> argument to our get_health_status function.

async fn get_health_status(data: web::Data<AppState>) -> HttpResponse {
    ...

Next, let's write a lightweight PostgreSQL query to check our database connection using the SELECT 1 query.

async fn get_health_status(data: web::Data<AppState>) -> HttpResponse {
    let is_database_connected = sqlx::query("SELECT 1")
        .fetch_one(&data.db_conn)
        .await
        .is_ok();
    ...

Next, let's update the HttpResponse response to return an Ok when our database is connected, and ServiceUnavailable when it is not. Also, for debugging purposes let's include a more useful response body, than healthy or not healthy, by serialize a Rust struct, using serde_json, that describes why our health check succeeded or failed.

    ...
    if is_database_connected {
        HttpResponse::Ok()
            .content_type("application/json")
            .body(serde_json::json!({ "database_connected": is_database_connected }).to_string())
    } else {
        HttpResponse::ServiceUnavailable()
            .content_type("application/json")
            .body(serde_json::json!({ "database_connected": is_database_connected }).to_string())
    }
}

Finally, let's run our service with the cargo run command:

DATABASE_URL=postgres://root:postgres@localhost:5432/member?sslmode=disable cargo run

Next, open up another terminal tab and run the following curl command:

curl -i localhost:8080/health

Which should return the following response:

HTTP/1.1 200 OK
content-length: 27
content-type: application/json
date: Tue, 12 Oct 2021 15:56:00 GMT

{"database_connected":true}%

If we were to turn off our database via docker compose stop, then after two seconds you should see a ServiceUnavailable HTTP response when you call the previous curl command again.

HTTP/1.1 503 Service Unavailable
content-length: 28
content-type: application/json
date: Tue, 12 Oct 2021 16:07:03 GMT

{"database_connected":false}%

Conclusion

I hope this blog post served as a useful guide for implementing the Health Check API pattern. You can apply more information to your /health API endpoint such as, and where applicable, number of current users, cache connection checking, etc. Whatever information is needed to ensure what "healthy" looks like for your backend service. Which varies from service to service. Thank you for reading for this blog post!