Building in Public | Choosing a programming language for the calculator library
In my last post, I decided to build the calculator before building the app. More precisely, I decided to build the calculation logic as a standalone library and give it a command-line interface. An iOS app, website, API, and AI-assistant integration could eventually become different ways of using that same library.
That settled the shape of the project, but it left one fairly important question unanswered: What language should I write the calculator in?
What the calculator needs
Before comparing languages, it helps to be clear about what I want from the calculator.
The calculation logic should not know anything about buttons, navigation, screens, or network requests. It should accept clearly defined inputs and return clearly defined results.
I also want it to be:
Thoroughly tested
Open source
Usable from a command-line tool
Importable into an iOS app
Importable into a macOS app
Importable into an Android app
Usable by a website
Capable of sitting behind a public API
Flexible enough to support platforms I have not thought about yet
The first interface will be the command-line tool. The second interface will probably be the public API (to be used by an MCP server). The third interface will probably be an iPhone app. Then an iPad app. Then maybe the macOS app. The exact order may change, and most of these are possibilities, not immediate requirements. Still, I would prefer not to choose a language that makes those possibilities unnecessarily difficult.
My first instinct was Swift
My first instinct was to write the calculator in Swift. Swift is the programming language I am most comfortable with because it's what I use every day at work, and it would make the library straightforward to use in native iOS and macOS applications.
That matters. I do not want to dismiss the value of choosing a familiar language simply because another option appears more flexible on paper. Familiarity would let me start quickly and spend more time thinking about the knitting problem itself.
Swift can also travel further than its association with Apple might suggest. It can run natively on several Linux distributions, compile to WebAssembly, and now has an official Swift SDK for Android.
In other words, choosing Swift would not necessarily confine the calculator to Apple devices.
But “technically possible” and “the most natural tool for the job” are not always the same thing.
What about Kotlin Multiplatform?
Kotlin Multiplatform is specifically designed for sharing logic across Android, iOS, desktop, web, and server applications. It allows the business logic to be shared without requiring every platform to use the same user interface.
Choosing Kotlin Multiplatform does not mean that I have to build a cross-platform interface. I could still create the iOS app using Swift and SwiftUI. The app would use the shared Kotlin library underneath, while its interface remained native to the platform.
The same source code could be compiled for other environments:
An Android app could use it as a Kotlin library.
An iOS or macOS app could receive it as an Apple framework.
A website could use a Kotlin/JavaScript or Kotlin/Wasm build.
A server could use the JVM version.
What to choose?
At this point, either language could work. The difference is not which platforms are technically possible, but how naturally the library would fit into each one.
With Swift, the iOS and macOS integrations would be straightforward. A command-line tool or server running on Linux would also be entirely reasonable. The extra friction would appear on Android and the web. Swift’s Android SDK is very new, and integrating Swift into a conventional Kotlin or Java app requires additional interoperability tooling. Using Swift in a website means compiling it to WebAssembly and connecting the resulting module to the website through JavaScript.
Kotlin Multiplatform moves some of that friction elsewhere. Using the library from an Apple app would be less direct than importing a Swift package: the shared code would be exposed as an Apple framework, and I would need to manage the boundary between Kotlin and Swift. I would also need to learn Kotlin and become familiar with Gradle and the Kotlin Multiplatform project structure.
That would once have weighed much more heavily against Kotlin. These days, however, I use AI assistants throughout my day-to-day development work, and that experience has made me far more willing to step into an unfamiliar language and IDE. An assistant can explain an unfamiliar project structure, help me interpret build errors, and translate concepts I already understand in Swift into Kotlin. I still need to understand the decisions and verify the code, but I no longer have to discover every new convention on my own.
If I were building only an iOS app, I would choose Swift without hesitation. But I am deliberately building the calculator as a library first, with the expectation that it may eventually have several different interfaces. Sharing business logic across platforms is the central purpose of Kotlin Multiplatform, rather than an additional capability built around its original ecosystem.
The calculator is also a relatively small and self-contained place to learn it. The knitting calculations can remain in shared Kotlin code, while future iOS and macOS interfaces can still be written natively in Swift and SwiftUI.
The decision
So, I am going to use Kotlin Multiplatform.
I am not choosing Kotlin because Swift cannot go where I need it to go. I am choosing it because multiplatform reuse is the starting point rather than an adaptation.
My next step is to create the Kotlin Multiplatform project, add the smallest useful calculation, and call it from the command line.
Comments