Using Instabug in a SwiftUI-based iOS App

When using the new SwiftUI-based app lifecycle introduced in iOS 14, it might not initially be obvious where SDKs like Instabug should ideally be initialized. After all, there’s no more didFinishLaunchingWithOptions app delegate method to implement, so where can we put logic that we want to run as soon as our app has launched?

Perhaps the simplest approach is to give our main app struct an initializer that performs all of our on-launch setup work. In this case, we’ll call Instabug’s start method directly within that initializer, which will ensure that Instabug will be up and running before any of our UI has been constructed:

While the above works perfectly fine, let’s also say that we’d like to utilize some of Instabug’s many customization APIs to tailor it to fit our needs. At that point, we probably don’t want to keep writing all of our setup code directly within our app struct’s initializer, as doing so could quickly get quite messy — so let’s instead create a dedicated InstabugConfigurator type that we can then call from our app implementation.

Since we’re looking to configure Instabug globally for our entire app, let’s make our new InstabugConfigurator completely static, and by implementing it as a case-less enum, we can even prevent it from being accidentally initialized:

Note how we’re wrapping our configureIfNeeded implementation within a #if !DEBUG compiler directive. That’s to prevent this code from running during development, since we likely don’t want to initialize Instabug when we’re testing or debugging our code in either the simulator or on a device. We’re also preventing our configuration code from ever running twice, by setting a static hasBeenConfigured property to true when our configuration method was called for the first time.

With the above in place, we can now simply call our new InstabugConfigurator from within our App struct’s initializer, which still ensures that Instabug will be fully configured right when our app is launched, while also letting our App implementation remain focused on configuring our app’s scenes and their main UI:

By default, Instabug will automatically log whenever one of our UIKit-based view controllers appeared on the screen, and since SwiftUI still uses UIViewController subclasses under the hood to manage our overall UI and its navigation stack, we can still use those automatic events even if we’re no longer creating any UIViewController instances ourselves.

Let’s start by extending SwiftUI’s View protocol with a method that’ll let us identify a given view as a named screen, and whenever that view appears, we’ll call Instabug’s logViewDidAppearEvent API to report its name — like this:

With the above in place, we’ll now be able to easily connect each of our top-level views to our Instabug reports, which will make it much easier to see what views that were involved in each reported issue. For example, here we’re identifying a HomeListView as our app’s “Home” screen:

Instabug also offers full support for logging custom user events as well — so let’s also add a second argument to our identifyAsScreen method, which will let us automatically log a given event as soon as a view disappeared:

Using the above, we can now log disappearance events (such as when an onboarding flow was dismissed and completed) simply by passing a disappearEventName when calling our identifyAsScreen method — like this:

Because Instabug includes such deep integrations with UIKit, it already works great within the context of SwiftUI as well, since much of SwiftUI is still built directly on top of UIKit-based classes like UIView and UIViewController.