New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CocoaPods leaves dSYMs for unused architectures in archive #7111

Closed
chefnobody opened this Issue Oct 6, 2017 · 39 comments

Comments

Projects
None yet
@chefnobody

chefnobody commented Oct 6, 2017

What did you do?

  1. Created a new empty iOS project with Xcode 9.0. Then closed it.
  2. Ran pod init.
  3. In the pod file, I added one framework TealiumIOS (docs here)
  4. Ran pod install to bring in TealiumIOS.
  5. Opened the SampleApp.xcworkspace with Xcode and archived my application.
  6. Next, I inspected the symbols for each architecture in the archive's dSYMs directory. Here they are after cd-ing to my archive and running dwarfdump:
dSYMs $ cd ~/Library/Developer/Xcode/Archives/2017-10-06/SampleApp\ 10-6-17\,\ 3.21\ PM.xcarchive/dSYMs
dSYMs $ dwarfdump --uuid *
UUID: C56F7ABF-DFD7-3ABC-A9F6-0B172E7B9F10 (arm64) SampleApp.app.dSYM/Contents/Resources/DWARF/SampleApp
UUID: EA990B6D-CAF9-3B87-8D99-D04A4FA36537 (i386) TealiumIOS.framework.dSYM/Contents/Resources/DWARF/TealiumIOS
UUID: 1306BCB7-953D-3FC5-956E-40B85B8986A1 (x86_64) TealiumIOS.framework.dSYM/Contents/Resources/DWARF/TealiumIOS
UUID: CF845CCB-4E31-379F-8835-DA3B16734722 (armv7) TealiumIOS.framework.dSYM/Contents/Resources/DWARF/TealiumIOS
UUID: B353F154-B6B4-3FCA-AA18-C18E400EC139 (arm64) TealiumIOS.framework.dSYM/Contents/Resources/DWARF/TealiumIOS

What did you expect to happen?

I would expect that in addition to stripping the invalid architectures here, that CocoaPods would also strip the invalid symbol files (if any):

strip_invalid_archs() {
binary="$1"
# Get architectures for current file
archs="$(lipo -info "$binary" | rev | cut -d ':' -f1 | rev)"
stripped=""
for arch in $archs; do
if ! [[ "${ARCHS}" == *"$arch"* ]]; then
# Strip non-valid architectures in-place
lipo -remove "$arch" -output "$binary" "$binary" || exit 1
stripped="$stripped $arch"
fi
done
if [[ "$stripped" ]]; then
echo "Stripped $binary of architectures:$stripped"
fi
}

More precisely I would expect that the symbol files left in my archive with UUIDs EA990B6D-CAF9-3B87-8D99-D04A4FA36537 (i386) and 1306BCB7-953D-3FC5-956E-40B85B8986A1 (x86_64) would be stripped from my archive because the App Store does not need or expect symbols for these architectures. In fact, iTunes Connect now warns about uploads of symbols that don't correspond to any binaries:

Too many symbol files - These symbols have no corresponding slice in any binary [1306BCB7-953D-3FC5-956E-40B85B8986A1.symbols, EA990B6D-CAF9-3B87-8D99-D04A4FA36537.symbols]

What happened instead?

The i386 and x86_64 symbols were left in the archive.

CocoaPods Environment

Stack

   CocoaPods : 1.3.1
        Ruby : ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin16]
    RubyGems : 2.5.1
        Host : Mac OS X 10.12.6 (16G29)
       Xcode : 9.0 (9A235)
         Git : git version 2.13.5 (Apple Git-94)
Ruby lib dir : /Users/aconnolly/.rvm/rubies/ruby-2.3.0/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ 5a6cc2e32ae83d327d318296c4fb69125e8fc3ab

Installation Source

Executable Path: /Users/aconnolly/.rvm/gems/ruby-2.3.0/bin/pod

Plugins

claide-plugins        : 0.9.2
cocoapods-deintegrate : 1.0.1
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.3.0
cocoapods-try         : 1.1.0

Podfile

# Uncomment the next line to define a global platform for your project
platform :ios, '10.0'

target 'SampleApp' do
  # Comment the next line if you're not using Swift and don't want to use dynamic frameworks
  use_frameworks!

  # Pods for SampleApp
  pod 'TealiumIOS', '5.3.0'

  target 'SampleAppTests' do
    inherit! :search_paths
    # Pods for testing
  end

  target 'SampleAppUITests' do
    inherit! :search_paths
    # Pods for testing
  end

