User Profile

I have recently created a pure (admittedly simple) SwiftUI app for iOS/iPad. Yes there are bugs and limitations I've had to face but eventually with a certain amount of compromise and without resorting to UIViewRepresentable, it works adequately. Great, I thought, how hard can it be to create a macOS version of the same app? Take TextField (swiftUI) views which my app depends on a lot, the issues I have found have been numerous... TextField does not appear to update the Binded variable after each character is typed in. You have to hit the return key for it to register. Totally different functionality. Placeholder text shifts up a few pixels when it gets keyboard focus. The rectangle where the text is typed needs to be taller holding the text, currently it looks squashed. Manually adding a ‘clear text’ button on top of the TextField (at the right) appears not to to be active when the cursor is over it (most of the time) Lots of missing autocapitalisation type functionality is missing. I could go back to a NSViewRepesentable solution of the TextField but that negates the use of 'supported' SwiftUI features. Has this half baked feature been pushed out there as a 'tick in the box' option or is Apple genuinely happy with their solution? Anyhow, I thought let's do a MacCatalyst version of my App instead. But we get a TabView looking like a iPad/iPhone App, there is no option to make it look more mac like AFAIS without abandoning TabView itself! Then there's the complication of making my Core Data App work as a 'Document Based' app with the new DocumentGroup/Scene solution.... how does NSPersistentDocument work in such scenarios? The documentation is vague at best, or simply not supported without a lot of workarounds. Just these few things make me feel we are being hyped with solutions which are far too premature for any real world work on macOS at the moment. What potential SwiftUI/macOS blockers have you encountered?

I am using iOS 14, Xcode 12 beta 4 running on both BigSur Beta 4 and Catalina 10.15.6. I created a simple SwiftUI project with this code replacing the default Content View. If you run this code in Landscape of iPhone 11 or Portrait on iPad 9.7, the very first time the View appears the Secondary view is empty. The user needs to hit the back button to get back to the Primary view. Surely if no selection is made the Primary View should be immediately visible? Also in my Code there is an option to add a Selection immediately, unfortunately when I do, I get 2 deep secondary view. The first is an empty view, hitting back brings me to my 'selected' Secondary View. struct ContentView: View { @State var tags = ["First", "Second", "Third", "Fourth", "Fifth", "Sixth"] @State var selectedTag: String? = "First"     var body: some View {         NavigationView {             List(tags, id: \.self) { contentItem in                     //  NavigationLink(destination: Text(contentItem + " Content"),                     //  tag: contentItem,                     //   selection: $selectedTag) {                     //   Text(contentItem )                     //   }.navigationBarTitle("Help")                     NavigationLink(destination: Text(contentItem + " Content") ) {                         Text(contentItem)                     }.navigationBarTitle("Help")             }         }     } } Should I not be putting my NavigationLinks in a List? The behaviour looks good in other orientations....

Hi there,It appears Im missing something fundamental in how ScrollViews manage its content view.I have a very large Content View to add into a ScrollView. If I build the content from Views smaller or not declaring their own frame sizes, the ScrollView manages the placement of the content view without issue. But if I declare a large view and try to add that to as the content view, the offset of the content view appears to be added it too far to the top left. If you scroll the view, you will find the content will show it is miss placed at the bottom. I can force the Offset of the content view to place it correctly, but the offset value will be different both in orientations and different sizes of the content view.Here's a simple example of building the content view which demonstrates the issue. What am I doing wrong? The code works best on an ipad simulator.// // ContentView.swift // BigContentScrollTest // // Created by Eleanor Spenceley on 27/11/2019. import SwiftUI struct ContentView: View { @Environment(\.horizontalSizeClass) var horizontalSizeClass: UserInterfaceSizeClass? @Environment(\.verticalSizeClass) var verticalSizeClass: UserInterfaceSizeClass? var body: some View { if UIDevice.current.orientation.isPortrait || horizontalSizeClass == .compact { let verticalStack = VStack { Text("Side Panel") .background(Color.gray) ScrollView([.horizontal, .vertical], showsIndicators: true) { ScrollContentView()// .offset(x: 100, y:300) // Use without the offset first. }.background(Color.blue) } return AnyView(verticalStack) } else { let horizontalStack = HStack { Text("Side Panel") .background(Color.gray) ScrollView([.horizontal, .vertical], showsIndicators: true) { ScrollContentView() //.offset(x: 100, y:300) // Use without the offset first. }.background(Color.blue) } return AnyView(horizontalStack) } } } struct ScrollContentView : View { private var optimumFlowChartSize = CGSize(width: 1500, height: 1500) var body: some View { VStack { Text("Top").frame(height:20, alignment: .leading) Rectangle() .fill(Color.orange) .frame(width: self.optimumFlowChartSize.width, height: self.optimumFlowChartSize.height) Text("Bottom").frame(height:20, alignment: .leading) } } } struct ContentView_Previews: PreviewProvider { static var previews: some View { ContentView() .previewLayout(.fixed(width: 1024, height: 783)) .previewDisplayName("iPad Pro (10.5-inch) Landscape") } }