Our open-source library packs a ton of useful features that make testing, debugging, and life in general much easier.

Have you ever been stuck in a loop where you have to rebuild your app constantly just so you can change a feature flag? What if you wanted to change your location or the base URL while using the app? You’re in for some more rebuilding. 

And what about untraceable UI bugs or elusive network issues in your app? Don’t count on “It works on my machine!” That ship has sailed a long time ago. 

Imagine a tool that would help you easily tackle the issues above and more. One that would provide you with network logs and useful information that allows you to quickly pinpoint what went wrong.

Meet Sentinel – an open-source library that will help you integrate these features with ease, allowing you and your QA colleague to find the root cause of the issues you’re experiencing.

Note: This article focuses on using Sentinel in iOS, but there is also an Android version available on GitHub.

Let’s start with some basic info. As mentioned, Sentinel is an open-source library that we sponsor and maintain. I’ll reference a part of the readme file from the GitHub repository here:

“Sentinel is a simple library that gives developers the possibility to configure one entry point for every debug tool. The idea of Sentinel is to give the developers the ability to configure a screen with multiple debug tools, which are available via some event (e.g., shake, notification).”

It’s important to note here that the library states a single entry point for every debug tool. This indicates that it must never end up in a production environment.

Sentinel aims to give developers an easy way to integrate any number of tools that can help them adjust the application data without the need to rebuild it. That is precisely the reason why it shouldn’t be exposed in production environments.

There are a number of benefits to using the Sentinel library. First of all, it is so easy to implement and use that the learning curve is not even a curve – it’s practically just the X-axis.

Another major benefit is that Sentinel can contain any number of debug tools, which means that you can implement your own tools, tailored to your needs.

For example, you have a logging screen that opens by shaking the device, and you have a report-a-bug feature that is triggered by using a screenshot on debug builds. That’s already two different inputs for opening a debugging tool. What if you wanted to add a database export debugging feature? How would you do that without overwhelming the tester with a new button combination? Sentinel comes in very handy here.

Finally, mastering Sentinel has a learning curve that isn’t much steeper than the one for learning to implement it. Once you’ve mastered it, you can think of new ideas to help yourself and your testing team make your app more bulletproof and easy to test out.

To use an example from my own experience, there’s an IoT project I work on where we use Sentinel to a great extent. The project involves a lot (and I mean a lot!) of Bluetooth communication and network requests. 

Utilizing Sentinel’s ability to log every Bluetooth command and every network request, we can actually see what we sent and if the request was successful or not. Besides helping us developers, this also saves our QA engineer’s time. Once we release a build, they check the feature we implemented by examining the logs to see if we’re sending the right commands. That way, the QA engineer can also indicate if there’s an issue, and whether it’s a firmware or an app issue.

Another example is getting a bug report with all the logs attached. Most of the time, we can pinpoint where the issue is happening just by using the elaborate logging integrated within the app.

You can add Sentinel to your project via the Swift Package Manager (SPM) or CocoaPods. This example will demonstrate how to add it via SPM.

Open your project in Xcode → Files → Add package dependencies… → Search for Sentinel or use this link → Add your project → Add package.

This will prompt you to add Loggie and Collar to your project too. Both of these are optional, but if you want a simple logging tool, you can use Loggie, and if you want an analytics tool that gives you a visual representation of your events, you can add Collar. After picking the right tools for the job, this is how you set up Sentinel in your app:

With these 18 lines of code in the setupSentinel() function, we have successfully set up Sentinel, and the only thing left to do is to call it in the didFinishLaunchingWithOptions function.

We had to create the Configuration object, which is exposed by the library. The configuration takes in a trigger that will tell your application how you want to open Sentinel. Currently, there are three options – screenshot, shake, and notification.

The tools parameter takes in an array of Tool objects, which represent all the tools that are available once you launch Sentinel. The preferences array lists all the switch options for your feature flags or other boolean values you want the user to be able to change without needing to rebuild the application. These can also be saved in UserDefaults, hence the userDefaultsKey parameter. The last and most important thing you have to do is set up Sentinel with your configuration.

Using this code, we have set up Sentinel in two minutes and exposed two custom tools – one for changing your location and the other one to read all the UserDefault values your app is storing.

As shown above, setting up Sentinel takes no more than a couple of minutes. You might expect there’s some sort of a catch with custom tools, but in this case – it’s not the case. Designing and customizing tools is just as simple.

