Duplicate CFBundleIdentifier in copied _Testing_* overlay frameworks breaks simulator install
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 62/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- ios, shell
- Domain
- build-system, mobile
Research direction
The bug lives in the copy loop of copy_bundle.sh, which the InjectionNext build phase runs, and in the proposed fix_testing_framework_ids.sh workaround. Start by running the PlistBuddy loop from the issue against Xcode's iPhoneSimulator Frameworks directory to confirm that _Testing_CoreTransferable.framework reports the CoreGraphics identifier. Done means a Debug build installs on a simulator with every Testing* overlay carrying a unique CFBundleIdentifier, and the script stays a no-op outside Debug.
Written by the indexing model from the issue text.
Description
Note: includes fix
Summary
copy_bundle.sh copies every Testing*.framework from the platform developer frameworks directory into the app's Frameworks/ directory. Apple ships _Testing_CoreTransferable.framework with a copy-pasted CFBundleIdentifier that duplicates _Testing_CoreGraphics.framework's. Two frameworks sharing one identifier inside a single app bundle makes installd reject the install, so any Debug build with the InjectionNext build phase fails to launch on the simulator.
Error
Please try again later. Found bundle at
/Users/<me>/Library/Developer/CoreSimulator/Devices/<UDID>/data/Library/Caches/
com.apple.mobile.installd.staging/temp.Y6ODte/extracted/Payload/Allstar.app/
Frameworks/_Testing_CoreGraphics.framework with the same identifier
(com.apple.dt.swift-testing.overlay.CoreGraphics) as bundle at
.../Frameworks/_Testing_CoreTransferable.framework
Root cause
The identifiers as shipped by Xcode:
$ D="$(xcode-select -p)/Platforms/iPhoneSimulator.platform/Developer/Library/Frameworks"
$ for f in "$D"/_Testing_*.framework; do
echo "$(basename $f): $(/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' "$f/Info.plist")"
done
_Testing_CoreGraphics.framework: com.apple.dt.swift-testing.overlay.CoreGraphics
_Testing_CoreImage.framework: com.apple.dt.swift-testing.overlay.CoreImage
_Testing_CoreTransferable.framework: com.apple.dt.swift-testing.overlay.CoreGraphics ← wrong
_Testing_Foundation.framework: com.apple.dt.swift-testing.overlay.Foundation
_Testing_UIKit.framework: com.apple.dt.swift-testing.overlay.UIKit
This is an Apple bug in the toolchain, but InjectionNext is what surfaces it: nothing else copies these overlays into a shipping app bundle. The relevant loop in copy_bundle.sh:
(cd "$PRODUCTS_DIR" && for fwork in $TESTING_FRAMEWORKS \
"$PLATFORM_DEVELOPER_LIBRARY_DIR"/Frameworks
TESTING_COPIED="$CODESIGNING_FOLDER_PATH/Frameworks/$(basename "$fwork")"
if [ -f "$fwork/Info.plist" -a ! -d "$TESTIN
rsync -a "$fwork" "$CODESIGNING_FOLDER_PATH/Frameworks" &&
codesign -f --sign "$EXPANDED_CODE_SIGN_
--preserve-metadata=identifier,entitlements,flags ... "$TESTING_COPIED"
fi
done)
Note --preserve-metadata=identifier — the bad identifier is carried through to the signature as well.
Reproduce
- Add the standard InjectionNext run-script phase to an iOS app target.
- Build & run in Debug on a simulator with an Xansferable.framework carries the CoreGraphicsidentifier.
- Install fails with the error above. Allstar.ath overlays with identical CFBundleIdentifiers.
Environment
┌───────────────┬──────────────────────┐
│ │ │
├───────────────┼──────────────────────┤
│ Xcode │ 27.1 │
├───────────────┼──────────────────────┤
│ InjectionNext │ 2.0.1 |
├───────────────┼──────────────────────┤
│ Destination │ iOS Simulator, Debug │
└───────────────┴──────────────────────┘
Suggested fix (upstream)
Derive each overlay's identifier from its own fr, and stop preserving identifier when re-signing:
(cd "$PRODUCTS_DIR" && for fwork in $TESTING_FRA
"$PLATFORM_DEVELOPER_LIBRARY_DIR"/Frameworks/_Testing_*.framework; do
TESTING_COPIED="$CODESIGNING_FOLDER_PATH/Fra")"
if [ -f "$fwork/Info.plist" -a ! -d "$TESTING_COPIED" ]; then
rsync -a "$fwork" "$CODESIGNING_FOLDER_P
# Xcode ships _Testing_CoreTransferable with CoreGraphics' identifier;
# installd rejects two bundles sharing a
OVERLAY="$(basename "$fwork" .framework)" &&
/usr/libexec/PlistBuddy -c \
"Set :CFBundleIdentifier com.apple.dt.swift-testing.overlay.${OVERLAY#_Testing_}" \
"$TESTING_COPIED/Info.plist" &&
codesign -f --sign "$EXPANDED_CODE_SIGN_IDENTITY" --timestamp=none \
--preserve-metadata=entitlements,fla
--generate-entitlement-der "$TESTING_COPIED"
fi
done)
Rewriting all overlays (rather than special-casing CoreTransferable) keeps the script correct if Apple duplicates another
identifier later.
Workaround (verified working)
For anyone hitting this before an upstream fix lld phase after the InjectionNext phase thatrepairs the copied overlays in place.
BuildScripts/fix_testing_framework_ids.sh:
#!/bin/bash
#
# Apple ships _Testing_CoreTransferable.framework with the same CFBundleIdentifier as
# _Testing_CoreGraphics.framework (com.apple.dt.Graphics).
# InjectionNext's copy_bundle.sh copies every _Testing_* overlay into the app, and
# installd refuses to install a bundle containinidentifier.
#
# Rewrite each copied overlay's identifier to ma, then re-sign.
# Must run after the InjectionNext build phase.
[[ "$CONFIGURATION" =~ Debug ]] || exit 0
FRAMEWORKS="$CODESIGNING_FOLDER_PATH/Frameworks"
[ -d "$FRAMEWORKS" ] || exit 0
shopt -s nullglob
for fwork in "$FRAMEWORKS"/_Testing_*.framework; do
plist="$fwork/Info.plist"
[ -f "$plist" ] || continue
name="$(basename "$fwork" .framework)"
want="com.apple.dt.swift-testing.overlay.${n
have="$(/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' "$plist" 2>/dev/null)"
[ "$have" == "$want" ] && continue
echo "fixing $name: $have -> $want"
/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier $want" "$plist" &&
codesign -f --sign "${EXPANDED_CODE_SIGN_IDEe \
--preserve-metadata=entitlements,flags --generate-entitlement-der "$fwork"
done
Then chmod +x it and add a New Run Script Phase last (after InjectionNext):
"${SRCROOT}/BuildScripts/fix_testing_framework_i
It's idempotent, no-ops outside Debug, and --prey drops identifier so the new one makes it intothe signature.
- Dominant language
- Swift
- Stars
- 437
- Forks
- 32
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from johnno1962/InjectionNext
-
Difficulty 4/5 3-5 days Newbie friendliness 56/100
johnno1962/InjectionNext#173 · 2 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 65/100
johnno1962/InjectionNext#167 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
johnno1962/InjectionNext#147 · 1 comment ·
-
Issue injecting on real device – Code signature invalid & Unhide Symbols restart loopMay be free again A pull request for this issue was closed without being merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 38/100
johnno1962/InjectionNext#81 · 18 comments · 2 reactions ·
All issues in johnno1962/InjectionNext
Similar issues
-
type: cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
googleapis/google-cloud-swift#1477 ·
Maintainers usually reply within 1 day
-
product / auth product / console product / databases product / messaging product / self-hosted product / sites product / storage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
P1 status: first-line-handled status: needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
a2ui-project/a2ui#3282 · 1 comment ·
Maintainers usually reply within 2 days
-
binding:web core docs p3
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
RunanywhereAI/runanywhere-sdks#1123 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
omacom/try-omarchy#359 ·
Maintainers usually reply within 1 day