You need iOS developers to achieve the full potential of Kotlin Multiplatform; they’re half of the equation! At Touchlab, we’re committed to building the native experience for iOS developers using Kotlin Multiplatform.
We interviewed Partner Kevin Galligan on what we’re doing as an organization to ensure iOS developers are engaged when building with Kotlin Multiplatform.
In the application development world, you hear the term cross-platform all the time. The idea of “write once, run anywhere” is like an unreachable promised land for management stakeholders, and an unrealistic and frustrating reality for developers.
At Touchlab, we don’t use the term cross-platform. We prefer “multiplatform” – for a couple of important reasons.
First, cross-platform has a lot of baggage because of existing development platforms. PhoneGap, Titanium, Xamarin, Ionic, RubyMotion… the list is long. Initially, these solutions went through a phase of exuberance, followed by disappointment. Developers were frustrated with not being able to express the UI how they wanted, unavailability of features on their wish list, and invariably, teams would end up managing three platforms – cross-platform, iOS and Android. For product owners — and ultimately, the end-users — the UX was rarely satisfying.
Note: If your organization doesn’t care about native, traditional cross-platforms solutions might be okay. Context matters.
Second, cross-platform really is a super-inaccurate term because the solutions that are lumped under it are wildly different. We believe you need much more nuanced terminology to describe coding for a variety of platforms. The way we see it, at one level, when a native developer sees anything that isn’t Java, Kotlin or Swift, they’ll lump all alternatives into cross-platform and immediately (without pause) classify them all as bad based on a singular bad experience with a solution. “If it’s not native, it’s bad. I would know, we tried PhoneGap once.”
And while the world has always been ready for shared code, it’s rarely been implemented well. The good news? There are now better options to make things really work.
At Touchlab, we’re about shared logic that interops natively with the platform you’re working with, homogenized logic and libraries – all of which should occur below the UI and be performant. Simply put, our multiplatform approach can’t and shouldn’t be compared to “cross-platform.” It’s not an apple-to-apple comparison.
We call it “post-platform thinking”. It doesn’t matter what platform you’re delivering on, because the ultimate goal is to have a well-tested and well-architected backend, middle communication layer, and front-end architectural layer that’s all homogeneous.
So, if as developer can build the logic from the back-end to the front-end, and model the logic for the UI in a microservices model, the developer’s job becomes one of service aggregator rather than implementer. The iOS developer can focus on UI and UX, not on implementing the services themselves.
And that’s what Kotlin Multiplatform does: natively shared, performant, tested architecture with a fantastic developer experience and ecosystem. It enables you to do runtimes efficiently, and have the ability to test – all of which makes shared logic a lot more possible. The architectural stuff is well tested, it’s well engineered, it’s economical and efficient from a development standpoint, so it’s an easy platform to move to another UI.
So why is Kotlin the way to go? Here’s the thing: anything that requires you to make large decisions and potentially large rewrites, perform large retrainings and rehirings, or anything that has to share UI or doesn’t work well with a native platform is, well, very risky. The fact is, Kotlin Multiplatform is not risky in that same way, and that’s why we’re working with it at Touchlab.
Kotlin Multiplatform is a modern language with enthusiastic community support that allows native optional interoperability with the platform on which you’re working, with straightforward logic and architecture. Android, iOS, desktop platforms, JavaScript, and WebAssembly. For me, the idea behind Kotlin Multiplatform is that you can invest in this way of building logic, and you don’t have to guess which way the industry is going to progress in the next 5 or 10 years. If everything moves to the Web, you can support that that. If it all goes mobile, you can support that too. And that’s true multiplatform.
It’s no secret that we are major Kotlin Multiplatform fans (spoiler alert!); with your input, a survey can help us prioritize our engineering efforts and initiate a conversation with folks who aren’t quite as excited as we are.
You’ll see the basic, information-gathering questions as well as exploratory questions that might allow us to capture trends and thought processes surrounding the multiplatform space.
Thank you in advance for taking the time to complete our short survey below (3-5 minutes).
As a thank you for completing our survey, you will receive an invitation to attend our Kotlin Multiplatform Webinar.
Date: Thursday, March 28th, 2019 from 1-2 pm EST
Webinar is for developers and engineering managers interested in learning why the future of cross-platform is native and how Kotlin Multiplatform is different than “The Others” (Xamarin, React Native and Flutter).
Great, you have an app idea! You are a tech founder or enterprise mobile leader and you really believe in your vision and team, but now, you’re challenged with deciding Android or iOS.
First, there is no universal truth or answer to this question.
With variable amounts of time, money, and manpower, it can be difficult to determine which platform best suits your strategy. Despite the challenge, with careful comprehension of key considerations, you can definitely figure out the best platform for you.
Who is your target audience? Who do you see downloading this app? Break this question down into two identifiers: location and socioeconomic status.
Source: DeviceData
Location: If your target audience is based in America, Canada, United Kingdom or Australia, then iOS makes more sense. However, if your audience is located in more developing countries in continents like Asia, South America, or Africa, choose Android. Device Data has plenty of data for more specific country breakdowns.
Socioeconomic status: Similarly, if your audience is based in more developed countries, then their presumed wealth indicates that iOS might be more popular. Contrastingly, in less developed economies, users are less likely to pay for apps and prefer in-app advertisements. For this reason, Android might be more profitable. Slate produced an investigative report supporting the economic divide between Android and iOS.
Which operating system is more compatible with your vision? Break down the pros and cons: operating systems and the App/Play Store.
Operating Systems: If you would prefer the ability to have more customization and control, then Android’s operating system is more compatible. If customization and control are not major priorities in your decision, then the iOS, more restrictive language, might be best. On the other hand, if you would prefer to launch faster, develop on iOS—launching is faster here as iOS lacks device fragmentation.
App/Play Store: It is objectively easier to get your app approved on the Google Play Store—the approval process is automated and primarily focused on violations. Approval on the Play Store is a much more lenient process than the App Store. Contrastingly, approval on the App Store may be more difficult.
App development, of course, requires access to labor, funding and time. How long do you have to develop this app? And what does your funding look like? This will primarily serve to hire and sustain your engineering talent required to develop the app.
Access to Labor: If you only have access to iOS engineers (and your audience is on iOS), then you will lean towards developing for iOS first. If you have access to Android engineers (and your audience is on Android), then develop for Android first. If you have access to both and sufficient funding, then build for both!
We pulled this graph from Infinum that depicts the hours of work for each project. They calculated that Android development consumes 30% more time, thereby making Android more costly.
Funding: Developing a mobile application can have varying costs depending on the type of app and its features. On average, iOS engineers have a higher hourly rate for development.
Deployment Time: How quickly do you need the app deployed? The Google Play store is more likely to release your app—additionally, they offer Google Play beta App Store for test releases. Contrastingly, the App Store carefully reviews all apps and wait times can be days or weeks long. If you are in a hurry to deploy your app, then Android might be the best option here.
Modern Mobile Development: We believe the future of mobile innovation is multiplatform mobile development. If you’re interested in exploring how Kotlin Multiplatform can help you code once and deploy to Android and iOS, check this out.
Revenue: Your revenue model should reflect your target audience. iOS users are more willing to spend money on their apps, and are more annoyed by in-app advertisements. Contrastingly, Android users are more likely to not spend money on an app and more likely to be okay with in-app advertisements. If you are looking for the most revenue-generating model, iOS definitely wins there.
We pulled these charts off of App Annie depicting the difference in revenue generation for the App and Play Stores. More Google Play users are downloading apps; contrastingly, more iOS users spend in the App Store than Android users in Google Play. Therefore it makes more sense to use in-app advertisements to generate revenue in Android and charge consumers for in-app purchases in the App Store.
Android first: Thrive Global (current Touchlab client) is an app designed to effectively monitor and control mobile use. The app requires a lot of device side controls (not allowed on iOS), which guided the decision to develop on Android first. Check it out here!
iOS first: In the United States, iOS has 65% market share while Android has 35% (according to DeviceData). For this reason, there are generally more iOS engineers available compared to Android engineers and Apple gets more consumer fandom—therefore, successful startups in the past have generally developed iOS first, followed with Android. For example, App Annie states that Airbnb launched their first app in iOS in November 2010. In January 2012, after amassing a strong base and revenue model, they launched Airbnb in Android in January 2012. Another successful app, Instacart, also started this way with iOS in August 2012 and Android in May 2014. Unsurprisingly, Touchlab’s early years were porting iOS apps to Android.
Both (ideal!): If talent and funding are less constraints, developing iOS and Android simultaneously is the best option. One example of a successful app that developed on both platforms is: Crew. They launched in May 2015 and have raised $24.9 Million in VC funding.
Another example of developing for both is DoorDash. DoorDash released on Android and iOS around the same time! App Annie confirms that DoorDash in iOS was launched in October 2013 and DoorDash in Android was launched in December 2013. DoorDash is an excellent example of an app that understood its target audiences because DoorDash is hoping to attract not only clients who will use the app for deliveries, but also couriers who will make the deliveries. For these reasons, one can assume a difference in socioeconomic status and therefore expect to find clients on iOS and labor on Android. DoorDash reacted accordingly and pursued the development of iOS and Android concurrently.
Additionally, sometimes your app does not need to come first because, perhaps, your product is best for the web right now. App Annie shows that Reddit was launched on both iOS and Android on April 7, 2016. Yet, Reddit was founded in June 2005. As a web-based platform, they were able to establish themselves and later develop concurrently for mobile platforms.
As you can see, companies and developers take different approaches to their mobile app development—and no approach is right or wrong. The only way to mitigate risk is to first understand the considerations, factors, and your audience—then, you make a wise and informed decision.
=======
This post was written by Touchlab marketing intern Mina Mahmood.
An app is written for the Web.
Then, it’s written for Android.
Same app, different code.
Oh, and it needs be written for iOS, too. At the same time.
Again, different code. The question is, “Why?”
Development teams are essentially tripling their coding and testing efforts to ensure cross-platform coverage. It’s costly. It’s time-consuming. And – this might be the craziest part – it’s uncertain what the shelf life of the code will be. As we know, the future is unwritten.
As always, the goal is to be able to implement products more efficiently, and with better testing across platforms. And up to now, every cross-platform coding solution that has come along really hasn’t worked that well.
The good news is that there is now a better way. And a proven way.
We at Touchlab have been writing code in Kotlin and deploying it to Android and iOS platforms, with no hiccups.
That’s why we’ve gone all-in with Kotlin.
Kotlin is a true multiplatform language
Kotlin enables you to write once, and test once. No siloed development teams. The same code can be used across Android, iOS and Web apps with no changes, eliminating the need for a translation layer. In essence, you’re reducing the amount of business logic coded by frontend developers by consolidating it efficiently with native code, but not oversimplifying abstractions.
What’s not to love about that?
No wonder there’s a groundswell of enthusiastic support in developer communities around the world. There are 1.5 million developers currently using Kotlin, with 96,000 GitHub repositories containing 100 million lines of code. And the numbers keep growing. It’s one of the top two languages that developers are hungry to learn.
Kotlin was developed as a completely new language eight years ago, built from the ground up as a pragmatic approach to coding – a way to develop cleanly, clearly, and quickly. Simply put, Kotlin is more readable, reusable, interoperable, and safer, offering a first-rate developer experience.
Kotlin is your best bet on your complete tech stack
More important, it’s a low-risk way to code because it dovetails seamlessly with the native platforms on Java, iOS, and the web. It’s a modern language that enables you to build on what you’ve already coded, without re-working or re-inventing what you already have. Plus, because the code you share is optional, you can start small and increment as desired.
Kotlin is really an extension of Java, so it’s not a big leap for Java developers to start using Kotlin at all. In other words, you don’t have to make a big, potentially expensive decision to get started.
In fact, on Android, Kotlin was built for direct JVM interoperability. On iOS, Kotlin is ready for prime time, and the first half of 2019 will see rapid mainstream adoption. And Google officially recommends Kotlin as a language of choice.
The big considerations for any development team are cost, time, resources, and risk. And the big problem with the siloed approach is that organizations are often tripling them.
At the same time, the wrong teams are working on the wrong projects. Back-end developers should focus on architecture as well as APIs – but not UI. Enabling your back-end developers to code and test the client and server features as a unified whole enables more rapid development with safer, higher quality and identical implementation.
Our experience with Kotlin so far?
No siloed teams. More streamlined workflows. Real cross-platform functionality.
Yes, it’s working now!