Isaac Overacker

maker of things

WWDC 2016

I’m heading home from my first ever WWDC. What a blast! I’m excited to come to San Francisco again next year even if I don’t get lucky enough to attend WWDC proper.

The Keynote

The first day was filled with excitement, as everyone lined up in front of Bill Graham Civic Auditorium to anxiously await the big announcements for this year. We were not disappointed! Huge announcements all around on macOS, iOS, tvOS, and watchOS. Those have been covered in depth elsewhere, so I won’t go into them here, but needless to say, I was quite pleased.

The Conference

Tuesday marked the first day of sessions and labs. I was a bit torn about what to do, as the sessions are all recorded and available to watch any time. Labs are a neat opportunity to meet and talk with Apple engineers, but I didn’t really have any pressing questions to bring to the table. I ended up spending around half my time attending sessions and the other half sitting in the area just outside of the labs, where tables had been set up within viewing distance of live broadcasts of select sessions. This gave me a unique opportunity to listen to sessions while coding and occasionally talking to fellow attendees, including some notable open-source contributors such as Orta Therox (CocoaPods, Artsy) and Felix Krause (fastlane).

The Parties

Something exciting was happening every day, and thanks to WWDC Parties, we were able to find it all. Realm was an amazing host this year, with the challenging NSHipster Pub Quiz and their 1.0 launch party standing out as highlights of the week. #ButtonSelfieSoiree was an absolute blast, and their developers released an app that day which records a few second long GIF and auto-tweeted it with the hashtag. This led to hilarious, rapid-fire GIF selfies happening all over 111 Minna Gallery. Lastly, the official bash was a bit of a flop for me personally, and was the least interesting party of the week. It was basically just like attending a concert with food and drinks around the perimeter.

The Future

Next year, I’d like to at least pop into AltConf even if I’m fortunate enough to attend WWDC again. I’ll probably put more emphasis on meeting and greeting, and even less emphasis on sessions. Some of the parties filled up ahead of time, so planning those out in advance might help, although I was pleased with the fun that I had.

I’m feeling exhausted but invigorated, and I miss the hell out of my family, but I’m really excited with the direction the Apple spaceship is heading and look forward to getting to work. See you next year, Apple!

Introducing Alcove

I have been spending quite a bit of time working with Xcode Server for continuous integration of a fairly large iOS project. As part of the build process, I wanted to generate a test coverage report and place it in on the web server running on our build server. I investigated several existing tools that are capable of generating reports, but found things about each that I disliked. Frankencover is a good solution, but it requires installing the JDK, which is not a normal part of the iOS development stack. XcodeCoverage was another option that I investigated, but it required some executable files that I didn’t want to store in our repository. Dissatisfied with the existing options, I decided that a simple Ruby script could do the job and set out to write my first gem.

Alcove

Alcove is a simple gem that can quickly and reliably generate a code coverage report for an iOS project. Installation is simple, since it’s a gem.

Terminal
1
gem install alcove

That’s it. (You’ll also need to install lcov, either with Homebrew or MacPorts.)

To generate a report, you just need to give alcove your ${PRODUCT_NAME} and it will do the rest.

Terminal
1
alcove --product-name YourProductName

After crunching some files, the report will be ready to view in ./alcove-report/.

Check out the README for more information (be sure to check out the options), or the demo project to see it in action.

Creating an Xcode Plugin: A Quick-Start Guide

Xcode has a rich ecosystem of third-party plugins, exposed and cataloged by the wonderful Xcode plugin Alcatraz. Some of my favorites: Auto-Importer, BBUFullIssueNavigator, and FuzzyAutocomplete.

However extensive the Xcode plugin catalog may be, there are surely other useful plugins to be written. The process of writing a plugin is not very well documented, and frustratingly, much of the code required to interact with Xcode is still private. However, thanks to the efforts of a few clever developers, getting started is much easier than it used to be. Read on for a quick-start guide to creating an Xcode (5+) plugin.

Image Caching With AFNetworking

AFNetworking is one of the most popular open-source networking frameworks for iOS. You’re probably already using it, but if you’re not, you should consider it. One of the lesser-known features of AFNetworking is the ability to easily load an image from a URL to be used in a UIImageView.

Integrating Test Dependencies With CocoaPods

Most Xcode projects should have some level of test coverage, and any time unit tests are involved it’s nice to have a framework for generating mock objects. However, we don’t want to bloat our production app package with these test frameworks, so it’s nice to link these libraries only with the test target. Configuring this properly can be tricky, and the CocoaPods documentation isn’t very clear on exactly how to accomplish this in the podfile.

The cleanest solution I’ve found to this problem involves specifying the pods for each target individually and using a Ruby function to import the common pods. Here is a sample podfile that accomplishes this:

Podfile
1
2
3
4
5
6
7
8
9
10
11
12
13
14
platform :ios, '7.0'

def import_common_pods
   pod 'AFNetworking'
end

target 'MyAppTarget' do
   import_common_pods
end

target 'MyAppTestTarget' do
   import_common_pods
   pod 'OCMock'
end

Note that you may run into a few issues with this if you’re adding this to an existing project and the previous podfile did not explicitly specify the non-test target. In that case, you may need to delete the old Pods.xcconfig and libPods.a files then regenerate your workspace with pod install.

Update

As of CocoaPods 0.34, there’s a cleaner solution built-in:

Podfile
1
2
3
4
5
6
7
8
9
source 'https://github.com/CocoaPods/Specs.git'

platform :ios, '7.0'

pod 'AFNetworking'

target "MyAppTestTarget", :exclusive => true do
   pod 'OCMock'
end