In this article, we’ll share the details of:

• How we came to the conclusion that we should invest in shared code
• Different industry approaches to shared code and their limitations
• Lessons we learned from our first attempt at shared code with JavaScript
• Why we decided to rewrite our shared code in Kotlin Multiplatform

Like many startups, Quizlet began as a product for a single platform: the web. Our core product offering was essentially user-generated digital flashcards, and was originally created to master vocabulary.

In order to “assess” a user’s mastery over a specific element, we would simply pick at random from the list a user was studying, ask them to type in the answer, and perform a string equality check between the user’s submission and what the database said the correct answer was. If we were feeling generous, we might ignore case or punctuation.

These were simple times.

As the years progressed, word of Quizlet spread from student to student, teacher to teacher. We were being used by:

• tens of millions of users
• who were creating millions of sets of study material
• which spanned thousands of different subjects
• with demand to be able to study things across several different modalities

Things were starting to get complicated!

Quizlet’s Secret Sauce 🍝

To power the unique use cases for our rapidly growing userbase, we had to go beyond simply querying a database, throwing things into a UI, picking a random element, and using String comparisons to assess correctness.

Quizlet needed to be smarter.

We began writing extremely specialized, domain-specific logic to help our users learn more effectively. Some examples of this kind of business logic include:

• standardized analytics events to help track learning outcomes
• a context-dependent grading rule engine to go beyond simple string comparisons
• modeling the user’s brain to help them retain information better

In visual terms, our website went from this:

to this:

Each of these pieces of code are tied to Quizlet’s mission to make education better and more accessible. Each of these components also requires a deep, domain-specific understanding of our specific product and market, well beyond what it takes to write a generic web application.

This category of code is what we will refer to as a business’s “Secret Sauce.”

The Secret Sauce elevates an app from a simple view into a database to a product that delivers delightful experiences and results. The Secret Sauce is directly responsible for both empowering users, and outperforming competitors.

While it’s easy to infer that continued investments in the Secret Sauce have outsized impacts on a product, Quizlet was reaching a phase where that was easier said than done.

The web team had years to implement the fundamentals of the website before finding the need to dive deep into the Secret Sauce. But our fledgling mobile teams were still trying to reach parity on even the most basic features.

It’s hard enough to write niche, complicated, domain-specific business logic and get it right once. Writing it precisely the same on three platforms, where two of them were starting from scratch, and also had to deal with persistence and networking concerns?

This was proving to be a nightmare.

If we wanted to continue to make Quizlet magical, we had to address this problem head-on.

But how?

Stop? 🛑

One option was to declare that parity across clients is impossible with this category of features.

The most literal interpretation of this would mean that we simply wouldn’t support advanced features on our clients. We could just stop rewriting this fancy logic on non-web platforms and cut our losses.

The more likely situation would have been that we moved to an API-side implementation of our secret sauce instead of performing those operations on-device.

For many businesses, requiring internet connectivity for core product features might be a very reasonable requirement! Quizlet however has a particularly strong affinity for mobile users with limited Internet access.

Younger users and learners in developing countries tend to use mobile devices more than desktop computers. These same users also tend to have less reliable access to the Internet, either due to data caps or connectivity issues.

Furthermore, the components of Quizlet’s secret sauce that we would need to move behind the API are all extremely central to the user experience.

If we

• only had to call out to the server once per session,
• could do so in the background without blocking the user from proceeding,
• could cache the result, and also
• gracefully fall back if the server could not be reached…

then maybe waiting a second or two for a response might be fine.

However, our users rely on our Secret Sauce every few seconds to respond to user input during core studying flows. Taking even a second per request over a slow connection would result in an unacceptable user experience. As a result, this wasn’t a trade-off we were able to justify.

Slow Down? 🚧

Another option at our disposal was to slow down the pace at which we were writing advanced features that push the boundaries in learning.

This would give our mobile teams the breathing room to write an implementation of our Secret Sauce for each platform. In this world, we may have also been able to write test cases in some declarative way that all three platforms could validate against.

While taking a breather is always an option, maintaining a high velocity of feature development is what allowed Quizlet to get to where we are today. We understandably didn’t want to feature-freeze our product.

Double Down!

