Skip to content

Parameterize bundle ID and build workflow for identical sister-repo code#690

Open
bjorkert wants to merge 7 commits into
devfrom
parameterize-fastlane-bundle-id
Open

Parameterize bundle ID and build workflow for identical sister-repo code#690
bjorkert wants to merge 7 commits into
devfrom
parameterize-fastlane-bundle-id

Conversation

@bjorkert

@bjorkert bjorkert commented Jun 26, 2026

Copy link
Copy Markdown
Member

The sister apps (LoopFollow_Second, LoopFollow_Third) exist so users following 2–3 loopers can install separate apps with distinct bundle identifiers. They only need to differ from the main app by the bundle identifier and display name — both already driven by app_suffix / display_name in LoopFollowDisplayNameConfig.xcconfig. In practice a couple of build files still hardcoded LoopFollow, forcing them to diverge between the repos and making them a recurring merge-conflict source when changes are transferred on each release.

This makes those files identical across all three repositories and reworks how they are kept in sync:

fastlane/Fastfile — reads app_suffix from LoopFollowDisplayNameConfig.xcconfig and derives the app and Live Activity extension identifiers from it, replacing every hardcoded com.<team>.LoopFollow in the build_LoopFollow, identifiers and certs lanes. The same Fastfile now produces the correct identifiers everywhere:

  • main: com.<team>.LoopFollow (unchanged)
  • second: com.<team>.LoopFollow.Second
  • third: com.<team>.LoopFollow.Third

Because the derived identifiers match what each repo is already provisioned for, existing certificates and provisioning profiles keep working unchanged.

.github/workflows/build_LoopFollow.yml — the not-configured summary now derives the variant name from github.event.repository.name / UPSTREAM_REPO instead of hardcoding it, and two comments no longer name the variant. The only intentional per-repo differences left are the scheduled cron minute and UPSTREAM_REPO.

release.shupdate_follower now mirrors the release tree into each sister repo with rsync --delete instead of generating and applying a patch, then re-applies that instance's overlay (app_suffix, display_name, UPSTREAM_REPO, cron) and renames the workspace. The per-instance values are derived from the sister directory name; only the staggered cron minute is passed in. Mirroring makes each sister an exact copy of the release tree except for the overlay, so transfers no longer hit patch-context conflicts and any accidental drift is corrected automatically. Only .git, local/build directories and the local team override are protected from the sync.

Read app_suffix from LoopFollowDisplayNameConfig.xcconfig in the Fastfile and
build the app and Live Activity extension identifiers from it, replacing the
hardcoded com.<team>.LoopFollow strings. The same Fastfile now produces the
correct bundle identifiers in LoopFollow, LoopFollow_Second and
LoopFollow_Third without per-repo edits.

Update release.sh so the conflict notice no longer lists the Fastfile, which is
now identical across the sister repositories.
Accept any LoopFollow* directory in Scripts/swiftformat.sh instead of only the
exact 'LoopFollow' folder, so formatting runs consistently in LoopFollow,
LoopFollow_Second and LoopFollow_Third.

Drive the variant name in build_LoopFollow.yml's not-configured summary from
${{ github.event.repository.name }} / ${{ env.UPSTREAM_REPO }} and drop the
variant name from two comments, so the workflow no longer hardcodes 'LoopFollow'
in cosmetic text. The only intentional per-repo differences left are the cron
minute and UPSTREAM_REPO.
@bjorkert bjorkert changed the title Derive Fastlane bundle identifiers from app_suffix Make sister-repo build files identical (parameterize bundle ID, swiftformat, workflow) Jun 26, 2026
The exact-'LoopFollow' folder check is intentional: it prevents swiftformat from
reformatting source files when the tree is checked out as a sister repo
(LoopFollow_Second / LoopFollow_Third), which would create spurious diffs. The
script stays identical across all three repos and skips by folder name at
runtime.
@bjorkert bjorkert changed the title Make sister-repo build files identical (parameterize bundle ID, swiftformat, workflow) Parameterize bundle ID and build workflow for identical sister-repo code Jun 26, 2026
bjorkert added 4 commits June 26, 2026 15:30
Replace the git diff / git apply patch flow in release.sh's update_follower
with an rsync --delete mirror of the release tree into each sister repo,
followed by re-applying that instance's overlay (app_suffix, display_name,
UPSTREAM_REPO, cron) and renaming the workspace. The per-instance values are
derived from the sister directory name; only the staggered cron minute is
passed in.

Mirroring makes each sister an exact copy of the release tree except for the
overlay, so transfers no longer hit patch-context conflicts and any accidental
drift in a sister is corrected automatically. Only .git, local/build dirs and
the local team override (LoopFollowConfigOverride.xcconfig) are protected from
the sync.
Drop the DerivedData and LoopFollowConfigOverride.xcconfig rsync excludes — they
don't exist in any of the repos, so there is nothing to protect. The mirror now
only shields .git, .claude and build.
Capture the sister's existing scheduled-build cron line before mirroring and
restore it afterwards, rather than passing hardcoded minutes (27/40) into
update_follower. Each repo keeps its own staggered build time with no magic
numbers in the call sites; if a repo has no cron line the mirrored default is
left in place.
Pass each app's staggered Sunday-build minute into update_follower and write it
during the overlay, instead of capturing it from the sister repo. All per-app
data lives in the main repo's release script; the sister owns nothing and is a
pure product of the mirror plus the overlay. A comment at the call site explains
the staggered minutes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant