Try create a new version of my app:

func newVersion(appID: String, versionString: String) async -> AppStoreVersionResponse? {
    do {
        let appStoreVersionResponse = try await service.request(
            .createAppStoreVersion(
                requestBody: .init(
                    data: .init(
                        attributes: .init(
                            platform: .iOS,
                            versionString: versionString
                        ),
                        relationships: .init(
                            app: .init(
                                data: .init(
                                    id: appID
                                )
                            )
                        )
                    )
                )
            )
        )

        return appStoreVersionResponse
    } catch {
        print("ServiceError:", (error as? ServiceError)?.description ?? "")
        return nil
    }
}

An unhandled HTTP error occurred:

ServiceError: An unhandled HTTP error occurred. Status code 422. Data as UTF-8 string: {
  "errors" : [ {
    "id" : "0a77804d-9c04-4d71-93b4-a76f52bd33b2",
    "status" : "422",
    "code" : "ENTITY_UNPROCESSABLE",
    "title" : "The request entity is not a valid request document object",
    "detail" : "The data for relationship 'appStoreVersionLocalizations' is missing the required 'type' property."
  }, {
    "id" : "41bf8ba1-6b4d-445d-b985-3d3ca365eced",
    "status" : "422",
    "code" : "ENTITY_UNPROCESSABLE",
    "title" : "The request entity is not a valid request document object",
    "detail" : "The data for relationship 'build' is missing the required 'type' property."
  } ]
}

Maybe it's a @NullCodable related issue.

Hi Morten,

There's a small issue in the CiScheduledStartCondition.Schedule model for Xcode Cloud. Currently the type of days for a scheduled start is the day itself instead of an array of days as specified in the App Store Connect API.

where as App Store Connect API would expect something like:

public var days: [String]?
public var days: [Items]? // In Bagbutik's case

Check the API specs for more info: CiScheduledStartCondition.Schedule

As mentioned in DMs, Bagbutik currently makes apps very large due to a lot of the dependencies.

As part of #168 it introduced an "unstable" release for the Zip dependency so if you try to use SPM with that version it will fail with an error similar to this:

I'm not sure what's the best course of action here but it might be a good idea to look into removing the Zip dependency.
A hacky/faster solution would be to spin up a process calling the unzip command using https://developer.apple.com/documentation/foundation/process# since it's only being used for that purpose for the CLI.

I can work on it if this is an acceptable change.

Bagbutik-Models takes ~0:24 for a debug build and ~2:10 for a release build. The other targets don't have this same difference in build times.

I asked about this a while ago on Mastodon and you mentioned that Codable could be a source of the issue.
https://mastodon.social/@mortengregersen/110210277236346597

Experiment

I had some free time so I did a bit of an experiment to see what the effect of the generated Codable implementation is on the release build time. I also included CaseIterable just incase anything generated by the compiler was the cause. I used https://github.com/sharkdp/hyperfine to benchmark the build times one different branches with the following command.

hyperfine \
  --parameter-list branch main,generate-codable,remove-codable \
  --runs 5 \
  --command-name "Building {branch}"\
  --warmup 1 \
  --setup 'git checkout {branch}' \
  --prepare 'swift package clean' \
  'swift build --configuration release --target Bagbutik-Models'

Baseline

This was run on main (e1bdc2d).

Benchmark 1: Building main
  Time (mean ± σ):     133.187 s ±  2.863 s    [User: 290.170 s, System: 55.831 s]
  Range (min … max):   130.391 s … 137.076 s    5 runs

Generating Codable and CaseIterable Conformances

This was run on https://github.com/CraigSiemens/Bagbutik/tree/generate-codable

On this branch I updated the generation to create the conformances for Codable (including CodingKeys) and CaseIterable for all types in Bagbutik-Models.

Benchmark 2: Building generate-codable
  Time (mean ± σ):     152.551 s ±  3.086 s    [User: 310.417 s, System: 57.085 s]
  Range (min … max):   150.324 s … 157.834 s    5 runs

That seems to make the build slower still, so it seems the slower builds are not caused by the compiler generating the conformance, unless it's still doing checks for whether it needs to add conformance to all the files. Watching CPU usage, it spends most of the time using a single core before switching to using all available cores.

Removing Codable and CaseIterable

This was run on https://github.com/CraigSiemens/Bagbutik/tree/remove-codable

On this branch I modified the generation to remove Codable and CaseIterable from all models to confirm whether it was the source of the slower build times. This was just for experimenting since the change also causes the rest of the project to fail to build/function.

Benchmark 3: Building remove-codable
  Time (mean ± σ):     37.170 s ±  0.244 s    [User: 119.392 s, System: 18.215 s]
  Range (min … max):   36.890 s … 37.482 s    5 runs

The build was much faster confirming that Codable adds a lot to the build time.

Results

Summary
  'Building remove-codable' ran
    3.58 ± 0.08 times faster than 'Building main'
    4.10 ± 0.09 times faster than 'Building generate-codable'

It appears that adding Codable, regardless of whether it uses the compiler generated conformance, is the cause of the increase in build time. The next steps feel like they should be:

• Report this as an issue on the swift compiler as this feels like unexpected behavour. Adding multiple files conforming to Codable shouldn't impact build times that much.
• Investigate how the build time is affected with less files being built. That would help determine whether splitting the models into multiple modules would help the issue.

Debug configuration

Debug builds show a similar relationship between the different branches, though the total time is shorter and relative improvement is less.

Benchmark 1: Building main
  Time (mean ± σ):     22.309 s ±  1.616 s    [User: 126.424 s, System: 12.401 s]
  Range (min … max):   20.469 s … 23.955 s    5 runs
 
Benchmark 2: Building generate-codable
  Time (mean ± σ):     25.719 s ±  1.523 s    [User: 138.862 s, System: 12.123 s]
  Range (min … max):   23.974 s … 28.104 s    5 runs
 
Benchmark 3: Building remove-codable
  Time (mean ± σ):     11.727 s ±  0.755 s    [User: 54.623 s, System: 9.200 s]
  Range (min … max):   10.594 s … 12.276 s    5 runs
  
Summary
  'Building remove-codable' ran
    1.90 ± 0.18 times faster than 'Building main'
    2.19 ± 0.19 times faster than 'Building generate-codable'

Environment
Bagbutik Version: 10.3.0
Platform: macOS Sonoma 14.5

Details
I'm making the following request to get data related to an experiment. I noticed that if I make the request without the limit parameter, I only get 10 localizations (in a random order). This isn't great for apps that have many localizations in the experiment.

let treatmentID = treatmentRelationship.id
let response = try await service.request(
    .getAppStoreVersionExperimentTreatmentV1(
        id: treatmentID,
        includes: [.appStoreVersionExperimentTreatmentLocalizations],
        limit: 50
    )
)

When I make the request, I get the following error:

badRequest(Bagbutik_Core.ErrorResponse(errors: Optional([Bagbutik_Core.ErrorResponse.Errors(code: "PARAMETER_ERROR.ILLEGAL", detail: Optional("The parameter 'limit' can not be used with this request"), id: Optional("020add9f-38c7-41c8-a69c-9e8fba508db0"), meta: nil, source: Optional(Bagbutik_Core.ErrorResponse.Errors.Source.jsonPointer(Bagbutik_Core.JsonPointer(pointer: nil))), status: "400", title: "A given parameter is not allowed for this request")])))

Is something misaligned in the spec? Or is this a bug in the ASC API?