Added static lib support for cocoapods

[migs647]

What does this PR do?
Added the capability for the pod to be built as a static framework

Where should the reviewer start?
Test with Swift and Objective-C. It may be appropriate to use use_modular_headers! or use_frameworks! :linkage => :static in the Podfile

How should this be manually tested?
See above

Any background context you want to provide?
Github issue: #752

What are the relevant tickets?
https://segment.atlassian.net/browse/LIBMOBILE-211

Screenshots or screencasts (if UI/UX change)

Questions:

• Does the docs need an update?
• Are there any security concerns?
• Do we need to update engineering / success?

[bsneed]

There should probably be additions to the readme about anything extra people might need to do or want to do to get static vs. dynamic.

[fangmobile]

@sanscontext @bsneed
We use Segment with corp license and use it as a dependency in our pod spec.
.dependency 'Analytics', '~> 4.1'

with
s.static_framework = true

our app that uses our internal library will get this error,
target has transitive dependencies that include statically linked binaries: (Analytics)

why are we making Segment as a static framework?

[fangmobile]

@migs647 any idea to work around the error?

[bsneed]

@fangmobile can you see if these options work for you? https://guides.cocoapods.org/syntax/podfile.html#use_frameworks_bang

[fangmobile]

@bsneed thanks :linkage => :static works in the app Podfile.
We are also evaluating adding s.static_framework = true in our library pod spec. What are the pro and cons?

Cons: Since it is statically loaded App core memory usage is higher. App load time might be affected as well. There are some extra steps to do involving multiple copies of files produced by Cocoapods scripts.

Pros?

any thoughts are appreciated.

[bsneed]

Being statically linked, the app load time will be shorter. As for memory usage, that should be lower as well as there's no overhead of the frameworks. If you're seeing a memory difference it could be because some frameworks are being lazy loaded, but if they are being used, they'll get loaded eventually. Apple's had a few sessions that go over the benefits of static linking vs. dynamic, namely that they optimize the system such that performance is still good at, I think they said 4?? dynamic frameworks, and more than that it drops precipitously. YMMV though.

This article covers some of it as well as links to the WWDC sessions on the subject: https://medium.com/ios-expert-series-or-interview-series/ios-app-launch-static-binding-vs-dynamic-binding-linking-vs-embedded-e69ea9f03f72

I was thinking if you set the :linkage to be dynamic, it would override what we're setting, but not sure without checking.

[Noobish1]

I'm seeing similar to @fangmobile where we have an internal CocoaPod and this change forces the Segment framework to be built as a static framework so we get transitive dependency errors.