As long as you also pull in the dependencies specified in the podfile, you'll be absolutely fine just adding the class files to the project. I've tried to be careful to maintain that as a viable option. That you retain the option is one of the strengths of Cocoapods to my mind.
While far from perfect, I chose to use Cocoapods as it's becoming the defacto standard in the iOS community. I've used it in my apps, and have found it easier to manage my deps than a bunch of git submodules or copying source code into my projects.
The problems with static libraries on iOS have been well documented at [1]. Essentially, that you can't build static libraries as a third-party for iOS without resorting to low-level trickery. This seemed like it would become a maintenance burden vs. the Cocoapods approach.
While far from perfect, I chose to use Cocoapods as it's becoming the defacto standard in the iOS community. I've used it in my apps, and have found it easier to manage my deps than a bunch of git submodules or copying source code into my projects.
The problems with static libraries on iOS have been well documented at [1]. Essentially, that you can't build static libraries as a third-party for iOS without resorting to low-level trickery. This seemed like it would become a maintenance burden vs. the Cocoapods approach.
[1]: http://landonf.bikemonkey.org/code/ios/Radar_15800975_iOS_Fr...