Debugging tools in Sentinel should be designed in a KISS manner. One debugging tool should only be used for one purpose. If we create a tool that inspects a database, then it shouldn’t be able to also inspect UserDefaults. 

Before you start creating your own custom tools, you should check out the ones provided by the Sentinel library:

Let’s say we love the UserDefaultsTool, which is provided by Sentinel, but it’s missing something we need. In our case, the ability to change the value. We can easily create a new custom tool and import it to our application.

In this example, we’ll create a simple custom tool that can change a UserDefaults key for a system image and update the image afterward by pressing a button. To achieve this, we first need to create a Constants enum where we’ll save all the values we want to store in the UserDefaults.

In this case, we only have one value, but your app might require more. It’s always a good idea to extract constants like these into enums so you can namespace them easily. You potentially might want to add a UserDefaultsResetTool. That way, you can easily conform to CaseIterable and reset every single UserDefault value you added.

Let’s get back to our example.

Since I created this example project with Xcode 15, I got a SwiftUI view, and we’ll have to update it a bit.

In this case, we added an AppStorage variable which will fetch the value from the UserDefaults, and update the view if it gets changed.

It allows you to inject your UserDefaults, in which you’ll want to store the image name. In this simple example, I used TextEditingTool, which is provided by Sentinel, but if you need more complexity in your own custom tools, feel free to create your own solutions.

When creating your own custom Tool to integrate into the Sentinel configuration, you’ll need to conform to the Tool protocol. The protocol states that your custom tool has to implement a name, which is displayed in the list of your tools, and that it has to have a function presentPreview to handle the navigation. It’s as simple as that. Last but not least, we have to add our tool to the Sentinel configuration. So let’s update our setupSentinel function:

If we run the application now, we can shake the device and see our tool in action.

SUMMARY

While Android devices have generally gone in the direction of having just a camera cutout or even an under-the-screen camera, Apple has created a brand new user experience with the new camera housing – the notch. Here’s how to implement it in iOS.

Apple introduced widgets in iOS 14, allowing us to have glanceable information on our home screens.

But what if we went a step further and provided contextually relevant information that pops up when needed and doesn’t overstay its welcome? And what if that was done in a way that works seamlessly with the biggest front-facing update our iPhones have seen since the introduction of the notch? No more what ifs – Meet Dynamic Island.

We’ve covered our feelings about the Dynamic Island and live activities from the design perspective, and now is the time to show you how to implement them.

iPhone 14 Pro and 14 Pro Max are the only devices that support the Dynamic Island, but Live Activities are supported for all phones that can run iOS 16.1. So let’s see what’s needed to integrate them into your applications.

Lifecycle is one of the most important things to remember when creating apps. Live Activity can be in three states:

Your application can have multiple live activities at once, so it’s important to keep track of every activity. Before starting an activity, you must specify what data it needs to use. Since we’re talking about a Live Activity, you can guess that there will be some data that will change over time. Your Live Activity data will be separated into dynamic and static data. Dynamic data can be updated over time and static can’t.

For example, we’ll take a look at the FormulaAttributes structure which will contain both types of data.

After starting the activity, it can stay live for eight hours before it ends up being terminated by the system. Eight is enough for most activity use cases, but sometimes you can have an 8-hour flight in which case you wouldn’t be able to track the whole duration with the 8-hour limitation. 

After you end it, the Live Activity will still be available on the Lock Screen for another four hours by default. You can specify if you want to terminate the Lock Screen Live Activity immediately or the system will do it for you after four hours.

Ensure that you update the Live Activity after it ends if you’re not immediately removing it from the Lock Screen to reflect its proper state. That way, your users will have the latest information and know that the Live Activity has ended with the latest results.

As mentioned before, you can show the Live Activity on the Lock Screen, Dynamic Island, or a banner on devices that don’t support the Dynamic Island. When you’re developing for devices that have the Dynamic Island support, there are five views:

Every single one of these views can be different from the other.

As the name suggests, it should be minimal, eg. an image that uniquely represents your app. The Minimal view is shown when multiple Live Activities are running at once on the right-hand side of the Dynamic Island with slight padding. Tapping on the view will lead the user straight into your app.

The leading view will be shown on the left-hand side of Dynamic Island. You can specify some current information from your app related to the Live Activity. Just be careful not to stuff too much information inside the view.