The final option was to invest heavily in our ability to ship such features across platforms and double down on our Secret Sauce. For some companies, this might just mean hiring a ton of Android and iOS engineers to rewrite the secret sauce onto their platforms.

The approach that caught our eye however, was investing in our ability to write domain-specific code once, and share it across platforms.

Cross-platform shared code is far from a novel idea that we came up with at Quizlet. Several other companies have attempted it before us, in many different ways, with varying degrees of success.

Several other companies will do it after us and hopefully learn from our experiences.

Approaches to Shared Code in Industry

Here’s a very, very brief summary of approaches, technologies, and learnings on shared code from various companies.

Share All the Things!

Promise: Write your entire app once and run it everywhere

Industry Examples: React Native at Airbnb, Pinterest, Nextdoor

Realities

• Heavy reliance on bridging infrastructure
• Difficult to seamlessly integrate with existing native apps
• Apps may have performance issues due to differences in threading models
• UI can feel non-native
• Less mature frameworks/libraries than native code
• Difficult to integrate deeply with the OS when you need to do so

Unfortunately, many of the large companies that were pioneering React Native ended up discontinuing their use of it, for both organizational and technical reasons.

Every company that I know of that has tried this hybrid approach has walked it back months later. . . . The companies that seem successful with React Native seem to be the ones that have their entire app in RN and started out the app that way. . . . We’re still in the process of winding down RN here at Nextdoor. — Vivek Karuturi (Nextdoor)

Share Persistence and Networking Things!

Many issues from the previous approach stem from trying to share UI implementation, and from using JavaScript in performance-sensitive environments.

A few companies have tried to side-step these issue by sharing non-UI code. This code may rely on persistence and networking, and is typically written in highly performant languages such as C++.

Promise: Have a native UI and write non-UI code only once

Industry Examples: C++ at Dropbox, Slack, SafetyCulture

Realities:

• Issues with hiring/retention due to niche/custom tooling and languages
• Persistence and networking requires strong concurrency support
• Potential performance overhead with JNI on Android
• Much more difficult to share code with frontend web clients
• Loss of types when crossing the module boundary
• Some functionality simply works differently on different platforms

An industry example of this line of thinking is Dropbox. They wrote shared code for features such as syncing the camera roll on mobile devices, which introduces a dependency on networking and storage access. Dropbox Engineering recently posted about their experiences with shared C++ and announced that they stopped using it.

Although writing code once sounds like a great bargain, the associated overhead . . . outweigh[s] the benefits (which turned out to be smaller than expected anyway). In the end we no longer share mobile code via C++ . . . and instead write code in the platform native languages. —Eyal Guthmann (Dropbox)

Slack also followed up with a similar post, where they announced that they no longer use shared C++. Instead, they have switched gears to invest in engineering processes to maintain consistency across clients.

While we are no longer building a shared library, Slack still needs to maintain consistency and reduce duplication of effort, while developing separate implementations of client infrastructure. — Tracy Stampfli (Slack)

Share the Secret Sauce 🍝?

Common threads with the previously described approaches were the reliance on cross-platform abstractions for UI, persistence, networking, and/or serialization.

These concepts are hard to generalize across multiple platforms. As a result, we posit that frameworks attempting to do so tend to either:

• oversimplify to the point of having to bypass the framework to accomplish key tasks, or
• overcomplicate to the point of being too much of a hassle to work with in a productive manner

It would undeniably be nice if we could write our entire codebase once and share it everywhere. However, any given engineer at Quizlet already knows how to deal with UI, persistence, and networking concepts on their respective platforms.

Knowing ins-and-outs of German grammar rules to maintain grading logic, or keeping up with cognitive science research to model a user’s ability to remember information are much more difficult tasks.

Unlike companies like Airbnb, we had to implement our secret sauce on-device, so we had more pressing demands than iterating quickly on UI.

Unlike companies like Dropbox or Slack, our secret sauce doesn’t rely on the fine-grained details of network or disk I/O.

At Quizlet, we had a clear sweet spot at the intersection of our Secret Sauce and the areas where shared code has minimal complications.

So how did we do it?

Attempt 1: Shared JavaScript

Our first attempt to share code was an attempt to reuse what we already had.

The Quizlet Secret Sauce was originally written in JavaScript to target our web client. The challenge was getting it to run on mobile.

