Thoughts on WWDC

WWDC is a conference like no other. This past month, I was lucky enough to experience it as a part of Tumblr’s iOS cohort. While my peers have done a fantastic job recapping the conference’s highlights, I wanted to take a moment to reflect on the smaller details, things that went well, and things I wish I had done differently.

Recharge Days and Exercise

This is something I regret not doing during the week. At times, WWDC can feel like a marathon. It doesn’t have to be that way. Take a day to explore the city. Catch up with old friends. Squash lingering email. Get a guest pass to a local gym. Time off can help you recharge.

Layers 2016

I truly believe the magic of WWDC week is in the people you meet, not the actual sessions themselves1. If I were to do it all over again, I’d attend Layers. Layers is a three-day design conference for the macOS and iOS community and in their words: a “party, but for learning.” Moreover, Casey Liss’ post on his experience convinced me to attend next year.

Attending In-Person Podcast Recordings

Podcasts have become a huge part of my life, since moving to New York City. Commuting from Park Slope to the Flatiron District each day gives me about an hour2 of idle time to learn via auditory osmosis. During the week of WWDC, both RelayFM and John Gruber from The Talk Show hosted in-person recordings of episodes3! I definitely hope to attend some of these events next year to help put faces to the voices I listen to each day on the way to work.

Twitter

I recently uninstalled Twitter from my phone4. However, during WWDC, I made an exception. While the service gets a lot of flak, it has the magical ability to foster community, coordinate spontaneous lunches, and facilitate serendipity. The iOS community on Twitter is stellar and it truly shines during that week.

Aggregating Team Questions for Labs

Tumblr’s iOS app has ~20 contributors. At this scale, questions were bound to come up when reading through the API diffs. To coordinate and answer them for folks who couldn’t make it, we created a spreadsheet with links to sample projects and relevant Radars. This allowed us to divvy up the questions and better relay them to Apple engineers during the labs.

Attend a Random Session

When plotting out sessions I wanted attend, I decided to sprinkle in a random one for the fun of it. I chose “Working with Wide Color” and was blown away. Being a math major in university, I’ve always been fascinated by color theory. This session provided an in-depth walkthrough of the P3 Color Space and how it affects various color APIs on Apple’s platforms, something I would’ve easily missed otherwise!

Wear Your Company/App’s Shirt

I picked this tip up from an episode of Under the Radar. Countless conversations throughout the week started by recognizing the logo of an app on someone’s shirt. It’s a simple way to facilitate introductions and thank the developers who work on your favorite products!


1: Especially since they’re recorded

2: Round trip

3: RelayCon Announcement and The Talk Show 158 links

4: More on this in a separate post (also take this approach to e-mail)! I’m definitely not perfect at this, but it helps avoid the trap of continuous partial attention.

Swift's nonmutating Keyword

In preparing my recent “Hidden Gems in Swift” talk, I carefully combed through Swift’s “Lexical Structure” section. One keyword that stuck out to me, but ultimately didn’t make it into the talk was nonmutating. Much like the @nonobjc attribute, it surprised me that I hadn’t seen this keyword in the wild.

In searching for example uses, I stumbled upon this conversation between Andy Matuschak and Sidney San Martín:

Stepping through Sidney’s example, we can see how nonmutating signals that a setter doesn’t modify the containing instance, but instead has global side effects.

Whether or not this is good practice is a larger question. But, it’s definitely worth adding to your tool belt!

Hiding Selector Methods

On the Tumblr iOS team, we have a strict rule that everything with an internal or public visibility must be documented1. This gets a bit awkward when using the Target-Action pattern that UIKit often forces you into. When dealing with multiple action selectors, it makes sense to factor out the target into a separate object. However, we’ll often just need a one-off action selector to handle an event from a UIControl subclass. Previously, this would lead to the following scenario and awkward comment:

I was curious if we could make SampleViewController.buttonTapped(_:) private, thus avoiding the need to specify that the method shouldn’t be called externally, in its documentation. My teammate Paul pointed out that this is actually possible! To do this, we simply have to expose the method to the Objective-C runtime and give it a private access modifier:

This allows our action to be invoked from a selector, but prevents other files from accessing the method directly 🎉 Hope this helps better encapsulate your types!


1: To help with this, we use VVDocumenter.