112 lines
7.1 KiB
Markdown
112 lines
7.1 KiB
Markdown
---
|
|
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.
|
|
- In the current integration model, Fid4 consumes XFlow through XFlowViewMaker only, not by depending on XFlowSDK directly.
|
|
- For current-state reasoning and communication, treat XFlowViewMaker as a required part of the Fid4 propagation path, not as an optional or "usually" present layer.
|
|
- 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
|
|
- Useful Fidelity-specific sources include `iosinstaller`, which exposes App Store/internal builds plus their `Podfile.lock`, and the Flagship app pipeline artifact `appstore/DistributionSummary.plist`, which records the framework versions included in a shipped build.
|
|
- Even those checks are not perfect guarantees because the podspec repo can be edited after publication.
|
|
- When a consumer build must be reproduced exactly from an older dependency snapshot, `Podfile.lock` alone may still be insufficient if the private podspec repo changed afterward; the stronger reproduction path is to align the podspec repo revision too.
|
|
- 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.
|
|
- This appears to be a risky workaround rather than a healthy long-term dependency-management pattern.
|
|
- CocoaPods documentation recommends explicit dependency requirements in podspecs and specifically recommends the optimistic operator `~>` because it gives version control without being overly restrictive.
|
|
- Removing version constraints entirely from published intermediate podspecs weakens compatibility guarantees, makes transitive resolution less predictable, and increases the chance that consumers pick up unvalidated downstream versions.
|
|
- That risk is even higher in this workspace because Fid4 does not keep `Podfile.lock` in Git, so published podspec changes can alter future resolutions without a strong repository-level lockfile trail.
|
|
|
|
---
|
|
|
|
## 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.
|