Kevin: Touchlab Refactory is an incremental refactoring service that we provide for our clients. Over the years at Touchlab we have done this for a number of clients where we come in and we refactor architecture we reduced tech debt. We improve testing all those kinds of things and now we’re specifically focused on using Kotlin Multiplatform to also consolidate your code bases to reduce duplicate code reduce duplicate logic and architecture which will help prepare your code base for the future, reduce errors all kinds of stuff so you can focus on delivering products and new features well while we. clean up the code base and make things run smoother.
——
Question 2. Why do I need it?
Kevin: Pretty much every team on the planet would love to go back to refactor code, fix their architecture, improve test coverage but you have ongoing priorities and deadlines, which prevent you from doing so. We can come in and do that simultaneously while you’re delivering your ongoing work.
——
Question 3. How does it work?
Kevin: We come in for a fixed engagement, generally 8 to 12 weeks with our independent code logistics team. We’ll do an architectural review of your codebase to identify features best consolidated with Kotlin Multiplatform and begin that refactoring process. At the end we’ll leave you with a detailed roadmap for your Kotlin Multiplatform future.
——
Question 4. How much of our time will it take?
Kevin: There’s a minimal impact on your time because we’re coming in to refactor your existing code. We don’t need to sit down with users, we don’t need to iterate with the business, we don’t need to do feature development. We are taking existing code and making it better, so while you’re working on new features our workflow happens concurrently but independently and doesn’t impact your feature delivery schedule.
——
Question 5. Do we risk missing a deadline?
Kevin: So do you risk missing a deadline??? Easy answer is NO. Kotlin Multiplatform by its nature is optional and incremental, so we can take things feature by feature and you don’t have to do the whole thing at once. This code exists already in your code base so you can take this refactored code and put it into and deploy it on your platforms when you’re ready. You don’t have to do it right away there’s no external deadline for this to happen.
——
Question 6. What about the cost?
Kevin: It’s fixed cost and time engagement and with the predefined scope of work. Our approach is to take one feature at a time of your product and refactor it and improve it and our goal is to show that this is a sound strategy this is something that’ll work it’s low risk for you and at the end you’re going to have something measurable that you can use.
——
Question 7. So what’s the best reason for partnering with Touchlab?
Kevin: Well in the short term it’s really important to improve code quality and consolidate your codes so you can move faster so you can iterate faster deliver better product deliver safer products that has less issues less problems for both your internal teams and your users but it’s also about the future the future is not just iOS and Android the future is maybe the web the future is maybe voice the futures maybe other platforms. The future is hard to see and we are preparing for the future, a post-platform future by reducing risk and having an adaptable codebase and adaptable team and skills and we think that that’s really important and we think Kotlin Multiplatform is going to deliver that.
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.
Baggage
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.
Wide Net
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.
Multiplatform
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.
Kotlin Multiplatform
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).
And now for a special suprise!!!
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.
4 Factors to Consider When Deciding Android or iOS
1. Demographics
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.
2. Deployment
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.
3. Development
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.
4. Revenue Model
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.
Examples of Successful Companies Who Chose Android, iOS or Both
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.
