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
[edit]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
[edit]- 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
[edit]General factors
[edit]- 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
[edit]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
[edit]- 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