The SwiftSupport folder is missing

I am using the latest (non-beta) xcode - 13.2.1

This problem occurs whether I run the build on my local machine or use a github action.

I have also:

  1. used eas credentials to delete all of my certs
  2. gone to my Apple Developer Account page and revoked my certs and deleted the profiles
  3. recreated my provisioning profiles using eas credentials.

No love.

Hi @dk253

What happens if you specify the “latest” ios image in your eas.json?

Thanks! Tried it just now. No Love. :frowning: I assume you mean in the “build” object:

  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "node": "12.22.8",
      "ios": {
        "image": "latest"
      }
    },
    "preview": {
      "distribution": "internal",
      "node": "12.22.8",
      "ios": {
        "image": "latest"
      }
    },
    "production": {
      "distribution": "internal",
      "node": "12.22.8",
      "ios": {
        "image": "latest"
      }
    }
  },

Yes, that’s what I meant. I’m not sure what’s wrong. You definitely don’t have an ios directory in your project?

I believe you’re missing the --profile option. --auto-submit-with-profile specifies the submit profile.

Thanks, @wodin. I do not have an ios folder. I did add the --profile option and I made sure all caches were cleared this morning before I tried again. Same deal.

When you say:

Do you mean:

or:

The --profile option was just intended to address the former.

As for the SwiftSupport folder thing… I’m not sure, but I wonder if it has something to do with one of your dependencies.

Ahh… I see the confusion. I added the --profile=development and that solved the “always production” problem. Progress.

But the “SwiftSupport” is still present. I have a lot of dependencies, so I am reticent to start cutting them out to see where the problem is. I just upgraded react-native to the release that came out last week. Who knows! I’m doing a build and submit now.

But you just gave me an idea. I’m looking through my dependencies to see what’s in their “ios” folders.

Oh my… here is a list of my dependencies that each have ios folders:

./node_modules/@expo/config-plugins/build/ios
./node_modules/@expo/config-plugins/build/plugins/ios
./node_modules/@expo/configure-splash-screen/build/ios
./node_modules/@expo/metro-config/node_modules/@expo/config-plugins/build/ios
./node_modules/@expo/metro-config/node_modules/@expo/config-plugins/build/plugins/ios
./node_modules/@react-native-async-storage/async-storage/ios
./node_modules/@react-native-community/cli-types/build/ios
./node_modules/@react-native-community/cli/build/commands/doctor/healthchecks/ios
./node_modules/@react-native-community/masked-view/ios
./node_modules/@sentry/react-native/ios
./node_modules/detox/src/artifacts/instruments/ios
./node_modules/detox/src/artifacts/log/ios
./node_modules/detox/src/devices/drivers/ios
./node_modules/detox/src/ios
./node_modules/expo-application/ios
./node_modules/expo-constants/ios
./node_modules/expo-dev-client/e2e/ios
./node_modules/expo-dev-client/ios
./node_modules/expo-dev-launcher/ios
./node_modules/expo-dev-menu-interface/ios
./node_modules/expo-dev-menu/ios
./node_modules/expo-dev-menu/vendored/react-native-gesture-handler/ios
./node_modules/expo-dev-menu/vendored/react-native-reanimated/ios
./node_modules/expo-dev-menu/vendored/react-native-safe-area-context/ios
./node_modules/expo-device/ios
./node_modules/expo-document-picker/ios
./node_modules/expo-error-recovery/ios
./node_modules/expo-file-system/ios
./node_modules/expo-font/ios
./node_modules/expo-json-utils/ios
./node_modules/expo-keep-awake/ios
./node_modules/expo-localization/ios
./node_modules/expo-manifests/ios
./node_modules/expo-modules-autolinking/build/platforms/ios
./node_modules/expo-modules-autolinking/scripts/ios
./node_modules/expo-modules-autolinking/src/platforms/ios
./node_modules/expo-modules-core/ios
./node_modules/expo-screen-orientation/ios
./node_modules/expo-secure-store/ios
./node_modules/expo-splash-screen/ios
./node_modules/expo-structured-headers/ios
./node_modules/expo-updates-interface/ios
./node_modules/expo-updates/ios
./node_modules/expo/ios
./node_modules/jest-expo/ios
./node_modules/logkitty/build/ios
./node_modules/react-native-gesture-handler/ios
./node_modules/react-native-reanimated/ios
./node_modules/react-native-safe-area-context/ios
./node_modules/react-native-screens/ios
./node_modules/react-native/ReactCommon/react/nativemodule/core/platform/ios
./node_modules/react-native/ReactCommon/react/nativemodule/samples/platform/ios
./node_modules/react-native/ReactCommon/react/renderer/components/slider/platform/ios
./node_modules/react-native/ReactCommon/react/renderer/components/textinput/ios
./node_modules/react-native/ReactCommon/react/renderer/graphics/platform/ios
./node_modules/react-native/ReactCommon/react/renderer/imagemanager/platform/ios
./node_modules/react-native/ReactCommon/react/renderer/textlayoutmanager/platform/ios
./node_modules/react-native/scripts/ios
./node_modules/react-native/template/ios
./node_modules/sentry-expo/node_modules/@expo/config-plugins/build/ios
./node_modules/sentry-expo/node_modules/@expo/config-plugins/build/plugins/ios
./node_modules/standard-version-expo/build/bumpers/ios
./node_modules/standard-version-expo/ios
./node_modules/standard-version-expo/node_modules/@expo/config-plugins/build/ios
./node_modules/standard-version-expo/node_modules/@expo/config-plugins/build/plugins/ios
./node_modules/standard-version-expo/node_modules/@expo/configure-splash-screen/build/ios

