feat: Enhance documentation on build inspection sources, clarifying the role of iosinstaller and app-store debugging paths

This commit is contained in:
2026-04-17 14:48:30 -06:00
parent 696a1258b1
commit cfa047b6be
3 changed files with 11 additions and 0 deletions

View File

@@ -33,6 +33,8 @@ Fid4 is the main Fidelity consumer iOS app and the most important environment fo
- When a story touches presentation, entry points, or consumer behavior, check whether Fid4 is required to confirm scope. - When a story touches presentation, entry points, or consumer behavior, check whether Fid4 is required to confirm scope.
- Build or startup instability in Fid4 can slow validation and should be treated as a practical investigation constraint. - Build or startup instability in Fid4 can slow validation and should be treated as a practical investigation constraint.
- Fid4 currently adopts XFlow changes through the app repo `ap010981-ios-flagship-app` after XFlowViewMaker has been published. - Fid4 currently adopts XFlow changes through the app repo `ap010981-ios-flagship-app` after XFlowViewMaker has been published.
- Fidelity uses internal build-distribution tooling such as `iosinstaller` to inspect shipped consumer builds.
- `iosinstaller` can provide App Store and internal build downloads and expose the build's `Podfile.lock`, which makes it a useful validation source when the repo itself does not track that lockfile.
- The common update path is: - The common update path is:
- modify the Podfile to the new XFlowViewMaker version - modify the Podfile to the new XFlowViewMaker version
- run `tuist generate -n` - run `tuist generate -n`
@@ -40,6 +42,7 @@ Fid4 is the main Fidelity consumer iOS app and the most important environment fo
- open and merge a PR - open and merge a PR
- wait for the consumer team to carry the change forward in their normal App Store release flow - wait for the consumer team to carry the change forward in their normal App Store release flow
- `Podfile.lock` is currently ignored in the Fid4 repo, so version verification often depends on Podfile references or published pipeline artifacts instead of Git-tracked lockfiles. - `Podfile.lock` is currently ignored in the Fid4 repo, so version verification often depends on Podfile references or published pipeline artifacts instead of Git-tracked lockfiles.
- A useful app-store validation path is the Flagship app pipeline artifacts: `appstore/DistributionSummary.plist` records the framework versions installed in that build and can be used to confirm which XFlowViewMaker and XFlow versions were actually shipped.
--- ---

View File

@@ -89,6 +89,7 @@ Capture the durable release and validation path between XFlow changes and real c
- The fastest reliable signals are: - The fastest reliable signals are:
- fixed version references in the Podfile when present - fixed version references in the Podfile when present
- archived pipeline artifacts such as `xcarchive` outputs and captured `Podfile.lock` files - 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. - 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. - 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. - 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.

View File

@@ -88,3 +88,10 @@ tags:
- Jeff asked David to compare against the dependency snapshot from the device-oriented trunk build context to reduce uncertainty about the reported REST behavior. - Jeff asked David to compare against the dependency snapshot from the device-oriented trunk build context to reduce uncertainty about the reported REST behavior.
- David noted that downloading the referenced `Podfile.lock` and running `pod install` is a useful approximation, but still not a full guarantee if the private podspec repo changed after that build was produced. - David noted that downloading the referenced `Podfile.lock` and running `pod install` is a useful approximation, but still not a full guarantee if the private podspec repo changed after that build was produced.
- If exact dependency reproduction is required, the stronger path is to also check out the podspec repo at the matching earlier revision instead of relying on `Podfile.lock` alone. - If exact dependency reproduction is required, the stronger path is to also check out the podspec repo at the matching earlier revision instead of relying on `Podfile.lock` alone.
## Learning Correction - Build Inspection Sources
- David clarified that `iosinstaller` is one of Fidelity's internal apps for inspecting distributed consumer builds.
- `iosinstaller` can download App Store and internal builds and also expose the corresponding `Podfile.lock`.
- David also clarified a useful app-store debugging path in the Flagship app pipeline: the artifact `appstore/DistributionSummary.plist` records the framework versions installed for that build.
- That artifact can be used to confirm which XFlowViewMaker and XFlow versions were actually installed in a specific App Store build.