feat(swift-example-app): rebrand to "Dash Developer Pro" for TestFlight#3952
Open
llbartekll wants to merge 4 commits into
Open
feat(swift-example-app): rebrand to "Dash Developer Pro" for TestFlight#3952llbartekll wants to merge 4 commits into
llbartekll wants to merge 4 commits into
Conversation
llbartekll
requested review from
QuantumExplorer,
ZocoLini and
shumkov
as code owners
Contributor
📝 WalkthroughWalkthroughThe Swift example app is renamed from "SwiftExampleApp" to "Dash Developer Pro". The ChangesSwift Example App Rename
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp.xcodeproj/project.pbxproj`:
- Line 447: Two downstream scripts still reference the old bundle identifier
org.dashfoundation.SwiftExampleApp which will break with the new bundle
identifier org.dashfoundation.DashDeveloperPro. Update the SKILL.md file in
.claude/skills/simulator-control/ by replacing the old bundle ID in all
simulator control commands (look for BUNDLE=org.dashfoundation.SwiftExampleApp).
Also update packages/swift-sdk/get_logs.sh by replacing the old bundle ID with
the new one on lines 26 and 31 where the bundle identifier is used as the
default for log collection.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 599430b9-4f2e-44c5-946a-e33e281ab3e7
📒 Files selected for processing (2)
packages/swift-sdk/SwiftExampleApp/Info.plistpackages/swift-sdk/SwiftExampleApp/SwiftExampleApp.xcodeproj/project.pbxproj
ZocoLini
previously approved these changes
Jun 22, 2026
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/skills/simulator-control/SKILL.md:
- Around line 281-285: The find command in the APP variable assignment uses head
-1 which non-deterministically selects the first result rather than the most
recent one, and there is no guard to detect when no app is found. Replace the
piping to head -1 with a method to select the most recently modified file (such
as sorting by modification time in descending order and taking the first
result), and add a validation check immediately after the APP assignment that
exits with an error message if the APP variable is empty.
In `@packages/swift-sdk/SwiftExampleApp/Info.plist`:
- Around line 27-35: The ITSAppUsesNonExemptEncryption key in Info.plist is
currently set to false, but SwiftExampleApp actively implements non-exempt
encryption through Orchard zero-knowledge proof operations in functions like
shieldedIdentityCreateFromPool, shieldedShield, shieldedFundFromAssetLock,
seedShieldedPoolNotes, and startShieldedSync. Change the
ITSAppUsesNonExemptEncryption value from false to true to correctly declare the
app's use of non-exempt encryption, and ensure the required export-compliance
documentation is filed with Apple before submission.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: c631f25d-668d-4721-a7d8-708ddda2ecd2
📒 Files selected for processing (3)
.claude/skills/simulator-control/SKILL.mdpackages/swift-sdk/SwiftExampleApp/Info.plistpackages/swift-sdk/get_logs.sh
llbartekll
force-pushed
the
feat/dash-developer-pro-branding
branch
from
fd6b3dc to
0e5704e
Compare
Collaborator
|
✅ Review complete (commit dc3ae6e) |
ZocoLini
previously approved these changes
Jun 23, 2026
Set the home-screen display name (CFBundleDisplayName) to "Dash Developer Pro" and change the app bundle identifier to org.dashfoundation.DashDeveloperPro so the example app can ship as a standalone product on TestFlight / App Store Connect. Test target bundle identifiers are left unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Update the simulator-control skill and get_logs.sh to use org.dashfoundation.DashDeveloperPro so simctl launch/terminate and log collection keep working after the rebrand. The artifact-finding step still looks for SwiftExampleApp.app since PRODUCT_NAME is unchanged — only the bundle identifier moved. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ZocoLini
force-pushed
the
feat/dash-developer-pro-branding
branch
from
b0ef04d to
18a8fd6
Compare
llbartekll
force-pushed
the
feat/dash-developer-pro-branding
branch
from
18a8fd6 to
0811ee9
Compare
Restore .claude/skills/simulator-control/SKILL.md to its base state so it no longer appears in this PR's diff. Keep the PR scoped to the app (Info.plist, project.pbxproj) plus get_logs.sh. The skill still references the old bundle id and can be updated separately if needed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ZocoLini
previously approved these changes
Jun 23, 2026
…pdate Bring back the .claude/skills/simulator-control/SKILL.md change so the skill points at org.dashfoundation.DashDeveloperPro (the install block still finds SwiftExampleApp.app since PRODUCT_NAME is unchanged). Keeps the skill working after the rename. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.claude/skills/simulator-control/SKILL.md (1)
281-284: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick winRestore deterministic app selection.
head -1can still pick an olderSwiftExampleApp.app, so this step may install stale bits or fail unpredictably when multiple DerivedData builds exist. Please keep the newest-artifact selection and empty-match guard from the earlier fix.🔧 Suggested fix
BUNDLE=org.dashfoundation.DashDeveloperPro # The .app on disk is named after PRODUCT_NAME (still "SwiftExampleApp"), which -# differs from the bundle id — find by the product name, launch by the bundle id. -APP=$(find ~/Library/Developer/Xcode/DerivedData -name "SwiftExampleApp.app" -path "*Debug-iphonesimulator*" -not -path "*Index.noindex*" 2>/dev/null | head -1) +# differs from the bundle id — find by the product name, then pick the newest build artifact. +APP=$(find ~/Library/Developer/Xcode/DerivedData -name "SwiftExampleApp.app" -path "*Debug-iphonesimulator*" -not -path "*Index.noindex*" -print0 2>/dev/null \ + | xargs -0 ls -td 2>/dev/null | head -1) +[ -z "$APP" ] && { echo "SwiftExampleApp.app not found in DerivedData"; exit 1; }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/skills/simulator-control/SKILL.md around lines 281 - 284, The APP variable assignment in the find command uses head -1 which picks the first result alphabetically rather than the most recent build, causing stale artifacts to be selected. Replace the head -1 pipe with logic that sorts the results by modification time (newest first) and selects the most recent SwiftExampleApp.app. Additionally, add an empty-match guard to handle the case where no matching app is found in DerivedData, ensuring the script fails gracefully instead of proceeding with an empty or undefined APP variable.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In @.claude/skills/simulator-control/SKILL.md:
- Around line 281-284: The APP variable assignment in the find command uses head
-1 which picks the first result alphabetically rather than the most recent
build, causing stale artifacts to be selected. Replace the head -1 pipe with
logic that sorts the results by modification time (newest first) and selects the
most recent SwiftExampleApp.app. Additionally, add an empty-match guard to
handle the case where no matching app is found in DerivedData, ensuring the
script fails gracefully instead of proceeding with an empty or undefined APP
variable.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: ce61817d-168d-498d-82d7-70a7dc414422
📒 Files selected for processing (4)
.claude/skills/simulator-control/SKILL.mdpackages/swift-sdk/SwiftExampleApp/Info.plistpackages/swift-sdk/SwiftExampleApp/SwiftExampleApp.xcodeproj/project.pbxprojpackages/swift-sdk/get_logs.sh
✅ Files skipped from review due to trivial changes (2)
- packages/swift-sdk/get_logs.sh
- packages/swift-sdk/SwiftExampleApp/Info.plist
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/swift-sdk/SwiftExampleApp/SwiftExampleApp.xcodeproj/project.pbxproj
thepastaclaw
suggested changes
Jun 23, 2026
thepastaclaw
left a comment
thepastaclaw
left a comment
Collaborator
There was a problem hiding this comment.
Code Review
Branding-only PR rebranding SwiftExampleApp to Dash Developer Pro. Both agents converge on one valid finding: a developer tooling script (Scripts/swift_sdk_internal_logs) was missed by the author's extension-scoped search and still references the old bundle id, causing it to silently no-op after this rename — the exact failure mode the PR fixed in get_logs.sh and the simulator-control SKILL.
🔴 1 blocking
1 additional finding(s) omitted (not in diff).
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/swift-sdk/SwiftExampleApp/Scripts/swift_sdk_internal_logs`:
- [BLOCKING] packages/swift-sdk/SwiftExampleApp/Scripts/swift_sdk_internal_logs:41: swift_sdk_internal_logs still writes to the old bundle id
The app target now builds as `org.dashfoundation.DashDeveloperPro`, but this helper still sets `bundle_id="org.dashfoundation.SwiftExampleApp"` and runs `xcrun simctl spawn ... defaults write "$bundle_id" SwiftSDKLogLevel ...`. Since `LoggingPreferences.loadPreset()` reads from `UserDefaults.standard` inside the rebranded app, the script will report success while the relaunched app continues reading the new bundle's defaults and ignores the override — the same failure mode the PR fixed for `get_logs.sh` and the simulator-control SKILL. This file has no extension and was missed by the author's `*.sh`/`*.md`/`*.swift`/`*.yml`/`*.json` search, which is why it slipped through. Verified by grep: this is the only remaining non-test reference to the old bundle id in the tree.
ZocoLini
approved these changes
Jun 23, 2026
thepastaclaw
left a comment
thepastaclaw
left a comment
Collaborator
There was a problem hiding this comment.
Code Review
Small rebranding PR. Carried-forward prior finding is STILL VALID at dc3ae6e and both new agents converged on the same issue: the dev helper swift_sdk_internal_logs still hardcodes the old bundle id, so SwiftSDKLogLevel writes will silently target an unused defaults domain after the rename. No other in-scope issues found.
🟡 1 suggestion(s)
1 additional finding(s) omitted (not in diff).
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/swift-sdk/SwiftExampleApp/Scripts/swift_sdk_internal_logs`:
- [SUGGESTION] packages/swift-sdk/SwiftExampleApp/Scripts/swift_sdk_internal_logs:41: Dev log-level toggle still writes to the old bundle id
After this PR the installed app's UserDefaults domain becomes `org.dashfoundation.DashDeveloperPro`, but this helper still sets `bundle_id="org.dashfoundation.SwiftExampleApp"` and writes `SwiftSDKLogLevel` to that domain via `simctl spawn ... defaults write`. `LoggingPreferences.loadPreset()` reads `UserDefaults.standard` from inside the rebranded app, so the script will report success while the high/medium/low toggle silently no-ops. The PR description claims no remaining references to the old bundle id across `*.sh`/`*.md`/`*.swift`/`*.yml`/`*.json`; this file has no extension, which likely hid it from the suffix-based grep. The sibling `get_logs.sh` was updated in the same PR — this script appears to have been missed.
thepastaclaw
suggested changes
Jun 23, 2026
thepastaclaw
left a comment
thepastaclaw
left a comment
Collaborator
There was a problem hiding this comment.
Code Review
Correction to the prior dc3ae6e review: the carried-forward prior finding is STILL VALID and remains blocking, as it was in the b0ef04d review. The SwiftExampleApp target is rebranded to org.dashfoundation.DashDeveloperPro, but swift_sdk_internal_logs still writes SwiftSDKLogLevel to org.dashfoundation.SwiftExampleApp, so the helper silently configures the wrong defaults domain. No new latest-delta findings were found beyond this carried-forward blocker.
🔴 1 blocking
1 additional finding(s) omitted (not in diff).
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/swift-sdk/SwiftExampleApp/Scripts/swift_sdk_internal_logs`:
- [BLOCKING] packages/swift-sdk/SwiftExampleApp/Scripts/swift_sdk_internal_logs:41-45: swift_sdk_internal_logs still writes to the old bundle id
The carried-forward b0ef04d2 finding is STILL VALID on dc3ae6e9. The app target now builds as `org.dashfoundation.DashDeveloperPro`, but this helper still sets `bundle_id="org.dashfoundation.SwiftExampleApp"` and writes `SwiftSDKLogLevel` to that defaults domain via `simctl spawn ... defaults write`. `LoggingPreferences.loadPreset()` reads `UserDefaults.standard` from inside the rebranded app, so the script reports success while the relaunched app keeps reading the new bundle defaults and ignores the override. This is the same failure mode the PR fixed for `get_logs.sh`, and this no-extension helper was missed by the suffix-based grep described in the PR body.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue being fixed or feature implemented
We want to ship the iOS example app to TestFlight as a standalone product, Dash Developer Pro, rather than the internal-looking "SwiftExampleApp". This requires a user-visible app name and a distinct bundle identifier so Xcode can register it as its own app record in App Store Connect.
What was done?
CFBundleDisplayName = "Dash Developer Pro"toInfo.plistso the home-screen / TestFlight name is the product name (previously the label fell through toPRODUCT_NAME→ "SwiftExampleApp").PRODUCT_BUNDLE_IDENTIFIERfromorg.dashfoundation.SwiftExampleApptoorg.dashfoundation.DashDeveloperPro(both Debug and Release configurations). Test target bundle identifiers are intentionally left unchanged — they reference the host app by product name, not bundle ID, so tests still build.packages/swift-sdk/get_logs.sh(defaultBUNDLE_ID+ usage comment) — used viasimctl get_app_container, straight swap..claude/skills/simulator-control/SKILL.mdsetupBUNDLE. The install/launch block previously derived the.appfilename from the bundle ID (${BUNDLE##*.}.app); since only the bundle ID changed (notPRODUCT_NAME), it now finds the artifact by the literalSwiftExampleApp.appand launches by the new bundle ID.Note: this is scoped to branding only. ATS hardening (the
NSAllowsArbitraryLoadsflag, tracked in #3714) and network-default cleanup are out of scope here — fine for TestFlight, but should be addressed before any public App Store review.How Has This Been Tested?
org.dashfoundation.DashDeveloperPro.DashSDKFFI.xcframeworkincludes theios-arm64device slice so the archive links (previously simulator-only).CFBundleIconName = AppIcon, compiled rendition present inAssets.car).*.sh/*.md/*.swift/*.yml/*.json.Breaking Changes
None for the SDK. The bundle identifier change means the app installs as a new app rather than upgrading an existing
org.dashfoundation.SwiftExampleAppinstall.Checklist:
For repository code-owners and collaborators only
🤖 Generated with Claude Code
Summary by CodeRabbit
Dash Developer Proand refreshing associated identifiers throughout the project.