With a bit of initial setup, we were able to clean up the existing web code along our class boundaries and export a suite of small libraries. Each library was responsible for a distinct portion of our Secret Sauce business logic.

We could then bundle these files into our mobile apps and run them. The end-result was to read each library file into a String in-memory and pass it into a JavaScript runtime.

In order to interact with this code, we would marshal “real” iOS or Android classes into JS-friendly versions, and build a string that ran a given function from the JS runtime. We would then marshal the output strings back to “real” classes.

This was relatively straightforward to throw together on iOS using an official Apple framework called JavaScriptCore. JavaScriptCore powers Safari on iOS, is maintained by Apple, and behaves consistently across devices.

Initially, we attempted the same approach on Android using the official WebView::evaluateJavascript API. With this approach, we ran into several issues with performance, stability, and variance across manufacturer implementations. In a blog post from 2016, we detail how we evaluated several external third-party JavaScript engines before deciding on the J2V8 library for Android.

Far from Problem-Free

Our experiences sharing JavaScript on native mobile were shaky.

While web browsers are of course tailor-made to run JavaScript, relying on JavaScriptCore/J2V8 on iOS/Android raised significant issues.

Relying on disk I/O to load the initial JS files, building and retaining a reference to an entire JavaScript context, and then having to marshal “real” objects to/from JavaScript in order to interact with the code resulted in huge performance issues and memory leaks.

Unlike actual native code, interacting with untyped objects that are passed to/from JavaScript contexts was disastrously error-prone, without any compile-time safety.

Since none of the shared code was being run in a first-class mobile runtime, debuggability was also an issue once crashes inevitably occurred.

On Android, the J2V8 library caused our APK size to almost double.

And this is all before even mentioning the almost comical disdain for JavaScript among mobile developers 😱.

All-told, these issues resulted in an ecosystem where frontend web developers might have felt comfortable writing shared code, but mobile developers certainly did not feel comfortable consuming it.

But It Worked

Problems aside, sharing our Secret Sauce through JavaScript worked. For years!

As much fun as people have hating on JavaScript, just getting to this point was an enormous win for Quizlet.

We were able to write our most critical business logic in one place, ship it across multiple platforms, and unblock our resource-constrained native mobile teams. Most importantly, we were able to do this without committing to writing our entire client with the same framework.

Without shared code, we would not have been able to get our award-winning Android and iOS clients to where they are today.

Lessons Learned

Through our experiences with Shared JavaScript, we learned several lessons.

Clean interfaces are crucial.

Writing code with clear interface boundaries made it much easier to extract later. By isolating our vital business logic from regular application code, we were able to share this logic across applications!

Aggressively validate inputs along the public API.

It’s easy for misunderstandings about the meanings of parameters to arise in a complex module. This is doubly true when the module is used by many people who may have never talked directly to each other. Aggressively validating for unexpected input, especially in a loosely-typed language like JavaScript, helps minimize issues due to miscommunication or under-documentation.

Practice Test-Driven Development.

Test Driven Development (TDD) pays extra dividends with shared code. TDD is nearly always a great way to build software, but it is especially well-suited for shared modules with little dependence on external state.

Particularly with shared code, investing in TDD:

• Minimizes time spent debugging the final artifact within a host client, which tends to be more difficult than debugging purely native code.
• Minimizes the number of times we have to have to recompile/repackage shared code for inclusion into a client due to implementation errors. This multi-step processes can be awkward and takes more time than working entirely in a native environment.
• Gives us extra confidence in the shared code we write, preventing issues that have ripple effects across multiple host apps.

Complex state machines and rule engines are ideal candidates.

Compared to user interfaces, persistence, or networking, state machines and rule engines are well-suited for shared code. This isn’t to say networking and persistence are bad candidates for shared code: they just have additional complications to work around.

By focusing our shared code efforts on code based around state management and control flow, we saved our engineering team countless person-hours with minimal time spent on cross-platform threading or concurrency concerns.

Enter Kotlin Multiplatform

Kotlin is a programming language created by JetBrains. It was designed to run in the JVM and has excellent interoperability with Java. Once it took off within the Android development community, it also received backing from Google, through the Kotlin Foundation.

