iaphub/react-native-iaphub

<explanation>

1. Identify the project type and purpose

- This is a React Native SDK module (“react-native-iaphub”) for integrating IAPHUB’s in‑app‑purchase/subscription services into mobile apps.

- It includes two deliverables:

• A reusable library with JavaScript/TypeScript bindings (in src/), plus native Android (Kotlin) and iOS (Swift/ObjC) modules.

• An “Example” React Native application that demonstrates usage and contains platform build configs.

2. Analyze the file structure

- Top‑level folders:

• src/ – core JS/TS code (config.tsx, iaphub.tsx, index.tsx, models/)

• android/ – Android native implementation (RNIaphubModule.kt, Package.kt)

• ios/ – iOS native implementation (RNIaphub.swift/m, bridging header, podspec)

• Example/ – full React Native app for demonstration (with its own android/, ios/, src/)

• guides/ – Markdown migration guides (not part of runtime)

- Key patterns:

• Bridge pattern (JS ↔ native modules)

• Singleton service (IAPHUB instance)

• Model layer (Transaction, Product, BillingStatus)

- Config and build files: babel.config.js, metro.config.js, tsconfig*.json, gradle wrappers, Podspec, package.json

3. Extract insights from README

- Core function: wrappers for IAPHUB REST API + App Store/Play Store purchase flows

- No built‑in UI; consumers write their own UI on top of the exposed methods/events

- Supports iOS and Android through native modules bridged to JS

4. System design diagram: main components and interactions

a. Components

1. React Native JS layer (src/index.tsx → config.tsx & iaphub.tsx)

2. Native Bridge Modules

– Android: RNIaphubModule (Kotlin)/RNIaphubPackage

– iOS: RNIaphub.swift + ObjC shim + Podspec

3. Platform IAP SDKs

– Google Play Billing (Android)

– StoreKit (iOS)

4. IAPHUB Backend API (cloud service)

5. Example App (consumer of the library)

6. Local State Management (stores/iap.js & app.js in Example)

7. External Dependencies (e.g., axios/fetch for REST calls, event emitter)

b. Relationships & Data Flow

• JS calls IAPHUB methods → forwarded through React Native bridge

• Native module invokes Play Billing/StoreKit → returns purchase events

• Native layer relays events back to JS via callbacks/events

• JS layer sends REST requests to IAPHUB API (authenticate, get products, validate receipts)

• Responses update JS models & fires events to app logic/UI

c. Architectural Patterns & Principles

• Bridge (JS ↔ native) ensuring platform‑agnostic JS interface

• Singleton pattern for the IAPHUB client instance

• Observer/event‑driven (app subscribes to purchase, restore, error events)

• Layered separation: UI (in Example) ←→ JS service ←→ native implementation ←→ platform SDK ←→ backend

d. Key technologies

• React Native (JS/TS)

• Native Android: Kotlin, Play Billing API

• Native iOS: Swift/Objective‑C, StoreKit, CocoaPods

• HTTP client (Fetch or Axios) for IAPHUB REST API

• Metro bundler, Babel, TypeScript

5. Tailoring the diagram to this SDK project

- Emphasize the JS/native bridge layers, since this is a cross‑platform library

- Highlight how the Example app sits on top of the library (demonstration consumer)

- Show external flows to IAPHUB cloud service and to platform IAP stores

6. Diagramming guidelines

- Use distinct shapes or colors:

• Blue rectangles for JS/TypeScript modules

• Green for native modules (Android/iOS)

• Orange for external platform SDKs (Play Billing, StoreKit)

• Purple for external service (IAPHUB API)

• Gray for Example App UI & local stores

- Label each component clearly (e.g., “RNIaphubModule.kt”, “iaphub.tsx”)

- Draw directional arrows:

• JS → native bridge calls

• Native → platform SDKs

• JS → IAPHUB API (REST)

• IAPHUB API → JS response handlers

• Native → JS event callbacks

- Optionally group platform‑specific sub‑components into pods/gradle modules

7. Final notes

- Be as granular as needed: you may split “native module” into Android and iOS lanes.

- Capture all layers: UI (Example), SDK interface (JS), native bridge, platform billing, backend.

- Ensure every arrow is labeled with the method or protocol (e.g., “purchaseProduct()”, “onPurchaseFinished event”).

- A clear, layered diagram with color‑coding and directional flows will give a complete, accurate view of the system.

</explanation>