Worked for me today (6 months later). Today, I had many 1.0.8 builds and wanted to bump to 1.1 — I simply went to "App Store", "1.0.8 Prepare for Submission", scrolled down to "General App Information", and changed 1.0.8 to 1.1 — working as expected so far.

My FB number is FB9812317. I downloaded XCode 13.2 direct from Apple on Dec 14 (3 days ago); built fine! I actually archived and submitted to App store. Today (Dec 17) I'm having the "Internal error: missingPackageDescriptionModule" build error. I sorely wish I'd kept XCode 13.1 (renamed as secondary app) instead of replacing it with XCode 13.2 — can I get a download of 13.1? I'm completely unable to build our team's project now.

Just ran across this on a project that is being refactored to have "better" code structure. This inability to preview views within a package that depend upon another package is pretty surprising, given the push toward Packages, the age of this post, and the number of upvotes here. In my experience, it's not that it couldn't find the package—adding the full path to the package ("/my/specific/dir/PackageName" instead of "../PackageName") did not work. The project builds and runs fine for simulators and the automated tests run and pass, but it does not build for previews. I sometimes see crashes, and sometimes the inline xcode source code error "could not find module '' for target 'x86_64-apple-ios-simulator'; found: arm64, arm64-apple-ios-simulator". Those details seem interesting (not available for x86 when running simulator)—is this what others are seeing? I've tried setting various architectures—my Mac, my Mac (catalyst), iOS simulator running iOS15, etc. For now, my workaround may be to not have packages that depend upon each other, which partly defeats the purpose. And I may file a bug report, but I may find existing and upvote.

Same. These are 6 local packages (same Git repo), worked as-is in XCode 13. In addition to the main app target not finding them, 4 of the 6 are not navigable at the top, in the Scheme selector. The other 2 are selectable, but say "No Destinations" (and when "No Destinations" is selected, it says "The active scheme has no targets". Package.swift seems fine/same for all. I've tried removing and re-adding packages with mixed success (it seemed to clear up some errors, but ultimately resulted in others, and I reverted). May try that again. Have tried "File > Packages > Reset Package Caches" and of course "Clean Build Folder" and restarting XCode and Mac. I suppose it goes without saying this is a business-critical app, and that I didn't expect to have major local package issues with the update.

Same issue; Have been uploading two separate iOS + Catalyst builds weekly/monthly for a long time; MacCatalyst upload stopped working two days ago with same "Invalid Provisioning Profile Signature" whilst iOS keeps working fine. All certs/profiles seem OK (not expired) and in place. Will try deleting that folder mentioned above!

We are seeing this too. Will upvote. Uploads fail on Cellular (when using a javascript POST, selecting from image library), and work fine on WIFI.

My observation (and the reason I found this thread) is that in MacOS Sequoia (15.2), many .sheets outright do not dismiss visually. I say "visually" because the dismiss logic runs and the dismissal state changes. In fact, if you switch away from the app, and back to it, it shows the correct state. Many .sheet modifiers work 3-4 times, then show this "freeze" effect the next attempt. For now (after many many workaround attempts) I'll stick with #if targetEnvironment(macCatalyst) .fullScreenCover(...) #else .sheet(...)

For me in MacOS Sequoia 15.2, this seems to be connected to an issue with dismissing .sheet in MacCatalyst. This message appears three times when a .sheet is presented. Randomly (about 1/3 of the time), the sheet cannot be dismissed (its dismiss/state does run/update, but the window/visual does not update). The window does then update when I navigate away from the app, and back to it.

You may want to make your JournalPromptRoute take a lightweight EntryDescriptor value object (hashable, sendable, etc) — it would have enough information to generate the JournalEntry, but be lightweight enough that it could be created 100s of times without any ill side-effects. The navigationDestination could then create the "entry" only after the navigation is selected, before passing it to the view.

Brainstorming: Try the workaround of factoring the body of the ForEach into its own view, with a boolean isFocused property, and .focused($isFocused)