Cocoapods on Andrew Bancroft

Managing Xcode Project Dependencies with CocoaPods

Wed, 03 Feb 2016 18:23:49 +0000

Course Outline

I try to get as practical as possible in the course. As you’re watching you’ll be “embedded” into a team of iOS developers, and you’ll explore the problems that CocoaPods can solve for you by watching the team struggle through not having a dependency manager, and then sharing in their victories as they bring in CocoaPods to ease that dependency management struggle.

The course is a progressive journey. First, the team has problems managing dependencies without a dependency manager. Then, they bring in CocoaPods to help them find and organize 3rd party libraries. Then, they start to think, “Hey, what if we could create our own CocoaPod libraries?”. Finally, they use that knowledge of how to create a CocoaPod library to set up a private repository to share code internally between projects with their team.

I’ve got four modules that cover the following topics:

1 - Introducing Project Dependency Management

I teach the basic concepts and definitions associated with “project dependency management”. What is it all about? Why does it matter? And most importantly, how is it done in the Apple Ecosystem?

2 - Managing Dependencies with CocoaPods

I guide you through installing CocoaPods, configuring your Xcode project to use CocoaPods, and working with the CocoaPods command line utility.

3 - Creating CocoaPod Libraries

This is where things turned really fun for me. :] In this module of the course, I teach you how to create a CocoaPod library, host its source code on GitHub, and publish the library to the CocoaPods Trunk.

4 - Hosting a Private CocoaPods Repository

As the capstone to the course, I teach you how to set up a private spec repository and how to configure CocoaPods to utilize it. It really is the culmination of everything learned in the prior modules, but it’s also one of the most practical strategies for sharing code between your various Xcode projects that I’ve found to-date.

In addition to the four modules of content, the course comes with an example Swift iOS app if you’re a Pluralsight Plus subscriber!

Something for Everyone

The course is targeted at beginning to intermediate level developers. I assume no prior knowledge of how to work with a dependency manager.

That being the case, I do my best to offer something for everyone. If you’ve never used a dependency manager on another platform before, I’ve got you covered – I’ll take you step by step through using CocoaPods.

If you’re already using CocoaPods in your Xcode project, maybe you can benefit from the modules on creating CocoaPod libraries yourself! If you’re already creating libraries and contributing to the open source community, what about setting up that private spec repository to share with your team internally?

Feedback Welcome!

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

Considerations for Choosing 3rd Party Swift Libraries

Tue, 27 Oct 2015 18:04:09 +0000

While relying on 3rd party dependencies can provide you the benefit of not having to spend time implementing a portion of your app, realize that you’re essentially giving away little pieces of your app when you bring in a dependency.

You’re delegating away a certain level of control off to someone else who has no knowledge of or interest in the final outcome of your team’s app.

Adding dependencies to your project doesn’t come without cost, so it’s best to count that cost up front in order to make sure it’s a good idea to pursue this option.

If you are going to seek out modules of code from a 3rd party, what are some key assessment factors that could help you in this important decision?

Josh Brown wrote a really comprehensive list of questions that guided me a lot in my own considerations of choosing a 3rd party library. I’m really grateful for his article – if you’ haven’t read it, go check it out!

My own list that follows takes a more categorical approach for those of us who think in box-like structures. I thought of at least four broad categories that we should think about and ask questions about when it comes to choosing our dependencies.

How can you avoid depending on bad Swift libraries? What are some markers of good ones? Let’s find out!

Community matters

A good library has a good community surrounding it. Try using your favorite search engine to see what kind of content comes up for the dependency you’re thinking about. Search on StackOverflow to see what questions are being asked and what issues folks are running into, and what kinds of answers (if any) are being given.
Take a look at the GitHub stars and forks counts. Stars are a good way for developers to flag repositories that are interesting to them. Forks indicate potential contributors to the repository, since the typical flow is to fork the project, branch, publish the branch, and submit a pull request.
“Buzz” and “popularity” can come and go, but if folks are talking about the dependency you’re considering, that’s not a terrible sign. Unless what they’re talking about all the problems the library has, haha. In all seriousness, though, utilize social media and observe / ask around to see what other developers are saying about it before bringing it into your app.

Maintenance matters

When was the last commit to the repository? If it was 5 years ago, this could be a red flag. Sure, it could just mean that the library is “done” and works great. But you and I both know that as the world of software moves forward, change is inevitable, and a library that doesn’t change with the times is more than likely doomed to failure. Checking the pulse of the repository on GitHub is one way to determine how well-maintained the library is.
How many issues are open? How many are being closed as resolved? Repositories with a lot of issues open could indicate an active community… unless those issues never get closed. In which case the indicator is a less positive one. Once again, GitHub’s Pulse feature will be a good guide even on figuring out how the repository owner is responding to issues that come their way.

Documentation matters

If a library has no documentation to speak of, how are we as developers supposed to figure out how to use it? The better and more exhaustive the documentation, the better the chances are that the library is worth surviving the candidate list to incorporate into your project
Even better is when the repository owner provides examples of how to use their library. Seeing examples will give you an idea of what’s possible, how nice the API is, and is overall a good reference point for integrating it with your own app. Documentation without examples is less valuable than documentation with examples.

Quality matters