It’s only been getting more popular ever since!

Kotlin Multiplatform was announced at KotlinConf 2017. The basic promise of Kotlin Multiplatform was to bring the same magic of Kotlin’s excellent JVM interop to other runtime targets and platforms.

By building out separate compiler backends for different targets, Kotlin Multiplatform compiles platform-agnostic Kotlin code (aka “Common” code) into many different artifacts.

One of the core features of Kotlin Multiplatform is the ability to write platform-specific declarations. This allows Kotlin Common code to define a class or function as expected, and then continue to use it within Common code.

// Common
expect fun platformName(): String

fun getGreeting(): String {
    return "Kotlin is running on ${platformName()}!"
}

Each platform-specific sourceset is then required to provide an actual implementation for every expected declaration. The beauty here is that platform-specific sourcesets are not restricted to Kotlin Common. Instead, they are free to use every API available to that platform!

// Android
actual fun platformName(): String = "Android"

// iOS
actual fun platformName(): String {
    return UIDevice.currentDevice.systemName() + " " +
            UIDevice.currentDevice.systemVersion
}

// JS
actual fun platformName(): String {
    return Navigator.userAgent
}

Though it is excellent to see that Kotlin Multiplatform has well-supported networking, persistence, and serialization libraries, none of these were even necessary to support Quizlet’s shared code.

What caught our attention was how Kotlin Multiplatform’s unique approach addresses many of the issues we had with sharing JavaScript across platforms.

Namely:

• performance,
• error-proneness, and
• developer satisfaction.

By generating actual Objective-C Frameworks, JavaScript files, and Java bytecode, Kotlin Multiplatform promises the ability to write code in Kotlin and have it run as a first-class citizen on each platform.

This approach eliminates the most problematic areas of our Shared JavaScript approach: the bridge layer and external runtime requirement. While other technologies (such as shared C++, Rust, or Go) might have foregone the external runtime requirement, the they still rely on bridging technologies.

As mentioned earlier, the shared code interop area traditionally relies on manual type declarations, loss of type-safety, and a considerable performance hit when marshaling between types on mobile clients. Kotlin Multiplatform on the other hand, generates type-safe/null-safe code for our mobile clients. Our Android client can treat Kotlin Multiplatform code the same way it treats all Kotlin code. Our iOS client can safely create instances of Kotlin classes as if they were written in Objective-C.

Furthermore, Kotlin is a modern language, with established tooling, and great IDE support: It is after all, designed by an IDE company!

Quizlet’s Android, iOS, and backend engineers are more eager to write and maintain code written in Kotlin rather than JavaScript. After playing around with the interactive “Kotlin by Example” section on the Kotlin website, even our frontend web engineers found themselves impressed by Kotlin.

Kotlin Multiplatform addresses all of our pain points with Shared JavaScript on mobile clients. In early 2019, Quizlet migrated all of our shared code over to Kotlin Multiplatform, and we are using it in production to serve over 50 million monthly active users.

Was the process perfect and painless? Of course not! Some issues we had to navigate include:

• Increasing Kotlin knowledge across our engineering organization
• Developing workflows to publish, consume, and debug iOS and Web artifacts
• Not having Typescript definitions for JS clients (although JetBrains is working on this!)
• Navigating differences in Kotlin types on JavaScript and iOS when validating inputs

But was it worth it? Yes it was!

In the future, we’ll continue to share more detailed benchmarks and specifics about our experience migrating our shared libraries from JavaScript to Kotlin Multiplatform.

Keep an eye out for future posts!

Learn how Quizlet uses Kotlin Multiplatform to build iOS, Android, and web learning experiences for over 50 million users per month.

By pinpointing the best areas of our codebase to share (and skipping over many others), Quizlet was able to use Kotlin Multiplatform to share the “secret sauce” of our product.

We did this without forcing our Android, iOS, and Web clients to follow a rigid, predetermined architecture. You’ll hear Quizlet’s journey getting Kotlin Multiplatform into production, how it compares to other approaches of sharing code, and (most importantly) lessons about shared code that we learned along the way.

Learn how Quizlet uses Kotlin Multiplatform to build iOS, Android, and web learning experiences for over 50 million users per month.

