A Multiplatform Case Study for an Inclusive Virtual Try-on Experience

A Multiplatform Case Study for an Inclusive Virtual Try-on Experience

Getting Started:

At Touchlab, it is typical for us to take on leads and projects that are new to us. We’ve worked on hardware, watch faces- all kinds of things- with no previous experience; we embrace the challenge and rise to it. It is atypical, however, for client research to blossom into a philosophical, platform agnostic, week-long design sprint.

But, we are nerds.

It all started as a simple conversation with people in the retail cosmetics industry. First, we noticed how fun it was to take virtual selfies with funky eyeshadows. Then, we noticed that some virtual try-on apps were waaay better than others. Finally, we got feisty (and immensely curious) when two makeup apps failed to recognize Jeff’s face correctly.

Not quite. 

We saw value in spending time to develop a deeper understanding of the virtual try-on world- really to foster our own awareness of what it takes to accomplish inclusive and feasible design in this space.

Our goal? To design a user-centric, e-commerce experience for a single makeup brand in one week.

Cultivating Empathy and Acknowledging Context:

When it comes to people who wear makeup, you cannot generalize into one or two flattened personas; anyone can wear makeup and the reasons behind applying even a simple black eyeliner are fluid and highly subjective.

Matching eyebrows to lids: the things we notice now. More from Ziggy here:

As Nielsen puts it in the 2018 Future of Beauty Report, “There is no one beauty shopper.” It is also important to note that wearing makeup — be it skin tone or neon green — is less related to confidence, vanity, conformity or belonging than some might think.

For most, it is a form a self-care and for many, a creative and even artistic expression of Self. This is how we are approaching makeup during this design sprint.

(By the way, if you didn’t already know, the biggest makeup trend in 2019 is gender fluidity.)

This idea of makeup as a form of expression is by no means new. But culturally and technologically, the beauty industry must embrace/is embracing the “no rules” approach as social boundaries are broken, social media influences the path-to-purchase and buyers across industries begin to trust and expect VR offerings.

Our Discovery Process:

Armed with what we feel is a grounding contextual view of the modernizing makeup industry, Touchlab’s design team kicked off a more hands-on discovery process by conducting a contextual inquiry and investigation through many of Manhattan’s makeup stores.

Why? In order to get off of our laptops and challenge any preconceived assumptions about makeup shoppers IRL. 🕵🏻‍♀️ 🕵🏻

 Left: Sephora’s virtual try on installation. Right: An example of MAC’s in-store product organization.
As we made our way around the different retailers, four interactions stick out:
  1. Quiet 20-somethings experiment with every bright-blue lipstick in the store. The makeup artists were kind and attentive, but let everyone play around with bold blues and shiny reds unbothered. Everyone was rubbing makeup on, wiping it off, checking themselves out, asking questions. Allowing and encouraging customers to play creates a positive retail environment and a magnetic vibe.
  2. A seasoned makeup artist explains their goals for their popular youtube channel; to target people who are “going somewhere” and do memorable street makeovers to match expectations around that experience.
  3. An older woman’s experience at an in-store virtual installation is somewhat marred by a technical gaffe; her virtual lipstick is overtly offset from her actual lips, seemingly because of her wrinkles. Despite this error, she expressed how fun it was and stayed for over 15 minutes.
  4. Two girls hesitate at the door of the store that seems a bit, well, “stuffy.” They leave almost immediately.

Amongst the perfumed chaos of the wildly different retail environments, we do detect an overarching trend: all kinds of people want to play and experiment with fun makeup, no matter their intention to buy.

Trying on different shades on your hands is commonplace in stores. Virtual try-on certainly solves this “pain point.” (Is it a pain point?)

User Testing and Product Audits

We moved into user testing and product audits of the more popular virtual makeup apps, the goal: to test not only the usability of these virtual experiences but also people’s reactions to e-commerce-oriented flows versus more playful user flows.

Examples of our testing sessions during which we asked users to complete 3 tasks. Users were consistent in having trouble completing retail transactions and finding the virtual try-on feature.

We tested the most popular apps in both the App Store and Google Play. The reactions were emotionally loaded. Most reacted negatively to commerce-oriented user flows that sent them back and forth between traditional, scrollable product grids and the virtual try on camera. Some had trouble even finding the virtual try-on feature on many apps.

Memorable quotes include:

