[Thread] Google's staff engineering lead for Apple's platforms says Google stopped using Material Design for iOS apps after almost a decade, in favor of UIKit
Google had put Material Design into Chrome for iOS in 2015 through a Chrome 40 redesign, making the framework part of its early cross-platform visual strategy. The reported switch to UIKit reverses that approach for Google’s Apple-platform apps and puts native iOS conventions ahead of a single Google design language.
The change separates Google’s iOS design choices from the broader Material system, which also expanded to the web through Material Design Lite. It matters because Google is choosing platform fit over uniformity in one of its largest app distribution channels.
First-order effects
Google’s Apple-platform teams will build and maintain interfaces around UIKit rather than Material Design for iOS, changing the design and engineering baseline for affected apps.
iOS users of Google apps are more likely to encounter controls and interaction patterns aligned with Apple’s native UI framework.
Second-order effects
Google’s shared cross-platform design assets become less reusable on iOS, requiring its product teams to accommodate a more distinct Apple-platform implementation.
Material Design for iOS loses its role as Google’s default interface layer on Apple devices, while UIKit gains influence over how Google’s services are presented there.
Third-order effects
If other large app developers make similar choices, cross-platform design systems will increasingly serve as brand guidance rather than a single implementation layer, with native frameworks governing platform-specific products.
The split points toward product organizations budgeting for separate platform experiences where interface conventions materially shape usability and user expectations.
The trend: Major app publishers are moving from visually uniform cross-platform interfaces toward native framework-led experiences on Apple and Android devices.
Google arrogantly believed that people were first and foremost users of Google's platforms, and benefited from consistency across those platforms, when the truth was people who use iPads/iPhones expect apps to behave like every other app on the platform https://sixcolors.com/...
@eli_white
Eli White on x
I'm pretty interested to see the long term results of this. It seems like Google is saying that matching user's expectations of the platform is more important than being an identical app across iOS and Android. That's also React Native's #1 principle. https://reactnative.dev/... …
@carnage4life
Dare Obasanjo on x
Google apps using material design on iOS is an example of confusing a business problem with a people problem. Users care about all the apps on their phone behaving similarly. Google apps behaving like Android apps was great for corporate synergy not users. https://sixcolors.com/.…
@stroughtonsmith
Steve Troughton-Smith on x
After ~10 years, Google is winding down its Material Design custom UI work on iOS in favor of pure UIKit. Why? UIKit got better, and “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”…
@maxrudberg
Max Rudberg on x
This is so important. The same goes for apps who build a custom UI across platforms. Apps should have a common design paradigm with the platform they're on. Users don't care about your brand, or wherever the reason. 'Google's apps to embrace iOS on iOS' https://sixcolors.com/...
@steven_aquino
Steven Aquino on x
I've never liked Google's iOS for not adhering to Apple's UI conventions. As a heavy Nest user, it's one reason I cling to the OG Nest app rather than Google Home for our cameras. https://twitter.com/...
@charlesarthur
Charles Arthur on x
I think the TL;DR of this thread is that Google apps on iOS will start looking like they were born on iOS in future, rather than looking like they're from another planet. https://twitter.com/...
@realgenekim
Gene Kim on x
Fascinating. Google's 10 year journey to create great mobile apps, leading to creation of Material UI framework, and now leading to embracing native iOS UI elements. https://twitter.com/...
@featherless
Jeff Verkoeyen on x
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 :)
@featherless
Jeff Verkoeyen on x
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.
@featherless
Jeff Verkoeyen on x
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.
@jtaby
Majd Taby on x
@sdw I literally remember asking a designer for an asset, and they asked me to leave their desk because they had to pull it from a secret folder I couldn't know about
@collindonnell
Collin Donnell on x
@stroughtonsmith I'm trying to understand what was missing in UIKit for the past 10+ years which necessitated creating their entire own UI toolkit in the first place when it worked for every other app on the platform. What was wrong with a UISwitch or UITableView five years ago b…
@collindonnell
Collin Donnell on x
@stroughtonsmith Either way I'm glad for them to be doing it. It sounds like Google's iOS apps are about to get a whole lot better 😃
@jtaby
Majd Taby on x
My last job at Apple was rebuilding https://me.com/ to use the iPad interface on the desktop web. My soul died when I replaced the native drop down with an iPad-style popover. Still haven't emotionally recovered from that https://twitter.com/...
@sdw
Sebastiaan de With on x
Fun fact: when I was working on the iCloud web apps we had to redraw all of the super detailed iPad UI from scratch because there was no sharing of design source files between teams at Apple. The Calendar / Contacts UI were styled after planner books. So many photoshop layers... …
@tpoholmes
Tim Holmes on x
This is big news for iOS users frustrated with the performance and behaviors of Google's apps on the platform. https://twitter.com/...
@featherless
Jeff Verkoeyen on x
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.
@featherless
Jeff Verkoeyen on x
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). https://github.com/...
@featherless
Jeff Verkoeyen on x
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. https://www.theguardian.com/ ...
@designatednerd
Ellen Shapiro on x
Interesting thread, via @iOSDevWeekly, about Google deciding to deprecate its iOS Material Components libraries. Platform-appropriate design is easier to use for both developers and users, it turns out! https://twitter.com/...
@benlovejoy
@benlovejoy on x
Google probably not helping here, but I do wish Apple would do it ... https://twitter.com/...
@gartenberg
Michael Gartenberg on x
Apple goes with RCS right after they migrate iMessage to Android. https://9to5mac.com/... via @GoogleNews