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.
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.
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.
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.
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.
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:
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.
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 follow-up 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.
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.
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.
In the months before June:
In the week or two before WWDC:
On Monday during WWDC week:
On subsequent days during WWDC week:
Between June and September:
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.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。