Wikimedia Apps/Team/iOS/Third Party Libraries

Here are practices the iOS apps team will follow with respect to third party libraries (e.g. those integrated via CocoaPods).

Adding new dependencies

In general, we should always consider third-party libraries when a problem presents itself over implementing something ourselves. In general, this is philosophy is described as "Proudly Discovered Elsewhere," which is meant to oppose the mindset of: "Not Invented Here." The motivations behind incorporating third party code are:

• Increase productivity via
  • Reduced implementation time (incorporating a ready-made, and tested, solution to a common problem)
  • Facilitating a specific, common development task (e.g. making AutoLayout constraints easier with Masonry)
• Reduce complexity
  • Using PromiseKit to simplify asynchronous tasks
• Improve performance
  • Using SDWebImage to improve image caching performance and ease of use
• Improve diagnostics
  • Using CocoaLumberjack for better logging (organized, fast, extendable)
• Integrating third-party services
  • Using HockeyApp iOS SDK for crash reporting

Integrating the dependency

• Use a package manager to integrate when possible (currently using CocoaPods)
  • Otherwise, submodules are preferred over copying & committing the source directly to the repo
• Use version specifiers in the Podfile to make sure minor & major upgrades are explicit and intentional
• If possible, integrate as a separate pull request. If not, make the integration a single commit in your pull request, so that reviewers can still see incremental changes without the "noise" of the Pods folder diff

Key Considerations

General factors

• Does it have a FLOSS license (e.g. MIT)?
• When was the last release?
• How many open issues are there?
• Does it have decent test coverage?
• Does it support Objective-C? (i.e. Swift-only libraries would be a special case)
• What is the integration size (as specified the Pod's page on CocoaPods.org
• Does it support our current deployment target?
• Does it introduce a new paradigm or design pattern (e.g. ReactiveCocoa or PromiseKit)?

Special considerations for third-party views

Libraries that provide view components should ideally be RTL compliant. If not, the additional work of modifying it to be RTL compliant should be factored into the integration cost.

Post-integration checklist

• When new libraries are added, team members will follow up by:
  • Ensuring "About" and "Acknowledgements" data are updated (i.e. PodsAcknowledgements)
  • Emailing mobile-l with the above points addressed, pointing to this page's take page for further discussion