If you’re using CocoaPods, know that each CocoaPod that’s submitted to the central ‘Trunk’, as they call it, receives a quality index that is based on various pieces of analysis that can be done on the repository and on the code within the pod itself. Some of the analysis that’s done is based on some of the things I just discussed, such as GitHub stars, documentation, etc. A full list of how the CocoaPods quality index is assessed and assigned can be found at https://guides.cocoapods.org/making/quality-indexes

Wrapping up

So there you have it – a few broad categories to think in terms of when trying to get direction on whether or not you should bring a given 3rd party library into your own Swift project.

Do you have other “box-like” categories that you use to guide your dependency decisions? Feel free to sound off in the comments with your thoughts!

OpenSSL for iOS and Swift the Easy Way

Tue, 22 Sep 2015 04:39:28 +0000

I’m currently working on outfitting an app I’m working on to be able to validate receipts to verify purchases of the app.

Little did I know, this adventure would introduce the need to understand how to use cryptography in order to work with the receipt.

Cryptography library needed

In order to even “open” the receipt itself, we’ve got to work with something called a “PKCS #7 container”. Once we get the container open, we need to be able to validate Apple’s certificate that they use to sign every purchase of every app.

All of this requires the use of a cryptography library, and OpenSSL seems to be the common choice, due to its being open source.

I found that figuring out what to do to get OpenSSL into my project was harder than I wanted it to be. It turns out that there are a few to do this, but I wanted the easiest to implement (and the easiest to maintain). The options I was able to identify are:

Build the binaries for each platform yourself. To do this you’ve got to make sure you build for both the simulator and the device by running special config routines and using makefiles and what-not. It seemed error-prone, and I’m not confident enough in my ability to know whether or not I’ve done it right.
Download a pre-built static library – however, this introduces a risk that I wasn’t really willing to take. How do I trust that pre-built library? If there’s a vulnerability there, how do I easily upgrade the library to the patched version? Every recommendation I’ve seen thus far says, “Always build your own static library, rather than download it already-built from somewhere”.
Cocoapods. Simply put, this was the easiest route for me.

OpenSSL for iOS with Cocoapods

How easy is it to get started with OpenSSL for iOS with Cocoapods?

Pretty easy.

If you don’t have Cocoapods yet, you can head over to Cocoapods.org and follow their instructions for installing. It’s literally one command at the terminal:

sudo gem install cocoapods

Once Cocoapods is installed, open your project in Xcode and add a new empty file (File -> New File -> Other -> Empty) called Podfile.

In its contents, you simply add a reference to the OpenSSL library:

1
2
3

target 'NameOfYourApp' do
    pod 'OpenSSL', '~> 1.0'
end

Note that there are several ‘OpenSSL’ Cocoapod specs out there to choose from. I originally tried one that looked like it was for iOS (OpenSSL-iOS), but I was never able to get Swift code to recognize the C functions and types.

The one that seemed to still pull the source from openssl.org and build it when the pod is installed was simply named ‘OpenSSL’ and I’ve verified that my Swift code can ‘see’ the C code without running into ‘unresolved identifier’ compiler errors.

Once the Podfile is created and configured, save it and close Xcode. Then head to the Terminal.

Navigate to your Xcode project folder where the Podfile is located and run pod install.

Once it’s finished doing its thing (be patient… it took several minutes for me), you can open the new .xcworkspace file that Cocoapods created for you. You’ll have everything in your project configured to depend on the OpenSSL library through the new Pods project that’s been added to your Workspace.

Bridging header

In order to use OpenSSL with Swift, you’re going to need to create an Objective-C bridging header to access the functionality provided in the OpenSSL libraries.

If you don’t already have an Objective-C bridging header, it’s simple to get one added automatically by Xcode for you:

Choose File -> New -> File
Choose Source under iOS (on the left
Choose Objective-C File
Name it “bridge” (or anything, really – it’s a dummy file that you’ll delete after Xcode generates the bridging header)
Choose Next, and then Create

Xcode will prompt you to create the bridging header – you should let it. Once it’s created, you can delete “bridge.m” (the Objective-C .m file that you just created in the steps above).

Within the bridging header, you can insert some #import statements to make the OpenSSL library components visible to your Swift project. For example, to start off, you could flesh out the bridging header with a couple of OpenSSL header files:

1
2
3

#import <openssl/pkcs7.h>
#import <openssl/objects.h>
// Others that you may need in your Swift project

Xcode 7 & Bitcode

When you build and run your newly configured project in the Simulator, things are going to work fine.

When you build it for your device, however, it will fail.

…Pods/OpenSSL/lib/libcrypto.a(bio_lib.o)’ does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64

At the time of this writing, there is somthing in OpenSSL that doesn’t support Xcode 7’s Bitcode feature. Eventually (hopefully) they’ll fix it, but for now, if you want to use OpenSSL in a Swift project using Xcode 7, you’ll have to turn off Bitcode.

Click on your project, and then click on your app target under ‘Targets’ in the project settings window.

Find Build Options and set Enable Bitcode to ‘No'

If you try re-building against the device with this setting set to ‘No’, it should build and run without issue.

Wrapping up

That’s all there is to getting OpenSSL built and added as a reference in your app. Now will come the fun part of using it with Swift, but I will save that for another entry.