This pull request extracts a number of Apple Developer Account specific values from the pbxproj to a xcconfig file.

The extracted values include DEVELOPMENT_TEAM, APP_GROUPS and a base for the PRODUCT_BUNDLE_IDENTIFIER. The system includes a method to override them with a fallback to the current values for @EthanLipnik's account.

Ultimately this change makes it much easier for a contributor to setup OpenSesame in their own Apple Developer Account, including the ability to run app on device.

This change should be complete - but will require testing to make sure I've caught everything.

Testing on an iPad Pro running iOS 15, on first launch when prompted to enter a new master password, the password field is not properly masked as a password and shows the full text entry.

Inside CreatePasswordView (where you set a new master password), the password wasn't hidden (you could see it as you type). I changed it to a SecureField (in case it wasn't intentional).

Describe the bug OpenSesame seems to keep crashing in the background without actually being open. It probably wouldn't matter when the app is on the App Store because there are no alerts for this but on the TestFlight build it's really annoying lol. I don't really know when it happens, but the device seems to be doing something in the background. When I use the device in the morning I get about 10 alerts at the same time about how OpenSesame crashed.

To Reproduce I have no idea, probably just wait?

Expected behavior It shouldn't crash

Screenshots Couldn't get a screen recording of it because you can't open the control center when an alert is shown, I'll try to do that tomorrow morning via my computer. Hopefully it'll work.

iPad (please complete the following information):

• Device: iPad Air 4th generation
• OS: iOS 15.0 (19A5337a)
• Version: 1.0 Build 8

Additional context It's possible that this is an issue caused by the iOS 15 beta, but I haven't noticed this with any other app. I think I shared a crash report once, but didn't do it again because I don't wanna spam your ASC dashboard lol

I noticed that the AppDelegates for both iOS/macOS - perform a call to registerForRemoteNotifications - yet neither has appropriate calls to get the DeviceToken e.g. application(_:didRegisterForRemoteNotificationsWithDeviceToken:) or to handle the error.

https://www.hackingwithswift.com/read/33/8/delivering-notifications-with-cloudkit-push-messages-ckquerysubscription suggests that the DeviceToken is silently made available to CK

If there was no error, we call registerForRemoteNotifications(), which creates a unique device token that can be used to message this device. That device token is silently handed off to CloudKit, so we don’t need to do anything other than request it.

I haven't seen in the app where CloudKit is using those notifications - so the probably naive question is...

Is the call to registerForRemoteNotifications needed for CloudKit integration or are both AppDelegates not needed? (and could the RemoteNotification entitlement be removed too?)

The toolbar in the supplementary view does not display correctly.

The standard macOS appearance (as seen in apps such as Mail.app and Xcode 13) is to have separate sections in the toolbar for each view in the NavigationView. In OpenSesame, the toolbar appears as one continuous section (aside from the sidebar).

Current TestFlight Build:

This PR Fixes that issue, giving the Toolbar the expected macOS appearance. Note that you may have to adjust the password list's width in order for it to look right (I think it's because macOS tries to restore the column width to its previous value).

Fixed version (this PR):

My guess is that it needs to use plainButtonStyle in order to display properly, but I could be wrong.

(Also, I think it's supposed to be "Enjoying" and not "Enjoing")

Screenshots

• macOS Monterey (21A5522h)

I think the account detail labels are a bit too cramped and could use slightly more spacing around them. A few more pixels between would probably be enough. And maybe a separator between the email and password labels?

Bug description When clicking the little "i" at the top right on the lock screen view, it shows an alert with an option to reset the password, but there's no way for the user to cancel the operation other than relaunching the app.

To Reproduce Steps to reproduce the behavior:

1. Open the app (or click the lock icon when already in the app)
2. Click the "i" icon at the top

Expected behavior There should be an option to dismiss the alert and to not reset the password. I clicked on it because I was curious what it is. Maybe the "Reset password" option should also have the descructive attribute to make it red. Is there a backup of the data stored when resetting the password? Because currently it's a bit easy to reset it and delete all data which is really bad when you store all logins within the app.

Screenshots

Device

• Device: iPad Air 4th generation
• OS: iOS 15.0 Beta (19A5337a)
• App Version 1.0 Build 8

Idea

Account names for saved logins

Why?

Sometimes a login doesn't have to have a website associated with it (e.g. computer logins, database credentials,...). Adding a account name field would

1. remove the need to for a website url
2. enable users to differentiate between multiple accounts on the same platform without needing to look at the username (e.g. Twitter) (even more helpful if the username is the same which can be the case for Microsoft accounts)

On my first app open, I just hit enter in the master password, and I’m unable to change it. Also, I don’t think users should be able to do this.

Edit: forgot to mention that the reason it locks out the master password box is because it lets you set the password to blank, but on reopen, it doesn’t let you enter blank text in the master unlock page. How can I change the password after?

Is your feature request related to a problem? Please describe.

As title

Describe the solution you'd like

As title

Describe alternatives you've considered

N/A

Additional context

N/A

Describe the solution you’d like Similar to how it’s done in 1Password, I would like the account/login name and website to be separate. For some websites, I have multiple accounts that I want to clearly label inside OpenSesame. Additionally, the account name (and website URL) should be editable. Right now, only the username and password fields are editable.

When trying to import passwords from a CSV file generated by Safari, OpenSesame shows all entries, but clicking the Import button has no effect whatsoever.

To Reproduce Steps to reproduce the behaviour:

1. Export passwords from Safari
2. Select File → Import… → Web Browser… in OpenSesame
3. Select the exported CSV file
4. In the modal showing all entries, click Import

Expected Behaviour When clicking Import, OpenSesame should import all passwords from the CSV file.

System Information

• macOS 12.2.1 Monterey
• Safari 15.3 (17612.4.9.1.8)
• Version 1.1.1 (36)

Describe the bug On iOS app doesn’t add an item if the app is locked in the background

To Reproduce

1. Open app
2. Start adding an account
3. Minimize the app (it is locked now)
4. Open the app again
5. Dialog is still on top, but "Add" button does nothing. Underneath the dialog is the lock screen.

Expected behavior Lockscreen should be on top of the dialog. And it should be possible to add that item after unlocking.

Smartphone (please complete the following information):

• Device: iPhone 12
• OS: iOS 15

Originally posted by @EthanLipnik in https://github.com/OpenSesameManager/OpenSesame/issues/25#issuecomment-917745550