I have a similar question (https://developer.apple.com/forums/thread/651667).
In regard to the nav bar, you can simply attach navigationBarItems to the content view. I would recommend you do this inside the content view itself, not as I've shown here in the App file.
struct testApp: App {
var body: some Scene {
DocumentGroup(newDocument: testDocument()) { file in
ContentView(document: file.$document)
.navigationBarItems(trailing: Button("Button", action: { print("button tapped") }))
}
}
}
Post
Replies
Boosts
Views
Activity
beckersoft - https://developer.apple.com/forums/profile/beckersoft, that’s an interesting approach. I thought of trying something like that, but my app supports different file types (different file extensions) and by the time the editor gets invoked, the OS has already generated a file at the location the user chose. The app had to choose what kind of file to create as part of initializing the DocumentGroup. If the user then chooses a different file type in the template picker, I don’t think it’s easy to convert the file that was already created. It feels like I’m really working against the system and that may come back to bite me.
It also seems that if you cancel out of the template picker, there’s already a document created that you’d really want to be deleted.
What device are you testing? Popovers are presented as sheets in compact environments. But work fine on iPad. When using UIKit, there are ways to get popovers on iPhone (using adaptivePresentationStyle) but that is not directly available in SwiftUI. At least not yet.
They were added for iOS in Xcode 12 beta 3. https://developer.apple.com/documentation/swiftui/menu?changes=latest_beta
Yes, it has worked in all previous versions of Xcode. I have filed a bug report. It's as simple as calling
let fontPicker = UIFontPickerViewController()
present(fontPicker, animated: true)
You’re probably going to have to show an example, but have you looked at things like .frame(maxWidth: .infinity)?
Take a look at .ignoresSafeArea(...), which is new in Xcode 12 beta 4. The first parameter allows you to specify whether or not to include the keyboard in the safe area. Being able to treat the keyboard like a safe area seems to be a good route to go. I find the documentation to be a little confusing, but in my use case, .ignoresSafeArea(.container) allows my view hierarchy to avoid the keyboard. I’m not including keyboard in that first parameter, meaning the keyboard IS considered a safe area and hence my layout avoids it.
I’ve seen that as well. Assume it is a bug.
You might need to fallback to using the old UIKit App Delegate life cycle type instead of the newer DocumentGroup. With the old pattern, you are totally responsible for presenting the document view after the user selects a document. That gives you more control. With DocumentGroup, you only provide your content which DocumentGroup then embeds in it’s own view hierarchy. I have found that DocumentGroup doesn’t provide all the flexibility that was previously available. I’m hoping it will in the future, but for now, I’m avoiding it.
Working again in Xcode 12 beta 5
I’ve asked this as well - https://developer.apple.com/forums/thread/655113 I also submitted a feature request to Apple but have received no feedback from them.
Firstly, make sure you don’t have "Slow Animations" turned on under the Debug menu in simulator. Secondly, I don’t think you should expect performance to be accurate. It’s simply a simulator.
There is no substitution for testing on a real device, especially if you have timing-sensitive code. Over the years, the simulator has had bugs that aren’t present on devices, and vice versa. Use it as a convenience, but not as an indicator of real world performance. “use the simulator to tune code performance’ simply isn’t practical.
If you just need to know when the text changes, this works for TextEditor, so I assume will work on TextField:
TextEditor(text: $text)
.onChange(of: text, perform: { newValue in
print(newValue)
})
This is NOT fixed in Xcode 12 GM