The trailing view will be shown on the right-hand side of the Dynamic Island. It works just like the leading view, which you can see on the image below for the Formula1 tracking Live Activity ​​that we’ll develop in this example.

The expanded view will be shown once the user long-presses the Live Activity and it should be used to display more information about the activity. In our example, we’ll specify which driver is in front and which one is the last. As you can see in the image below, Max is already in first with Latifi sitting in last – a familiar sight if you’ve been watching F1 lately.

This example is quite simple – you can customize it by setting the views in particular regions of the expanded view, and the system will try to size them correctly based on the views you’ve provided. You can check out the image below to see which regions are covered with the expanded view.

We’ll use a similar example to show how it looks on the Lock Screen. An important note here is that we can use a different view for this case. It allows us to reuse the existing UI or create new situation-dependent views for Dynamic Island and Live Activities separately. You can see an example of this below.

First of all, Live Activities are available from iOS 16.1, and I’ll be using Beta Xcode 14.1 for this example.

After you’ve decided on which app you want to liven up, head into Xcode, and under the targets section, you can find a “+” sign where you can add a widget extension.

After you’ve added the widget extension head into the Info.plist file of your application and add a boolean flag for the Supports Live Activities permission and set it to YES.

Now we’re ready to get this show on the road. First, we’ll define the FormulaAttributes I’ve mentioned above. It conforms to the ActivityAttributes protocol which helps us define dynamic data inside our structure. Make sure that when you create the FormulaAttributes.swift file you include it in both the App and the Widget target. 

First, we’ll add a button and a reference to our Activity inside the ContentView. The Activity will be set as optional since we want to create it when we need it and the reference is kept so we can update the correct Live Activity later.

The compiler will complain that there’s no startActivity function and we’ll add it inside a private extension on the ContentView. The startActivity function will return the newly created Activity.

Now that we’ve covered the implementation of our Live Activity, we can start looking into activity updates.

Add another button inside the content view just like the one we added in order to start the activity and call the updateActivity function. Inside the private extension of the ContentView add the following function:

The function will get the reference we kept for our activity and call the .update(using:) function with some new content. It is wrapped inside a Task since it’s an async function.

This example shows how to update our Live Activity from the app, but as mentioned before, you can also do that using push notifications. The code would differ a bit from our example and you’d have to start the Live Activity by specifying the pushType parameter. You’d need to send the pushToken from your Live activity to the server so it can receive notifications.

Ending the Live Activity can also be done via notifications or from the app. As I’ve mentioned before, make sure that you have updated the Live Activity with the latest information before you end it.

Add another button to the ContentView which will reference the endActivity function. Inside the private extension of the ContentView add the following function:

The endActivity function goes through all of the started Live Activities with the FormulaAttributes and ends them while specifying that it should remove the Lock Screen activity immediately. Just like the update(using:) function, the end(dismissalPolicy:) is an async function as well.

Since we’re using only the Live Activity Widget for this example, we’ll annotate it with @main. If you’re using more Widgets, please add them to a WidgetBundle. The code below shows the user interface for our formula Widget which was used for prior screenshots.

Inside the Widget, we specify the ActivityConfiguration and which Attributes it’s going to use. First, we’ll set the views on the Dynamic Island, and afterwards we’ll add the Lock Screen one.

As it’s a simple example, I’ve only used the center region of the Expanded view to set some data inside. Afterward, there are closures describing which part of the Dynamic Island it covers so you can put whichever view you want it to show.

Now we can set the Lock Screen and the Home banner view. Here’s a Lock Screen view which will have a reference to the context from our attributes so it can be updated properly.

After you’ve created the Lock Screen view, initialize it inside the closure for the ActivityConfiguration. And there you have it, you can now run the app and test it out.

Since the Live Activity is a Widget, it can deep link into your app. Every Live Activity view can lead to a different place inside your app, but Apple still recommends that the leading and trailing views lead to the same place. DeepLinking is a great tool to add inside the expanded view where you can have multiple views, some of which could navigate where you need them.

Live Activities are a new way to show information at a glance. The animations and different views make Live Activities unique from other widgets. Tailor the Live Activities to your app’s needs and make it a unique yet pleasant experience that the users can enjoy.

PS. We probably don’t even need to update our Live Activity since Max most likely won.

Hope you enjoyed the article and happy coding, we’re looking forward to seeing your own live activities out in the wild!