“I don’t even know what this picture means. How do I even get to the try-on? I feel like it’s trying to just sell me *things*.”

“Where are my lipstick colors even going after I try them?”

“Wait! I wanted to see the whole look!”

However, we observed that users had the most fun when playing with colors as a form of self-expression:

“Dang, I look good. 👩‍🎤

“I’m going to go with… this color — “Dangerous” — because that’s how I feel.”

 

Danger is a pretty cool middle name.

Defining our Scope:

Surfacing from our deep immersion into virtual-try on make-up apps proved rather difficult for us designers; we are both now addicted to makeup apps and were getting pretty good at selfies. 🤳🤳🤳👩‍🎨 👨‍🎨

Touchlab Designers conducting product audits WHILE looking really, really good. If we do say so ourselves.

It was time to start taking our data and synthesizing it into actionable points of departure. Harnessing the passion of the makeup-wearers we interviewed and observed, we constructed a persona spectrum.

“Instead of defining one character, persona spectrums focus our attention on a range of customer motivations, contexts, abilities, and circumstances.” — Margeret P. for Microsoft Design (More here)

We know from our process of empathetic understanding that customer motivations for trying on makeup virtually vary greatly, but an overarching motivation might best be called “play”- with an underlying asterisk: ***”play” without the blight of glaring technical virtual misunderstandings for which a modern user has little tolerance.

Left: virtual try on of lipstick. Right: IRL photo of that same lipstick. I would (and did) buy this in-store, but not online. Not all virtual makeup was as inaccurate. 

We are moving forward with the assumption that users are less likely to buy a makeup product (in-app or in-store) if they do not trust the accuracy of the application of the virtual makeup. We define “Accuracy” here as the belief that the product will look, in real life, just as it does on camera. Accuracy, then, is relative to the proper recognition of the user’s facial features, skin tone, race, age, etc.


 Brainstorming at the office. #nomakeup #nofilter

From user testing sessions, we gathered that users of virtual try-on experiences want:

  • A balance of “Play” and “Pay” (Allowing product exploration and experimentation to be the natural point of sale, similar to the in-store experience. )
  • A means for creative expression with makeup
  • A variety of products to try
  • Accuracy in the virtual try-on experience. (Where product accuracy cannot be achieved, at least a positive, fun experience can funnel users in-store.)

Users of virtual try-on experiences need:

  • Easy control of the camera view with one hand/thumb
  • Proper architecture and timing of e-commerce product areas during the play to pay funnel.
  • A well-lit camera view, flexible enough for a myriad of environments
  • A natural multi-platform user experience
  • Facial Recognition for all genders, ages, and races*

*Feasibility-wise, this is an idealistic thought summarily strangled by the inequity in facial recognition we’ve witnessed thus far in our research. The feasibility of speedy and comprehensive machine learning for all faces will come from developers out there; as designers, we feel it is important for us to engage in the conversation and point out the inequity. Idealistic? Yes. Nonetheless, an underlying need.

With our user-centric motivations in mind, as well as recognition of the strengths and shortcomings of existing products- we arrived at our goal:

Create a modern, e-commerce, camera-focused experience that feels seamless and authentic.

Ideation meets its frenemy- Feasibility:

With our guiding principles in mind, we asked ourselves: How do we harness existing powerful API’s and a cultural affinity towards dramatic and playful makeup to create a delightful and inclusive e-commerce experience?

 ~Low Fidelity Ideation Techniques including sketches and thumb maps~ AKA Paper!

For the ideation process, we considered both constraint and context, respectively restricting and potentially accrediting features down the road. Constraints become especially important here when dealing with a camera/virtual experience:

For instance, design-wise, we must consider the one-handed “thumb zone.” and commonplace user experiences and, related, expectations around popular camera-oriented apps.

More about Scott Hurff’s thumb zone here. Note that these photos reflect right-handed thumb zones.

Feasibility-wise, we must remember:

  1. Our sprint time constraint 👮🏼‍♀️
  2. The importance of an e-commerce funnel
  3. The availability and robustness of cosmetic API’s
  4. The machine learning curve of accurate makeup application for the whole spectrum of race, gender, and age.

Some of the contextual circumstances that we considered include:

  • Physical limitations, temporary or permanent. (We are, after all, asking the user to take a selfie and therefore should absolutely keep the one-handed experience in mind.)
  • Users with the inability to deeply focus on the task at hand- be it temporarily due to various forms of distraction, or permanently, perhaps due to disability.
  • A range of environmental lighting and how that might influence virtual quality and accuracy

