I think you might be getting confused on where the username and password is being required. TestFlight requires an Apple Developer Program membership, thus you have to sign in to TestFlight with an Apple ID that has that subscription. There shouldn't be any requirement for the app that you are testing to collect login information for any reason (unless that is part of your app's capabilities, which it looks like is not the case).

Having put your small code snippet into an App playground, the compiler is telling me that your Emoji struct does not have any member allCases. Note that the allCases property is only automatically generated for enumerations conforming to the CaseIterable protocol. As such, just add , CaseIterable between the String raw value type and the open curly brace. See below: enum Emoji: String, CaseIterable { case 😀,😝,🤨,🎉 } Generally, my trick to trying to find these source errors is to comment out certain parts of the code and rebuild and repeat. If commenting out a particular portion of code results in the problem being rectified (not necessarily correct behaviour, but rather just the lack of compilation errors in this part of your code) then I basically drill down and comment out smaller and smaller portions of code until the error becomes more obvious (usually reading a single line of code or so at that point). Occasionally, the compiler provides a specific error that points me in the right direction without having to drill down as far as otherwise but this may not occur depending on where exactly the error is occurring in your code.

It appears to me that what you're doing is very tedious and repetitive, since Apple provide the colorScheme environment variable that you can use to access the current system colour scheme and adapt the stuff that is specific to your application (such as the sun and moon images). Many of the built in views such as List also support the system colour scheme setting automatically out of the box.

The minimum deployment target defines the minimum version of the operation system (iOS in this case) that your app will run on. If your app is targeted for iOS 16.5.1, you will only be able to run your app on devices running iOS 16.5.1 or later (which include your iPhone 8). However, I'm not entirely sure if your computer will work for that because Apple tend to only provide some support for devices whose operating systems are older than those that the computer is running. For example, with your Mac, the latest version of macOS that I believe is supported is the latest version of macOS Monterey (not entirely sure of the number but 12.x.y), while iOS 16 was released around the same time as macOS 13. As such, I think your computer is likely too old to develop for your phone. However, having said that, even if your computer were able to develop for iOS 16.5.1, it would likely not have support for much longer. Usually Macs can last at least five years with future macOS updates, though it can be somewhat unpredictable based on the requirements of a particular software version and the hardware in question.

Which beta of Xcode 15 are you running? I'm having reasonably good luck with beta 5, it only seems to have difficulty with very specific things, which can usually be fixed by adding files on the command line (git add <files>).

When you've added a file, it will stay in the state it was in the last time you added it until you 'add' it again or 'restore' (inverse of adding). 'Add' is a little confusing as a term to use, though by 'adding' a file, you are really selecting which change(s) will be included in the next commit. On the command line, you can type git add <files, separated by spaces> in order to update the changes that you want to commit (or not want to commit). You can also accomplish this by removing the changes that you've 'added' by typing git restore --staged <files, separated by spaces>. Note that that second command will remove any and all changes that have been added (which sounds like what you would want in your situation). If the latest commit state matches the current working copy state, the change should not be mentioned anymore. Alternatively, in Xcode 15 (beta), you can also right click on the file and select "unstage changes" and it should clear it there too. Hope this helps.

The MemberAccessExprSyntax (the type of syntax returned to me) does not (on it own from SwiftSyntax at least) provide an obvious way to take the member access and transpose it into the value of that member.

The primary issue with this that I'm having is that I need in order to generate the accessors for the sample data files that are in the bundle directory, I need to know where to look for the files. At the moment I'm using the FileManager type from foundation to perform the searches. I'm trying to find a way to do this, thus it isn't strictly necessary for me to ask for the path. try FileManager.default.contentsOfDirectory(atPath: "\(sampleDataDirectoryPath)/\(fetcherName)")

Last night I checked my configuration in GitLab and the web hook automatically appeared, though I received a no route to host error. This is most likely something wrong on the GitLab self-hosted server where I have my projects. I was most initially concerned about the creation of the web hook which has seemed to resolve itself. However, I am not 100% sure as to whether merely waiting is the correct procedure, and if so, for how long. I will update this post as new developments emerge if possible and will not mark this thread as solved until I figure out the situation with the web hook.

I submitted a request to DTS asking for their assistance, through which I skimmed down the project where I was having this issue. Attached is this project and I'm sending the link to this thread this evening. Hopefully in the next few days they will be able to answer the question here for the benefit of all concerned. Link to sample project: https://www.icloud.com/iclouddrive/01bLWvFE-5ycofgxbpBsxDqDw#TransportBase-AbstractionForCodeLevelSupport2024-06-14

I believe that the situation is a GitLab issue, but I won't know for sure until this weekend when I go through and see precisely what the situation is.

For those who have just stumbled upon this thread, my situation is that I am trying to run the code above in the first post to verify that the colors that I get from an asset catalog are being correctly converted into SwiftUI Color instances so that frequently used custom colors can be more easily managed. This conversion is done automatically using a Swift package plugin that generates the accessors automatically based on the asset catalogs. The persistent issue that I've been having for a longer period of time as I am writing this is that neither XCTest nor Swift Testing find the two instances equal because one is instantiated using the initializer that takes three Double instances (one red, one green, and one blue) and the other is instantiated using the initializer that specifies the color as it appears in an asset catalog. These tests have been consistently failing as a result and are marked as being known issues. My updated version of this project uses Swift Testing for these tests, though the issue occurs regardless of the testing framework in use. I have thought about how it may not be necessary to do as deep as comparison. I could make sure that the correct symbols are being generated by filling in manually what I would expect from the generated code. I recently contacted Apple Developer Technical Support and am working with them to resolve my issue. I will occasionally post new updates on the status of my issue.