This happens since 1.11 when bitcode support was added

Can we maybe get a version of the SDK with bitcode disabled?

Otherwise, please see how Paypal and card.io handled this:

https://github.com/card-io/card.io-iOS-SDK/issues/147
https://github.com/paypal/PayPal-iOS-SDK/issues/339

This issue should be closed.

The Podfile.lock is sufficient to reproduce a Pods directory by installing CocoaPods from the network with:

    $ pod install

http://stackoverflow.com/a/22350027/2562357

I'm pretty disappointed that this issue was dismissed so quickly.

I feel like there are 2 main points that weren't considered at all:

1) I'm literally only using GMSAutocompleteViewController, it's absurd that I need to link my app to a 100MB+ binary for this one little widget

2) Committing up the Pods directory is actually an extremely common workflow, one that's been in use at every place I've worked. It provides multiple advantages, most notably when it comes to:
- onboarding new devs
- working with a CI server
- switching between branches
- going back in time to past commits

As a matter of fact, the official Cocoapods docs state: "We recommend that you keep the Pods directory under source control, and don't add it to your .gitignore" (http://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control)

As such, I feel like this issue should be re-opened, and that you guys should take a look at the solutions that the Paypal and card.io teams came up with:
https://github.com/card-io/card.io-iOS-SDK/issues/147
https://github.com/paypal/PayPal-iOS-SDK/issues/339

I'll ask the various teams to look at splitting up the libraries.

I'd also suggest raising a ticket with GitHub about their 100 mb limit.

(No comment was entered for this change.)

Until this is resolved I am staying on 1.10.5

You could try setting up Google maps locally, without cocoapods. linking the framework to your project without adding it to the project.

I also will not be able to upgrade from 1.10.5 until this is resolved.

Can someone help!? Ive deleted this pod from my project by changing the Podfile then doing 'pod install' and its removed from my project but when i try to commit its throwing this error and saying that its still there when it isn't!? I'm so confused!

You also have to remove the file / directory from your git history. It's a complicated command. This should get you started: http://stackoverflow.com/questions/21230090/remove-a-deleted-folder-form-git-history

Thank god i came across this, I am now using 1.10.5 too, so many git filter commands before seeing this...

(No comment was entered for this change.)

+ 1 on the max size of Github and the fact that most stuff (mainly resources) are not needed for most developers, resulting in large code repositories & binary files.

I am now using 1.10.5 too, because of it

Quick question for the assembled crowd: What architectures do you guys compile your apps with?

A quick and simple way of stripping back the size of the bundle from 119mb to 87mb is to drop armv7s. Run the following command from the Versions/A/ directory in the framework:

    $ lipo -remove armv7s GoogleMaps -output GoogleMaps 

+1 to this issue. removing armv7s support will not work. 

I am still experiencing this issue with 1.12.1. 

@brettmor Any update on this?

Per the release notes, 1.12.1 is identical to 1.11.1. We were part way through launching 1.12.0 when we found issues with the build. Due to reasons, we couldn't roll back the 1.12.0 CocoaPod, and thus had to push 1.11.1 as 1.12.1.

Sorry for the confusion.

We also cannot drop armv7s support.

I used Git Large File Storage to solve this issue. It's very simple to set up: http://www.modeo.co/blog/2016/2/22/google-maps-ios-file-too-large

Has anyone gotten Git Large File Storage to work with OS X Server / Xcode Server? That's what stopped us.

+1 I also check in the Pods folder.

I think a decent workaround for now is to add just Pods/GoogleMaps to .gitignore. I still have to run pod install after a clone, but I feel better knowing the only pod I need to reinstall is GoogleMaps and not 20 other random pods that could have changed or disappeared all together.

Are there any updates on this? If I try to update the GoogleMaps cocoapod to a newer version, suddenly I get an error in 2 of my View Controllers:

Cannot convert value of type '(GMSReverseGeocodeResponse!, NSError!) -> Void' to expected argument type 'GMSReverseGeocodeCallback' (aka '(Optional, Optional) -> ()')

The solution to fixing that one is not documented in a single place anywhere other than someone else who asked the same question on SO and the 1 answer someone gave was to downgrade to version 1.11.1. Somehow this all comes full circle... https://stackoverflow.com/questions/35618629/gmsreversegeocodecallback-after-updated-google-map-via-pod

Now I'm back to square 1 trying to solve the original problem of pushing up to my GitHub repo without updating to the newest cocoapod and having to tear apart my code for the GMSReverseGeocodeCallback error.

Where does this issue stand?

MHorn918, you are actually talking about a completely separate issue, which isn't a bug.

In release 1.12.2 we updated the API annotations to make the API better for Swift. See:
https://developers.google.com/maps/documentation/ios-sdk/releases#version_1122_-_february_2016

There were places in the API where we had the default ObjC -> Swift conversions which implied a non-null value which we were actually treating as optional in ObjC. The updated annotations now correctly reflect that the values to the callback are optional. 

The fix in this case is to update your code.

Thanks Brett. However, What is the solution to the original issue here?

remote: error: File Pods/GoogleMaps/Frameworks/GoogleMaps.framework/Versions/A/GoogleMaps is 113.56 MB; this exceeds GitHub's file size limit of 100.00 MB

MHorn918, the bug is marked as Accepted, which means we are looking at ways we can reduce the binary size without losing required functionality. 

As this requires architectural work, there is no quick and easy fix. We will update this bug if and when we have more information.