Mobile Development and the race to cross-platform
|Alin Turcu in Apps Monday, August 24, 2020|
Mobile app development has increased dramatically year over year. In Q1 of 2020, the Apple App Store had approximately 1.8 million applications while Google Play Store had approx. 2.5 million. More important, every indication says this trend will continue, and with COVID-19 impacting every business of every size, the reality is that all businesses are now developing a mobile presence in addition to one on the web.
Since the turn of the century, mobile app development has increased dramatically year over year. In Q1 of 2020, the Apple App Store had approximately 1.8 million applications while Google Play Store had approx. 2.5 million. More important, every indication says this trend will continue, and with COVID-19 impacting every business of every size, the reality is that all businesses are now developing a mobile presence in addition to one on the web.
The only major players left in the mobile app development business are Android and iOS, which together account for around 98% of the total mobile operating system market share. Two large players controlling the market may feel like consolidation that could lead to a standards-based approach for developers. Unfortunately, two dominant players have translated into some challenges.
Developing natively for both platforms requires two separate teams. These teams typically develop the same thing using different languages and frameworks. This leads to a great deal of redundancy and increases the overall cost of developing your mobile apps. Even from the user interface perspective, each platform has started to adapt the other’s designs and as a result, the gap and differentiation between the two has narrowed.
Community Jumps In
In recent years, Google and Apple were in such fierce competition that they didn’t care to tackle the issue of standards across the two platforms. Because of this issue, the mobile community was inspired to jump in and create frameworks, such as Cordova, Ionic, or NativeScript. Other companies also started developing their cross-platform frameworks like Microsoft’s Xamarin, Adobe’s Ionic, and Facebook’s ReactNative forcing Google and Apple to face a new reality.
All the frameworks mentioned above brought the benefit of having one code for both platforms and in some cases, one language for both Web and Mobile. This represents a huge advantage. Unfortunately, the advantage comes with a downside, and that’s lower performance and UI fidelity.
Google and Apple’s Answer to the Cross-Platform Movement
The Business Is Pushing Cross-Platform
In recent years, more and more big companies have been leaning towards ReactNative/Xamarin or other cross-platform solutions for their business. They do this because they can’t afford a native solution, so instead compromise for a more economical cross-platform solution. The alternative is not having a mobile presence and that is a compromise most companies can’t live with.
Let’s look at what Google and Apple have done in this space:
Historically Apple has stuck with developing and promoting its own systems, mostly to control security issues and to encourage the purchase of their hardware. However, the modern age has seen the rise of open source software and the decline of brand loyalty, with many users transitioning across platforms and operating systems (e.g., Android phone to a Windows desktop to an Apple watch). Apple seems to have decided they want to push Swift forward as a language beyond their platforms. As of 2015, Swift is an open source language. As part of this, Apple released Swift binaries for use on Ubuntu.
Again, the community picked up on this and pushed for cross-platform development. Swift can be used for writing server code using Vapor and you can even port Swift into Windows and Android.
In 2019, Apple released SwiftUI with the purpose of using one framework across all the Apple platforms. This is in contrast to the current system which has WatchKit for watchOS, AppKit for macOS, and UIKit for iOS and tvOS. This is important for developers working in the Apple ecosystem as it unifies the platforms and eases the creation of an app for all of them.
Again, even before it has left beta, the Swift community has created a way of running SwiftUI in the browser. Whether Apple will pick this up themselves remains to be seen, but it’s another steppingstone for Swift towards running on all platforms.
In May 2018, three years after Facebook’s release of ReactNative, Google released Flutter. Flutter is Google’s UI toolkit for creating natively compiled applications for mobile, web, and desktop from a single codebase. Flutter is a free and open source. Flutter is different than most other options for building mobile apps because Flutter uses neither WebView nor the OEM widgets that shipped with the device. Instead, Flutter uses its own high-performance rendering engine to draw widgets.
Flutter quickly became very popular and is now competing with ReactNative in popularity
Sounds great right? Well, the downside of Flutter is that it uses Dart as its language, so developers will need to learn a new language to start building Flutter apps. Flutter is also still young and lacks large production apps built entirely with Flutter. In many respects, Flutter still has to prove itself.
A few years after Apple announced Swift, at Google I/O 2017, Kotlin was unveiled as an official Android development language. In 2018, Kotlin was the fastest growing language on GitHub with 2.6 times more developers compared to 2017, and it is the fourth most loved programming language according to the 2020 Stack Overflow Developer Survey.
Why does this matter? Well because it’s another move towards cross-platform. Kotlin works on the server-side and the Kotlin language team is working on a Kotlin Multiplatform project that will allow developers to use Kotlin for iOS development. Also, the community built Ktor: a framework to easily build connected applications — web applications, HTTP services, mobile and browser applications.
Working on all platforms is an explicit goal for Kotlin — https://kotlinlang.org/
The idea behind Kotlin multi-platform is interesting because it doesn’t affect the way UI is built on iOS. You will still use your native development framework to build the UI, and use Kotlin for the business logic of your app.
Another interesting fact is that the number of jobs for Kotlin developers for Android is higher than Swift, according to LinkedIn.
5. Declarative UI
In recent years, both Google and Apple have borrowed the declarative UI system from the web, using it in Flutter, Jetpack Compose, and SwiftUI frameworks. This means that in the future, the Swift developer no longer needs to understand the Android XML structure and the Android developer no longer needs to know how to work with XIB files or storyboards.
Write Once, Run Everywhere?
Some will argue that the iOS and Android UI will never converge and you will still need to write specific code for the interface of each platform. I tend to agree with this, although frameworks like Flutter and ReactNative managed to solve this part also.
Even if the UI will still need platform-specific knowledge, the declarative UI frameworks that have emerged lately will probably solve this problem, making the code easy to understand and write by one developer for both platforms.
But what about the rest of the app? Many developers believe the business layer, the network layer, the persistence layer, and the presentation layer should not be duplicated for both platforms. Kotlin Multi-Platform seems to solve this problem, but it’s too early to give a verdict on this.
Like most of us, I’m waiting to see what solution will emerge as a winner from this race. But I think we’d all agree that rationally and emotionally, ‘Learn Once, Write Anywhere’ is a better approach than ‘Write Once, Run Everywhere.’ You can’t have a universal solution for all platforms, but at minimum you should have the same language or patterns.
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.