The error message in the subject line greets me for EVERY file in my main build project when I attempt to build or run the main scheme. Looking at the build log, I see the following when the builtin-swiftTaskExecution for every file: <unknown>:0: error: deserialized error type '<null>' in module 'Amber3Utils' (The build within Amber3Utils has no errors...) The workspace has one framework (Amber3Utils) which is a git submodule. The build depends on this framework, which builds automatically (after a "Clean build folder", for instance). I'm using the same source code (from the git branch "develop") for a different project and it builds perfectly without issue. I've tried running the same project against Xcode 15.0.1, Xcode 15.1, and the current Xcode 15.2 with the same results. Each different attempt is preceded by clearing out DerivedData. I've used "xcodebuild" instead of Xcode IDE, which does not generate these errors. When I click on an error in the Issue navigator, there is no indication of which line the error is on in the editor, and the message disappears from the navigator. If I then select a different file with the same message in the navigator, the previously removed error message reappears and the message for the new file disappears from the navigator. This is extremely frustrating. I used DuckDuckGo to search for the string "Deserialized error type '<null>'" and within Google, it got no results for the string, and instead returns results for each of the words, and none of the citations it finds has this particular error. This appears to be an issue with the import Amber3Utils statement because if I remove it and remove references to the framework from a source file, the issue will no longer appear for that file in the Issue Navigator. Does anybody have a clue what's going on?

For quite a while, I have been using a somewhat simple-minded technique to provide semi-automatic localizations for strings used within a few of my apps. Here is the gist: Create an enumeration with RawValue of String that conforms to LocalizedRawRepresentable. Use this enum to associate a "key" with a string (default localization) Run a script that parses all Swift code looking for the enumerations that conform to LocalizedRawRepresentable and create/update a Localized.strings file. There were some minor issues, as it isn't easy to parse a complex Swift set of sources, but it got the job done. Simple example: enum L: String, LocalizedRawRepresentable { case fileNotFound = "File not found" } // [ ... ] if !FileManager.default.fileExists(at path: String) { print(L.fileNotFound.localized) } Well, we now have Xcode 15, and we have some new features: Macros - these things can parse Swift sources with excruciating detail A new ***** called String Catalogs Xcode supports these String Catalogs by automatically detecting localizations and creating, updating, and deleting entries into Strings Catalog automatically. So, it was time to update my simplistic LocalizedRawRepresentable and update it to support the String Catalogs! So, with my contrived example above, I spent quite a lot of time reading up and experimenting with the new Swift macros and created a macro that will make localizations much easier (so I thought...): @LocalizedStrings() enum L { private enum Strings: String { case fileNotFound = "File not found" } } The macro takes this modified enumeration and expands it to the following code: @LocalizedStrings() enum L { private enum Strings: String { case fileNotFound = "File not found" } static let fileNotFound = NSLocalizedString("fileNotFound", tableName: nil, bundle: .main, value: "File not found") } extension L: LocalizedStrings { } What I expected: Xcode would pick up the NSLocalizedStrings() generated code, and insert it into the strings catalog, and all of my work is done... no scripts needed! What I got... Xcode did not detect the generated code, and nothing was added, modified, or deleted from the strings catalog. So, I have a few questions: Is my code deficient in some way? Is there something I need to add to my generated code that would let Xcode know there are localizations to be detected? Is this an intentional limitation of Xcode's auto-detection of localizations for string catalogs to ignore generated code in its detection? (I'd hate to think I went through all this work for Xcode to simply ignore what I've done...!) Is this an accidental omission of Xcode that may be "fixed" in a future release? Right now, I can use the expanded macro to cut/paste the localization keys and values into the strings catalog, but I hoped that Swift macros plus Xcode auto-detection of localizations would have made this process nearly automatic. Does anybody have any suggestions?

iPad Air M1 - Most recent iOS 18.2 beta3 i did this two times. i have multiple photos on my Lock Screen. I can touch to get from one picture to the next. if I touch enough, it shows me the weather app. From there, I can swipe up for Home and see the springboard. At no point from the start was I logged in (hitting the power button for Touch ID never happened). This appears to be a security hole.