For me, my setup was working with a "local" package inside an Xcode project. After adding the Localizable.xcstrings file, I had to quit Xcode and reopen it then build the project using the main app target scheme selected for it to work as expected and populate the strings. This seems like a bug in Xcode 16.2. Editing local packages from Xcode app projects is buggy in other ways as well, for example, deleting a file in a local package from the Package Dependencies section in the project navigator does not work and I have to close the app project and open the local package alone for deleting to work. I'm starting to get used to quitting and starting Xcode in my setup.

I recently found out that Apple's Swift Crypto open source package has a _CryptoExtras module that supports AES CBC encryption in Swift. I have used it in my iOS app after I discovered it using Xcode's Add Package Dependencies… window under Apple Swift Packages. It satisfied my AES CBC encryption needs perfectly, although it lacked proper documentation and has all of its types prefixed with an underscore. I shared some feedback about it in the pitch thread in Swift Forums.

I also wonder why "Preserve Vector Data" can't be set at run time via an API like the rendering mode and other properties of image assets.

For deleting the builds, at first I deleted the internal and external test groups thinking that was enough and this operation will cascade and expire all builds, but that didn't work. Then I had to create a new group for the builds to appear, open each build, clear the Test Information section for that build, then expire the build. I had a lot of active builds so the process was tedious. I think Apple can improve the experience here by adding a single button that clears and expires all the builds right inside the Transfer App criteria checklist.

I'm facing the same issue on the iOS 17.2 simulator with TextField.init(_:value:format:prompt:). Even though the official documentation provides an example binding to a Double?, every time I submit the text field, the state variable is reset back to nil. https://developer.apple.com/documentation/swiftui/textfield/init(_:value:format:prompt:)-6ug7k

Hello @noloman I faced the same issue as well and was searching for an answer for hours until I found a simple one that worked for me: Just disable Code Coverage for your scheme. From the "Edit Scheme…" window, select Test from the side menu and then choose the Options tab, then uncheck the box for Code Coverage. This is where I found the answer https://github.com/CocoaPods/CocoaPods/issues/9275#issuecomment-576937202

I think the ability to capture Live Photos using UIImagePickerController is broken. In fact, if you print the value of mediaTypes immediately after the line where you assign it the values [UTType.image.identifier, UTType.livePhoto.identifier], you will find the print output to be only ["public.image"], when it should be ["public.image", "com.apple.live-photo"]. UIImagePickerController seems to immediately and deliberately prevent UTType.livePhoto.identifier from being set on mediaTypes. UIImagePickerController.availableMediaTypes(for: .camera) is also missing the value "com.apple.live-photo". Even though the device I tested on supports Live Photos (iPhone 12 Pro) and the system Camera app allows me to capture Live Photos. There are a few possible explanations here: This used to work when it was first introduced back in iOS 10 and broke sometime after, so it's a bug. It was silently removed without a deprecation notice. It was never meant to work when using the camera source type and the documentation is simply wrong and confusing. I hope we get some explanation from Apple about this. For the time being I have created a feedback for it (FB12191966).

I'm also facing this issue in Xcode 14.1 If I put a breakpoint inside any async function and try to po any value in the local scope of the function, I get the cannot find in scope message. The workaround for now is to use the good old print() and print the values at run time. I hope there's a solution for this.

I'm facing this exact same problem. And the only solution is to delete the certificate from Keychain Access, which lets Xcode prompt me to revoke it, then Xcode generates a trusted one the next time, then the cycle repeats and it happens every time. I don't understand the root cause and seem to be stuck to where @mungbeans latest findings are.

I'm also facing this issue in a brand new iOS project in Xcode 14 (14A309) with a minimum deployment target of iOS 16. I tried changing the Lock setting from the Identity Inspector's Document section for both the navigation controller and its navigation bar. I also tried manually assigning an empty delegate to my view controller's navigationController?.navigationBar property, but all of these attempts did not resolve this assertion message. I'm assuming it is simply an oversight; one of those harmful internal logs that should be hidden, but left visible by mistake, as it doesn't seem to cause any visual issues for me when using the default navigation controller scene in the storyboard. I hope it will be fixed or silenced in Xcode 14.1

As of Xcode 13.3 and iOS 15.4, the keyboard onboarding screen does not count as an interruption by the XCTest framework and does not trigger a call to the interruption handler closure of addUIInterruptionMonitor(withDescription:handler:). I created this convenient function that taps a keyboard key while also handling the keyboard onboarding screen. It should minimize the chances of failing a test that interacts with the keyboard. extension XCUIApplication { /// Taps the specified keyboard key while handling the /// keyboard onboarding interruption, if it exists. /// - Parameter key: The keyboard key to tap. func tapKeyboardKey(_ key: String) {     let key = self.keyboards.buttons[key]     if key.isHittable == false {         // Attempt to find and tap the Continue button         // of the keyboard onboarding screen.         self.buttons["Continue"].tap()     }     key.tap() } }

I'm still seeing this issue in Xcode 12.5.1 I wonder if it was fixed in Xcode 13 beta or not, but I can install it on my computer.

If you manage existing accounts for users such as education accounts or enterprise accounts. For example if you are a university that distributes accounts for students and want them to use the app only if they authenticate with the university account. Then it's OK to not implement Sign In with Apple. However, if you use MSAL to authenticate personal accounts ending with @outlook.com or similar, while the user have the ability to register an account using your own UI with an email and password, then I guess this makes MSAL the same as any other 3rd party authenticator and you have to provide Sign In with Apple as well.

I'm also looking for any workarounds to fix this behavior in iOS 14. I haven't tested iOS 15's ColumnNavigationViewStyle yet.

I faced the same issue when adding a unit testing bundle target to my project after already signing and distributing it to the Mac App Store. I was using the "Automatically manage signing" checkbox for my main app target. To fix this I had to uncheck that box and check it again before adding the unit testing bundle. I don't know what happened under the hood, but this solved it for me.