Cache products and requestProducts confusion

[farynaio]

Documentation for useIAP() says Cache products to avoid repeated fetches but it looks like it's already done with fields subscriptions and products, or am I missing something?

I try to prefetch products, so they are ready to go when opening offer page. But as long as in the previous library the context used to hold it, here it's all gone and need to be re-fetched every time useIAP() is used, unless we introduce back the context or similar solution.

Here documentation says Returns: Promise resolving to array of products, but it's not, it returns Promise<void>.

Also there is undocumented function restorePurchases. How it should be used, considering restore purchase process may be complicated like restoring user in app credits?

Here documentation say to import initConnection, but afaik that seams to be not needed as it's handled automatically by useIAP() now. Is that correct?

[hyochan]

Thanks again for another great point, following up from the first issue in openiap.
I have to apologize here — this was my mistake, as I didn’t carefully review the Claude-generated docs.

---

1. Cache products

The docs currently say “Cache products to avoid repeated fetches”, but in fact, you don’t need to handle this at the application level.
This logic is already taken care of inside the library. Here’s the relevant part from ExpoIapModule.swift:

AsyncFunction("getItems") { (skus: [String]) -> [[String: Any?]?] in
    // Fetch products from StoreKit
    let fetchedProducts = try await Product.products(for: skus)
    
    // Add fetched products to the cache
    await productStore.performOnActor { isolatedStore in
        fetchedProducts.forEach { product in
            isolatedStore.addProduct(product)  // Cache the product
        }
    }
    
    // Retrieve all cached products
    let products = await productStore.getAllProducts()
    return products.map { serializeProduct($0) }
}

To clarify:

• The Open IAP specification is primarily aimed at library developers who need to align with the spec across different platforms.
• The docs here are meant to help library users understand the flow more easily without worrying about internal details.

I’ll fix the misleading line in the docs right away. Thank you again for catching this!

---

2. API differences between useIAP and the module

You’re right that the API surface in useIAP doesn’t exactly match the underlying module.
That’s intentional — useIAP is designed to follow the React Hooks flow. Instead of returning values directly, the hook updates internal state, which your components can then consume.

Because of this, methods like purchase or getProducts return void in the hook, even though the underlying module provides explicit return types.

---

3. initConnection

You’re also correct here: useIAP() automatically calls initConnection on initialization.
So importing and calling it manually isn’t necessary anymore. This is another part of the docs that I’ll revise to avoid confusion.

---

Thanks once more for the valuable feedback 🙏
I’ll update the docs to reflect these clarifications so they’re more consistent and easier to follow.

[hyochan]

Handles in #169

[farynaio]

Thank you for addressing all of these. I was trying to get the full picture how the library works, to create my own workflows on top of that. I got information from both sources, but in fact as you pointed out, their purpose not exactly match.