Scoping in, “Must Have”, feasible features include:

  • Ability to save looks/products for later
  • A predominantly camera view
  • Cart / Wearing list
  • Guided process
  • Color picker
  • Control over makeup intensity
  • Adding to bag
  • Seeing Makeup Details
  • Easily Changing/Removing/Adding Products

Features that we should or could have:

  • Automatic camera light correction
  • The ability to report or fix incorrect virtual makeup application
  • Saved “Looks” that apply all at once
  • The ability to share

How exactly those retail elements are presented was guided by user reaction and also screen space available, considering that we don’t want to cover the users’ face with text during their selfie session.

Design Progression:

During low-fidelity prototyping, we noted and observed users’ expectations.

Because of the e-commerce element of this project, we needed to test when, where and how to show the user the product information sooner rather than later. We started off by letting them play first, then show them their choices in a cart-like setting after the fact.

Even though the process to get to the cart did not take long, users rejected being in the dark; they wanted to know exactly what they are wearing when they were wearing it.

 Mid-fidelity prototypes did not show the user the e-commerce details until they saw their cart. Both the copy and the timing were problematic.

Mid-fidelity prototyping identified weak spots in both visual hierarchy and the timing of e-commerce introduction as we strove to balance UI and branding with the selfie-camera view.

During our iterative process, we determined what we think is the most natural way to introduce e-commerce elements into a playful virtual experience using thoughtful choice architecture:

For lipstick application, for instance, you first narrow the product areas by color-which is easily changed-, then choose the preferred finish (and thereby the exact product line and color), and then finalize with manipulation of the intensity of the makeup application.

For brows, however, you should first choose what type of application method you prefer, then choose between the few colors that are offered (thereby the exact product line and color), and then select the “style” (which is where things get fun again, for the user).

Hi-fi prototyping with re-architecture of e-commerce details

In our “final” prototype, we wanted to reflect a selfie-focused experience that encourages the user play with products without feeling forced to buy those products. 

In order to do so, we introduced the product description as a minimalistic, clickable overlay at what users deemed an appropriate time- and added the ability to change the products that the user is wearing from a “now wearing” list.

This person has opened a virtual makeup app, they want to try on makeup, they want to have fun, they want to see the price of the makeup, and ultimately, they just might buy something that they like.

The takeaway from designing this sprint for multiplatform is the importance of maintaining a human-centric approach so that when we pass off to developers, they understand our thoughts on tackling feasibility in this space.

“Final” prototype for both iPhone 8 and Pixel 3

A note on prototyping:

Because of our one-week time limit, we decided against framer and instead chose to work with still images to imitate a live camera view. A natural next best option would have been to use Sketch, but keeping in mind that early concepts need iteration to happen fast we decided to use Adobe XD

XD allowed us to change and test things between and across the team quickly and efficiently. Additionally, the lack of an app for previewing Sketch files on Android was a deal breaker.

XD’s auto-animate unlocked effortless micro-interactions on the final prototype that gave it an extra layer of realism; this was absolutely key in our virtual + selfie experience.

Ending Thoughts:

If you have read anything about Touchlab recently (see this post about our recent announcement with Square!) you have probably picked up that we are proponents of multiplatform design and development.

In this sprint, we forego assumptions about the differences between iOS and Android users and instead design for our spectrum.

Does it matter if iOS users “spend more money on makeup products” or if Android users “take fewer selfies”? Defining a person (or persona) by the phone that they buy seems silly and too blanketed.

As the industry of mobile development moves to a future where iOS and Android Engineers are becoming Mobile Engineers, our design team becomes Mobile Designers.

We focus on expressing our client’s brands across platforms the right way, instead of focusing on items on a list.

Frances Biedenharn & Nelmer De La Cruz

Our philosophy is to step back from “I’m an iOS designer. I’m an Android designer” and instead advocate for experience designers that understand the possibilities and constraints of each platform.

Accelerating Development with Kotlin Multiplatform

Accelerating Development with Kotlin Multiplatform

When leading a team of iOS and Android developers and creating the same application for both platforms, you are bound to face one (or all) of these issues:

