iOS
Pods-resources.sh
Permission denied
Xcode
CocoaPods

Pods-resources.sh Permission denied in iOS Project

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

Introduction

A Pods-resources.sh Permission denied error means Xcode tried to execute a CocoaPods-generated shell script during the build, but the operating system refused to run it. The failure is usually not about the script logic itself. It is usually about file permissions, an incorrect path in a build phase, or stale generated files after pod changes.

Understand What the Script Is Doing

CocoaPods generates support scripts under Pods/Target Support Files/... and wires them into the build phases of your app target. The resources script copies or processes pod resources so they end up in the final app bundle.

When Xcode reaches that build phase, it expects the script file to exist and be executable. If the file exists but lacks execute permission, or if the build phase points at the wrong generated file, the build stops with “Permission denied”.

First Check That the Script Exists and Has Execute Permission

The quickest verification is from Terminal.

bash
ls -l Pods/Target\ Support\ Files
find Pods -name '*resources.sh' -maxdepth 4

Once you locate the exact script for the affected target, inspect its mode bits. If the file is present but not executable, add execute permission.

bash
chmod +x Pods/Target\ Support\ Files/Pods-MyApp/Pods-MyApp-resources.sh

The exact path varies by target name, but the fix pattern is the same.

If the script is missing entirely, the problem is not permissions. It is pod generation.

Regenerate CocoaPods Support Files When the Path Is Wrong or Missing

Generated pod scripts can become stale after branch switches, target renames, or pod configuration changes. In that case, regenerate them instead of trying to patch around the symptom.

bash
rm -rf Pods Podfile.lock
pod install

Open the .xcworkspace afterward, not the .xcodeproj. If you build the wrong project file, Xcode may not see the generated CocoaPods setup correctly.

This step is especially important when the error appears after a merge, dependency update, or CocoaPods reinstall.

Inspect the Build Phase in Xcode

Sometimes the script file exists and is executable, but the build phase references an outdated path. Open the app target, go to Build Phases, and inspect the CocoaPods-generated script phase.

You are looking for issues such as:

  • a hard-coded old target name,
  • a stale path copied from another configuration,
  • or a script entry that survived a target rename.

If the build phase points at the wrong file, fixing permissions on the correct file will not help.

Derived Data and Ownership Problems Can Add Noise

If the project was copied from another machine, checked out with unusual file modes, or manipulated by scripts, ownership or cached build output can also contribute to confusing errors.

A clean build is worth doing after you fix the root cause.

bash
rm -rf ~/Library/Developer/Xcode/DerivedData

Then reopen the workspace and rebuild.

Use sudo very carefully here. If the fix requires running Xcode or CocoaPods under sudo, you are often masking a permissions problem that should be corrected at the file level instead.

Source Control Can Reintroduce the Problem

If the generated Pods directory is committed to source control, bad file modes can be committed too. Then the problem keeps returning for other developers even after a local chmod.

That means the durable fix may be one of these:

  • stop committing generated pod support files,
  • or correct the file mode in the repository so every checkout is executable.

The right choice depends on how the team manages dependencies, but the important part is to stop treating the problem as a one-machine accident if it keeps reappearing.

Common Pitfalls

  • Running chmod on the wrong generated script because the target path was not checked carefully.
  • Fixing permissions locally when the real problem is a stale or incorrect build-phase path.
  • Opening the .xcodeproj instead of the .xcworkspace after pod install.
  • Using sudo as the first fix instead of repairing file permissions or regenerating pods.
  • Committing broken file modes to source control so the error returns for the whole team.

Summary

  • The error means Xcode could not execute a CocoaPods-generated resources script.
  • First verify that the script exists and has execute permission.
  • If the file is missing or stale, regenerate pod support files with pod install.
  • Inspect the target’s build phase for incorrect script paths.
  • Fix repository or workflow issues if the permission problem keeps coming back.

Related reading
Course
Beginner
27 lessons
10 hours
System Design Fundamentals

Build a strong foundation in designing scalable, reliable distributed systems.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

All Rights Reserved.