Add SwiftUILists pod

[kyleve]

Getting the base targets set up for the SwiftUI interface. I am not including anything in the changelog yet.

[kyleve]

This was never committed before, but I figure it should be like the Demo one for consistency across developers.

[n8chur]

Would you be open to doing this on a feature branch until it's ready to be integrated upstream?

[kyleve]

Would you be open to doing this on a feature branch until it's ready to be integrated upstream?

We're not publishing the pod at all, so main seemed fine to me. This repo doesn't see much action anyway...

[n8chur]

I'd prefer this to go on a feature branch, but don't feel too strongly—maybe let's get one more review with a comment regarding this before merging?

• 1 more review addressing feature branch topic

[kyleve]

So I think I've said this before, but maybe haven't written it down: Feature branches are only useful when, without one, you're going to be forced to ship something buggy or incomplete to your customers – but they come with downsides, eg the longer running they are, the more of a pain it is to merge back and forth, and avoid incongruent changes on main vs the-feature/branch. This is why instead of feature branches in POS, we tend to leverage feature flags for example. Given that we can just not publish this pod (or any other pods) until they're ready, the feature branch in general is just extra legwork for no benefit, IMO.

[robmaceachern]

1 more review addressing feature branch topic

In this context (an open source repo) I would advocate for a feature branch. Even without publishing the pod it would accessible to consume by an eager client. I don't think there's any harm in an empty podspec/framework being available but I probably hold it in a feature branch until some set of functionality was closer to being made available.

Approving because I'm not going to lose sleep over this whether it lands in main or not.