Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Pods to the rescue

Pods to the rescue

This talk describes how to use CocoaPods for the modularisation of your own application by creating private pods and a private specs repository.

Michael Ochs

July 20, 2015
Tweet

More Decks by Michael Ochs

Other Decks in Programming

Transcript

  1. Pods to the rescue
    API Design und Modularisation

    View Slide

  2. Pods to the rescue
    • Benefits of modularisation
    • CocoaPods
    • Creating a pod
    • The specs repository

    View Slide

  3. Benefits of modularisation

    View Slide

  4. Benefits of modularisation
    Clean API
    ViewController
    Model
    View

    View Slide

  5. Benefits of modularisation
    Clean API
    ViewController
    Model
    View ViewController
    View

    View Slide

  6. Benefits of modularisation
    Clean API
    ViewController
    Model
    View ViewController
    View
    AppDelegate

    View Slide

  7. Benefits of modularisation
    Clean API
    ViewController
    Model
    View ViewController
    View
    AppDelegate
    CloudKit

    View Slide

  8. Benefits of modularisation
    Clean API
    ViewController
    Model
    View ViewController
    View
    AppDelegate
    NSUserActivity
    CloudKit

    View Slide

  9. Benefits of modularisation
    Clean API
    Tab1
    Tab2
    Remote Handoff
    Network

    View Slide

  10. Benefits of modularisation
    Clean API
    Tab1
    Tab2
    Remote Handoff
    Network
    Data

    View Slide

  11. Benefits of modularisation
    Clean API
    Tab1 Tab2
    Remote Handoff
    Network
    Data

    View Slide

  12. Benefits of modularisation
    Clean API
    Tab1 Tab2
    Remote Handoff
    Network
    Data

    View Slide

  13. Benefits of modularisation
    Clean API
    Tab1 Tab2
    Remote Handoff
    Network
    Data
    Application

    View Slide

  14. Benefits of modularisation
    • Less code to maintain (per module)
    • Less dependencies
    • Explicitely declared dependencies
    • Well defined interface
    • You can’t be lazy anymore
    Better maintainability

    View Slide

  15. Benefits of modularisation
    • Managing dependencies is a nightmare
    • Multiple modules might have the same dependency
    • Different modules use different versions of their dependencies
    • Updating one module requires all dependant modules to update
    The downside of all of this

    View Slide

  16. Pods to the rescue!

    View Slide

  17. CocoaPods

    View Slide

  18. CocoaPods
    • Manages dependencies between different modules
    • Only gives you access to public files
    What does it do?

    View Slide

  19. CocoaPods
    Structure
    .podspec
    Podfile Specs repo
    Your application Global directory Module

    View Slide

  20. CocoaPods
    pod ‘AFNetworking’
    > pod install
    The Podfile

    View Slide

  21. CocoaPods
    • Adds the source code of AFNetworking
    • Adds all resources of AFNetworking
    • Adds all dependencies of AFNetworking
    • Configures your Xcode project
    The Podfile

    View Slide

  22. CocoaPods
    > pod update
    The Podfile

    View Slide

  23. CocoaPods
    • Updates the source code of AFNetworking
    • Updates all resources of AFNetworking
    • Updates all dependencies of AFNetworking
    • Configures your Xcode project
    The Podfile

    View Slide

  24. CocoaPods
    • Contains all dependencies a pod has
    • other pods, libraries, frameworks
    • Contains the list of public files and resources
    • Contains the path to the pod and other meta data
    • version, description, author,…
    The .podspec

    View Slide

  25. Creating a pod

    View Slide

  26. Creating a pod
    • A pod contains a .podspec file
    • Contains all the meta data that is necessary
    • May contain a demo and a test target
    > pod lib create
    Essential parts

    View Slide

  27. Demo

    View Slide

  28. Semantic Versioning

    View Slide

  29. Semantic Versioning
    • Dependency management through version numbers
    • All modules follow the same versioning concept
    • Great to be used for frameworks and libraries
    • Not for marketing or application versioning

    View Slide

  30. Semantic Versioning
    MAJOR.MINOR.PATCH

    View Slide

  31. Semantic Versioning
    • Used for backwards compatible bug fixes
    • No new public API
    • Internal API may change
    • Fixes internal misbehaviour
    MAJOR.MINOR.PATCH

    View Slide

  32. Semantic Versioning
    • Introduces new features or new public API
    • Introduces deprecations in the public API
    • May introduce substential internal changes
    • May contain patch level changes
    • Patch version must be reset to 0
    MAJOR.MINOR.PATCH

    View Slide

  33. Semantic Versioning
    • Introduces backwards incompatible changes to the public API
    • May contain minor and patch level changes
    • Minor and patch version must be reset to 0
    MAJOR.MINOR.PATCH

    View Slide

  34. Semantic Versioning
    • 0.x.x is a special major version
    • Public api is considered unstable at any time
    • Used during initial development
    Version 0.x.x

    View Slide

  35. Semantic Versioning
    • Development starts with 0.1.0
    • New features and removed public API: 0.2.0
    • Bugfix release: 0.2.1
    • First stable version: 1.0.0
    • Public method is deprecated: 1.1.0
    • New features: 1.2.0
    • Bugfix release: 1.2.1
    • New version that removes previously deprecated methods: 2.0.0
    Example

    View Slide

  36. Semantic Versioning
    • Modules depend on another modules major version
    • Minor and patch are just used to get the minimum version
    • Automatically upgrade to all minor and patch versions
    Dependency management

    View Slide

  37. Semantic Versioning
    pod ‘AFNetworking’, ‘~> 2.5’
    Dependency management

    View Slide

  38. The specs repository

    View Slide

  39. The specs repository
    • A git containing all .podspec files from the supported pods
    • Used by pod install and pod update
    • Referenced in the Podfile via the source keyword

    View Slide

  40. The specs repository
    • Create a private specs repository for your own modules
    • Company wide
    Private

    View Slide

  41. The specs repository
    • Create an empty git repository
    > pod repo add REPO_NAME REPO_URL
    > pod repo push REPO_NAME SPEC_NAME.podspec
    • Add source ‘REPO_URL’ to Podfile
    Private

    View Slide

  42. Demo

    View Slide

  43. The specs repository
    • Do not fork the master specs repository
    • Prefix your private pods
    Private

    View Slide

  44. Thank you
    Michael Ochs
    @_mochs
    http://ios-coding.com

    View Slide