iOS App Contains Developer Path Information

go to Archive file and - > Show Package Contents

1. In Xcode, choose Product > Archive.

2. In the Organizer, select the archive and click Distribute App.

3. Select App Store Connect and click Next.

4. Select Export and click Next.

5. Continue on as you normally would.

6. The result is a directory containing a .ipa file. That’s actually a zip archive in disguise, so change the extension to .zip and then open it in the Finder to unpack it.

7. You’ll find your app in the Payload directory. Run strings against its main executable.

@eskimo I followed your steps and I am able to find my workspace path as well.

I am working on this issue as well due to security reasons and I have found that disabling bitcode during export process is limiting this issue somehow, but disabling bitcode is not necessarily what I want to do because of dsym, analytics and other advantages of bitcode being enabled.

Do you have any solutions to this problem?

disabling bitcode is not necessarily what I want to do

Right, but bitcode doesn’t ship to your customers, only to Apple. So, are you trying to protect your secrets from Apple? Or from the general public? Or both?

[Any answer is fine; I’m just trying to scope the problem.]

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

when I run strings against main executable I get the unwanted strings.

OK. Consider this:

1. Using Xcode 13.1, I created a new project from the iOS > App template (I assume you’re targeting iOS here), selecting the simplest options (Storyboard, Objective-C).

2. I did a Product > Archive to create a release build.

3. I use the Xcode organiser to export that.

4. I unpacked the .ipa.

5. I poked at the main executable with strings:

   % strings Test676234.app/Test676234 | grep quinn
   % 
   

My home directory path is /Users/quinn, meaning that there are no home directory paths encoded in my app.

So, this doesn’t happen always, which means there’s something about your project that’s triggering it. Tracking that down can be tricky. To explore this, I added the following to the app’s main function:

printf("%s\n", __FILE__);

I now get a hit from strings:

% strings Test676234.app/Test676234 | grep quinn
/Users/quinn/Desktop/Test676234/Test676234/main.m

To debug this further I used the Write Link Map File build setting (LD_GENERATE_MAP_FILE) to enable a link map. I then went through the Product > Archive cycle again, which created a link map file Test676234-LinkMap-normal-arm64.txt. In that file I see this:

0x100007F67	0x00000032	[  3] literal string: /Users/quinn/Desktop/Test676234/Test676234/main.m

The [ 3] indicates that this string literal came from the third .o file. At that top I saw this:

[  3] /Users/quinn/Library/Developer/Xcode/DerivedData/Test676234-ajppxbraomjtoldtyvugwlwsxkqv/Build/Intermediates.noindex/ArchiveIntermediates/Test676234/IntermediateBuildFilesPath/Test676234.build/Release-iphoneos/Test676234.build/Objects-normal/arm64/main.o

confirming that this is main.o, which the output from building main.m.

Now, this is an easy case, where the string is passed as a string literal to the linker. That’s not always going to be true:

• In some cases the string might be embedded in a large block of code or data that’s passed to the linker. You can track that down by finding the offset of the string in the file, mapping that offset to an address (using the segment info printed by otool -l), and then finding that address in the link map.

• In some cases the string might be in segments actually generated by the linker. I don’t have any quick suggestions for how to deal with that case.

Still, my general advice here holds: First find where the string is coming from, then try to track down the relevant knobs to twiddle in order to disable it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

In the .o files I have found the unwanted strings, but now I am confused where does it come from?

Each .o file is the product of one source file, so you can search through the corresponding source file for likely candidates.

If that doesn’t pan out, do a binary division process, removing source from that file until the path goes away. You don’t need to go back to the link map here. You can dump the .o file directly using otool.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Does this setting have influence on the problem?

Sorry, but I can’t help you with the third-party tools.

I am kind of wandering in the dark here

This type of debugging is like any other types of debugging: You want to confine the scope of the problem to see what triggers it. You can work this from both ends:

• Take an empty project, confirm that it doesn’t have the problem, and then expand it to be more like your main project. For example, if you add a single library using your third-party package manager, does it immediately trigger the issue?

• Take your main project and cut it down until the problem goes away. For example, if your remove all your third-party packages, does the issue go away? If so, the issue is related to how your project is set up. If not, you can do some binary division to find out what package is triggering it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I have taken @eskimo advices into consideration and the result of my debugging process is that these strings are 3rd party related, in this case Firebase Crashlytics and Analytics. Removing these dependencies and related code resolved the issue. I have created an issue in the developer repo on GitHub to research this case further: https://github.com/firebase/firebase-ios-sdk/issues/9027