Moving away from AppCenter

[durandt]

We loved AppCenter but it was announced last week that it will retire on March 31st, 2025.

Share tips and discussions about alternatives here (personally mostly interested i crash handling and some analytics).

History of the discussion that started in the wrong issue:

durandt It doesn't look like any of the recommend alternatives are related to mobile app crash/error reporting and telemetry?

I would also like to hear about alternatives for crash/error reporting and telemetry. jfversluis did a video on Sentry: https://www.youtube.com/watch?v=9-50zH8fqYA But it seems to be uploading waaaaaay too much data for my liking (sure, it's neat to debug, but you have to consider your users privacy too)

One Thread with a few suggestions: https://www.reddit.com/r/dotnetMAUI/comments/1beuv2i/visual_studio_app_center_retirement_visual_studio/ image

bruno-garcia bruno-garcia commented The goal is to automatically attach data that can be useful for debugging problems. Device model etc. What data do you find that affects user privacy?

Worth noting you have control of what’s sent. You get the whole object in a callback where you can delete data before it leaves the device. And you can also add filtering rules to run at ingestion time before the data hits disk.

Regarding crashes with messages with underlines or missing stack traces. Please raise a ticket so folks can dig into it, I’m unaware of issues matching that in the MAUI SDK for Sentry at the moment: https://github.com/getsentry/sentry-dotnet

Sentry invested heavily in MAUI and .NET in general. And adoption indicates folks recognize that https://nugettrends.com/packages?months=72&ids=Sentry&ids=Microsoft.AppCenter

Request for line numbers on C# exceptions have been open here for years. Sentry offers that for all platforms including iOS and Android release builds. Debug file upload is convenient with dotnet build (https://docs.sentry.io/platforms/dotnet/configuration/msbuild/) and it includes bindings to native sdks ootb

PS: I was the maintainer of the dotnet sdk at sentry

@durandt durandt commented bruno-garcia thank you for chipping in, really appreciate it!

One more question while you are here, how about one of my comments on Mastodon, that the .NET Sentry SDK seems to (from what I see in the video) be sending crash reports directly rather than saving on disk to be sent at next app startup? Docs for unhandled exceptions for iOS and Android both suggest the code handling exceptions should be quick about it, and in my mind it has always been excluded to do some network stuff there. So my question is: Does the .NET Sentry SDK attempt to do network operations in the unhandled exception code? If it fails, will it save it to the disk and retry at startup? Can this behavior be configured? Thanks!

durandt commented yesterday Regarding the amount of data: The couple of minutes after 11:20 in this video: https://youtu.be/9-50zH8fqYA?feature=shared&t=680 Thats: . Stacktrace . List of rendering events . about 30-40 data points* . loaded assemblies

Sure that could be interesting but that seems like a huge footprint to add to every events (I like to add many events and usually just want to track a couple of values associated with the event)

data points image

bruno-garcia commented 18 hours ago You ended up not pointing out what is concerning regarding user privacy there. I see that as technical detail potentially useful for debugging.

Regarding amount, data is compressed before leaving the device and it’s not a lot specially since it’s only in the event of an error.

Ultimately as I said you can control what’s sent, so you can keep only the stack trace if you feel that’s right for you.

---

the .NET Sentry SDK seems to (from what I see in the video) be sending crash reports directly rather than saving on disk to be sent at next app startup?

It stores it on disk first and deletes it after sending it. In the event of a native crash it can only work this way. It can’t make network calls out of a signal handler.

Docs for unhandled exceptions for iOS and Android both suggest the code handling exceptions should be quick about it, and in my mind it has always been excluded to do some network stuff there.

On Android it tries to send it, but only after writing to disk. In my tests if a network connection was already open, for Java exceptions it managed to send immediately. But NDK crashes always only after restart.

So my question is: Does the .NET Sentry SDK attempt to do network operations in the unhandled exception code? If it fails, will it save it to the disk and retry at startup? Can this behavior be configured?

C#, Java, Koltin, Swift, C++, Objective-C (any native) crashes will store crash data on disk first. In managed code, it will try to send it immediately (because it can work, not a real OS signal handler , it’s a managed code global error handler). On the native crashes only on app reload data is sent out

durandt commented 36 minutes ago Thank you for your explanations!

You ended up not pointing out what is concerning regarding user privacy there. I see that as technical detail potentially useful for debugging.

There aren't really specific data-points that are directly affecting user privacy, but the combination of some of them may increase the risk of making it possible to identify some users. Battery level -> Could be ranges or "IsBatteryLevel10PercentOrLower" = true/false Storage/memory size -> Could be "HasAtLeast100MBFreeStorage" = true/false (100MB or another threshold)

Regarding footprint, there is also a (minor) concern that the more data you fetch using platform APIs, the bigger risk that these any of these APIs get deprecated and start creating issues (Keep it stupide simple)

I am not trying to be negative toward Sentry, I may very well use it in the end. But I have burnt myself in the past using 3:rd party crashlytics tools that made my apps crash and I am just being very cautious.

[durandt]

@bruno-garcia Related: Apple recently started to send warnings to apps using the aforementioned APIs over concerns for User Privacy (fingerprinting): https://github.com/dotnet/maui/issues/21296 https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api

[lucen-ms]

Thank you. We have shared all our official recommendations on https://aka.ms/appcenter/retire

[bruno-garcia]

@bruno-garcia Related: Apple recently started to send warnings to apps using the aforementioned APIs over concerns for User Privacy (fingerprinting): dotnet/maui#21296 developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api

The native iOS SDK isn't causing warnings, it seems MAUI itself is (for now but being fixed). If the Sentry .NET SDK becomes a source of problem please let folks know on this repo

• https://github.com/getsentry/sentry-dotnet

[ramtechjoe]

I see this is closed but thought I would ask this question anyway.

We don't use AppCenter for builds, already using DevOps. However, one thing AppCenter did provide was a very simple way to push the build to Microsoft Intune through a Store Connection. I have been unsuccessful at finding a way that the build could be pushed directly from DevOps pipeline to Intune. DevOps has a task to push to Apple Connect to go to the Apple Store. But no task for going to Intune. Which seems crazy to me as Intune is the Microsoft Azure product.

Does anyone know a way to push builds from DevOps pipeline to Intune?

Thanks

[DordeDimitrijev]

Hi @ramtechjoe thank you for reaching out. For publishing build to intune trough AzDO you'd need to create custom powershell scripts as an alternative to Appcenter. Here are some powershell script examples which you can use as reference https://github.com/microsoftgraph/powershell-intune-samples/ and also the Intune/Microsoft Graph API reference https://learn.microsoft.com/en-us/graph/api/resources/intune-graph-overview?view=graph-rest-1.0