1. PRODUCT: Tech debt and architecture issues are slowing development
Your team is having difficulty adding new features because too many parts of your codebase are tangled and interconnected. As a result, new bugs emerge whenever you add new features or fix existing bugs. Your team is constantly putting out fires when they could be innovating on the product.

2. PEOPLE: Your iOS and Android teams are siloed and lack collaboration
Android and iOS engineers should be able to deliver on both platforms. However, modern teams often lack a structure for leveling up engineers to deliver on both platforms. Furthermore, with little or no collaboration, this makes it particularly difficult to achieve feature parity between the two apps. It’s just too labor-intensive and requires too much management time.

3. PROCESS: Your engineering approach could be better defined
It could be that your iOS and Android engineers work at different speeds, making it tough to keep feature releases in sync. At the same time, independent backlogs can make some things slip between the cracks. And if some features are deliberately delivered on one platform before the other, it’s more difficult to predict when the second will be available because the code isn’t being shared. In effect, separate apps and separate teams result in divergent apps and user experiences.

 

 

The cause of these setbacks across people, product and process is a lack of common ground between developers and too much dependency and coupling with each platform. The solution, then, is to converge these development efforts and divorce it from the platforms.

Code sharing, specifically with a native framework like Kotlin Multiplatform, encourages better architecture by pushing the developer to decouple the view and approach the logic from a more modular perspective. By isolating the presentation layer from the business logic layer, you not only streamline the architecture, but also simplify bug testing, maintenance, and upgrades. All these gains come just from moving towards a Multiplatform friendly architecture, before even addressing the obvious benefit of only having to write the code once for both platforms.

 

(diagrams by Sam Hill, designed by Nelmer De La Cruz)

 

Compared to alternative multiplatform solutions like React Native or Flutter, KMP focuses on maximizing shared business logic. We believe this provides an advantage over the loathed “cross-platform” model by providing consistent platform experiences for users while sharing as much code as possible. For a deeper dive into why we prefer KMP over alternatives, you can view our webinar here.

 

How to get started

So where do you start with Kotlin Multiplatform (KMP) — In a word, small.

 

PRODUCT: Start small — and avoid big risks

Start by isolating a single layer or component or feature. For example, you can isolate the persistence layer, in effect creating a single database implementation for both platforms.

Isolating the persistence layer enables it to function for the entire app across both platforms. In other words, every time the app calls the database, it behaves the same; it’s not platform-specific. Rather than using CoreData for iOS or Room for Android, you can use a single implementation of SQLDelight for both.

As you start isolating layers such as persistence and improving the architecture in KMP it becomes easier to start refactoring other layers as well. For example, using KMP, a networking component can move from AlamoFire on iOS and likewise from Retrofit on Android to a shared layer, perhaps using KTOR.

 

PEOPLE: Create platform-agnostic teams

With KMP, your development teams no longer have to be siloed. By expanding the common ground and simplifying platform code, you gain an opportunity to easily level up your platform engineers — both iOS and Android — to become mobile engineers. A few low-risk ways to do this?

– Introduce flex time for Android engineers to learn iOS, and vice-versa.

– Insist the same platform-specific developer tackle the same user story on both platforms. (This is understandably a slower process but it has higher long-term ROI.)

– Perform shared code reviews. (For example, have an Android developer write a pull request, and get an iOS developer to review it.)

– As tasks start becoming more multiplatform, code reviews start giving developers opportunities to see complete stories and draw parallels between platforms

 

PROCESS: Promote D.R.Y. (Don’t. Repeat. Yourself)

Creating a platform-agnostic environment extends beyond just development. It’s equally important to consolidate the processes that drive development. Tracking a multiplatform feature in a single place makes it simple to maintain platform alignment. Having all of you multiplatform developers participating in the same planning processes improves communication. Consolidated defect tracking makes sure bugs don’t fall through the cracks on a platform.

 

 

So, if you are looking for opportunities to accelerate and optimize development, KMP is a great way to begin streamlining and future-proofing your productpeople, and process:

– Product: KMP focuses on sharing code at the business logic layer (where most architecture issues occur) and enables you to address the issue in a piecemeal fashion — no big decisions. You start small at your own pace and see the results before continuing.

– People: Using KMP, your engineers will be better prepared for the future, increasing the value of your department to the wider organization because they can deliver on multiple platforms.

– Process: With KMP at the center, you introduce better engineering processes that promote code sharing and multiplatform development.