end

Project that demonstrates the issue

https://github.com/chefnobody/SampleApp

Thoughts / Findings:

  • It seems Carthage had a similar problem back in 2016 and resolved it (I think): Carthage/Carthage#1023
  • This issue has been identified elsewhere by other Framework makers: mapbox/mapbox-gl-native#10137
  • I think this is the step in the generated -frameworks.sh where the copy of all dSYMs happens. But I could be wrong:
    # Copies the dSYM of a vendored framework
    install_dsym() {
    local source="$1"
    if [ -r "$source" ]; then
    echo "rsync --delete -av "${RSYNC_PROTECT_TMP_FILES[@]}" --filter \\"- CVS/\\" --filter \\"- .svn/\\" --filter \\"- .git/\\" --filter \\"- .hg/\\" --filter \\"- Headers\\" --filter \\"- PrivateHeaders\\" --filter \\"- Modules\\" \\"${source}\\" \\"${DWARF_DSYM_FOLDER_PATH}\\""
    rsync --delete -av "${RSYNC_PROTECT_TMP_FILES[@]}" --filter "- CVS/" --filter "- .svn/" --filter "- .git/" --filter "- .hg/" --filter "- Headers" --filter "- PrivateHeaders" --filter "- Modules" "${source}" "${DWARF_DSYM_FOLDER_PATH}"
    fi
    }
@dnkoutso

This comment has been minimized.

Contributor

dnkoutso commented Oct 6, 2017

Interesting thanks! Will take a look.

@dnkoutso

This comment has been minimized.

Contributor

dnkoutso commented Oct 6, 2017

@chefnobody excellent report. Confirmed the same and working on a fix.

@chefnobody

This comment has been minimized.

chefnobody commented Oct 6, 2017

For sure. Stoked!

@dnkoutso

This comment has been minimized.

Contributor

dnkoutso commented Oct 6, 2017

@chefnobody fix #7112

Do you use bundler? If so you can point to my branch and verify this? I did and it worked.

@chefnobody

This comment has been minimized.

chefnobody commented Oct 7, 2017

@dnkoutso Thanks for knocking that out! Quickly though, you'll have to forgive me, I'm new to some of this....

I started using bundler in my sample app like so and pointed the CocoaPods gem at your branch:

gem "cocoapods", :git => 'https://github.com/dnkoutso/CocoaPods.git', :branch => 'strip_dysm'

Next, I ran bundle install and everything seemed to go well. Bundler reported that CocoaPods was pointing at your last commit on your branch (dnkoutso@0b8fd4c), .... so that seems right.

...
Using cocoapods 1.4.0.beta.1 from https://github.com/dnkoutso/CocoaPods.git (at strip_dysm@0b8fd4c)
Bundle complete! 1 Gemfile dependency, 28 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

However, running pod install threw the following error and stack trace:

NoMethodError - undefined method `script_phases' for #<Pod::Specification::Consumer:0x007fad8d2016f0>
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/target/pod_target.rb:191:in `map'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/target/pod_target.rb:191:in `script_phases'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/target/pod_target.rb:197:in `contains_script_phases?'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/target/pod_target.rb:166:in `should_build?'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/installer/xcode/target_validator.rb:50:in `block (3 levels) in verify_no_duplicate_framework_and_library_names'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/installer/xcode/target_validator.rb:50:in `select'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/installer/xcode/target_validator.rb:50:in `block (2 levels) in verify_no_duplicate_framework_and_library_names'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/installer/xcode/target_validator.rb:45:in `each'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/installer/xcode/target_validator.rb:45:in `block in verify_no_duplicate_framework_and_library_names'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/installer/xcode/target_validator.rb:44:in `each'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/installer/xcode/target_validator.rb:44:in `verify_no_duplicate_framework_and_library_names'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/installer/xcode/target_validator.rb:35:in `validate!'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/installer.rb:406:in `validate_targets'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/installer.rb:118:in `install!'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/command/install.rb:41:in `run'
/Users/aconnolly/.rvm/gems/ruby-2.3.0@global/gems/claide-1.0.2/lib/claide/command.rb:334:in `run'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/command.rb:52:in `run'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/bin/pod:55:in `<top (required)>'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bin/pod:23:in `load'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bin/pod:23:in `<main>'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bin/ruby_executable_hooks:15:in `eval'
/Users/aconnolly/.rvm/gems/ruby-2.3.0/bin/ruby_executable_hooks:15:in `<main>'

