[Data Connect] Bug: Swift SDK generates conflicting property/class names

[samtsangbiz]

[REQUIRED] Environment info

firebase-tools: 15.1.0

Platform: macOS

[REQUIRED] Test case

Create a Firebase Data Connect mutation with an underscore-prefixed or PascalCase name:

# File: dataconnect/app-connector/mutations.gql

mutation _Placeholder @auth(level: NO_ACCESS) {
  company_upsert(data: { cik: "_placeholder" })
}

Configure Swift SDK generation in connector.yaml:

connectorId: app
generate:
swiftSdk:
outputDir: ../apps/ios/MyApp/DataConnect
package: MyAppDataConnect

[REQUIRED] Steps to reproduce

1. Create a Data Connect connector with a mutation named _Placeholder (or any PascalCase name like CreateUser)
2. Run firebase dataconnect:sdk:generate
3. Open the generated Swift project in Xcode
4. Attempt to build the project

[REQUIRED] Expected behavior

The generated Swift SDK should compile without errors. The SDK generator should ensure that property names use camelCase to avoid conflicts with class names.

Expected generated code:
// Property uses camelCase, class uses PascalCase - no conflict
public let placeholderMutation: PlaceholderMutation

[REQUIRED] Actual behavior

The generated Swift code produces a compilation error because the property name and class name are identical:

Xcode Error:

  Use of 'PlaceholderMutation' refers to instance method rather than class 'PlaceholderMutation' in module 'MyAppDataConnect'

  Generated code (AppClient.swift):
  public class AppConnector {
    init(dataConnect: DataConnect) {
      // Property and class have the same name - causes Swift conflict
      self.PlaceholderMutation = PlaceholderMutation(dataConnect: dataConnect)
    }

    // MARK: Operations
    public let PlaceholderMutation: PlaceholderMutation  // ❌ Conflict!
  }

Root Cause:
When the GraphQL operation name starts with uppercase (after removing _ prefix), the SDK generator uses the same casing for both the property name and class name, causing a Swift naming conflict.

GraphQL Name	Generated Property	Generated Class	Result
_Placeholder	PlaceholderMutation	PlaceholderMutation	❌ Conflict
CreateUser	CreateUserMutation	CreateUserMutation	❌ Conflict
placeholder	placeholderMutation	PlaceholderMutation	✅ Works
createUser	createUserMutation	CreateUserMutation	✅ Works

Workaround:
Use camelCase for all GraphQL operation names (e.g., placeholder instead of _Placeholder).

Suggested Fix:
The SDK generator should normalize property names to camelCase regardless of the input GraphQL operation name casing.

[aashishpatil-g]

I was able to reproduce the issue when the operation name is prefixed with underscore _ . The conversion to lower camel case seems to be not working due to the underscore prefix.

But CreateUser is working as expected. It generates a lower camel case variable

mutation CreateUser($name: String!) @auth(level: USER) {
    user_insert(data: {name: $name})
}

produces =>

public let createUserMutation: CreateUserMutation

If possible, can you share the operation definition for CreateUser to see what is different.

[samtsangbiz]

You're right, thank you for testing! I apologize for the confusion in my original report.

I re-tested and confirmed that PascalCase works correctly:

mutation CreateUser($name: String!) @auth(level: USER) {
user_insert(data: {name: $name})
}
→ public let createUserMutation: CreateUserMutation ✅

I had mistakenly included CreateUser in the error cases. The only issue is with underscore _ prefix:

mutation _Placeholder @auth(level: NO_ACCESS) { ... }
→ public let PlaceholderMutation: PlaceholderMutation ❌ Conflict

Corrected summary:

Pattern	Example	Result
camelCase	createUser	✅ Works
PascalCase	CreateUser	✅ Works
lowercase	placeholder	✅ Works
_ Prefixed	_Placeholder	❌ Bug - Swift conflict

Sorry for the confusion earlier!

[aashishpatil-g]

No worries and thanks for confirming that PascalCase works.

The handling of the _ prefix is a breaking change since it also impacts generated APIs on other platforms. I'll fix it during our next breaking change release.

In the meantime, is not adding the underscore prefix an option for you? If yes, I'd recommend doing that for now.