Context I have an app that uses the container for two things: store a realm database, and store a log.txt file with some debugging logs for myself. The realm database path is set via Realm.Configuration.defaultConfiguration The log.txt file path is set with FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)[0].appendingPathComponent("log.txt") I already have released and distributed the version 1 to a few users. Given the complexity around signing an app in Xcode, the app was released and distributed unsigned. And now I'm trying to release the version 2 signed, but here's when I'm getting this weird issue. All unsigned apps (version 1, and the unsigned version 2) are using as container the path ~/Library/Containers/com.dgrcode.{appName}/Data. The signed version 2, however, is using ~/ as the container. So for example log.txt is located at: unsinged apps: ~/Library/Containers/com.dgrcode.{appName}/Data/Documents/log.txt. signed app: ~/Documents/log.txt Realm's default.realm file is located at: unsigned apps: ~/Library/Containers/com.dgrcode.{appName}/Data/Library/Application Support/default.realm signed app: I haven't found it yet 😓 The obvious problem is that any user from version 1 that installs version 2 signed, will start using a new database instead of continuing using the existing database. And obviously having my app's data spread through their ~/ directory is far from ideal. Here's what I get when I run codesign -v -d on the first version (everything between {} has been redacted for clarity: Executable={/path/to/app} Identifier=com.dgrcode.{appName} Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=56564 flags=0x10002(adhoc,runtime) hashes=1757+7 location=embedded Signature=adhoc Info.plist entries=29 TeamIdentifier=not set Runtime Version=13.3.0 Sealed Resources version=2 rules=13 files=2 Internal requirements count=0 size=12 Where I think the most relevant part is the Signature=adhoc and TeamIdentifier=not set. Now I archive a version 2 of the app. I make a copy and I sign only one of them using codesign -v --sign. I package them inside a .dmg (not sure if this affects anything, but just in case), and check the .app inside each of the .dmg after mounting them. Here's the result of codesign -v -d for each one: unsigned: Executable={path/to/app} Identifier=com.dgrcode.{appName} Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20400 size=57452 flags=0x2(adhoc) hashes=1785+7 location=embedded Signature=adhoc Info.plist entries=31 TeamIdentifier=not set Sealed Resources version=2 rules=13 files=4 Internal requirements count=0 size=12 signed Executable={path/to/app} Identifier=com.dgrcode.{appName} Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20400 size=57335 flags=0x0(none) hashes=1785+3 location=embedded Signature size=4798 Signed Time=13 Nov 2023 at 12:17:24 Info.plist entries=31 TeamIdentifier=2W564BCY7Z Sealed Resources version=2 rules=13 files=4 Internal requirements count=1 size=188 The unsigned app works as expected. When I open the unsigned app, it continues using the realm database in the previous location ~/Library/Containers/com.dgrcode.{appName}/Data, and I can see the log.txt update its content. The signed app, however, doesn't use the same database, and is no longer writing to the log.txt file at ~/Library/Containers/com.dgrcode.{appName}/Data, but it's writing at ~/Documents/log.txt instead. It does use a database, but I have no clue where it is. Questions How can I make the signed app use the path ~/Library/Containers/com.dgrcode.{appName}/Data/ as its container lcoation? How can something like this happen just by signing the .app?

I think there's something broken with certificates or Xcode that's preventing me to sign a new version of a Mac app I've made. First, I know my "login" keychain password. I can use this password to export a .p12 file for my "Apple Development: {email} (CLW499436V)" item in my login keychain. Second, I can use security find-identity -v -p codesigning to see my signing identities. It shows two of them. They have a different initial number, and then the same string "Apple Development: {email} (CLW499436V)". The behavior using codesign -vf --sign SIGNING_ID ./test.app is different for each one of them. One requests the signature with the following message: I can input my "login" keychain password, which I know, and all is good The other uses the following message: It requires "the keychain password", which I have no clue what it is. Now, in Xcode, if I go to the Build Settings/Signing, I can set my "Coding Signing Identity". Opening the dropdown I can see a section named "Certificates in Keychain", and there's one "Apple Development: {email} (CLW499436V)". I don't know which one is that. Anyways, if I select that, going to "Signing & Capabilities" I see an error that tells me to select "Apple Developer" in the previous setting. When I do that, however, it seems Xcode is trying to sign the app with the certificate that request a password I don't know. I don't think I had this problem in the past, so I'm not sure how I've reached this situation. I also don't seem to be able to remove certificates and create new ones because I'm not subscribed (paying) to the Apple Developer program. Maybe there's a way to remove them that I have missed? How can I go back to having Xcode automatically sign my app?

Hi, I'm trying to manage singing certificates but it's proving impossible without having the Apple Developer subscription. I think it should be basic that any developer can handle their certificates as they wish. The opposite could easily result in increased security risk for all Apple users. I was hoping I could: Delete existing certificates, since I can't manage to find the password, so they're useless Create a new certificate. It would also be create if when creating a new certificate I could use a different email and name. The ones in my AppleID are my personal email and name, which are used for the certificates. However, I'd like to use my brand's name and email for the app I'm building. Is there a way to do this without paying USD 99 per year to Apple?