A daunting task to determine which is a problem!

If expo doctor doesn’t complain, then you should in theory be able to ignore any of the expo dependencies. detox should be a dev dependency, rather than a dependency. Same with jest-expo and standard-version-expo.
react-native-gesture-handler, react-native-reanimated, react-native-safe-area-context, react-native-screens, sentry-expo should all be OK, I think.

hmmm… so nothing there jumps out at me.

What happens if you create a new, blank app? Can you submit that OK? What if you add half the dependencies and try again? Do you get the SwiftSupport error? What if you add the other half instead? If it is one of the dependencies then maybe you can narrow it down like that. I’m not sure if it is one of the dependencies, though.

Good luck.

Hey @wodin , sorry for the delay. Distracted by other issues. Some more data: When I use expo build the old way and then use transporter, then it all goes through. But when I use the eas, the problem persists. I have not tried an eas build and then a transporter upload.

It may be related to usesNonExemptEncryption in the app.json file. WHen I use transporter Apple asks at the end if I use encryption. I just added usesNonExemptEncryption to my app.json file but I have not had a chance to try the whole process. Will keep you posted. Thanks for your help!

This uses a completely different build process.

I think it’s worth creating a new, blank app to see if that has the same problem. If not, then maybe see if the problem is coming from one or more of your dependencies by adding subsets of your dependencies, building and submitting. You can probably use a “binary search” strategy to cut down on the number of builds you need to do.

You could also try “usesNonExemptEncryption” with a new app to see if it causes the problem.

I have narrowed this down to some difference between eas build and expo build. When I use expo build and transporter then testflight has no issue. But when I use eas build and then either eas submit or transporter, the “SwiftSupport folder” problem shows up again. I have not tried building a blank app. All of this points to a high probability of some issue with a dependency. But I’m stuck for time. So I will continue to use expo build/transporter for ios. Damn!

OK! I got a response on StackOverflow that fixed it here: ios - Expo eas react-native app submit gets "SwiftSupport folder is missing" error - Stack Overflow.

By deleting the “distribution”: “internal” lines in the eas.json files the app went all the way through!

Finally!

1 Like

Thanks for posting the solution here.

I did not know that "distribution": "internal" had that effect. As far as I know it’s only meant to be in the preview profile.

I know, right?

What I mean is you should be able to keep it in the preview profile. Glad you have it working now :slight_smile:

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.