How to store user data blobs in MAUI iOS
What is the right way to get a safe path that binary, non user readable data can be stored? I tried using FileSystem.AppDataDirectory, but I noticed that it gets cleared on every test flight build.
13 Replies
Dont SecureStorage work?
sounds like a test flight issue over the directory. that path is the common path u should be using to store the app data.
https://learn.microsoft.com/en-us/dotnet/maui/platform-integration/storage/file-system-helpers?view=net-maui-8.0&tabs=android
its also a sync path that will be auto backup so there is no reason it would be erased
per say
I need to store some relatively large data files. While the Secure Storage does survive it doesn't really help me for my issue.
https://learn.microsoft.com/en-us/dotnet/maui/platform-integration/storage/file-system-helpers?view=net-maui-8.0&tabs=macios#platform-differences this says that the directory changes with every build
iOS pitfalls, you would use relative paths instead
this indeed sucks it wasn't like that
Note for posterity: the application ID (or app's UUID) always changed for over the air updates (TestFlight, App Store) but originally didn't change for deployments from Xcode. However, Xcode 6 introduced the app's UUID changing on each build/deployment. So the doc presumably called this out because it was new behaviour for simulator deployments at the time.
So if I store a file at a relative path to the AppDataDirectory, will it get copied over to the new location?
On every update
no
my point was that u would perhaps be able to access older ids by using the relative path
but im looking if there is a better solution
that is indeed a weird way to handle things
give me a moment
The way I did things so far was write files into AppDataDirectory and store (absolute) paths to them in Secure Storage but after a test flight update, the Secure Storage data was there but the app crashed because the actual files where no longer there
and have u tried reading the files by using the api to access files you dont own?
perhaps the error was not that it does not exist but that u didnt have access to the path since ios gave u a new path
i.e.: FilePicker
The error was a File Not Found Exception
yes but that could have been the error due to lack of access from simple using File.Read***
FilePicker will query for access before trying to access place it cant
just trying to rule this out
or if u can use a file explorer to check the folder to see if it was really erased
either is fine
so I've asked it in the maui toolkit community where there are people a lot more experienced including MS devs that work on MAUI.
their answer was that this behavior does not occur for updates
only on reinstalls
and as long as the vendor tag does not change the folder should also not change
@Maxwell175 🎗 how are u dropping the new build?
are u uninstalling old ones and installing new ones or just updating or what?
@Maxwell175 🎗 $mauitoolkit
so if u dont mind it would be better if u talk directly there instead of me being a middle man
the conversation is in the chat
he is querying whether you are updating the app or uninstalling and installing again.
with bijington so you can just provide the info directly to him
If you have no further questions, please use /close to mark the forum thread as answered