By pinpointing the best areas of our codebase to share (and skipping over many others), Quizlet was able to use Kotlin Multiplatform to share the “secret sauce” of our product.

We did this without forcing our Android, iOS, and Web clients to follow a rigid, predetermined architecture. You’ll hear Quizlet’s journey getting Kotlin Multiplatform into production, how it compares to other approaches of sharing code, and (most importantly) lessons about shared code that we learned along the way.

Corresponding code for this blog post is available on GitHub.

Background on Parcels

The Android OS uses Parcels as a high-performance method to communicate data. The Android-only Parcelable interface is used to denote classes that can easily be serialized to/from a Parcel.

They’re most frequently used with Bundle objects to communicate across activities and intents, and to store state across configuration changes.

As a result, most Android developers should be familiar with the concept of Parcelable classes.

Using the @Parcelize Android Extensions Plugin

Hand-writing Parcelable implementations can be quite a pain. Thankfully, several tools exist to automagically generate the requisite code for you.

One such tool is the @Parcelize Kotlin compiler plugin. @Parcelize is included with Kotlin and can automatically generate Parcelable implementations for you! The following section is adapted from their documentation.

In the base case, the process is pleasantly simple:

import android.os.Parcelable
import kotlinx.android.parcel.Parcelize

@Parcelize
data class User(
  val userId: long,
  val userName: String
): Parcelable

Advanced Parceling Logic

The @Parcelize Android Extensions plugin has built-in support for several types, but also allows you to specify a custom parceling logic!

If your class requires advanced serialization logic, you can write it inside a companion class:

@Parcelize
data class User(
  val userId: long,
  val userName: String
): Parcelable {
  private companion object : Parceler<User> {
    override fun User.write(parcel: Parcel, flags: Int) {
      TODO("my custom write implementation")
    }

    override fun create(parcel: Parcel): User {
      TODO("my custom read implementation")
    }
  }
}

If you are working with an unsupported type that you can’t personally modify the code for, you can supply an external Parceler implementation for it.

For example, if we used the java.util.UUID class instead of a Long to create a unique identifier for our User, we could write an external Parceler for UUID as follows:

import java.util.UUID

import kotlinx.android.parcel.Parceler

object UUIDParceler : Parceler<UUID> {
  override fun create(parcel: Parcel): UUID {
    val mostSigBits = parcel.readLong()
    val leastSigBits = parcel.readLong()
    return UUID(mostSigBigs, leastSigBits)
  }

  override fun UUID.write(parcel: Parcel, flags: Int) {
    parcel.writeLong(mostSigBits)
    parcel.writeLong(leastSigBits)
  }
}

We can then apply our external Parceler using either the @TypeParceler or @WriteWith annotation:

import java.util.UUID

import kotlinx.android.parcel.*

// Class-local parceler
@Parcelize
@TypeParceler<UUID, UUIDParceler>()
data class User(
  val id: UUID
)

// Property-local parceler
@Parcelize
class User(
  @TypeParceler<UUID, UUIDParceler>()
  val id: UUID
)

// Type-local parceler
@Parcelize
class User(
  val id: @WriteWith<UUIDParceler>() UUID
)

If you take a peek at the source code for the Parcelize Android Extension, you will find a few other annotations such as @IgnoredOnParcel and @RawValue, however their usage isn’t officially documented so I won’t get into them here 😉

Enter Kotlin Multiplatform

Generating Parcelable implementations using @Parcelize works great when you’re operating in the Android world. However, if you are working in a Kotlin Multiplatform Project, you will find that things aren’t quite so simple!

If you try to paste those earlier code samples into the common sourceset in a Kotlin Multiplatform Project, you’ll quickly find that you can’t import Parcelable or @Parcelize, @TypeParceler or @WriteWith!

If you take a step back however, this makes sense. The concept of Parcelable objects is Android-specific. Parcel-related classes simply don’t exist in non-Android environments.

But what do we do if we use a Kotlin Multiplatform library, and want to store some of those classes in an Android Bundle?

We could manyally declare external Parcelers for every class. We’d write them by hand, and then sprinkle @TypeParceler or @WriteWith all over our Android codebase.

Or, we can take advantage of Kotlin Multiplatform’s powerful platform-specific declarations to make things work for us!

Declaring expect Definitions

