In mid 2019, Apple shook the developer world with the announcement of SwiftUI — a simple declarative way to build user interfaces across all Apple platforms. I was lucky enough to be in the audience for this announcement and it was clear from the excitement and reactions that this was a huge moment for the Apple development community. And although a shock, an announcement many developers had been waiting on for a while.
The announcement of reactive programming wasn’t new for iOS, but it had finally gotten the native support it needed to give adoption a confidence boost and at the same time bought with it quite a few benefits for both developers and users. After a week of many labs, workshops and a whole lot of compilation warnings, it was time to head back to Transpire to formulate a strategy that would allow us to reach 100% project adoption in SwiftUI safely and smoothly.
Formulating a strategy and skilling-up
By far the most important part of forumatling this strategy was the communication and engagement within the iOS team. Just because I had experienced an excitement level of that similar enough to opening presents it doesn’t mean the team was feeling the same way. It was important to make sure that the team was onboard with the call to transition into SwiftUI and that they understood the significance of such a transition. This involved many team discussions along the lines of `There’s going to be bugs we can’t solve`, `How do we get buy in from our clients` and `How will this impact each individual project`. Even with all of these discussions there was still the practical requirement of up-skilling the team and being able to safely perform code reviews which would need to be accounted for.
After a few weeks of discussions we had reached a place where the iOS team felt comfortable moving towards adopting SwiftUI and it was time to start focusing on starting to up-skill the team in SwiftUI. It was important here that each team member had their own individual goals to focus on that allowed them to skill-up in their own preferred way — from following along in a guided project, reading a book about SwiftUI (that was still being published whilst reading it) to building out small sample projects (we recreated our own coding challenge in SwiftUI). Each team member went with what they felt comfortable with and we continued to catch up regularly to share learnings. Because these learnings were coming from different sources the team were able to establish a level of trust in the quality of their learnings and a reassurance in the skills they were developing.
Getting buy-in / answering questions
Device metrics and latest iOS adoption figures were used to highlight compatibility to the product owner along with the future benefits of easier development support and in some cases feature integration to convince the client that SwiftUI was the right call for the project, and after a little reassurance the developers were now in a place to start implementing features in SwiftUI (with the intention to release these features alongside Apple’s release of iOS 13 in September).
It was really important for us to start with one project first where Transpire had a high level of trust established with the client so the developers on the project could make calls as to where they best felt it made sense to implement features in SwiftUI. Even with this high level of trust the developers still felt safe to fail and were strongly encouraged to be open and honest when doing feature estimations or handling any user experience issues. The openness here allowed the team to make a late call to pivot the release to iOS 13.1 as it was clear in the last iOS 13 beta that there were still some underlying foundational issues — to the point where we were almost convinced Apple was going to do the same.
Once the features in SwiftUI were merged into the project and a release branch was cut the team was in a much better place to answer the outstanding question around the impact to the project. To understand the impact the team looked at industry trends and used social connections to reach out and see how others were proceeding with adopting SwiftUI. These connections combined with some guided conversations around feature isolation, the ease of onboarding new developers to the project, the project stability and alignment with Transpire’s goals and objectives helped the team further validate that transitioning features to SwiftUI just months after it had been announced was the right call for the project and it was time to start looking at a wider project level of adoption.
The wider level of SwiftUI adoption progressed naturally throughout the iOS team at Transpire. At the time we had a number of smaller POC (proof of concepts) in the pipeline that again helped reduce the inherited risk of a new development language. These smaller POCs actually allowed the team to focus on areas in SwiftUI that the larger project teams weren’t touching, and by sharing this knowledge between project teams, pairing up when needed, sharing pull requests and having many more iOS team meetings the team was able to skill up at a more rapid pace, but more importantly had established a way of sharing learnings between projects.
The learnings
There were a number of learnings for me in leading the team to adoption and also in the adoption process itself. The first learning for me was that above I mentioned “The wider level of SwiftUI adoption progressed naturally”. Naturally here might have been an understatement as the adoption progressed at a very rapid pace — to the extent where the adoption could have easily gotten out of control (in terms of project safety and risk). In order to mitigate this risk it was important to question the use of SwiftUI to see if it made sense for a particular feature and served a purpose. These questions helped prevent using SwiftUI in the most risky form of `just because`.
I believe the main reason why the adoption went smoothly was because it was never forced on the team on how they should adopt it (or if they should adopt it at all). Each team member was given the freedom and tools to skill up as they desired, they were given the flexibility to do this and once the developers had a passion and interest in it this quickly spread to the wider organisation causing some of our processes (like interviews and coding challenges) to change alongside it.
Every active iOS project at Transpire is built with Swift and SwiftUI. SwiftUI adoption on projects ranges from 60% to in most cases around 90%. SwiftUI has allowed the iOS team to adopt a `learn once apply everywhere` principle, meaning we can target almost any Apple device (macOS, iPadOS, watchOS, iOS) with a singular codebase. In most areas project code is more and stable due to the declarative syntax and the adoption of SwiftUI has led to faster prototyping and in some areas faster feature development.
