Importing a framework with a generated client

[adamkornafeld]

Question

Great project, thanks for working on it!

I have a fairly large openapi spec (22k+ lines) that I use to generate a client with. The resulting Client.swift is 21k lines and Types.swift is 90k lines. Takes a good while to compile, like drink my coffee long. To avoid slowing down the compilation of projects that use the generated client, I created a framework (F) with the generated client that I distribute as a binary framework. I can import (F) into my app project (A).

The issue I am running into is that both generated swift files import OpenAPIRuntime on the very first line:

@_spi(Generated) import OpenAPIRuntime

Hence, I have to add OpenAPIRuntime as a dependency to my framework (F) project. So far so good, I will not add OpenAPIRuntime as a dependency to (A) to avoid the issue described below. However, I do have to add OpenAPIURLSession as a dependency to (A). That also depends on OpenAPIRuntime, so it pulls it in as a transitive dependency.

Net-net, when I run the app I see log messages:

objc[1426]: Class _TtC17OpenAPIURLSession40BidirectionalStreamingURLSessionDelegate is implemented in both 
/private/var/containers/Bundle/Application/02BB3430-E963-422B-9938-F07FFAB45EC4/A.app/Frameworks/F.framework/F (0x1032ed228) and 
/private/var/containers/Bundle/Application/02BB3430-E963-422B-9938-F07FFAB45EC4/A.app/A.debug.dylib (0x1039116d0). 
One of the two will be used. Which one is undefined.

The client and the app still works, it's mostly cosmetic that every time the app starts up, the console is flooded with tons of these messages. I have exhausted all my options to remedy this. Do you have any ideas how to resolve this? Thx

[czechboy0]

Hi @adamkornafeld,

before I make a recommendation about a way forward, can you say more about what % of the total operations in the OpenAPI each of your clients end up using? Is every client using ~all of them? Is each client using a small subset? Are those subsets the same, or is each client using a different subset?

[adamkornafeld]

Hi @czechboy0,

Thanks for the quick response. I see where you're going with the question. I don't have a specific %, but it is probably not all of the functionality. However, we do already have client libs for a number of other languages and chose to distribute them as single binaries.

[czechboy0]

Yeah, if your clients only need a subset of the API, I'd instead recommend you distribute the OpenAPI doc to them, and they'd use Swift OpenAPI Generator directly with the filtering feature, and only generate the exact operations they need. That's what I do for large APIs, like GitHub and others. Leads to super fast build times and lets the adopter have the full flexibility of adding more operations to the filter whenever they need. And doesn't require distributing/signing/etc binaries.

[adamkornafeld]

@czechboy0, while working on the "publish the spec and filter"-approach, ran into an interesting problem; wanted to get your take on it and see if you have any recommendations.

I took this sample from the openapi.yaml and simplified it a bit for clarity:

components:
  schemas:
    TransferOptions:
          type: object
          properties:
            sourceOptions:
              type: array
              items:
                $ref: '#/components/schemas/PaymentMethod'
            destinationOptions:
              type: array
              items:
                $ref: '#/components/schemas/PaymentMethod'

    PaymentMethod:
      oneOf:
        - $ref: '#/components/schemas/AchDebitCollectPaymentMethod'
        - $ref: '#/components/schemas/AchDebitFundPaymentMethod'
      discriminator:
        propertyName: paymentMethodType

Practically, the PaymentMethod type is used twice in TransferOptions, once as sourceOptions and second as destinationOptions. The swift codegen generates code from this just fine. The issue I ran into is that the version of openapi.yaml that we publish is fully expanded so instead of references it contains full copies of the reference items. In this version, the sourceOptions and destinationOptions end up in the generated code as two distinct, albeit identical types SourceOptionsPayloadPayload and DestinationOptionsPayloadPayload:

internal enum Body: Sendable, Hashable {
  /// - Remark: Generated from `#/paths/transfer-options/POST/responses/200/content/json`.
  internal struct JsonPayload: Codable, Hashable, Sendable {
      /// A method of moving money
      ///
      /// - Remark: Generated from `#/paths/transfer-options/POST/responses/200/content/json/SourceOptionsPayload`.
      internal enum SourceOptionsPayloadPayload: Codable, Hashable, Sendable {
          /// - Remark: Generated from `#/paths/transfer-options/POST/responses/200/content/json/SourceOptionsPayload/AchDebitCollectPaymentMethod`.
          case achDebitCollect(Components.Schemas.AchDebitCollectPaymentMethod)
          /// - Remark: Generated from `#/paths/transfer-options/POST/responses/200/content/json/SourceOptionsPayload/AchDebitFundPaymentMethod`.
          case achDebitFund(Components.Schemas.AchDebitFundPaymentMethod)
          