In order to use these annotations and the Parcelable interface in common code, we must declare common-code versions of them.

First, let’s start with the Parcelable interface:

package com.example.parcel

// Common Code
expect interface Parcelable

By declaring an empty expected interface in our common sourceset, we will be able to write classes that implement com.example.parcel.Parcelable.

Let’s continue by defining the expected @Parcelize annotation:

package com.example.parcel

// Common Code
@UseExperimental(ExperimentalMultiplatform::class)
@OptionalExpectation
@Target(AnnotationTarget.CLASS)
@Retention(AnnotationRetention.BINARY)
expect annotation class Parcelize()

If you’re extra-observant, you might have noticed something different here. We’re using the @OptionalExpectation annotation, after opting-in to the experimental multiplatform feature.

@OptionalExpectation can be added to annotation classes to denote that the class isn’t required to have an actual counterpart on every platform. If we use the annotation and compile for a platform where we don’t implement the annotation at all, the Kotlin compiler just pretends the annotation never existed!

If an optional annotation has no corresponding actual class on a platform, the annotation entries where it’s used are simply erased when compiling code on that platform.

This is the same mechanism that Kotlin Multiplatform uses to allow us to use built-in annotations like @JvmName and @JsName in Common code.

Now that we’ve declared our expected classes, we have to actually define them on our platforms.

Android-Land

Building a Real Android Library

Most default Kotlin Multiplatform templates write code for Android using the jvm target. In many cases, this is fine. However, in order to use the @Parcelize plugin, we will need to create an actual Android Library using the com.android.library Gradle plugin.

Take a peek at this commit on Github to see the full details, but below are some of the changes you may need to make:

Adding the com.android.library and kotlin-android-extensions plugins:

plugins {
  id 'com.android.library'
  id 'org.jetbrains.kotlin.multiplatform'
  id 'kotlin-android-extensions'
}

Adding an explicit android() target platform:

kotlin {
  jvm()
  android()
  js {
    nodejs {
    }
  }

  // Configuration...
}

Adding an android { } block where we point to our sourceSets to the code for the android() target platform and enable the @Parcelize plugin:

android {
  compileSdkVersion 28

  androidExtensions {
    experimental = true
  }

  defaultConfig {
    minSdkVersion 21
    testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
  }

  // Android Gradle Plugin expects sources to be in main, test, and androidTest
  // In order to keep our code structure consistent across platforms, we redefine
  // the sourceset directories here.
  sourceSets {
    // Main code is in androidMain
    main {
      manifest.srcFile 'src/androidMain/AndroidManifest.xml'
      java.srcDirs = ['src/androidMain/kotlin']
      res.srcDirs = ['src/androidMain/res']
    }

    // Unit test code is in androidTest (to parallel jvmTest, jsTest)
    test {
      java.srcDirs = ['src/androidTest/kotlin']
      res.srcDirs = ['src/androidTest/res']
    }

    // Android instrumentation test code is in androidInstrumentationTests
    androidTest {
      java.srcDirs = ['src/androidInstrumentationTest/kotlin']
      res.srcDirs = ['src/androidInstrumentationTest/res']
    }
  }
}

The Magic of actual typealiases

A powerful feature of Kotlin Multiplatform is that platform-specific declarations can be simple typealiases to existing classes.

This is great, because it allows us to point our expected interface and annotation to very real classes that we already have on Android!

package com.example.parcel

// Android Code
actual typealias Parcelable = android.os.Parcelable
actual typealias Parcelize = kotlinx.android.parcel.Parcelize

Every Other Platform

Thanks to the magic of the @OptionalExpectation annotation, we don’t need to declare actual implementations for @Parcelize on non-Android platforms.

Unfortunately, @OptionalExpectation only supports annotation classes. As a result, we do have to write an empty actual interface Parcelable for every platform:

package com.example.parcel

// Non-Android Code
actual interface Parcelable

Once we do this, we should be ready to roll!

Putting It All Together

We can now use our custom Parcelable and @Parcelize definitions in Common Code!

import com.example.parcel.*

// Common Code
@Parcelize
data class User(
  val userId: long,
  val userName: String
): Parcelable

In Android, we can take advantage of the class we defined in common code, and store it in a Bundle!