Running pod update throws the same exception. There's a very good chance I'm not utilizing your branch correctly. Any tips?

@amorde

This comment has been minimized.

Member

amorde commented Oct 7, 2017

@chefnobody you need to use the executable found in at bin/pod in the bundler checkout. One handy way to use it is to make an alias, like alias dpod=/path/to/cocoapods/bin/pod then do dpod install

@chefnobody

This comment has been minimized.

chefnobody commented Oct 7, 2017

@amorde If I understand correctly, you're saying that when I run pod install from my SampleApp bundler-managed project that is specifying @dnkoutso's branch of the CocoaPod project, that pod is not the correct executable? If that is so, why does the stack trace seem to point to the custom cocoapods gem?

/Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/lib/cocoapods/target/pod_target.rb:191:in `map'

At any rate, I tried referencing that specific executable directly per the path specified by bundle info cocoapods:

SampleApp $ bundle info cocoapods
  * cocoapods (1.4.0.beta.1 0b8fd4c)
	Summary: The Cocoa library package manager.
	Homepage: https://github.com/CocoaPods/CocoaPods
	Path: /Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69
SampleApp $ ls -al /Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69

But I get the following:

$ /Users/aconnolly/.rvm/gems/ruby-2.3.0/bundler/gems/CocoaPods-0b8fd4cf2f69/bin/pod install
Could not find rake-10.5.0 in any of the sources
Run `bundle install` to install missing gems.

Running bundle install again doesn't resolve this missing gem issue. I've also created an alias per your recommendation that points at the same custom CocoaPods gem but I get the same error.

I'm missing something simple here.

@amorde

This comment has been minimized.

Member

amorde commented Oct 7, 2017

Oh oops! Sorry I missed that - ignore what I said :)

@justinseanmartin

This comment has been minimized.

Contributor

justinseanmartin commented Oct 7, 2017

I think you'll also need to point at the latest SHA of cocoapods-core as well for some other changes to be kept in sync.

@dnkoutso

This comment has been minimized.

Contributor

dnkoutso commented Oct 7, 2017

@chefnobody, @justinseanmartin is correct you also need to bump and use master branch of cocoapods-core gem.

This is the repo https://github.com/CocoaPods/Core

@chefnobody

This comment has been minimized.

chefnobody commented Oct 7, 2017

@justinseanmartin @dnkoutso @amorde I'm pretty sure I've got it now. Thanks for helping me understand the issue.

  1. Added the CocoaPods Core gem to my Gemfile and pointed at master. Which should be good looking at the commits there.
  2. Ran bundle install and pod install successfully.
  3. Archived the SampleApp project.
  4. Drilled into archive's dSYMS and viola. No simulator slices 👍
dSYMs $ dwarfdump --uuid *
UUID: C56F7ABF-DFD7-3ABC-A9F6-0B172E7B9F10 (arm64) SampleApp.app.dSYM/Contents/Resources/DWARF/SampleApp
UUID: B353F154-B6B4-3FCA-AA18-C18E400EC139 (arm64) TealiumIOS.framework.dSYM/Contents/Resources/DWARF/TealiumIOS

I pushed my changes to the SampleApp as well.

@dnkoutso

This comment has been minimized.

Contributor

dnkoutso commented Oct 7, 2017

perfect! should land this this coming week and hopefully get a 1.4.0.beta.2 out.

@chefnobody

This comment has been minimized.

chefnobody commented Oct 7, 2017

Awesome! Thanks

@dnkoutso

This comment has been minimized.

Contributor

dnkoutso commented Oct 8, 2017

Merged.

@chefnobody

This comment has been minimized.

chefnobody commented Oct 16, 2017

@dnkoutso Any idea when this will ship?

@dnkoutso

This comment has been minimized.

Contributor

dnkoutso commented Oct 16, 2017

@chefnobody possibly this week with 1.4.0.beta.2.

@chefnobody

This comment has been minimized.

chefnobody commented Oct 17, 2017

@dnkoutso One last question, if I wanted to leverage this beta would I do so the same way I did before with my Sample project and Bundler and your branch that has this fix? By that I mean pointing at a git branch or tag for both CocoaPods and CocoaPods Core? If so where do I find those branch/tag names?

After looking at the Releases page, I'm guessing this might be all I would need:

gem "cocoapods", :git => 'https://github.com/CocoaPods/CocoaPods.git', :tag => '1.4.0.beta.2'
@dnkoutso

This comment has been minimized.

Contributor

dnkoutso commented Oct 17, 2017

@dnkoutso

This comment has been minimized.

Contributor

dnkoutso commented Oct 17, 2017

Can use

gem 'cococapods', :git => 'https://github.com/CocoaPods/CocoaPods.git', :ref => 'SHA'
@Yourney

This comment has been minimized.

Yourney commented Apr 29, 2018

I use Cocoapods 1.5.0 and today I again received the 'Too many symbol files' email from Apple.
Is there anything that I should do after updating cocoapods? I did:

  • pod update
  • pod install
  • clean build folder
  • archive

pod --version returns 1.5.0.

Thanks!
Wouter

@dnkoutso

This comment has been minimized.

Contributor

dnkoutso commented Apr 29, 2018

@Yourney please provide a sample app and demonstrate the issue clearly.

@kdawgwilk

This comment has been minimized.

kdawgwilk commented May 8, 2018

Kind of hard to provide a sample app here since the only way to know if the issue is still there is to submit the app to Apple and I doubt anyone wants to to do that just for a sample app

@Yourney

This comment has been minimized.

Yourney commented May 8, 2018

I guess it can be done ... by either submitting to Apple for TestFlight, or by creating an archive and then using a command that shows the dSYM files:
dSYMs dwarfdump --uuid *
I am looking for time to do something like that ;-)

@chefnobody

This comment has been minimized.

chefnobody commented May 8, 2018

@Yourney You should be able to create a vanilla iOS app (or fork mine) and follow my steps above (using whatever version of CocoaPods you think has this issue) to verify.

@armcknight

This comment has been minimized.

armcknight commented May 8, 2018

I've been looking into this for myself and just found this ticket. Using cocoapods 1.5.0 and Xcode 9.3.

I listed all the UUIDs in my archive with this command: find /path/to/.../archive/dSYMs -type d -name "DWARF" | xargs -I@ find @ -type f | xargs -tI@ dwarfdump -u @

That'll show you: dSYM and path on disk, architecture, UUID. In my project, I noticed that there were both arm64 and armv7 slices for targets in Pods.xcodeproj, whereas my app target only has arm64 slices.

Then I looked at the architectures being build with xcodebuild:

# my app
$ xcodebuild -showBuildSettings | grep ARCHS
    ARCHS = arm64
    ARCHS_STANDARD = arm64
    ARCHS_STANDARD_32_64_BIT = armv7 arm64
    ARCHS_STANDARD_32_BIT = armv7
    ARCHS_STANDARD_64_BIT = arm64
    ARCHS_STANDARD_INCLUDING_64_BIT = arm64
    ARCHS_UNIVERSAL_IPHONE_OS = armv7 arm64
    VALID_ARCHS = arm64 armv7 armv7s

# cocoapods
$ xcodebuild -project Pods/Pods.xcodeproj/ -showBuildSettings | grep ARCHS
    ARCHS = armv7 arm64
    ARCHS_STANDARD = armv7 arm64
    ARCHS_STANDARD_32_64_BIT = armv7 arm64
    ARCHS_STANDARD_32_BIT = armv7
    ARCHS_STANDARD_64_BIT = arm64
    ARCHS_STANDARD_INCLUDING_64_BIT = armv7 arm64
    ARCHS_UNIVERSAL_IPHONE_OS = armv7 arm64
    VALID_ARCHS = arm64 armv7 armv7s

A problem I see is that ARCHS resolves to different values between my app and cocoapods framework targets, even though they are all set to $(ARCHS_STANDARD). I don't observe this if I create a new Xcode project, create app and framework targets and run the same check:

$ xcodebuild -showBuildSettings -scheme test-fw | grep ARCHS
    ARCHS = arm64
    ARCHS_STANDARD = arm64
    ARCHS_STANDARD_32_64_BIT = armv7 arm64
    ARCHS_STANDARD_32_BIT = armv7
    ARCHS_STANDARD_64_BIT = arm64
    ARCHS_STANDARD_INCLUDING_64_BIT = arm64
    ARCHS_UNIVERSAL_IPHONE_OS = armv7 arm64
    VALID_ARCHS = arm64 armv7 armv7s

Here's my workaround in my Podfile:

post_install do |installer|
    installer.pods_project.build_configuration_list.build_configurations.each do |configuration|
        configuration.build_settings['ARCHS'] = 'arm64'
    end
end

I've confirmed this produces an xcarchive without the frameworks' armv7 slices, just waiting to hear back from iTunes Connect.

@segiddins

This comment has been minimized.

Member

segiddins commented May 9, 2018

huh, what are the object versions for your project vs the pods project, out of curiosity?

@dnkoutso

This comment has been minimized.

Contributor

dnkoutso commented May 9, 2018

Gut feeling tells me the users xcodeproj is on Xcode 9 which is 64bit only and the one generated from pods is with 8 or earlier hence the discrepancy between the $(ARCHS_STANDARD) value.

@Yourney

This comment has been minimized.

Yourney commented May 9, 2018

@dnkoutso Gut feeling is right!
My project is iOS 11 only, built on xcode 9.3.
Dependencies have for instance
s.platform = :ios, "10.0"
in their podspec file. And are supporting xcode 8.
I will try the armyknight workaround to see if that satisfies iTunesConnect.

Would it be an idea to set the validArchs (of the main project) to arm64 and changing armcknight's workaround so that all dependencies get the main project's validArch?

Side question: Is there a performance isue on the iPhone 5S when building arm64 only?

@armcknight

This comment has been minimized.

armcknight commented May 9, 2018

Both my project and pods project have object version 46.

Not sure if it's relevant but I created my project in Xcode 8 IIRC. I ran pod deintegrate and pod install after upgrading to cocoapods 1.5.0. My podfile declares a platform version of iOS 11, but not sure how podspecs' platform versions would affect this... I'm sure there are several that go before iOS 11.

@anonym24

This comment has been minimized.

anonym24 commented May 16, 2018

so why I meet this error?

is it fixed or not?

platform :ios, '11.0'
use_frameworks!
target 'MyApp'
pod 'OpenCV'
pod 'VGPlayer', '~> 0.2.0'
pod 'TesseractOCRiOS'

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['ENABLE_BITCODE'] = 'NO'
    end
  end
end
@anonym24

This comment has been minimized.

anonym24 commented May 16, 2018

@armcknight how can I set more cpus using your solution?:

post_install do |installer|
    installer.pods_project.build_configuration_list.build_configurations.each do |configuration|
        configuration.build_settings['ARCHS'] = 'arm64'
    end
end

@anonym24

This comment has been minimized.

anonym24 commented May 16, 2018

I will also try (only with arm64, who needs those 32 cpus anyway?):

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['ENABLE_BITCODE'] = 'NO'
      config.build_settings['ARCHS'] = 'arm64'
    end
  end
end
@anonym24

This comment has been minimized.

anonym24 commented May 16, 2018

yes, no errors from apple anymore

also don't forget to remove all other cpus in your target settings (leave only arm64):

screenshot at may 16 13-37-25

plus #7111 (comment)

@Yourney

This comment has been minimized.

Yourney commented May 16, 2018

I have changed the ValidArchs of my main project to Arm64 only.

Now Cocoapods generates the dependency-projects with 'only arm64' too ... brilliant.

dwarfdump --uuid * gives me just one dSYM per dependency.
So that looks great!
Apple did not complain about an overdose of Symbol files after the upload!!
No need to add the bit of scripting to the Podfile.

I still think that there is a problem somewhere. I think it might be a bug @ Apple. It seems like xcode generates one dSYM file per architecture, and iTunesConnect does not want that.
However, this problem only occurs if an app should still support 32 bit code, for instance to be able to run on an iPhone 5 or older.

Apple reports it as a warning, so it does not break anything.

@navaneet

This comment has been minimized.

navaneet commented Jul 2, 2018

This issue is still happening, when will this get fixed?

@SebastianBoldt

This comment has been minimized.

SebastianBoldt commented Aug 2, 2018

Same issue over here. The fix of @Yourney does not solve the problem for me. I changed the supported architectures of my main target to arm64 but if i archive and dwarfdump later armv7 is still present.
My Deployment-Target is iOS11 so there is no need for Xcode to create those files. I will stick to the post install phase.

installer.pods_project.build_configuration_list.build_configurations.each do |configuration|
    configuration.build_settings['VALID_ARCHS'] = 'arm64'
end
@amorde

This comment has been minimized.

Member

amorde commented Aug 2, 2018

@SebastianBoldt I think the iOS 11 issue you are having should be fixed by #7932

@SebastianBoldt

This comment has been minimized.

SebastianBoldt commented Aug 3, 2018

@amorde Awesome. So Cocoapods 1.6.0 will provide this fix if i see this right, correct?

@amorde

This comment has been minimized.

Member

amorde commented Aug 3, 2018

Yup!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment