# Kodein Koders - Medium Kodein Koders Tech Blog - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Introducing Compose-ur-Pres DevFeed: [Introducing Compose-ur-Pres]() Original publisher: [Read original article]() Author: Salomon BRYS Published: 2024-06-25T11:35:42Z Content type: release Language: en Sources: [Kodein Koders - Medium]() Topics: [compose-for-desktop](), [Kotlin](), [multiplatform](), [Open Source](), [Documentation](), [Template](), [wasm]() Tags: [android](), [compose](), [compose-multiplatform](), [desktop](), [documentation](), [kotlin](), [kotlinconf](), [open-source](), [project](), [wasm]() ### AI overview This article introduces Compose-ur-Pres, or CuP, an open-source presentation tool written in Kotlin with Compose for Desktop. It lets developers create and animate presentation slides as composable application screens, with features including slide navigation, transitions, an overview, speaker tools, and experimental web export. ### Source excerpt A tool that allows you to write a presentation slide deck in Kotlin with Compose. https://medium.com/media/92b00e09e5e75db453796863708f60e6/href I've always been frustrated with regular presentation tools, such as Keynote, Powerpoint, or Google Slides. While I do not want to deny their quality, I simply do not believe these tools can implement everything that I have in mind. After all, as an application programmer, creating screens and animations is what I do. I have many ideas of how I want to present and animate my content, and I do not want to be constrained by a WYSIWYG editor. Since I program my screens, why not program my slides? When I first encountered Reveal.js, I thought "OK, that's what I want, but I want it in Kotlin". At that time, Compose multiplatform did not exist, so I wrote my first version with Kotlin-React. Then came Compose multiplatform and more specifically what was then known as Compose Web and is now named Compose HTML. So, of course, I rewrote the entire tool using that. I used it for several presentations (including my presentation at KotlinConf 23). At the same time Compose Desktop became stable and the new Compose Web with Wasm was introduced, my frustration with CSS (especially CSS animations) grew stronger. I wanted to position my content pixel by pixel, and frame by frame, just like Compose allowed me to. So I rewrote this presentation tool a third time, but this time for Compose desktop, and named it "Compose-ur-Pres", or "CuP" for short. A few weeks ago at Android Makers 24, I was thrilled to open source that tool. You can read its documentation, start creating your slides with a template project, and of course access its sources. The pitch of Compose-ur-Pres is very simple: write and animate your slides just like you would your application screens. Focus on your slide content, and CuP will take care of: Creating & managing the application window. Displaying your slides in order and animate transitions between them. Showing an overv ## iOS development with JetBrains Fleet DevFeed: [iOS development with JetBrains Fleet]() Original publisher: [Read original article]() Author: Romain Boisselle Published: 2023-11-26T19:17:05Z Content type: tutorial Language: en Sources: [Kodein Koders - Medium]() Topics: [jetbrains](), [ide](), [SwiftUI](), [iOS development](), [User interface design]() Tags: [appcode](), [how-to](), [ide](), [ios](), [ios-app-development](), [ios-development](), [jetbrains](), [jetbrains-toolbox](), [swift](), [swiftui](), [xcode]() ### AI overview A tutorial on using JetBrains Fleet for iOS development with SwiftUI. It explains how Fleet supports code navigation, refactoring, collaboration, and running iOS applications, while noting that Xcode remains necessary for tasks such as project configuration, signing, and dependency management. ### Source excerpt Farewell, AppCode; we've found a worthy replacement. This article is intended to demonstrate how to use JetBrains Fleet for the development of Swift/UI applications, including SwiftUI previews. For those who may not know about JetBrains, it is an amazing company that builds tools for developers, such as IntelliJ IDEA or Kotlin. To me, JetBrains has always provided tools that exceeded my developer expectations, even when those tools are considered "not stable." A year ago, JetBrains announced Fleet, a brand new distributed and polyglot IDE. While many people saw it as just another VSCode IDE, I knew it would become more than that. Bringing collaborative work for remote developers and providing multiple language support out-of-the-box is a real game-changer. And if you've already tried a JetBrains IDE, you know that they are serious about developer productivity! In the meantime, a year ago, they discontinued AppCode, an underrated IDE for working within the Apple ecosystem. AppCode was particularly helpful for developers who found it challenging to adjust to alternative IDE workflows, such as XCode. With Fleet, you will experience easy code navigation, refactoring, collaboration, and support for a wide range of languages and project types, including SwiftUI applications. Let's be honest, you won't completely escape from Xcode -- there are still essential tasks like project configuration, signing, and package dependency management that require its user interface. However, for the majority of your coding sessions, you'll find that you won't need it anymore. Edit and run your iOS app from Fleet Let's start by installing Fleet using the JetBrains Toolbox. This is the easiest way to manage and upgrade your JetBrains IDEs in one place. JetBrains Toolbox -- IDE version management Once Fleet installed, you can either use your own SwiftUI project or clone the following GitHub project created for this article's purpose. https://github.com/KodeinKoders/playground-fleet-swiftui Jet ## Moving forward with the Kodein Open Source Initiative DevFeed: [Moving forward with the Kodein Open Source Initiative]() Original publisher: [Read original article]() Author: Salomon BRYS Published: 2022-06-08T12:53:24Z Content type: opinion Language: en Sources: [Kodein Koders - Medium]() Topics: [Kotlin Multiplatform](), [Open Source](), [Development](), [Mobile](), [Library]() Tags: [announcement](), [application-development](), [dependency-injection](), [kodein](), [kotlin](), [kotlin-multiplatform](), [library](), [mobile](), [open-source]() ### AI overview Kodein Koders announces the sunset of Kodein-Framework and the creation of the Kodein Open Source Initiative, or KOSI. Its libraries will receive independent identities while continuing to be maintained and advanced, with organizational and project changes planned for the following weeks. ### Source excerpt Photo by Daniel Lerman on Unsplash Back in the very early days of Kotlin Multiplatform, when the KODEIN Dependency Injection library was the very first community library ever being ported to this new promising technology, I dreamt of an integrated suite of components that, together, offered mobile developers tools to quickly and easily develop multi-platform mobile applications. In essence, I wanted to create a framework providing DI, DB, Logging, MVI, and more, all integrated into a cohesive platform. However, as time went on, I realised that Open Source development is quite long and difficult (who knew, right?), especially when you're a team of two, and that you also need to work for clients, in order to, you know, eat. I also realised that I was promoting our work backwards. The message "This lib is part of a framework that does not really exist yet, but it is also its own independent library that you can totally use without any other of our libs" is actually very ambiguous. Furthermore, full fledged frameworks are nowadays a lot less attractive to developers. As application craftsmen & craftswomen, we want to own our architecture, and make choices that reflect our very own business needs, opinions, and experience. It's not because you are using the Kodein Dependency Injection container that using SQLDelight (instead of Kodein-DB) should feel a mistake, or vice-versa. I came to the realisation that when we advertise each library as part of a whole framework, we harm each individual library by preventing them to be evaluated only by their own merits. We (Romain and I, founders of Kodein Koders) decided that it is time to sunset the Kodein-Framework. This by no means signifies that we will stop working on our Open-Source libs, but simply that each library will be given its very own independent identity. We will be maintaining & advancing these libraries as the "Kodein Open Source Initiative", or KOSI for short. The biggest change that this decision will bring is th ## MocKMP : a Mocking processor for Kotlin/Multiplatform DevFeed: [MocKMP : a Mocking processor for Kotlin/Multiplatform]() Original publisher: [Read original article]() Author: Salomon BRYS Published: 2022-01-17T13:29:28Z Content type: tutorial Language: en Sources: [Kodein Koders - Medium]() Topics: [Kotlin Multiplatform](), [Mocking](), [Code](), [test](), [Gradle](), [Programming]() Tags: [gradle](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [ksp](), [mocking](), [multiplatform](), [test](), [tests]() ### AI overview This article introduces MocKMP, a mocking solution for Kotlin Multiplatform. It explains why JVM reflection-based mocking does not work for Kotlin/JS and Kotlin/Native, and describes using Kotlin Symbol Processing to generate mock implementations at compile time. MocKMP includes a runtime API, a symbol processor, test helpers, and a Gradle plugin. ### Source excerpt MocKMP : a Mocking processor for Kotlin/MultiplatformPhoto by Stefano Pollio on Unsplash Recently, when working with Deezer on a Kotlin/Multiplatform project, we came across multiple unit tests that were written in src/androidTest/kotlin, meaning that they were only run on Android. When investing why that choice was made, the answer became evident : there is no mocking system on Kotlin/Multiplatform, and Mockk only supports JVM & Android. Mocking with reflection The JVM reflection is an amazing powerful API, allowing libraries to instrument existing classes and create new implementations at run time. When you write : https://medium.com/media/28a2defcfc5197a7e44d270d4414acd1/href ...the mocking library : Creates a new implementation of the Repository type Sets the behaviour of the getUser method on this mock to return a fake User, whatever the id parameter. Furthermore, a JVM mocking framework is able to create "fake objects" on demand: https://medium.com/media/2e91c376131e77315f319705fd45e8b2/href All of that is done at run time, by instrumenting the JVM runtime, which is not possible with 2 of the 3 types of targets of Kotlin/Multiplatform (Kotlin/JS & Kotlin/Native). A Kotlin Symbol Processor Google KSP allows to inspect Kotlin code at compile time. In essence, it provides a reflection API available at compile time (rather than at run time). KSP also allows to generate Kotlin code according to the code being inspected. This is meta-programming: writing code to generate code according to code. With a Kotlin Symbol Processor, we can generate implementation of interfaces at compile time, and delegate the implementation of said implementations to a mocker delegate. Introducing MocKMP The MocKMP project consists of multiple moving parts that allow to easily generate and configure mocks: A runtime that provides the mocker API A Kotlin Symbol Processor that generates configurable mocks A test helper library to make the use of mocks as easy as possible A Gradle plugin to ma ## Why we need iOS developers on board with Kotlin/Multiplatform DevFeed: [Why we need iOS developers on board with Kotlin/Multiplatform]() Original publisher: [Read original article]() Author: Salomon BRYS Published: 2021-05-20T16:28:29Z Content type: opinion Language: en Sources: [Kodein Koders - Medium]() Topics: [Kotlin Multiplatform](), [multiplatform](), [iOS](), [Android](), [Swift](), [Android Studio](), [Xcode](), [React Native]() Tags: [android](), [android-studio](), [ios](), [kotlin](), [kotlin-multiplatform](), [multiplatform](), [react-native](), [xcode]() ### AI overview This opinion argues that Kotlin Multiplatform needs iOS developers because it shares business logic while preserving native Android and iOS application development. It emphasizes that platform-specific expertise remains important for features such as notifications, background work, permissions, battery optimization, configuration changes, and sensor data. The article also discusses concerns about investing in multiplatform technologies and contrasts Google's and Apple's incentives. ### Source excerpt Last week, we published the testimony of Robbie Hanson, whom we've been working with for several months on the Phoenix-KMM multiplatform application. We thank him again for his valuable feedback. In this post, I want to share my thoughts after reading his, and express my feelings about the state of Kotlin/Multiplatform for iOS developers. First of all, I want to reiterate that we believe that Kotlin/Multiplatform can only thrive with the support of iOS developers. Seeing Kotlin/Multiplatform as "just another React-Native", is a big mistake. In Kotlin/Multiplatform, Android apps are developed with official Android Kotlin APIs and compiled with Android Studio ; while iOS apps are developed with official iOS Swift APIs and compiled with XCode. Kotlin/Multiplatform focuses on what is truly common to these apps : their business. It does not try to provide a unified application model. This is important, because it means that you do need expertise in both Android and iOS native applications to create the best experience on each platform. It goes beyond navigation & UI: notifications, background work, permissions, battery optimization, configuration changes, sensor data retrieval, and more APIs, are exposed in very different ways on iOS and Android. If you want a quality iOS application, get an iOS expert. Kotlin/Multiplatform is not going to change that, and that's a very good thing. The first question we often get when presenting Kotlin/Multiplatform, and specifically from iOS developers is "How safe is it to invest in it?". After all, there's one tool to develop iOS apps that will never disappear : XCode. Our very short tech field history is littered with examples of amazing tech being dropped in a heartbeat. RoboVM was developing an amazing AoT compiler for the JVM to target iOS (a precursor of GraalVM), only to be bought by Microsoft and killed without so much as a warning or a migration strategy. If you worked with RoboVM, you bet on the wrong horse. Your loss. Robbie ## We asked an iOS developer his thoughts after working with Kotlin/Multiplatform Mobile DevFeed: [We asked an iOS developer his thoughts after working with Kotlin/Multiplatform Mobile]() Original publisher: [Read original article]() Author: Salomon BRYS Published: 2021-05-13T14:30:18Z Content type: opinion Language: en Sources: [Kodein Koders - Medium]() Topics: [Kotlin Multiplatform](), [Mobile](), [multiplatform](), [Kotlin](), [Android](), [iOS](), [App]() Tags: [android](), [business-logic](), [cross-platform](), [developer](), [ios](), [kotlin](), [kotlin-multiplatform](), [kotlin-multiplatform-mobile](), [mobile](), [multiplatform](), [swift](), [swiftui]() ### AI overview An iOS developer reflects on working with Kotlin Multiplatform Mobile while contributing to the Phoenix Bitcoin Lightning Wallet for iOS and Android. The article presents KMM as a way to share business logic while retaining native user interfaces. ### Source excerpt Photo by Mihai Moisa At Kodein Koders, we think that Kotlin Multiplatform Mobile will only rise with the help and support of iOS developers. As KMM only abstracts application backends, we need to have both platform communities on board to create great products. We were fortunate enough to work for several months with Robbie Hanson, a notorious iOS developer, on the new Phoenix Bitcoin Lightning Wallet KMM application for iOS and Android. We asked him to give us his feedback about the state of Kotlin/Multiplatform Mobile, and how it felt working with it. With his gracious permission, here goes: For mobile developers, the dream has always been to have a modern language for sharing code between iOS & Android. But for the last decade, the dream has remained just that. The available options were lacking. There's C++. I've been down that road before. When I worked with Verizon. It sucked. Hard. I wouldn't wish it on my enemies. And then there are the "let's just use a web framework" solutions. Which is a clearly a good idea -- to those who have never written a native mobile app in their life. Do you remember those horrible cross-platform Java apps from the 2000's (with user interfaces made with Swing) ? It's like that. Except now replace your user base with people who have never heard of AOL, and who grew up using the latest smartphones. Don't expect them to be kind to your crappy UI, and your non-existent animations. I was at WWDC when Apple announced Swift. And I remember hearing the other devs wax poetic about how "Swift is the new cross-platform language because it's open source. We will be able to write Android apps in Swift !!!" But I was skeptical. Why would Apple want to help you make apps for Android ? It goes against their business model. Well... Swift has been out for many years now. Does Apple provide Android support for Swift? Nope. Do they provide Windows support for Swift? Nope. What they support is server-side Swift. Because that's a completely different mark ## Deploy your internal libraries on Github DevFeed: [Deploy your internal libraries on Github]() Original publisher: [Read original article]() Author: Romain Boisselle Published: 2021-04-27T05:20:12Z Content type: tutorial Language: en Sources: [Kodein Koders - Medium]() Topics: [GitHub](), [Gradle](), [Maven Central]() Tags: [bintray](), [build](), [dependency](), [github](), [gradle](), [gradle-plugin](), [how-to](), [http](), [maven](), [maven-central](), [open-source](), [plugin](), [releases](), [repo](), [tutorial]() ### AI overview This tutorial explains how to publish internal libraries or early-access releases outside Maven Central by hosting Gradle plugin releases in a GitHub repository branch and serving them over HTTP. It also explains why the authors chose this approach instead of GitHub Packages, which requires authentication even for public packages. ### Source excerpt In a previous tutorial, I explain how to configure and deploy your libraries to Maven Central. But, there are some libraries that that do... Continue reading on Kodein Koders " ## Targeting Android in a Kotlin/Multiplatform Mobile library DevFeed: [Targeting Android in a Kotlin/Multiplatform Mobile library]() Original publisher: [Read original article]() Author: Salomon BRYS Published: 2021-04-26T14:32:30Z Content type: tutorial Language: en Sources: [Kodein Koders - Medium]() Topics: [Kotlin Multiplatform](), [Android](), [Android Gradle Plugin](), [Kotlin](), [Android Library](), [Gradle](), [Library](), [Mobile]() Tags: [android](), [android-gradle-plugin](), [build](), [gradle](), [how-to](), [kotlin](), [kotlin-multiplatform](), [kotlin-multiplatform-mobile](), [library](), [mobile](), [multiplatform](), [plugin]() ### AI overview This tutorial explains how to target Android APIs from a Kotlin Multiplatform Mobile library. It advises developers to distinguish Android APIs from JVM APIs, then outlines an official approach using the Android Gradle plugin and Kotlin's Android target, as well as a lighter but more restrictive alternative. The official approach publishes an AAR instead of a JAR and supports Android resources such as images, XML files, and JNI native libraries. ### Source excerpt https://medium.com/media/6c54678f49c79a047a73b582f72c478e/href So far, we've seen how to create a Kotlin/Multiplatform Mobile library, how to access iOS Swift APIs in it, and how to push it to Maven Central. We haven't discussed how to access Android APIs. Kotlin is the main Android programming language, so how difficult can it be ? Well, it turns out that the Android platform is not as simple as the JVM, so there are multiple strategies you can use to access Android APIs in your KMM libraries. Let's discuss them! First and foremost, you need to make sure that you actually need an Android API, and not a JVM API. You should not have your library target Android if the API you want to access is actually provided by the JVM. Most of the file access, date time, cryptography, and many more APIs are JVM APIs, and even if your library is supposed to be used especially on mobile targets, it is way simpler to target the JVM rather than adding the entire Android toolchain to your build. OK, so you're positive you need Android APIs? The way I see it, there are two ways you can add the Android APIs to the classpath of your library: There's the official way, which enables all Android capabilities to your library. There's the lighter way, a hack, really, which is more restrictive, but a lot simpler, which we'll discuss at the end of this video. The official way consists in adding the Android Gradle plugin to your build, as well as its corresponding Kotlin target & Android configuration. https://medium.com/media/b40d2cd887b34d8002fb3861463fd19b/href Adding the com.android.library plugins and defining an Android target, rather than a regular JVM target, has a notable effect: what will be published is an AAR (for Android ARchive) rather than a JAR (for Jvm ARchive). This means that the library can package Android resources, such as images, XMLs, or JNI native libraries. As you can see, most of the Android configuration is not happening in the kotlin block, but in the android block. T ## Building Kotlin/Multiplatform with Github Actions DevFeed: [Building Kotlin/Multiplatform with Github Actions]() Original publisher: [Read original article]() Author: Romain Boisselle Published: 2021-04-15T11:44:49Z Content type: tutorial Language: en Sources: [Kodein Koders - Medium]() Topics: [GitHub Actions](), [Kotlin Multiplatform](), [CI/CD](), [kotlin-multiplatform-libraries](), [Maven Central](), [Gradle](), [HTTP](), [API]() Tags: [ci-cd](), [github](), [github-actions](), [gradle](), [http](), [kotlin](), [kotlin-multiplatform](), [kotlin-multiplatform-libraries](), [maven-central]() ### AI overview This tutorial explains how to automate Kotlin Multiplatform library publishing with GitHub Actions. It covers publishing snapshots to Maven Central, building across Linux, macOS, and Windows, and managing a shared Sonatype staging repository for stable releases. ### Source excerpt In a previous tutorial, I showed you how to configure your Kotlin/Multiplatform libraries to be published on Maven Central. To go beyond a publication process we now need to automate things with a good CI/CD workflow. Let's see how to do this with Github Actions. As the Kodein Open Source Initiative libraries are hosted on Github, we felt that it was the best choice to use the Github Actions pipelines to test, build and deploy our libraries, as it is entirely integrated with every other part of Github. Let's start with the snapshot publication process, as it is fairly straightforward. Publishing snapshots on Maven Central has no more constraints than just being authenticated with your Sonatype account, and having your artifacts file names ending with the uppercased word SNAPSHOT. This means that you could literally upload anything in your staging repositories. Here is a Github Actions script to upload a snapshot of a Kotlin/Multiplatform project: https://medium.com/media/41c7ac097f1ff802076f92acc8243077/href In that example, we run the task publishAllPublicationToOss on Linux, Mac & Windows, literally saying to publish every available targets onto the oss repository, which is the name we gave to it in our maven-publish configuration in our Gradle build script. This is not optimal, as every platform could upload shared targets like JVM, JS or even the Kotlin Multiplatform Metadata, but it's simple, and it works! Let's now see how to deploy stable releases. We have to discuss how we will be managing the unique staging repository we need. In fact, this is quite simple, and it is resume by this image: What we need is to create a staging repository, by using the sonatype API over HTTP. This step will generate a repository ID, that we use in later steps. In the build-upload matrix, we upload every artifact onto the same staging repository. Finally, In the drop-or-release job, depending on the success or failure of the build-upload matrix, we drop or release the staging re ## Publish a Kotlin/Multiplatform library on Maven Central DevFeed: [Publish a Kotlin/Multiplatform library on Maven Central]() Original publisher: [Read original article]() Author: Romain Boisselle Published: 2021-03-09T15:02:47Z Content type: tutorial Language: en Sources: [Kodein Koders - Medium]() Topics: [Kotlin Multiplatform](), [Maven Central](), [Tutorial](), [Gradle](), [Library]() Tags: [dependencies](), [gradle](), [how-to](), [kotlin](), [kotlin-multiplatform](), [maven-central](), [maven-plugin](), [releases](), [sonatype](), [tutorial]() ### AI overview This tutorial explains how to publish a Kotlin Multiplatform library to Maven Central. It covers migrating from Bintray and JCenter, Maven Central's requirements for sources, documentation, POM files, and signatures, and the staging-repository complications that arise in multiplatform builds. ### Source excerpt https://medium.com/media/1f069bfe70a66ec0f8528588ae5ee209/href In our last tutorial, Salomon showed you how to create a Kotlin Multiplatform Mobile library. Now that we have some code ready to be used by the community, let me show you how to publish your future releases to Maven Central. Before going into details about how to deploy your libs to Maven Central, I want to adress library developers who already have a library published on JCenter. This tutorial is also for you! Publishing on Bintray and JCenter was a choice most of us made, because it had less constraints and more flexibility. Now that they will be shutting down quite soon, we must migrate our publication workflow. Maven Central seems to be the right choice these days, but we need to deal with new requirements. Where Bintray was giving us some latitude on what we could upload and publish, Maven Central has always been more restrictive. Indeed, every uploaded artifact needs to be accompanied at least by the following items: A bundle of the sources of the artifact The documentation that goes with the artifact, in the JVM world this is the Javadoc. A well formatted POM file. For those who are not familiar with Maven, this is the description of your project, with its name, its version, its dependencies, etc, in an XML format And finally, every item needs to be signed to be accepted. Actually, these requirements are not that hard to fulfill, and Gradle provides almost everything we need to publish our artifacts smoothly, with 2 official plugins, maven-publish and signing. But... I told you : almost! When performing a publication, before being available on Maven Central, all your uploaded artifacts with maven-publish are generally stored and referenced in one staging repository that you need to validate as the final step of publishing. While this is true for standard JVM projects, this is not the case for Kotlin/Multiplatform ones. As Kotlin/Multiplatform developers, you may know that you need two machines to b