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.
Both these frameworks are integrated into software development kits (SDK). These being Android Studio for Google and Xcode with Apple. Both SDKs were invented by their respective manufacturers and are constantly being developed further. To continue our building analysis, these would be the toolboxes, containing all you’ll need to build a house.
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.
Sure, both groups talk about openness and throw around terms such as «intuitive». But this only applies if you’re an Android programmer using Android Studio for Android. Everything else requires a workaround. A look at Flutter for iOS Developer will show you how to do this. Terms differ, things work differently, and users will generally have to completely relearn the programming language.
Swift is a powerful and intuitive programming language for iOS, iPadOS, macOS, tvOS, and watchOS.
Forget about «intuitive» or «easily accessible». Even just attempting to use these incredibly complicated workarounds in practice will result in frustration. It would be easier for a programmer to simply install two SDKs and write the app twice. But that takes time and resources that only larger programming studios have. In reality, all app programming studios, small or large, face a choice:
- You choose one platform (iOS or Android) and vow to use the other one day.
- The studio implements a hybrid framework for simplicity. You don’t have to use a native framework, Ionic is one of these hybrids. Flutter is another, but you can’t get around Xcode.
- The studio builds the app twice. This can even be cheaper than using a hybrid approach.
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.
Both are political decisions from the respective manufacturers. And there’s only one thing to say about both choices: fair enough. Companies aren’t committed to openness. It may be more sporting, but no one can force Apple to be fair. Just like Google isn’t obligated to be present on Apple platforms. From a legal point of view, the only thing that needs to be avoided in software development is obvious monopolistic behaviour. As long as that isn’t an issue, everything’s okay.
Google chose Maps as the first app it would port to iOS back in 2012. While developing the Google software for Apple’s ecosystem, Development Leader Jeff Verkoeyen’s team noticed that Apple was missing some necessary elements for Google’s program. The team therefore recreated these elements – as foreign bodies, known in technical jargon as Material Components. They’re open source, of course. This way, Google and Apple didn’t form a monopoly.
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
But all that changed in July 2021. Material Components for iOS – the foreign objects – were put into Maintenance Mode by Google. This means that they won’t be continuously developed until further notice, only maintained. If something’s broken, it’ll be repaired. Security leaks will get plugged. But otherwise, Material Components will be allowed to die with dignity.
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.