          internal enum CodingKeys: String, CodingKey {
              case paymentMethodType
          }
          internal init(from decoder: any Decoder) throws {
              let container = try decoder.container(keyedBy: CodingKeys.self)
              let discriminator = try container.decode(
                  Swift.String.self,
                  forKey: .paymentMethodType
              )
              switch discriminator {
              case "ach-debit-collect":
                  self = .achDebitCollect(try .init(from: decoder))
              case "ach-debit-fund":
                  self = .achDebitFund(try .init(from: decoder))
              default:
                  throw Swift.DecodingError.unknownOneOfDiscriminator(
                      discriminatorKey: CodingKeys.paymentMethodType,
                      discriminatorValue: discriminator,
                      codingPath: decoder.codingPath
                  )
              }
          }
          internal func encode(to encoder: any Encoder) throws {
              switch self {
              case let .achDebitCollect(value):
                  try value.encode(to: encoder)
              case let .achDebitFund(value):
                  try value.encode(to: encoder)
              }
          }
      }
      /// - Remark: Generated from `#/paths/transfer-options/POST/responses/200/content/json/sourceOptions`.
      internal typealias SourceOptionsPayload = [Operations.CreateTransferOptions.Output.Ok.Body.JsonPayload.SourceOptionsPayloadPayload]
      /// - Remark: Generated from `#/paths/transfer-options/POST/responses/200/content/json/sourceOptions`.
      internal var sourceOptions: Operations.CreateTransferOptions.Output.Ok.Body.JsonPayload.SourceOptionsPayload?
      /// A method of moving money
      ///
      /// - Remark: Generated from `#/paths/transfer-options/POST/responses/200/content/json/DestinationOptionsPayload`.
      internal enum DestinationOptionsPayloadPayload: Codable, Hashable, Sendable {
          /// - Remark: Generated from `#/paths/transfer-options/POST/responses/200/content/json/DestinationOptionsPayload/AchDebitCollectPaymentMethod`.
          case achDebitCollect(Components.Schemas.AchDebitCollectPaymentMethod)
          /// - Remark: Generated from `#/paths/transfer-options/POST/responses/200/content/json/DestinationOptionsPayload/AchDebitFundPaymentMethod`.
          case achDebitFund(Components.Schemas.AchDebitFundPaymentMethod)
          internal enum CodingKeys: String, CodingKey {
              case paymentMethodType
          }
          internal init(from decoder: any Decoder) throws {
              let container = try decoder.container(keyedBy: CodingKeys.self)
              let discriminator = try container.decode(
                  Swift.String.self,
                  forKey: .paymentMethodType
              )
              switch discriminator {
              case "ach-debit-collect":
                  self = .achDebitCollect(try .init(from: decoder))
              case "ach-debit-fund":
                  self = .achDebitFund(try .init(from: decoder))
              default:
                  throw Swift.DecodingError.unknownOneOfDiscriminator(
                      discriminatorKey: CodingKeys.paymentMethodType,
                      discriminatorValue: discriminator,
                      codingPath: decoder.codingPath
                  )
              }
          }
          internal func encode(to encoder: any Encoder) throws {
              switch self {
              case let .achDebitCollect(value):
                  try value.encode(to: encoder)
              case let .achDebitFund(value):
                  try value.encode(to: encoder)
              }
          }
      }
  }

}

And due to the generated code uses the shorthand constructor .init() inside the switch discriminator { ... }, it yields a type inference failure:

OpenAPIGenerator/GeneratedSources/Types.swift:32614:59: error: cannot infer contextual base in reference to member 'init'

Have you ran into something like this? What would you recommend? (other than publishing the non-expanded openapi.yaml :) Thanks, for all you do!

[czechboy0]

Oh interesting, could you attach the snippet as whole OpenAPI doc that reproduces the build error? That's definitely something we should look at, we should never generate non-compiling code.

[adamkornafeld]

The whole doc is published here. I usually have to run yq eval 'explode(.)' on it to have star* references unfolded as the generator does not like those.

[adamkornafeld]

Oh, and filter for transfers, otherwise it takes a while to compile:

filter:
  tags:
    - Transfers