// Android Code
val user = User(1, "Android User")

val bundle = Bundle().apply {
  putParcelable(
    USER_BUNDLE_KEY,
    user
  )
}

val unparceled: User? = bundle.getParcelable(USER_BUNDLE_KEY)

assertEquals(user, unparceled) // Nice!

You might notice that we didn’t go into the details needed for @TypeParceler or @WriteWith.

While these classes certainly can be added to a Kotlin Multiplatform project in this manner, doing so requires creating expect/actual declarations for many more classes (for example, Parcel, kotlinx.android.parcel.Parceler), and their methods.

For this reason, these extra steps (if you need them) are left as an exercise for the reader 😉

Wrapping Up

The same principles used here can apply to many other platform-specific annotations, classes, and interfaces.

If you’ve got other cool ideas for how this technique could be used, drop me a tweet!

In this talk, you’ll learn the guiding principles behind Quizlet’s approach to shared code, regardless of which technologies you use.

We’ll begin by exploring the business need for shared code at Quizlet. You’ll learn about popular approaches to dealing with shared code across the industry, and we’ll share how we identified which areas of our codebase that were good candidates for sharing cross-platform, and which were best left for platform-specific code.

We’ll detail our initial foray into shared code using Javascript, and explain both its benefits and drawbacks.

We’ll then switch gears and explore Kotlin Multiplatform – Quizlet’s current technology of choice for shared code. We’ll share all the spicy details:

• How we evaluated Kotlin Multiplatform as a technology
• How writing and distributing Kotlin Multiplatform code works
• Our path to successfully migrating our shared codebase into this new paradigm
• The impacts of switching to Kotlin Multiplatform for both our developers and end-users (spoiler alert: better mobile developer experience, huge reductions to app size and crash rates on mobile platforms, and minimal overhead on web)

Hear the story of how we shipped Kotlin Multiplatform across Android, iOS, and the Web to power Quizlet’s learning experience for over 50 million users per month.

By pinpointing the best areas of our already mature codebase to share (and intentionally skipping over many others), Quizlet was able to use Kotlin Multiplatform to share the “secret sauce” of our product without shackling our Android, iOS, and Web clients to a predetermined architecture.

We drastically reduced the size of our Android app, achieved performance and stability wins across both iOS and Android, simplified our Web build process, and unlocked the ability for mobile and backend engineers to work confidently on this shared code – but we also faced several speed bumps along the way.

Learn how we overcame challenges such as platform-specific quirks of the Kotlin standard library, constantly evolving tooling, and many more to make the magic happen!

As described by the PCI Security Standards Council, early versions of the TLS security protocol are susceptible to widespread exploits that could expose potentially sensitive data. On June 30th, we upgraded Quizlet’s security to require TLS 1.2 or higher as part of our continued following of best-practice data security recommendations.

While our web client and iOS app were largely unaffected by this transition, we had to do a bit of work to make sure our Android app was up to the job.

This was due to a few reasons:

1. There is a lack of clarity surrounding TLS 1.2 support on older Android devices,
2. Device manufacturers have differing commitments to the official Android specs for shipping TLS 1.2 on their devices
3. Carriers and device manufacturers have differing commitments to providing software and security updates to their customers

There’s unfortunately no simple way to ensure all of our users are seamlessly able to use TLS 1.2 to access Quizlet, but we’ve tried our best to minimize disruption to our users as we made the transition.

In this post, I want to share how we went about doing it.

Installing TLS 1.2 Where Needed

We support Android 4.1–4.3 (API 16–18) with a long-term-support version of our app, and Android 4.4+ (API 19+) in our latest builds. Our goal was to minimize disruption for users in both of those builds, so our target was ensuring TLS 1.2 support for Android 4.1 and higher.

The first thing we realized was that despite documentation suggesting otherwise, not all devices on Android 4.1+ actually support TLS 1.2. Even though it is likely due to device manufacturers not fully following the official Android specs, we had to do what we could to ensure this would work for our users.

Luckily, Google Play Services provides a way to do this. The solution is to use ProviderInstaller from Google Play Services to try to update the device to support the latest and greatest security protocols.

We do this as follows:

For devices without Google Play services, we unfortunately don’t have an alternative way to patch the device’s security Provider to support TLS 1.2. For these users, we display a message so they know the app may not work properly for them.

