Thread by @featherless

This year my team shifted the open source Material components libraries for iOS into maintenance mode. Why?

A 🧵...

Since 2012 and the original launch of Google Maps iOS, my team has supported the creation and maintenance of shared UI components across Google. This was originally born out of a need to fill gaps in UIKit's design language.

theguardian.com/technology/201…

Along the way, the problems we aimed to solve grew from filling gaps in UIKit to bridging design language gaps across platforms. Material came into being, and we eventually sourced many of our libraries as Material Components for iOS (MDC).

github.com/material-compo…

But as we continued on the pursuit of cross-platform pixel parity, our iOS components were slowly drifting further and further from Apple platform fundamentals because those fundaments were also evolving year over year.

(Aside: omg so. many. UINavigationController subclasses. 😅😅😅)

It's now been almost ten years now since we set out on this journey, and many of the gaps MDC had filled have since been filled by UIKit — often in ways that result in much tighter integrations with the OS than what we can reasonably achieve via custom solutions.

So at the beginning of this year, my team began a deep evaluation of what it means to build a hallmark Google experience on Apple platforms by critically evaluating the space of "utility" vs key brand moments, and the components needed to achieve either.

Does a switch really need to be built custom in alignment with a generic design system? Or might it be sufficient to simply use the system solution and move on?

This evolution of how we approach design for Apple platforms has enabled us to marry the best of UIKit with the highlights of Google's design language.

The result? Many custom components simply aren't needed anymore. And the ones that are, they now get more attention and focus.

App bars become UINavigationControllers. Standard controls just need light branded touches. Lists can align with modern UITableView and list-based collection view APIs. Menus are just UIMenus.

Simplification, while still affording distinction where it matters.

This is part of why the public MDC repo is in maintenance mode. With the introduction of SwiftUI and significant UIKit improvements in iOS 14+, it's never been easier to build a great branded experience with a tiny amount of code.

And the best code is often no code :)

The time we're saving not building custom code is now invested in the long tail of UX details that really make products feel great on Apple platforms. To paraphrase Lucas Pope, we're "swimming in a sea of minor things", and I couldn't be more excited about this new direction.

This is all just the beginning of a big shift for my team. There's a lot we still need to figure out, and we're looking for design leads to help shape this as it continues to evolve.

If this is of interest to you, hit up
careers.google.com/jobs/results/1… for more details. My DMs are open.

I think I meant "quote" Lucas Pope here 😅

Source, for reference: forums.tigsource.com/index.php?topi…

(also just a really rad look into the design process for this game)