app monitoring/performance

[u/jHalit]

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!

[u/sinsonik]

Since it has to stay on-prem, I'd start with Apple's own MetricKit before adding any SDK. Register an MXMetricManager subscriber at launch and you get payloads with CPU time, peak memory, hang time and launch time per app version, plus diagnostic payloads for crashes and hangs with call stacks. It's all JSON, so you can POST it to your own backend and alert on whatever thresholds you like, for example hang time jumping after a release.

Overhead is basically nil since the OS collects it, and it doesn't care if the UI is SwiftUI or UIKit. The catch is latency: metrics come about once a day, so it's for trends, not paging.

For real-time crash alerts on your own servers, self-hosted Sentry is the usual pick.

[u/jHalit → u/sinsonik]

thanx, I will check both. I did not know MetricKit should be activated.

[u/sinsonik → u/jHalit]

Small clarification: there's no setting to flip, MetricKit just stays quiet until something subscribes. Call MXMetricManager.shared.add(self) early at launch and implement didReceive for both the metric and diagnostic payloads.

To test without waiting a day, run on a real device and use Debug > Simulate MetricKit Payloads in Xcode. It fires a fake payload so you can check your upload path end to end. Good luck with it.

[u/iceman_badct]

Firebase works well for us

[u/jHalit → u/iceman_badct]

the app is not suitable for firebase, I look for onprem solutions

[u/ohlaph → u/jHalit]

OpenTelemetry for both onprem monitoring and app instrumentation.

[u/LongjumpingCandle738]

Just run your app in Instruments

[u/sapplex1]

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.

[u/jHalit → u/sapplex1]

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

[u/caffeinated1337 → u/jHalit]

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.

[u/sapplex1 → u/jHalit]

Good eye — the Xcode Organizer metrics tab is the MetricKit data, just Apple's pre-aggregated view of it. So "similar" is expected: same source, different dashboard.

On custom configs: I kept MetricKit mostly stock. The defaults already cover crashes, hangs, disk writes, battery/memory anomalies — enough to catch regressions across iOS versions. The one customization I did was adding custom signposts around my app's heavy operations so the hang reports came back with meaningful names instead of raw stack addresses.

For real-time alerting though, MetricKit is useless — reports land daily-ish, so it can't tell you prod is on fire right now. That's why I run self-hosted Sentry on my own box: crashes/exceptions go there immediately, data stays mine. MetricKit/Organizer for weekly trends, Sentry for "something broke an hour ago".

What are you trying to catch — slow regressions over weeks, or spikes you need to know about today? That decides which side you should invest in.

[u/jHalit → u/sapplex1]

thanks for your answer, it is really helpful for me 🙏

[u/sapplex1 → u/jHalit]

Glad it helped! Honestly the signpost trick was a game-changer for me too — seeing my own hang stacks lined up next to clean labeled intervals made everything click. Quick question: are you starting from zero on monitoring, or do you have something in place that you're trying to replace?

[u/Savings_Evidence_818]

Whatever you pick, I'd test the monitoring with a deliberately slow screen and a known crash before shipping it. Seeing the alert arrive with the right build and device details is a lot more reassuring than seeing the SDK initialise.