WWDC at Nutrient

Table of contents

    WWDC at Nutrient

    Apple’s Worldwide Developers Conference (WWDC) is the high point of the iOS developer year each June. For our iOS team at Nutrient, it’s a very special week, so I wanted to share how we make the most of this exciting occasion.

    Previously in person

    To understand how we approach WWDC these days, it’s helpful to look back at what we did before 2020, when WWDC was chiefly an in-person conference in California. At PSPDFKit (as we were called all the time), we had a strong tradition of getting many members our iOS team over there. I was fortunate to be there for four amazing years, from 2016 to 2019. Those years were all fantastic: I met brilliant people at Apple and from the developer community truly from all around the globe. Other highlights were the huge American breakfasts and the parties and events happening alongside the conference.

    Here we are in 2018. From left to right that’s me, Jonathan (now our CEO), Matej (now our CTO), and of course, company founder Peter.

    Photo of four of our team members outside the convention centre at WWDC 2018.

    Naturally, since those of us in California were attending WWDC (or AltConf, for those without a ticket), we’d focus on the conference instead of regular work for the week. Those with a WWDC ticket spent the bulk of their time at labs or preparing for labs: a rare opportunity to sit down with the developers from Apple who make the APIs we build on. The session videos remain available later, but WWDC week is typically the only opportunity for anything like labs.

    Now remote

    Nutrient is a remote-first company, so it makes sense that the switch to a remote-first conference in 2020 suited us well, as we thrive with this way of working. It’s normal for us to initially learn topics on our own (sessions) and then come together to discuss the most challenging questions on video calls (labs).

    In the first years of remote WWDC, we were uncertain if it counted as a conference, and therefore whether our engineers should have to request to pause regular work to ‘attend’ the conference. It’s clear to me now that remote WWDC is a unique occasion, and it’s clearly the best use of the whole team’s time to give our attention to the new announcements and labs.

    The way we do remote WWDC is the same way we used to do in-person WWDC: We give it our full attention for the week, with a dedicated #wwdc channel in Slack (which is great for keynote hot takes). We watch sessions just enough to prepare for labs, which are our priority. It’s even similar in how our evenings run late: in person, this was due to parties; now it’s due to time zones, as labs run on California time.

    Clearing the decks

    To focus on WWDC while being in our regular work environments, our iOS team explicitly sets aside regular work for the week. This means that when estimating our capacity for projects spanning this week, we act like the team is unavailable. However, we do continue customer support, which is always important for us, especially during a week when customers may have questions about Apple’s latest announcements.

    For longer-term planning, we anticipate earlier in the year that some of Apple’s announcements will be relevant to our work, so we reserve Q3 in our roadmap for potential WWDC-related projects.

    Getting the most out of labs

    Remote WWDC labs are a wonderful resource, and I have a sense they aren’t as widely used as they could be. Just like with in-person labs, the labs present an unusual opportunity to talk to developers from Apple. A few factors make remote even better than in-person:

    • You send your topic in advance, so Apple can usually send the very best person — for example, not just someone from the SwiftUI team, but the person who implemented the particular SwiftUI API you’re asking about.
    • You don’t spend time waiting for someone to be available. Just open Webex at the prearranged time.
    • The appointment is confirmed or declined in advance, so you can avoid wasted effort by deferring detailed preparation until the day of the lab if it’s confirmed.
    • Easily add your colleagues from anywhere in the world using the power of the internet (just send them the Webex link).

    In the weeks before the conference, we make a list of our open issues with Apple’s frameworks. We start requesting labs as soon as they open on Monday; waiting a day would mean a quarter of the available slots would be gone. Learning about new APIs (discussed in the next section) usually provides additional topics to ask about later in the week.

    Apple doesn’t allow recording labs, so we always try to attend in pairs. One person leads the conversation and shares their screen. The other takes notes and helps recall the details later. We spread ourselves out so that we can cover the most ground. This year, we had different engineers focus on Liquid Glass, App Intents, Foundation Models, and Apple’s new PaperKit framework.

    Our most important task each day is preparing for confirmed labs happening in the evening. This involves refreshing our memory of the issues to be discussed and making sure we have sample projects ready to demonstrate issues over screen sharing.

    Learning and experimentation

    We all download the Xcode beta on Monday evening or first thing on Tuesday. Usually by Tuesday morning, someone has pushed a branch that compiles our codebase. That way, everyone else can start testing features and experimenting.

    Throughout the week as we watch sessions and test our software, we maintain a shared document of rough notes. Anything that might require action later goes in this list, including new APIs, handy Xcode improvements or compatibility issues. After WWDC, we evaluate the impact of each item as a team and prioritise followup work for the summer.

    As examples from this year, here’s an initial glass document editor toolbar from during WWDC week (left) and a basic implementation of the new PaperKit framework (right), which seemed to only partially work in beta 1.

    Screenshot of Liquid Glass Document Editor toolbar in Nutrient iOS SDK on iPhone and shaped on a white canvas on iPad.

    Everyone on the team experiments with what’s possible with the new SDKs. This year, we had a prototypes of floating Liquid Glass toolbars and semantic search for PDF documents using Foundation Models ready to show at our all-hands company meeting on the Monday a week after Apple’s keynote. It’s fun and rewarding going from announcement to demo in just a few days.

    Shipping in September

    It’s important for us not to block customers who want to adopt the latest iOS and Xcode versions. Therefore, our goal is to release a fully compatible update as soon as Apple puts out the Xcode release candidate, which is typically in the second week of September. We make this release focused and safe: We want it to be easy to adopt, so it doesn’t include breaking changes or major refactors.

    Over the years, we’ve supported some major additions from Apple right away. For example, we were ready for Mac Catalyst and Dark Mode in September 2019. Additionally, integrating our SDK using Swift Package Manager was possible as soon as Apple added support for binary frameworks in September 2020.

    We also love taking advantage of improvements in developer tools and Swift language safety. These improvements help us move faster and maintain higher quality in the long run.

    WWDC summary checklist

    In the months before June:

    • Keep Q3 clear in the roadmap
    • As issues come up, make a shared list of questions for labs
    • Make sample projects and file feedback if possible

    In the week or two before WWDC:

    • Plan to account for the team being unavailable during WWDC
    • Revisit the list of questions for labs, making sure there are runnable projects to demonstrate the issues
    • Don’t start larger projects

    On Monday during WWDC week:

    • Watch the keynote and share hot takes
    • Download the Xcode beta
    • Request labs for Tuesday

    On subsequent days during WWDC week:

    • Prepare for confirmed labs
    • Watch a few sessions, but not too many
    • Try out new APIs and features
    • Make shared notes on anything that might require action later
    • Request labs for the next day

    Between June and September:

    • Turn notes into a concrete list of tasks
    • Install the beta operating systems when feeling brave
    • Work through tasks to be ready to ship alongside the new OS versions

    A great week, every year

    Since we hire people who are curious and keen to try new technologies, we see enthusiastic engagement with WWDC on the team. WWDC is always a whirlwind: It’s exhausting, but it’s also one of the most energising parts of our year. It’s well worth the investment of focusing on it fully so our team is motivated and our knowledge and codebase are levelled up for the latest technologies.

    Douglas Hill

    Douglas Hill

    iOS Team Lead

    Douglas makes the most of our fully remote setup by frequently traveling around Europe by train. He’s a proponent of iPad as a productivity platform and is obsessive about the details of great user experiences. He’s also an organizer of the NSLondon meetup.

    Explore related topics

    FREE TRIAL Ready to get started?