If you’re interested in learning how KMP can accelerate mobile innovation at your organization, please contact us.

Touchlab & Square Collaborating on Kotlin Multiplatform

Touchlab & Square Collaborating on Kotlin Multiplatform

My professional career started in college with Java 1.0. I started working during the bright Write-Once-Run-Anywhere heyday. We were finally going to get one platform!

Well, we know how that went. Java failed as a consumer UI platform. However, as a vehicle of portable logic, Java has been one of the biggest success stories in computers.

Thus one of my favorite quotes:

Shared UI is a history of pain and failure. Shared logic is the history of computers.

-Kevin Galligan (me)

I have been fixated on this for the last few years, because the need is obvious, as seems the opportunity. Native mobile, Android and iOS, are almost identical under the UI. They are architecturally homogenous. The web, although somewhat different, still needs mobile-friendly logic, and as WebAssembly matures, will look increasingly like native mobile at an architectural level.

Kotlin Multiplatform is a great entry into the pool of options for shared logic. It natively interops with the host platform, allowing optional code sharing. The tools are being built by JetBrains, so as the ecosystem matures, we can expect a great developer experience. Kotlin is also very popular with developers, so over the long term, Kotlin Multiplatform adoption is pretty much assured.

I believe in its future enough to move my role at Touchlab to be almost entirely Kotlin Multiplatform R&D. That means I code and speak about open source and Kotlin Multiplatform. As a business, we’ve pivoted Touchlab to be the Kotlin MP shop. We are of course still native mobile product experts, but we are also looking forward to helping clients leverage a shared, mobile-oriented architecture as the future of product development.

Square’s Jesse Wilson recently announced his team’s commitment to Kotlin Multiplatform. We are super excited to get to work with them on improving the developer experience and catalyzing the KMP ecosystem. It would not be an exaggeration to say that this team, and Square more broadly, is responsible for much of what the Android community considers best practice, if not the actual libraries themselves.

To be successful for native mobile, Kotlin Native needs to be something that Swift developers feel is productive and at least somewhat native to their modern language and environment. I think also selling iOS developers on Kotlin as a language and platform is important. This will largely be our focus for the near future.

Will it work out? We’ll see. In as much as it’s possible to make Kotlin native to iOS, I think we have one of the best possible teams to help us find out. I am very much looking forward to the challenge.

 

Learning More about Kotlin Multiplatform 

If you want to learn more about Kotlin Multiplatform here are a couple resources:

– Webinar for evaluating multiplatform development frameworks

– Sign up for our Kotlin Multiplatform newsletter

– Register for a future webinar on Kotlin Multiplatform for iOS Developers

Engineering Manager Framework: How to Evaluate Mobile Multiplatform Solutions

Engineering Manager Framework: How to Evaluate Mobile Multiplatform Solutions

The following text is transcribed from our Kotlin Multiplatform webinar. There is a video at the bottom of the blog post if you would rather listen to the segment. If you find this segment interesting, you can register for the full webinar recording and slides here

 

Slide 1

This diagram. Here’s where we find out what Native really means, and, even simplified, there’s a lot going on here.

Definitions

This input category is how the app developer writes the app. A Native Language isa language officially supported by the platform. Swift and Objc on iOS, Kotlin and Java on Android, HTML/CSS/Javascript on Web. An Other Language is a language like JavaScript on mobile, or ClojureScript on the Web. It also includes WYSIWYG visual programming interfaces that some no-code multiplatform solutions use.

The Process category is what the build chain does to the input in order to create an output. I mentioned Cross-Compilation and Trans-Compilation earlier.

But to clarify both of these, cross-compilation here is when a high level language is compiled directly to the native code for each various platforms before outputting the final product. This is called Ahead of Time compilation or AOT for short.

Trans-compilation here is when a a high level language is compiled to a another high level language which can then be fed back as input to another process, usually to a language native to the platform that can then go through the native build-chain.

Runtime here includes things external to the platform that implements portions of an execution model needed to execute the app like virtual machines, interpreters, and necessary libraries.

The Outputs category determines the type of app generated. Native Code is the low level code executed natively by the platform. Native code generates Native apps. A Native Container bridges web technologies with platform specific technologies by running web code in a webview on the native platform. A native container plus web views generates Hybrid apps. As mentioned before, a Native Language needs to be processed again to become a mobile app. But, it could also create a Web app if the output language is JavaScript or Wasm.