In the Quizlet Android app, we call this in a background thread if our first API call fails with an SSLHandshakeException. Calling ProviderInstaller.installIfNeeded only after an SSLException allows us to support users with TLS 1.2 already installed with minimal disruption (i.e., if they have an old version of Google Play Services, or don’t have it installed at all). In your apps, it might make sense to handle this logic in a similar manner.

Calling ProviderInstaller.installIfNeeded only after an SSLException allows us to support users with TLS 1.2 already installed with minimal disruption

Alternatives to this approach include Google’s official suggestions: either blocking network transactions by calling installIfNeeded upon creation of all network-specific threads (it’s a no-op if the security Provider is already up-to-date, so the performance impact should be minimal), or using the asynchronous variant to start a call from the main thread.

Originally, we thought we were done after doing this step. However, after further testing, we noticed something peculiar. Many devices succeeded in updating the security Provider via installIfNeeded, but were still throwing SSLHandshakeExceptions when the server required TLS 1.2!

Forcing TLS 1.2 To Be Enabled

Our initial understanding of OkHttp’s HTTPS strategy was that it uses the highest-installed version of TLS, and it falls back to older protocols if newer ones are not installed. This is false.

OkHttp’s default behavior is to use an SSLSocketFactory to create SSLSockets with default parameters, and select from protocols that are enabled for a given SSLSocket. Here’s the kicker: The latest protocols installed on a device are not necessarily enabled on its default SSLSockets!

The latest protocols installed on a device are not necessarily enabled on its default SSLSockets!

The docs for SSLSocket on Android state that TLS 1.2 is only enabled as a default client protocol starting in Android 4.3. To make things more confusing, developers have found that certain Samsung devices on Android 4.4 don’t have it enabled either.

To fix this, we need to override OkHttp’s SSLSocketFactory to enable TLS 1.2 on all SSLSockets. We adapted the helper class from this Github issue, and cleaned it up a bit to make it more Kotlin-tastic. We cleared up deprecation warnings by explicitly passing in an X509TrustManager and made use of Kotlin’s extension functions to simplify some of the code, but the actual logic is largely the same.

The new-and-improved Tls12SocketFactory is a bit too long to embed, but here’s a link.

Now, we can simply call the enableTls12() extension function in our OkHttpClient.Builder chain in Dagger, and there we have it!

Or so we thought.

Forcing TLS 1.2 To Be Enabled, Take 2: Glide

It turns out this still wasn’t enough! Our regular-old API calls were working just fine, but all of our images were still failing to load through Glide due to even more SSLHandshakeExceptions.

By default, the Glide OkHttp3 integration uses a vanilla OkHttpClient to load images from URLs. This means it uses the regular SSLSocketFactory that does not forcefully enable TLS 1.2.

Lucky for us, this fix wasn’t too complicated for Glide. We set up our AppGlideModule to use our Tls12SocketFactory for its OkHttpClient as well:

If you use Glide or any other libraries that manage their own network calls, you should make sure that their SSLSockets are also configured to enable TLS 1.2.

If you use Glide or any other libraries that manage their own network calls, you should make sure that their SSLSockets are also configured to enable TLS 1.2.

Whew. Now we’re done!

In Summary

A device can be in one of several states with regards to supporting TLS 1.2:

1. Device does not have TLS 1.2 installed at all.
2. Device has TLS 1.2 installed, [but not enabled by default.](https://developer.android.com/reference/javax/net/ssl/SSLSocket#default-configuration-for-different-android-versions)
3. Device has TLS 1.2 installed and enabled by default.

It’s important to make sure you handle not only installing TLS 1.2 support (via ProviderInstaller) but also ensuring that it’s enabled for all of your network connections — even ones that are handled automagically by other libraries!

Such applications not only call for large-scale analytics, but also for real-time streaming support, smaller analytics at interactive speeds, data visualization, and cross-storage-system queries.

The importance and effectiveness of such a system has been demonstrated in a hospital application using data from an intensive care unit (ICU).

In my Master’s Thesis, I implemented and evaluated a cross-system Query Executor. I focused on cross-engine shuffle joins, taking into account the skew of the data distribution.

Download the paper