I have taken a long-ish break from 100 Days of SwiftUI to do a couple of related things.  I am trying to really nail done SwiftData so I am doing the SwiftData by Example Collection.  Also, using what I have learned, thus far, I have created an app from a long languishing idea that has been waiting for me to turn it into an app on the AppStore.  I completed the business logic two years ago, but needed the time and SwiftUI experience to make it happen in a way that would make me happy.  It is in Test Flight now.  Every part of creating the app just flowed.  I knew what I wanted to do.  I knew how to execute each part of the app or knew where to get the info.  For this app, I had reached critical mass in my progress and I needed to create it.  I'll get back to learning SwiftUI in a week.

One more thing I discovered while doing this new app was how to get the Section Header to stay on the screen when scrolling the contents of the section.  Much like the secret of how to get buttons to recognize button taps when they are in a list row, you just had to somehow know or find the secret.  It was not discoverable.

var body: some View {

        List {

            Section(header: SectionHeaderView(total: users.count)) {

                ForEach(users) { user in

                    ListRowView(user: user)

                }

                .onDelete() { indexes in

                    users.remove(atOffsets: indexes)

                }

            }

        }

        .listStyle(.plain)

    }

}

Again, it was changing the style of a UI View.  Here, in order for the Section Header to be "sticky" and stay in view which scrolling the list up, the style of the list had be .listStyle(.plain).

Why this is?  I believe it is because of a complicated interaction with the default .insetGrouped listStyle support of sidebars on iPads and Macs.  That's all I know.  You need to apply this one non-default listStyle and then it works.  Magic.

(UL10)

I have submitted a few dozen radars/feedbacks over the years since Swift was first released. While some have gotten more traction than others, the one's that really find honest to gosh broken functionality get fixed. The bug I detailed here was reported on to Apple on 11 Nov in Feedback: FB15764538. On 3 Dec, I was notified by Apple that they believe it was fixed in Xcode 16.2 Beta 3 and they asked me to test it. I did and they did indeed fix the issue. Success. Effort justified.

import SwiftUI

struct ContentView: View {
  @State private var text = ""
  var body: some View {
    VStack {
      TextField("Enter Text Here", text: $text)
        .foregroundStyle(text.count > 3 ? .primary : Color.red)
      Text(text)
        .foregroundStyle(text.count > 3 ? .primary : Color.red)
    }
  }
}

This is the simple test case I sent Apple detailing the problem with TextField.

We developers don't work for Apple, but we are a critical part of the app development eco-system. The folks who produce the developer tools and the libraries are not perfect but they try really hard to get as close as they can to that goal. We, 3rd party developers and hobbiests, play an important role in helping close that gap even more. 

And just in case you think that you don't need to report bugs like these, that someone else will, don't bet on it. This Feedback was marked as: 

           Recent Similar Reports:None 

While a bunch of reports on the same bug from multiple developers can help draw more attention to the really hard to find or solve problems, even more powerful is a simple bit of sample code that clearly reproduces the problem - pure gold for the engineer trying to find the issue. Be clear, be concise, be polite. 

I feel great when a bug like this gets fixed. I helped someone elses app shine because it wasn't hobbled by this bug. I helped another developer not waste hours tracking this same bug down in order to find a work-around. I helped an Apple Developer Tools Engineer get a little closer to their goal and feel justifiable pride in producing a product just a little better than it was the day before.

Also, thank you to @MartinAtElitappar on the HackingWithSwift+ forums who helped validate my conclusion that this was a bug and who encouraged me to report it to Apple.

(LU9)

Back to Work

I took some extra time after family departed before I got back into 100 Days of SwiftUI.  For those keeping track, I am on Day 54.  I took extra time with the challenge on Day 47, Habit Tracker, not because it was difficult, but because I really wanted to pull together the concepts and try a couple of new things.  

One of the new things was adding buttons views in a list row. Turns out there is a secret to making this work. You have to read the documentation or get a bit lucky on StackExchange.  I really don't know how people coded before the internet.  Oh yeah, I remember.  I RTFM.  Anyhow, the problem was that tapping on the button in the list row, just selected the row.  The button press was not detected.  Turns out for the button press to be recognized, the .buttonStyle must be anything other than .automatic, the default.  My thanks to Ramis who provided the answer.  It has 312 likes (at the moment) so I think a great many others have searched for this answer.

The other issue was crafting an input screen that also served as a detail view.  The former was reached by an add button, sliding up a sheet.  The latter via tapping on the list row of an existing habit that was a NavigationLink to a detail view.  The two cases were differentiated by passing in the selectedHabit.  In the case of adding a new habit, the selectedHabit was nil.  In hindsight they certainly could have been two different views, but I enjoyed working out how to do it with a single Swift view.

Anyhow, I'm currently getting an introduction to SwiftData on Day 54 and enjoying replacing CoreData with all its quirks.  I'm too new to SwiftData, but I'm sure I'll be cursing its particular quirks soon enough.

 (LU8)