Background information
My favourite root apps for Android 13
by Martin Jud
Google is going after Apple: how one button on your phone can change the world
13/10/2021
Translation: Patrik Stainbrook
Google is changing. iPhone and iPad apps are being rebuilt with Apple components. Little will change for users, but Google has achieved a win, even if it helps out the competition.
Google Apps on iPhone and iPad should start acting more like Apple ones.
That alone doesn’t sound sensational, but it means a lot. The decision to make Google apps more Apple-like is motivated by a whole lot of work, politics, resentment and competitiveness.
The switch from Google’s own development to Apple components may play into the hands of the competition, but it was bitterly necessary and worthwhile for Google.
App architecture: what’s going on behind the scenes
Every app has a framework. When building a house, the framework on which the user interface you see and use is built would be the scaffolding. Frameworks exist for back- and front ends. In this article, only front ends are relevant – user interfaces and everything customers see. For the sake of simplicity, I’ll just call them «frameworks» moving forward.
The framework, how it looks and its peculiarities, is all decided by managers, not only programmers.
Apps on your smartphone are created in what is called an app framework.
You can make Android apps with Apple’s SDK. This is because UIKit and Xcode use the Swift programming language, which can also be used for Android apps. Android works with Java, but supports pretty much every common programming language on the market.
In short: so it is possible to make iOS apps with Android programming skills. And vice versa. However, this isn’t recommended in most cases. The reason for this is less technological and more political.
The politics behind programming
These SDKs are free. Both programming languages are open source and freely available, surely paving the way for a golden age of apps. One program, compatible with everything. Technologically, this would allow anyone to develop and use native apps with the whole world.
Only, neither Google nor Apple are particularly interested in this happening.
Swift is a powerful and intuitive programming language for iOS, iPadOS, macOS, tvOS, and watchOS.
The Apple Swift compiler has had the ability to compile code for the Android platform for a few years now, but it hasn’t made many friends in the developer community due to its complexity.
This is where management and operational efficiency meet. Developers build something that is open source, but its actual real-life implementation outside of a set framework is absurdly complicated. Could this be solved easily? Absolutely. Will it be improved? Absolutely not. The reason: components for the company’s own platforms must be further developed. This takes resources, time and work. Resources that shouldn’t be spent on the competition.
A slightly less abstract example: If Apple were to optimise Swift for Android, then the Cupertino-based company would be actively helping its greatest opponent Google, wasting precious Apple resources. Apple itself would have nothing to gain from this. The programming world maybe, but Apple doesn’t really want to work for its competition, and is subsequently really good at creating and keeping compartmentalised areas for itself.
Google Maps on iOS: patched together, historically
The rise of the iPhone and Android’s simultaneous triumph didn’t just create a competitive situation, but also demand. A need for YouTube on iPhone, Google Maps and maybe even Google Photos.
Google wasn’t very keen on this, as this would remove a reason for Apple users to switch to Android. But the public pressure was too great. So Google Apps gradually found their way onto Apple’s platforms. Apple offers a handful of its own apps on the Google Play Store, but makes no effort to port iCloud to Android.
And why should it? If you want iCloud, use an iPhone.
If you prefer Google Drive, you can use pretty much any smartphone.
In other words, the first version of Google Maps on Apple’s iOS was a patchwork. The app contains Apple’s own libraries, design elements, and features mixed with those supplied by Google.
That’s how it was. For nine years.
Material Components: in Maintenance Mode since July
Google is thus taking a big step, politically speaking. Because instead of loading their own components, Jeff Verkoeyen and his team will rely entirely on Apple’s own tools in the future. Verkoeyen confirmed this in a Twitter thread.
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 foundations were also evolving year over year.
Verkoeyen described a situation that is inevitable during the non-standard development of a software. Material Components were further developed and went in one direction. Apple’s core components evolved in a different way. The bridge that Material Components had to build was getting bigger and bigger.
In early 2021, Jeff Verkoeyen’s team asked themselves: was the bridge even still necessary?
A look at what Apple’s SDK and its components are capable of showed: Apple can take care of itself. It was time to ask some uncomfortable questions: does a simple switch in an app really require its own component from an external library?
The answer was clear: no. Many Material Components were no longer needed as Apple’s core tools now met those same needs. The few additional components that needed to be loaded in would receive more attention thanks to maintenance mode. This promised faster and more efficient development of Google Apps on iOS.
It is quite possible that you as a user won’t even notice this change. This despite the fact that simple elements in Google Apps are now made with Apple’s own «UINavigationController» instead of the Material Component «App bar».
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.
Of course, these Apple Components in Google’s apps won’t look as if Apple created them. Google’s own brand identity will be incorporated.
Verdict: money (and some extra development) takes precedence over politics
Google’s decision to work with Apple’s components is a double-edged sword. But it shows that reason can prevail. After all, switching from Google’s own components to Apple’s equivalents saves Google money, yet simultaneously grants the competition information, knowledge and perhaps even some code to improve something that Apple has so far refused to work on. Or that Apple didn’t know needed improving.
But on the function side, the decision is reasonable. Just because something was good or even necessary ten years ago doesn’t mean it’s still good or necessary today. If Apple can deliver components that perform the same function as Google’s own, then it makes sense to let in-house developments die with dignity.
Google is also making a big splash with the changeover. The services provided by the search engine giant’s apps are dear to all users. But the criticism that apps on iPhones don’t feel as good as they do on Android or vice versa with Apple is valid. And likely correct, given the changeover.
The search engine giant is saving money, time and endearing itself to users. Jackpot.
Verkoeyen’s team had to show courage, however. Because admitting that ten years of work is no longer needed takes strength. On the one hand, jobs could be lost within the team, but on the other, Verkoeyen and Co. prove that the «Sunk Cost Fallacy» can be overcome. Or even must be overcome. Just because money and time have been invested so far doesn’t mean that further investment is worthwhile.
For users, maybe a switch in the app will change. In our house-building metaphor, this would be the insulating material within the walls. For Google and Apple, however, the world has just changed a bit.
Journalist. Author. Hacker. A storyteller searching for boundaries, secrets and taboos – putting the world to paper. Not because I can but because I can’t not.
Background information
Interesting facts about products, behind-the-scenes looks at manufacturers and deep-dives on interesting people.
Show all
