Add how much space an app takes up on the user's device
Problem Statement
In the iOS settings (General -> Storage) I can see how much space an app takes up. This is split into:
- App Size
- Documents & Data
The use case is, that I can see if the app creates too much data or if I don't properly clean up data.
Relates to https://github.com/getsentry/sentry-java/issues/1917
Solution Brainstorm
No response
This issue has gone three weeks without activity. In another week, I will close it.
But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!
"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀
What also would be useful is the available disk space on the device.
What also would be useful is the available disk space on the device.
At least on Android that's already available.
Documents and data size is interesting. We could use something similar to this, but the solution is to traverse all files inside the app folder. If the app has created hundreds of files, this can be expensive. The sample I read says something about 35ms for 100 files.
To get available disk space we can use this snippet:
let values = try url.resourceValues(forKeys: [.volumeAvailableCapacityForImportantUsageKey])
if let capacity = values.volumeAvailableCapacityForImportantUsage
It doesn't seem like feasible to attach either of those on each event because the overhead to retrieve this value "fresh" is rather expensive (depending on the amount of data on the folders).
We had a brainstorming session for this value to go out as measurements. Not for App Size because it's easily accessible in the App Store.
But if we're reading "Documents & Data" every few minutes, close enough when we capture a transaction (we can read it right before capturing the transaction without blocking anything), this could be very valuable.
I am going to send this as event.context.app.data_storage, as an integer. There isn't an existing property for the app data size (see https://develop.sentry.dev/sdk/event-payloads/contexts/), so I made this key up myself. It's also not rendered nicely in a human readable format yet. Where can we ask the sentry.io team if this key makes sense, and if they can render this one nicely?

Please be explicit about the unit we're using here. If it's bytes, for example, we need to document this in code and on develop.sentry.dev.
Also, the UI should be able to render KB/MB/GB, etc, if the field is set to the right unit in the Sentry front end
It's in bytes like all the other memory and storage sizes we send
Yes, please use the same approach as for these values https://github.com/getsentry/sentry-cocoa/blob/ceaa5790db2d26f454ad7962a9aaa62d09467449/Sources/Sentry/SentryCrashIntegration.m#L251-L253
They show up like this in Sentry:

We need changes in Sentry to support that. Similar to these lines of code https://github.com/getsentry/sentry/blob/0dbd18fc57a5a360fdfca921f59fbee4d0f650c6/static/app/components/events/contexts/device/getDeviceKnownDataDetails.tsx#L120-L127
case DeviceKnownDataType.EXTERNAL_STORAGE_SIZE: {
return {
subject: t('External Storage Size'),
value: data.external_storage_size ? (
<FileSize bytes={data.external_storage_size} />
) : undefined,
};
}
@priscilawebdev, can you maybe tell us how to add another known datatype in the file above?
Yes, please use the same approach as for these values
I'm not sure what you mean with this. What approach do you mean? I'm setting an integer of bytes to the field event.context.app.data_storage. Even though it happens in a different file, the approach in the end is the same, right? Sentry's UI just needs to know about it.
Even though it happens in a different file, the approach in the end is the same, right? Sentry's UI just needs to know about it.
Yes, exactly.
@ueman or @marandaneto, do you already send this for the dart SDK? If yes, which name did you choose for this property?
No, the Dart SDK doesn't send it.
nope, that would come directly from the iOS or Android SDK if possible.
We discussed this in our meeting today, and we're closing this issue for now until we can track metrics over time. We can't measure the Documents & Data size in real time for every single transaction because it's too slow, so it doesn't make sense to send this data as part of a transaction - it'll be stale data.
What would be interesting is to see the value change over time, for which metrics would be the way to go. This is something to pick up in the future.
I agree with the decision but I'd rather keep the issue open, it's a fair request and people can upvote if it's essential, if we don't do it for reasons, it's an implementation detail.