C# client: The OpenIap.Maui.Iap namespace shadows the OpenIap.Maui.Iap class

[softlion]

The OpenIap.Maui.Iap namespace shadows the OpenIap.Maui.Iap class.

Workaround:
using IapApi = OpenIap.Maui.Iap;

But it is a bad design that should be changed.

[gitdogbot]

@softlion ## Issue Analysis

You've identified a valid C# namespace design issue for the planned maui-iap library. The problem is that having both:

• A namespace OpenIap.Maui.Iap (likely for organizing types and utilities)
• A class OpenIap.Maui.Iap (the main API class)

...creates a naming conflict where the namespace shadows the class, forcing users to use the workaround using IapApi = OpenIap.Maui.Iap;.

Recommended Solution

Rename the main API class to avoid the conflict. Common C# patterns:

Option 1: Use a non-conflicting class name

// Instead of: public class Iap { }
// Use: public class IapApi { }

namespace OpenIap.Maui.Iap
{
    public class IapApi
    {
        public async Task<PurchaseResult> PurchaseAsync(string productId) { }
    }
}

// Users can now use it naturally:
using OpenIap.Maui.Iap;
var iap = new IapApi();

Option 2: Use a service suffix

namespace OpenIap.Maui.Iap
{
    public class IapService
    {
        public async Task<PurchaseResult> PurchaseAsync(string productId) { }
    }
}

// Usage:
using OpenIap.Maui.Iap;
var service = new IapService();

Option 3: Move the class to a parent namespace

namespace OpenIap.Maui
{
    public class Iap
    {
        public async Task<PurchaseResult> PurchaseAsync(string productId) { }
    }
}

namespace OpenIap.Maui.Iap
{
    // Utilities, models, interfaces here
}

// Usage:
using OpenIap.Maui;
var iap = new Iap();

Recommendation

Option 1 (IapApi) is the best choice because:

• ✅ Keeps the logical namespace organization (OpenIap.Maui.Iap)
• ✅ Class name clearly indicates it's the API entry point
• ✅ No workarounds needed for users
• ✅ Follows common library patterns (e.g., HttpClient, SqlConnection)

This eliminates the namespace/class name collision while maintaining clean, intuitive code organization.

---

🤖 Generated by gitdog.dev · Have more questions? Tag @gitdog and let me know!

[hyochan]

Checked and fixed in PR #184: #184

Gitdog was directionally right that this is a valid C# namespace/type collision, but its analysis assumed a source namespace layout that does not actually exist in this repo. The fix uses OpenIapClient as the preferred facade and keeps Iap as a hidden compatibility shim, so existing code keeps compiling while namespaces like OpenIap.Maui.Iap can reference global::OpenIap.Maui.OpenIapClient without the collision.

[hyochan]

Deployed the final MAUI fix in OpenIap.Maui 1.1.3.

• Follow-up fix PR: fix(apple): accept apple purchase props #185
• GitHub Release: https://github.com/hyodotdev/openiap/releases/tag/maui-iap-1.1.3
• NuGet: https://www.nuget.org/packages/OpenIap.Maui/1.1.3

This includes the PR #184 MAUI net10 / Android packaging work and the PR #185 iOS purchase-sheet fix. The iOS MAUI bridge now accepts the canonical apple purchase/subscription props while preserving the legacy ios fallback, so MAUI iOS purchase requests can resolve the SKU and present the StoreKit purchase sheet.