This is a follow-up to a previous blog post of mine. I explained how Mobile Analytics providers could not automatically capture user interactions and presented screens unless the controls were implemented in UIKit.

Consequently, you are forced to manually instrument your code with APIs provided by the Analytics provider of your choice.

If you use Dynatrace and you may benefit from their interesting approach to spare app developers from this tedious work.

Dynatrace provides a command-line tool, the so-called "SwiftUI instrumentor", that adjusts your Xcode project. This allows adding the necessary code to your project's source code (*.swift files) during the build process.

There are other tools or Swift build plugins that also change source code. This is usually transparent, and you would commit those changes as part of your source control management. The big difference is that the Dynatrace tool reverts the changes at the end of the build phase. Your code looks unchanged, but the build artifact contains the changes. Imo this is a bold move to change the original application code during build time in such a way. To check the difference between your original code and the code modified by the SwiftUI instrumentor, you can a command that produces a diff.

For this particular case, there are also some limitations, e.g. issues with SwiftUI previews and longer build times. And finally, Dynatrace doesn't support the instrumentation of custom SwiftUI controls. For the list of SwiftUI controls you can instrument, see their list of Supported controls.

I am not using and I am not promoting Dynatrace. I was merely fascinated by their initiative to provide such tooling that has challenges and costs for Dynatrace. But the company is willing to invest in a stopgap solution to ease the implementation efforts of their customers.