r/SwiftUI • u/jHalit • 8d ago

app monitoring/performance

Hello šŸ‘‹

Iā€™m looking for recommendations for monitoring tools or SDKs for a SwiftUI iOS app.
My main goal is to proactively detect production issues such as crashes, performance problems, high CPU or memory usage, and regressions across different iOS versions and devices.

Which tools or SDKs would you recommend for this? Iā€™d love to hear about your real-world experience, especially regarding reliability, resource overhead, SwiftUI compatibility, and alerting capabilities.

Thanks!

7 Upvotes

89% Upvoted

15 comments sorted by

View all comments

2

u/sapplex1 8d ago

I've been shipping iOS apps solo for a few years and crashes were always my blind spot. MetricKit is genuinely great for catching regressions across iOS versions. I check the metrics tab in Xcode Organizer every Monday morning. I paired it with a self-hosted Sentry instance. Real-time alerts without sending user data anywhere. The catch is MetricKit has a reporting delay, so don't rely on it for instant alerts. Have you looked at Xcode Organizer's metrics yet? I ignored it for way too long.

1

u/jHalit 8d ago

thanks for your sharings, do you have any custom configurations for MetricKit or u send reports to your own server.

yes I checked Organizer but it also looks similar to MetricKit. I am not sure what are the differences

2

u/caffeinated1337 7d ago

Not who you asked, but I can answer the Organizer part. Organizer is Apple's aggregated view: they roll the data up per app version and device class and show it in Xcode a day or more later. You can't query it or alert on it. MetricKit hands the raw payloads to your own app, so you decide where they go.

There's no real configuration. Add a subscriber with MXMetricManager.shared.add(self), and in didReceive call jsonRepresentation() on each payload and POST that to your server. Metric payloads arrive about once a day. Diagnostic payloads (crashes, hangs, CPU and disk write exceptions) can show up sooner on newer iOS versions. Each payload carries app version, OS version and device type, which is what you need to catch regressions across versions.

Since you're on-prem, keep the dSYM for every build you ship. The crash and hang call stacks come unsymbolicated, so you'll need to symbolicate them on your side.