Debugging superpowers with FLEX

I’ve been using FLEX for years and I just realised the little I’ve done to promote this great tool among the iOS community. So here is my attempt at giving some love to the project and show you the superpowers you can get with it.

FLEX is a library that adds an in-app debugging menu with a bunch of tools into your project. This is really helpful when you’re on the wild and want to check something on a real device. As developers, we’re probably more comfortable using other tools like LLDB, but this is for another context. An in-app debugging tool is way easier to use so it opens the gates of debugging to other people, like your QA and design teams or other stakeholders.

The library has constant activity with many developers using it and with improvements coming constantly.

Before you go and integrate the library make sure you read one important detail. This library is not designed to be released to the App Store so you need to make sure your installation process doesn’t include it for release builds.

I personally think that FLEX is one of the best libraries for this. In-app debugging libraries should offer a basic set of tools that are generally helpful, but also offer a powerful API to extend it with custom tools that are easy to write and feel as integrated as the default ones.

The list of tools included by default with FLEX is not short, I won’t go over them one by one but there are some that I would like to give special mention since they are the most useful to me.

Included tools

One of the most used tools that FELX includes is the network debugging utility. It’s something that you use constanly if your App connects to an API. Of course you can use more sophisticated tools like Charles, but having the ability to debug network calls in the app itself without requiring any external setup is invaluable.

Not only you can see all the information of a request, but also its contents and even copy a curl request to easily send it to other developers. It makes debugging API related issues so much easier!

Another really powerful tool is its UI hierarchy introspection. You can see all the views that are on the screen and explore the classes and data behind them. For example, this allows you to easily check that the content of labels or margins are what you expect. This is specially useful to allow designers to double check your work directly in a device.

But the UI introspection tools not only lets you check your UI, it also lets you change it! This is really interesting when somebody without access to developer tools wants to do some tweaks into the UI to see how it would look.

This ability of changing data at runtime is not only available for the UI, you can use it in many other tools offered by FLEX. For example the Database and NSUserDefaults exploration tools benefit a lot from this, letting you tweak on the fly user’s data.

There is a tool for pretty much anything you want to do on your iOS App. And thanks to the Heap Explorer if there is some object that doesn’t have a special menu, you can just search it yourself and tweak it.

Customisation

But of course every app is unique and it’s very likely that you have some set of data or information that you want to expose to QA or other alpha testers. You can probably access that data with the existing tools but sometimes is much better to build some simple custom UI that shows your data in the way it makes more sense.

I’ve been using custom tools with FLEX for years and recently decided to open a GitHub issue with some feedback on how the API could be improved. If it was good enough I can’t wait for it to be even better!

The nice think about extending FLEX is that the only thing you need to do is create your custom UIViewController and register it to the menu. That’s it.

FLEXManager.registerGlobalEntry(withName: "Fancy custom tool") { hostViewController in
    let viewController = ...
    hostViewController.present(viewController, animated: true)
}

Another powerful thing you can do is register custom keyboard shortcuts than can speed up a lot some flows. For example you can bind the key o (out) to an action that logs out the user from the App. Really useful for when you are working on a feature that forces you to switch accounts often.

But not everything you want to do may need a custom screen. Sometimes is useful enough to just have a button that triggers some code. For that you can register custom actions on the menu. They look the same as other entries but don’t open a screen, they just let you execute code.

To do this I had an ugly workaround for years. But now (still in PR) this functionality is exposed with an official API.

My tools

I imagine that by now you already have some ideas on how to help your peers with amazing tools. But, just in case, let me show you some of the tools I’ve developed over the years to help my team.

On our app we have feature fences that allow us to merge changes that are still in progress without the risk of impacting our users in production, but still letting testers try them. To toggle those fences on and off we build a simple screen that lists them and updates the local device flags.

One thing I developed around 2018 was an in-house UI component framework, it improved the team’s UI development flow so much that is one of the things I’m most proud off. But something I didn’t anticipate is the lack of discoverability. When you want to make sure that components are reusable and avoid making new similar ones all the time is crucial to have a way too easily see the ones we already have. To help with this an improvement was made to the components to support examples with the different states so it was easy to have a catalog with all of them. So the HubKit examples entry you see on the menu is a screen that is automatically generated via a combination of protocols and code generation.

Analytics tracking libraries are always a pain to work with. And even if they sell realtime updates on the Dashboards that’s rarely the case. To help us implement and test events I added a screen that shows the events and screens the App is capturing. This helps testers discard issues on our side very easily.

This screen is nothing fancy in terms of design but it gets the job done. And it even has some level of complexity with the filters and segmented control. But it was developed in a very small amount of time, the secret? SwiftUI 😃.

SwiftUI is ideal for this. And since this is not going to production you are more flexible in terms of using cutting edge frameworks. In fact this is the first SwiftUI code that we have on the LifeWorks app. I recommend you to give it a try, SwiftUI for tools is amazing.

Other interesting tools that we have are actions linked to shortcuts. Clearing the image cache is very useful when you want to make sure the initial impression of a screen is as nice as it can be. We also have an action that triggers a local notification with a payload that lets us test the behaviour of the app without having to force a real notification to come from APNS.

I’ve already mentioned the logout action, but we also have a login action that triggers what we call the magic login (or is the witchcraft one?). This is probably the most used action of all by a long shot.

Conclusion

If you haven’t integrated FLEX on your App yet you are probably wasting somebody’s time. This tool is a real time saver just with the default tools that it includes.

But building tools in a team is something really important that helps keep productivity high, so the fact that FLEX offers a menu to have all these things integrated is why I consider this an essential tool.

If you have other library preferences or ideas for custom tools feel free to send me a message 😉

Enjoy your new superpowers!