Setting non-nil String value crashes on force-unwrapping fetchOptional? about foil

[jessesquires]

Thanks for the report @peterkos!

It's hard to say what's wrong without more context. Is it possible that something else in your app could be modifying the values for these keys? Are you sure there wasn't a corrupted plist involved?

All of the scenarios you described (defaulting bool to false, crashing for non-nil string) are unit tested and (I think) also demonstrated in the Example project in the repo.

Can you reproduce this in the unit tests, example, or in another project outside of your app?

[peterkos]

(I made a standalone project but am still trying to find the repro case 😅)

Some extra context: this is for a macOS app w/ SwiftData + sandboxing. When I try deleting the .plist in ~/Library/Containers/[appname]/Data/Library/Preferences/[appname].plist, I get the following error:

// x50-ish times
Couldn't read values in CFPrefsPlistSource<0x6000014d45a0> 
(
  Domain: me.peterkos.[appname], 
  User: kCFPreferencesCurrentUser, 
  ByHost: No, 
  Container: (null), 
  Contents Need Refresh: Yes
): 
accessing preferences outside an application's container requires 
user-preference-read or file-read-data sandbox access

// warning
Not updating lastKnownShmemState in CFPrefsPlistSource<0x6000029d0090> (Domain: me.peterkos.Cabinette, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: Yes): 0 -> 20132

The app only calls into my AppStorage class in two places (the App.swift and a preferences window), commenting the other use out results in same crash. This logic is for determining which container to load for SwiftData, maybe it's something with that? (will keep digging)

Edit: It happens regardless of using the standard user defaults, or instantiating my own

[peterkos]

This is the nil-causing line: it's unable to convert the String value? Hmm.

[peterkos]

Aha!

Yes so -- Previously, I changed the type of the didMigrate var from a Bool to a String, which the above fetch<T> code wasn't able to convert because it was a literal number (from Bool's NSNumber encoding?).

I assumed deleting the prefs .plist in my container was the only place the key was stored (still unsure on that one) -- and that changing the type of the only variable would overwrite the previous instance, if it had the same name. Maybe that could be a feature? (Or if this is expected behavior, a defined error message vs. force-unwrapping)

The fix was to delete the old Bool-typed key from standard UserDefaults:

> defaults delete [appname] didMigrateFromv_0_2_to_0_3_VersionedSchema

[jessesquires]

@peterkos glad you got it figured out! 💯

When I try deleting the .plist in ~/Library/Containers/[appname]/Data/Library/Preferences/[appname].plist, I get the following error

I'm not certain, but I think you might see some unexpected behavior by doing this. Instead, I would probably uninstall and reinstall the app.

Previously, I changed the type of the didMigrate var from a Bool to a String, which the above fetch code wasn't able to convert because it was a literal number (from Bool's NSNumber encoding?).

Yes, something like this is what I anticipated was happening. 😊

I assumed deleting the prefs .plist in my container was the only place the key was stored (still unsure on that one) -- and that changing the type of the only variable would overwrite the previous instance, if it had the same name. Maybe that could be a feature? (Or if this is expected behavior, a defined error message vs. force-unwrapping)

The .plist in your container should be the only one. However, my suspicion is that you were probably running your app from Xcode as well? If that's the case, then your app binary and container are in Xcode's DerivedData/. So then deleting the plist at ~/Library/Containers/[appname]/Data/Library/Preferences/[appname].plist would not have any effect. The plist in ~/Library/Containers/... exists for an app that is properly installed on your mac. (So you'd need to export the app archive from Xcode, install it, etc.)

[jessesquires]

Regarding Foil, there isn't really anything we can do at the library level here, unfortunately. You can misuse UserDefaults directly in exactly the same way.

In the future, for your debugging purposes, instead of using terminal to run defaults delete ..., you can use the UserDefaults API directly in your app, by calling removeObject(forKey:). Just call that during app launch before anything else to "reset" UserDefaults.