Once I put this together, I searched through documentation looking for how different tools worked and fit them into this model. I’m going to talk specifically about Ionic because it is a Hybrid solution, but more importantly, I’ll talk about React Native, Xamarin, and Flutter because they are so popular and, of course, I’ll talk about Kotlin Multiplatform because that’s why we’re all here. One last thing before we move on. Notice how this starts to explain some of the negative feelings we have about cross-platform solutions. For any solution, If we need to code in a new language, it will slow developers down. And, If there is an interpreter or VM between code being asked to run and code being executed, it’s going to slow the app down. And for hybrid solutions, a webview is fairly heavyweight and will slow things down even more

 

Slide 2

Ionic is a popular Hybrid app development tool built on Apache Cordova. You write your app in standard web technologies; the runtime includes widget libraries and native platform interop libraries, then, everything is wrapped in a native container and you get a hybrid app. Now, the web and mobile are different. On mobile you need to handle things like the offline experience, the application lifecycle and back button expectations. Hybrid solutions promise to make things easy, but you actually need to work really hard to make a hybrid app meet native expectations. 

 

Slide 3

React Native takes something that worked really well on web (that is, react) and makes it work on mobile better than hybrid apps. You develop mainly in Javascript and the runtime provides native or native-like widgets along with tighter interop with the underlying platform. Native code is output at runtime by the JavaScriptCore interpreter which allows the app to be categorized as Native. The differences between web and mobile are still issues to consider, and it’s easier to meet native expectations with React native, but it’s still difficult. For example, one of the problems mentioned by both Airbnb and Udacity is the 3 platform issue: to make their React Native apps more native, they had to deal with the javascript bridge and code independently for Android and iOS. This was more of a pinpoint than expected and they needed to do it more often than expected

 

Slide 4

Xamarin was one of the first to focus on sharing business logic with native code across platforms. It was quite a bit later in Xamarin’s life that they introduced Xamarin.Forms to share UI as well. You write your code in C#, and it gets processed to include the .NET runtimes. On iOS, it is all compiled ahead of time because iOS doesn’t allow 3rd party execution engines on Android. The Mono VM is included in the distribution so it can just-in-time compile native code at runtime. AOT is generally faster than JIT and benchmarks do show Xamarin.Android is significantly slower than Xamarin.iOS

 

Slide 5

The Flutter solution is yet more native because it AOT compiles on both Android and iOS. You write your app in the Dart language and, for dev builds, the Dart VM will JIT compile, but for production builds it will AOT compile all the necessary run-time libraries for widget rendering and business logic directly to native code. 

 

Slide 6

Kotlin Multiplatform is the most native solution yet. It is first-class for developing Android apps. Kotlin is already the best for this and fully supported by Google. Flutter is not first-class for developing Android apps until Google puts a lot more money into it and commits to it because they will need to sustain both the Material Widget library on Flutter and the standard Android widget library. Neither Xamarin nor ReactNative will ever be first-class for developing Android apps. It AOT compiles on iOS to a standard Objective-C framework which is already first-class on iOS and, even though Swift is becoming more popular, Objective-C frameworks are still prevelant. ReactNative is difficult to use in existing apps. Xamarin is impossible to use with natively developed apps. Flutter is working on it.

And that’s a huge difference: Kotlin Multiplatform is about optionally and easily sharing code. ReactNative, Xamarin, and Flutter are foreign ecosystem with a disconcerting amount of vendor lock-in. Kotlin Native also outputs to JavaScript or Wasm for sharing code with web. It’s more difficult than it should be to share React for web and ReactNative, but there is a way. Xamarin isn’t officially supporting web output yet, but people are trying. This model is quite good and this is how most people approach the definition of native, even if they haven’t thought about it as deeply as this. Often it is simplified to just the final App Types, with Web being on one end of a spectrum, Native being on the other, and hybrid filling out the in between. 

 

Recording: Webinar Segment

 

The video is from our Kotlin Multiplatform webinar. If you find this segment interesting, you can register for the full webinar recording and slides here

Making Kotlin Multiplatform a Native Experience for iOS Developers

Making Kotlin Multiplatform a Native Experience for iOS Developers

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.

Cross-Platform? We Don’t Say That Around Here Anymore.

Cross-Platform? We Don’t Say That Around Here Anymore.

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.