---
type: workstream
project: fidelity
status: active
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4]
work-items: [pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
related: [xflow-swiftui-migration, xflow-debugging, xflowsdk, xflowviewmaker, ftframeworks, fid4]
updated: 2026-04-17
tags:
  - workstream
  - fidelity
---
# Consumer Integration And Release

## Goal

Capture the durable release and validation path between XFlow changes and real consumer behavior.

---

## Stable Patterns

- End-to-end validation often requires more than an SDK change.
- Historical Slack evidence shows repeated coupling across:
  - XFlowSDK
  - XFlowViewMaker
  - FTFrameworks modules
  - Fid4 / flagship
- Version pins, publishing delays, and consumer build issues can block validation even when the original code change is ready.

---

## Current Release Propagation Model

- The current release path is usually:
  - `pr100660-xflow-for-ios` releases XFlowSDK
  - `PR100660-ios-frameworks/Adapters/XFlowViewMaker` updates to that XFlowSDK version and publishes a new XFlowViewMaker release
  - `ap010981-ios-flagship-app` updates Fid4 to the new XFlowViewMaker version
  - downstream consumer release then determines when the change reaches the App Store build
- A code fix in XFlowSDK is not ready for Fid4 validation until that full dependency chain has propagated.
- In practice, the release effort often includes dependency bump work, PR approvals, protected-branch/code-owner requirements, Jenkins publishing, and local consumer dependency refresh steps.
- Fid4 currently consumes XFlow through XFlowViewMaker only, not by depending on XFlowSDK directly.
- Other frameworks also consume XFlow through XFlowViewMaker, especially `FTAccountOpen` and `FTTransfer`.
- For Account Opening paths, the practical consumer route is currently understood to run through `FTAccountOpen`.

---

## Step-By-Step Propagation

1. Release XFlowSDK from `pr100660-xflow-for-ios`.
   - Jenkins pipeline: `xflow-for-ios-publish`
   - Produces the XCFramework artifact
   - Publishes to internal Fidelity Artifactory at `artifactory.fmr.com`
   - Publishes the podspec to the dedicated podspec repo `ap010981-ios_podspecs_3x`
   - After publication, consumers can adopt the new SDK version through CocoaPods
2. Update and release XFlowViewMaker from `PR100660-ios-frameworks`.
   - XFlowViewMaker lives in `Adapters/XFlowViewMaker`
   - Update the XFlowViewMaker podspec to the new XFlowSDK version
   - Run `tuist generate -n`
   - Run `pod install`
   - Open a PR and get required approvals
   - Ping code owners when protected-branch approval is the remaining blocker
   - After merge, the `publish-XFlowViewMaker` Jenkins pipeline publishes the adapter
   - That pipeline usually auto-detects the next release and commonly auto-increments the minor version, for example `0.5.0` -> `0.6.0`
   - Publication updates Artifactory/podspec distribution and also updates the XFlowViewMaker version on `main`
3. Update Fid4 in `ap010981-ios-flagship-app`.
   - Modify the Podfile to consume the new XFlowViewMaker version
   - Run `tuist generate -n`
   - Run `pod install --repo-update`
   - Open a PR and get approvals
   - After merge, the consumer team owns the final application release to the App Store

---

## Investigation Rules

- Before concluding a fix is absent in Fid4, check whether the right version actually propagated downstream.
- When the question is specifically about Account Opening, verify the path through `FTAccountOpen` before assuming a direct Fid4-only dependency view is sufficient.
- Separate these failure modes:
  - SDK bug
  - adapter/version propagation issue
  - protected-branch or code-owner approval delay
  - publish pipeline failure or auto-versioning surprise
  - FT module publish/test issue
  - consumer app setup or pipeline issue
- Consumer validation constraints should shape story scope and estimates because they can dominate the real effort.
- Version verification in Fid4 is not always straightforward because `Podfile.lock` is currently ignored in the app repo.
- The fastest reliable signals are:
  - fixed version references in the Podfile when present
  - archived pipeline artifacts such as `xcarchive` outputs and captured `Podfile.lock` files
- Even those checks are not perfect guarantees because the podspec repo can be edited after publication.
- A newly published XFlowViewMaker version can still be blocked in Fid4 if downstream podspec constraints in `FTAccountOpen` or `FTTransfer` do not yet accept the new adapter version.
- Historical/current evidence suggests Tauf has resolved similar propagation blocks by updating the relevant constraint directly in the podspec repo.
- Current evidence suggests the effective constraint may live in the podspec repo layer rather than in the FTFrameworks source repo itself.
- For the current XFlowViewMaker propagation issue, the practical fix was made in the podspec repo by removing the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs.
- After that podspec-repo PR was merged, `pod install --repo-update` in Fid4 resolved successfully because those podspecs no longer constrained the XFlowViewMaker version.
- `FTAccountOpen` and `FTTransfer` do not appear to hold a direct XFlowViewMaker version reference in their checked FTFrameworks source podspec files; the effective resolution is managed through the published podspec layer and `ftAdapter` behavior.

---

## Historical Signals From Slack

- Version bump work repeatedly involved XFlowViewMaker, FTAccountOpen, and FTTransfer.
- Some rollout problems involved Jenkins, Apex/ApexKit, preview macro compatibility, or secret/token access rather than the product behavior under investigation.