Post not yet marked as solved
Is Body placeholder replaced with the actual View type?
Not exactly. When you create a new file in your project and select SwiftUI View, Xcode creates the file with a View compliant structure stub. The type of that structure will be what you named the file when you created it, and its body property returns some View.
What does "Self.Body" means?
Self refers to a type, where self refers to an initialized instance of the type. So, if you name your SwiftUI view "MyView" then Self.Body will be MyView.body which is of type some View which is an opaque return type. An opaque return type in this case just means that it is some kind of view that conforms to the View protocol. It could be of a type provided by the framework or a custom type.
Post not yet marked as solved
It does show up on my iPhone.
Post not yet marked as solved
The Resources folder doesn't exist in the Xcode project, only in the build version of you app. Just add the files to your project and let Xcode put it where they belong in the build.
Post not yet marked as solved
I realize I'm a bit late, but if it can help. Resource files such as xib and storyboard get their own strings file. You need a MainMenu.strings file in each of your lproj folders.
Apple has a tutorial in which you build a multi-platform app in SwiftUI that showcases inserting a menu command in the macOS version. You can find it here - https://developer.apple.com/tutorials/swiftui/. The macOS bit is at the end. Hope it helps.
Post not yet marked as solved
No, you're not alone. How the hell are we supposed to localize the mac App menu in SwiftUI using the App protocol lifecycle?
The storyboard/xib approach gives us a complete menu bar with even added menu items at run time which the system inserts and localizes for free such as "Enter Full Screen" and "Show/Hide Toolbar". The menu that SwiftUI gives us seems to be stripped down and not only does it not auto-localizes but there doesn't seem to be a way to localize it using strings file.
Post not yet marked as solved
I also use this enum based approach for the same reason and noticed the same thing in SwiftUI previews. Sorry, but I haven't found a way to make it work.
Post not yet marked as solved
The Recents item is just one of many items in the normal file picker, there's also iCloud Drive, On My iPad (or iPhone), Recently deleted etc. In order to get something in the Recents your app needs to have previously saved or read a document. If you run in the Simulator for the first time or erase the settings of the simulator device it would start with On My iPad (or iPhone) with a blank document icon which creates a new doc when the user taps on it. Concerning the spinning progress view, the system just tries to be smart by attempting to restore the previous state of the app by reopening the last viewed document, and if there aren't any, well it obviously can't. I haven't tried that on an actual connected device lately so I don't remember if it's just a Simulator oddity that the search never finishes.
Post not yet marked as solved
I'm not on BigSur so I can't build your test app on my current machine, but you have declared your app as Editor for the role in you document type declaration: select your project in the navigator, select the target, go to Info tab, under Document Types set role to Viewer (which means your app does not create this type of doc) and try Handler rank to Alternate instead of Default (I think default is Owner if I remember correctly, which is not the case for your app). The type is also declared as Imported which is correct. Try that and see what difference it makes.
Post not yet marked as solved
Actually, If you go the programmatic way, it is recommended to do that in applicationWillFinishLaunching, before the system inserts some of it's own menu items. I'm sorry I can't find the link to where I've read that (I think it was a technical note or a release note), but I remember it was from Apple.Hope it helps.
Not according to the Design page of the developpers website. It's for iOS 13, tvOS 13 and watchOS 6. But the symbols are exportable from the SF Symbols app as svg which can be edited (or not if you find one that fits your needs as-is) with an graphic desing app. Note that for macOS you would only use one of the embedded symbol (SF Symbols are a little bit like fonts, they contain different sizes and thickness of the same image) which you could export as a 1x pdf and let the system automatically scale it for retina displays.That's the only workaround I can think of.
Post not yet marked as solved
If I understand your question correctly, that is usually achieved by1) grouping the related options inside separators2) toggling the state property of the menuItems accordinglyThe state of a NSMenuItem displays or hide a checkmark to the left of the menu title (like the character encoding options in Safari there are at least 30 to choose from bu only one can be selected at any time). When state if .on the checkmark is dispalyed and .off hides it. You don't do that in NSUserInterfaceValidations, instead, you implement it in your IBAction.I know I'm a little bit late but I hope it clarifies the proper way to do it.https://developer.apple.com/design/human-interface-guidelines/macos/menus/menu-anatomy/
