• Здесь вы узнаете, как создать и запустить ваше первое Kotlin Multiplatform Mobile приложение.
• Вы также можете посмотреть видео этого урока, созданное Екатериной Петровой.

1. Настройте среду для кроссплатформенной мобильной разработки, установив необходимые инструменты для подходящей операционной системы.

   > Вам понадобится Mac с macOS для выполнения определенных шагов в этом руководстве, которые включают написание > специфичного для iOS кода и запуск iOS-приложений. > > Работать с iOS в других операционных системах, таких как Microsoft Windows, нельзя. Это связано с требованием > Apple.

2. В Android Studio выберите File | New | New Project.

3. Выберите Kotlin Multiplatform App в списке шаблонов проектов и нажмите Next.

   

4. Укажите имя для вашего первого приложения и нажмите Next.

   

5. В открывшемся окне выполните следующие действия:

   • Не изменяйте имена по умолчанию для приложения и общих папок;
   • Установите флажок, чтобы сгенерировать образцы тестов для вашего проекта;
   • Выберите Regular framework в списке вариантов распространения iOS-фреймворка.

   Нажмите Finish, чтобы создать новый проект.

   

   > Если вы хотите использовать мультиплатформенный модуль Kotlin в качестве зависимости CocoaPods, выберите опцию > CocoaPods dependency manager. Чтобы узнать больше о зависимостях CocoaPods, см. раздел Интеграция CocoaPods.

Теперь подождите, пока ваш проект будет настроен. Загрузка и настройка необходимых компонентов может занять некоторое
время, когда вы делаете это в первый раз.

Чтобы просмотреть полную структуру вашего мобильного мультиплатформенного проекта, переключите просмотр с Android на
Project. Вы можете разобраться со структурой проекта и
тем, как вы можете её использовать.

Запуск вашего приложения

Вы можете запустить свое мультиплатформенное приложение на Android или iOS.

Запуск вашего приложения на Android

• В списке конфигураций запуска выберите androidApp и нажмите Run.
  
  

Запуск эмулятора другого Android-устройства

Узнайте, как настроить эмулятор Android и запустить ваше приложение на другом моделируемом устройстве.

Запуск на реальном Android-устройстве

Узнайте, как настроить и подключить аппаратное устройство и запустить на нем свое приложение.

Запуск вашего приложения на iOS

• В списке конфигураций запуска выберите iosApp и нажмите Run.
  
  

Запуск эмулятора другого iPhone

Если вы хотите запустить свое приложение на другом симулируемом устройстве, вы можете добавить новую конфигурацию
запуска.

1. В списке конфигураций запуска нажмите Edit Configurations.

   

2. Нажмите кнопку + над списком конфигураций и выберите iOS Application.

   

3. Укажите название вашей конфигурации.

4. Выберите симулируемое устройство в списке Execution target, а затем нажмите OK.

5. Нажмите Run, чтобы запустить ваше приложение на новом симулируемом устройстве.

Запуск на реальном iPhone

Если ваша сборка завершится неудачей, следуйте инструкциям, описанным в этой issue.

Запуск тестов

Вы можете запустить тесты, чтобы проверить правильность работы общего кода на обеих платформах. Конечно, вы также можете
писать и запускать тесты для проверки кода, специфичного для конкретной платформы.

Запуск тестов на iOS

1. Откройте файл iosTest.kt в папке shared/src/iosTest/kotlin/com.example.kmmapplication.shared. Каталоги с именем
   Test содержат тесты. Этот файл содержит пример теста для iOS.

2. Нажмите на значок Run рядом с тестом.

Тесты выполняются на симуляторе без UI. Поздравляем! Тест пройден – смотрите результаты теста в консоли.

Запуск тестов на Android

Для Android процесс запуска тестов очень похож на этот же процесс для iOS.

1. Откройте файл androidTest.kt в папке shared/src/androidTest/kotlin/com.example.kmmapplication.shared.

2. Нажмите на значок Run рядом с тестом.

Обновление вашего приложения

1. Откройте файл Greeting.kt в папке shared/src/commonmain/kotlin/com.example.kmmapplication.shared. В этом каталоге
   хранится общий код для обеих платформ – Android и iOS. Если вы внесете изменения в общий код, вы увидите изменения в
   обоих приложениях.

2. Обновите общий код: используйте функцию стандартной Kotlin-библиотеки, которая работает на всех платформах и
   возвращает текст: reversed().

   `kotlin class Greeting {

   fun greeting(): String {
   return «Guess what it is! > ${Platform().platform.reversed()}!»
   }

   } `

3. Запустите обновленное приложение на Android.

4. Запустите обновленное приложение на iOS.

5. Запустите тесты на Android и iOS.

   Как вы видите, тесты проваливаются. Обновите тесты для прохождения. Вы знаете, как это сделать, верно? 😉

Следующие шаги

Как только вы поиграете со своим первым кроссплатформенным мобильным приложением, вы сможете:

Kotlin Multiplatform Project for Android and iOS: Getting Started

Update note: JB Lorenzo updated this tutorial for the alpha version of Kotlin Multiplatform. Dario Coletto wrote the original.

Hallo! Gluten Tag. :]

Are you a bit tired of writing two versions of similar code for Android and iOS?

While these two platforms are different, the business logic behind your app is probably similar: download files, read from and write to a database, send messages to a remote host, and retrieve and display fancy kitten pictures.

These similarities are why Kotlin Multiplatform Mobile (KMM) exists. Historically, it’s known as Kotlin Multiplatform Project, or MPP. Thanks to Kotlin/JVM, Kotlin/JS and Kotlin/Native, you can compile/transpile a single project for many platforms.

In this tutorial, you’ll learn how to build and update an app for Android and iOS while only having to write the business logic once in Kotlin. More specifically, you’ll learn how to:

• Integrate KMM into an existing project.
• Set up the common module.
• Fetch data from a network.
• Save data.

Ready to get started? Keep reading!

Getting Started

Download the starter project by clicking the Download Materials button at the top or bottom of the tutorial.

Open the starter project in Android Studio 4.1 or later.

Use a recent version of Kotlin — 1.4.20 or above. For iOS, you need Xcode 11.3 or later.

Note: This tutorial assumes you are familiar with the basics of Android and Android Studio. If you are new to Android development, check out our Android Tutorial for Beginners series first.

Looking at the code, you’ll find the starter project provides the interface and some logic for the MultiGrain app: A simple app that navigates a list of grains and their descriptions, it saves your favorite grains and has platform specific code in the UI.

Build and run the starter code on Android Studio and you’ll see the screen below.

Once you click the Grains button, you’ll see the screen below. It has a hardcoded list of grains.

Of course, you’ll want to update the list from time to time, and it’s better if it can be done remotely. It’s also great if you can save the users’ favorite grains locally. Since you have both Android and iOS apps, you can save some headache by sharing some code for fetching the data and saving your preferences.

But before you get into the implementation, you’ll learn some theory first.

Multiplatform

Kotlin Multiplatform supports more than just Android and iOS. It also supports JavaScript, Windows and other native targets. You’ll focus on the mobile aspect, or Kotlin Multiplatform Mobile (KMM).

Common Code

KMM allows shared code in Android and iOS. On Android, it does this by using a shared module with Gradle. On iOS, you can import the shared module as a framework that you can access from Swift code.

If you think it’s easy to understand how Android uses common code, you’re right. It’s a simple include in settings.gradle. However, as mentioned earlier, for iOS it’s different, as the code is compiled to native code. You’ll go through the steps of creating this framework later.

Not all code can be common; for example, calling native libraries for key-value storage requires writing different code for iOS and Android. To do this, there can be a common interface acting as common code. Then the platform specifies the interface that will be used in each platform separately.

Platform-Specific Code

Sometimes you need to call methods that are specific to a platform. It isn’t possible to use platform-specific code inside the common module, but Kotlin has a mechanism it uses to achieve this result: expect/actual.

First, declare a class, method or function in the common module using the expect keyword, and leave the body empty, as you often do when creating interfaces or abstract classes. Then, write the platform-specific implementations for the class, method or function in all the other modules using the actual keyword in the signature.

Each platform can share a common interface while also possessing its own implementation.

Now that you’ve covered the theory, what now? Keep reading to find out.

Integrating KMM Into an Existing Project

Kotlin Multiplatform Mobile (KMM): пример простого приложения

Если вы задумываетесь над созданием мобильного приложения одновременно под iOS и Android, знакомы с языком Kotlin и хотите попробовать что-то новенькое, то обратите внимание на Kotlin Multiplatform Mobile (KMM). Это SDK (набор инструментов для разработки программного обеспечения) разработанный компанией JetBrains (создателя языка Kotlin), недавно вышедший в публичную бету, а значит, самое время попробовать его в деле!

В этой статье мы разберем:

• основные особенности KMM;
• архитектуру типичного KMM-приложения;
• приемы организации кода;
• ресурсы для дальнейшего изучения.

Что особенного в KMM и чем он отличается от других технологий мультиплатформенной разработки?

Ядром KMM является технология Kotlin Native, позволяющая компилировать код, написанный на языке Kotlin, в платформонезависимые, нативные приложения и библиотеки.

Самое важное отличие от популярных решений для мультиплатформенной разработки, таких как React Native или Flutter, это то, что KMM предоставляет набор инструментов, позволяющий использовать общую логику для обоих приложений в виде отдельной библиотеки, написанной на языке Kotlin, которую затем можно импортировать как в Android, так и в iOS приложения (рис. 1).

Рис.1. Архитектура KMM-приложения

Основные плюсы такого подхода:

• Легко добавить в существующие нативные приложения. Достаточно просто постепенно выделять общий код в отдельную библиотеку.
• Меньший размер приложения. Компиляция кода Kotlin Native добавляет небольшой оверхед, поэтому размер приложения обычно меньше аналогов на Flutter и React Native.
• Большая гибкость. Вы можете использовать любые библиотеки и технологии внутри ваших iOS и Android-приложения, без необходимости написания дополнительного кода.
• Общий код можно использовать не только в мобильных приложениях, но также и в веб-приложениях, и в серверной логике на Kotlin (рис. 2).

Рис. 2. Использование общего кода между серверной логикой, мобильными платформами и web

Но не стоит забывать и о минусах:

• Высокий порог входа. Необходимы базовые знания разработки под iOS и Android даже для создания простого приложения.
• Небольшое комьюнити. Так как KMM все еще находится в бете, его использует не такое большое число пользователей. Для сравнения: на момент написания статьи вопросов с тегом Flutter в Stackoverflow больше 160 тысяч, а по KMM – чуть больше тысячи.
• Небольшое количество мультиплатформенных библиотек. Несмотря на то что стандартная библиотека языка Kotlin может быть использована в общем коде без ограничений, многие привычные библиотеки языка Kotlin используют платформозависимые вызовы Java-кода и не могут быть использованы напрямую.
• Сложность организации общего кода. KMM не предоставляет никаких готовых решений, как организовать архитектуру приложения, чтобы увеличить процент общего кода и не усложнить процесс разработки.

Команда JetBrains активно работает над развитием комьюнити, а также улучшает плагин для Android Studio, который заметно упрощает создание и поддержку KMM приложения. А последний минус мы рассмотрим подробнее далее и разберем популярный способ организовать код приложения так, чтобы максимально следовать золотому правилу разработки – DRY (don’t repeat yourself).

Интересно, перейти к каналу

Архитектура типичного KMM-приложения

Архитектура типичного мультиплатформенного приложения – это монорепозиторий, состоящий из трех модулей: Android-приложение, iOS-приложение и общая библиотека (рис. 3).

Рис. 3. Схема модулей базового KMM приложения

Проект с такой структурой можно создать с помощью официального плагина для Android Studio. Шаги по настройке подробно описаны на сайте проекта, поэтому мы не будем углубляться в него подробнее.

My first take on KMM — Kotlin Multiplatform Mobile

In order to finish the Dev Academy, I’ve had to develop an application as my practice assignment. I’ve been provided a mentor — Denzil Ferreira, whom I was guided by throughout the process.

The purpose of practice assignment is to provide to freshly recruited junior developers a safe environment, in which they can work on a small feature of an application or simple application of their own.

Moreover, thanks to mentor guidance development gets done carefully and is a great way to bootstrap as a new Software Designer.

On the initial project kick-off meeting, my mentor and I have decided that to mix things up a little. I should develop the app in a technology that I am not super familiar with.

After going over several different possibilities, we settled with Kotlin Multiplatform Mobile (KMM).

Some of the reasons behind the decision were: 1) my familiarity with Native Android Development and 2) KMM is an exciting and emerging technology worth exploring for a streamlined mobile development team.

Kotlin Multiplatform Mobile (KMM) is a tool developed by JetBrains to simplify iOS and Android app development. Kotlin Multiplatform empowers cross-platform (e.g., mobile, desktop, web) and yet support native development on such platforms. This article focuses on the mobile side of things.

Slicing apps into layers of concern

To create an applications with KMM is to develop one shared codebase for business logic and then separate codebases for each platform specific features. Separate native codebases are usually for user interface, and occasionally more depending on needing platform-specific functionality.

This approach doesn’t reduce native performance as Kotlin is compiled to native execution code. KMM can save teams’ time and effort as you do not have to write redundant business logic in both apps, nor coordinate between teams for feature parity.

We could consider a hybrid team, where we leverage each others’ experience effectively.

In addition, KMM offers flexibility to decide how much of the code is shared between the platforms. For instance, we can decide that only business logic will be shared between platforms, or that we will share API calls, or local database and business logic, and so forth.

KMM 101

KMM project is made of 3 modules: androidApp (Android native project and app code), iosApp (Xcode native project and app code) and shared module (everything that should be shared across both Android and iOS apps). Code in shared module can be called by the Android or iOS modules, and naturally code in platform related modules cannot be called in shared module. An introduction to KMM is available here.

In shared module most of the code is written in commonMain package however, sometimes our shared code cannot work without platform dependent stuff.

That’s why in shared module we have androidMain and iosMain packages. In case of developing the platform depended code in shared module we must use KMM specific Kotlin mechanism of expected and actual declarations.

The simplest example is already generated for us by KMM plugin while creating a project:

In shared module we create expect classes inside commonMain. Think of them as interfaces, without any implementation code, or a template of what should be converted to native code via KMM compilers:

expect class Platform() {
val platform: String
}

And then in each platform module, we implement the actual class we created as expect:

In androidMain:

actual class Platform actual constructor() {
actual val platform: String = «Android ${android.os.Build.VERSION.SDK_INT}»
}

In iosMain:

actual class Platform actual constructor() {
actual val platform: String = «iOS ${UIDevice.currentDevice.systemVersion}»
}

My Dev Notary implementation

Alright, so the project that gave me opportunity to test KMM in practice was Dev Notary. You can find the project pitch here. Dev Notary is a simple application that lets developers create notes, documentations or memos and interact with them. Basic CRUD with addition of sharing the notes with other users. The functional requirements were simple:

• Authentication
• Managing a note: create, read, edit, delete, share
• Restore notes
• List, sort, search

In order to accomplish this, I’ve decided to give myself a day to research other Kotlin Multiplatform Mobile projects, to learn from them, get some inspiration and only after that start planning my app.

Thanks to that investigation, I’ve realized that I can actually share quite a lot of code between both platforms.

After some planning it was decided that in order to test this untamed technology I should try to share as much code as I possibly can.

While looking for possible libraries that could make my expedition easier, I’ve found a library that implements Firebase SDK with pure Kotlin and therefore, enables usage of Firebase directly from the shared module! As for local database, I’ve decided to use safest option SQLDelight and for key value pairs multiplatform settings. Additionally, I’ve picked Kodein DI for dependency injection, Multiplatform UUID for Universal Unique IDs. OK… but, how to keep all this code separated and neat so that it’s easily testable and the presentation layers are not actually dependent on any shared module code? With a MVVM and clean architecture!

I could have shown here the actual code snippets from my application so that You could see how KMM actually gets done but by doing this, this post would become extremely long and probably dull for most readers. Instead, I’ll present some animated parts of the application, to show how it all works and I’ll link the repository so whoever’s curious can look into the code.

I recommend having a look at implementation of shared module iOS package and Android package to get a grasp of expect/actual mechanism. In case of Dev Notary I have used it in order to implement iOS working ViewModel, timer and ISO8601 date formatting.

Application

Creating notes

Sharing notes

Looking back

Getting started with Kotlin Multiplaform Mobile (KMM)

Kotlin Multiplatform Mobile (KMM) is a cross-platform framework to share code for Android and iOS apps.

When to use KMM?

• It is highly recommended to write business logics in KMM, because it usually requires very limited or even no platform features.
• We can also use KMM to access platform features, such as data accessing. For example, we can use Ktor to perform network requests, and SQLDelight to access SQLite databases. We can also use expect / actual declarations to access platform specific features.
• KMM can also be used to implement presentation layer. For modern declarative UI frameworks such as Jetpack Compose and SwiftUI, the Model View Intent (MVI) pattern is highly recommended. For legacy UI frameworks, both MVI and the Model View Presenter (MVP) pattern could be used.
• DO NOT use KMM for UI layer. Just don’t.

Be aware, Coroutines users!

It’s worth noting that for Coroutines, only the single-threaded code on Kotlin Native is supported in the Stable version. The multi-threaded version is available with known memory management issues. Additional details can be found here, and the latest update can be found here.

Despite of this, in my opinion, KMM is mature enough for production. So, let’s get started.

Create KMM project

First, we need to install Android Studio 4.2 or above, Xcode 11.3 or above, and the Kotlin Multiplatform Mobile plugin.

Project structure

The basic KMM project consists of the three components:

• A shared module that contains common code shared by both Android and iOS. This module is built into an Android library or an iOS framework using Gradle build system.
• An Android module that builds into an Android app, using Gradle build system.
• An iOS module that builds into an iOS app, using Xcode build tools. It is not connected with other parts of the project via Gradle, but instead using the shared module as a framework.

The shared module is the essential part of a KMM project, which uses the KMM plugin to configure the target:

plugins {
kotlin(«multiplatform»)
}

kotlin {
android()
iosTarget(«ios») {}

sourceSets {
// code that works on both platforms, including the «expect» declarations
val commonMain by getting {
dependencies {
// …
}
}
val commonTest by getting {
dependencies {
implementation(kotlin(«test-common»))
implementation(kotlin(«test-annotations-common»))
}
}

// Android specific code, including the «actual» implementations
val androidMain by getting
val androidTest by getting

// iOS specific code, including the «actual» implementations
val iosMain by getting
val iosTest by getting
}
}

Android library

To configure the build for the Android library, we also need to add the plugin:

plugins {
// …

id(«com.android.library»)
}

And also configure the android {} top-level block, e.g.:

android {
compileSdkVersion(30)
sourceSets[«main»].manifest.srcFile(«src/androidMain/AndroidManifest.xml»)
defaultConfig {
minSdkVersion(21)
targetSdkVersion(30)
versionCode = 1
versionName = «1.0»
}
}

To learn more about configuring the Android build, see the Android developer documentation.

Publish to Maven

To publish the Android library to a Maven repository, we can use the Maven Publish plugin:

plugins {
// …

id(«maven-publish»)
}

group = «com.example.kmmsample»
version = «1.0.0»

kotlin {
// …

android {
publishLibraryVariants(«release», «debug»)
}
}

Then we can consume it same way as any other Maven libraries.

iOS framework

The configuration to build the iOS framework is stored inside the ios {} block within the kotlin {} top-level block:

kotlin {
// …

val iosTarget: (String, KotlinNativeTarget.() -> Unit) -> KotlinNativeTarget =
if (System.getenv(«SDK_NAME»)?.startsWith(«iphoneos») == true)
::iosArm64
else
::iosX64

iosTarget(«ios») {
binaries {
framework {
baseName = «KmmSample»
}
}
}
}

To learn more about configure the iOS build, see the Kotlin Native documentation.

Publish as a Swift package

To publish the iOS framework as a Swift package, we can use the Multiplatform Swift Package plugin:

plugins {
// …

id(«com.chromaticnoise.multiplatform-swiftpackage») version «2.0.3»
}

multiplatformSwiftPackage {
packageName(«KmmSample»)
swiftToolsVersion(«5.3»)
targetPlatforms {
iOS { v(«13») }
}
}

The Swift package is created at shared/swiftpackage by default, and we can publish it to a Git repo with these steps. To consume it, follow the tutorial here.

Access platform-specific API

Learn how to build a cross-platform application with DhiWise

DhiWise

Kotlin is the most loved language among Android developers. But do you know it is also favored by developers for cross-platform mobile application development?

Know how to build a cross-platform mobile application using Kotlin Multi Platform with DhiWise.

In the 21 century, mobile applications are vital for all businesses to attract and provide better services to the customers. The growing demand for a better user experience and high performance puts a lot of pressure on mobile developers and testers.

Building and maintaining a mobile application is not an easy task; it requires lots of effort and dedication. It is challenging to create a cross-platform mobile application suitable for different platforms(iOS, Android, etc.) and testing it across different hardware and screen sizes.

Besides that, there are other difficulties such as maintaining code and duplicating business logic for each platform makes the entire process of application development costly and time-consuming.

Challenges in building a cross-platform application

Использование Kotlin Multiplatform Mobile в iOS-проекте

Настройка и использование Kotlin Multiplatform Mobile в iOS-проекте может быть довольно сложным. В этой статье мы добавляем в наш Xcode-проект под названием medium новую платформу KMM.

Kotlin Multiplatform Mobile в iOS-проекте: начинаем

В этом примере мы будем использовать пустой проект KMM с изюминкой. Если вы не знаете, как создать проект KMM, сначала прочтите мою предыдущую статью. Изюминка: в процессе создания на этот раз мы назовем приложение iOS точно так же, как наш проект Xcode. Это устраняет необходимость изменять путь и переменные проекта кода в Gradle и в файлах свойств.

Наш созданный проект KMM теперь состоит из трех компонентов:

• Приложение для Android
• Общий код (на Kotlin)
• Приложение для iOS

На следующем этапе мы хотим заменить стандартное приложение KMM iOS на наше существующее. Наше существующее приложение, которое используется, называется средним и может быть новым, пустым проектом или вашим последним шедевром. В этой демонстрации среда — это недавно созданный проект.

Замена iOS-приложения

Сначала мы заходим в каталог нашего приложения KMM в Finder. Вы можете увидеть три основные папки: androidApp, shared и medium. Заглянув внутрь папки носителя, мы видим типичный макет проекта Xcode, содержащий файл .xcodeproj и все исходные и тестовые файлы.

Действие: удалите все, что находится в средней папке, и поместите все существующие папки приложения внутрь. С этого момента мы будем открывать приложение для iOS отсюда.

Линкинг нашего приложения для iOS с общими компонентами KMM

Чтобы наше приложение iOS могло работать с общими компонентами KMM, должны произойти две вещи:

• Проект KMM необходимо создать для нашего приложения для iOS.
• Приложению iOS необходимо найти и ссылаться на созданные общие файлы.

1. Создайте проект KMM для Xcode

В своем проекте кода перейдите в корневой проект и откройте Build Phases. Щелкнув +, создайте новую Run Script Phase.

Сценарий выполнения позволяет запускать любой сценарий оболочки при сборке проекта. Этот скрипт позволяет нам создавать приложение KMM для iOS без Android Studio или без запуска Gradle в терминале.

В поле Shell script вставьте:

#!/bin/shPARENTDIR=»$(dirname «$SRCROOT/»)»cd «${PARENTDIR}»./gradlew :shared:packForXCode — PXCODE_CONFIGURATION=${CONFIGURATION}UNIVERSAL_OUTPUTFOLDER=»${APPNAME}/framework/${CONFIGURATION}-universal»FRAMEWORK_NAME=»shared»BASEPATH=»${UNIVERSAL_OUTPUTFOLDER}/${FRAMEWORK_NAME}.framework»ARM64PATH=»${PARENTDIR}/${FRAMEWORK_NAME}/build/bin/iosArm64/debugFramework/${FRAMEWORK_NAME}.framework»X64PATH=»${PARENTDIR}/${FRAMEWORK_NAME}/build/bin/iosX64/debugFramework/${FRAMEWORK_NAME}.framework» mkdir -p «${UNIVERSAL_OUTPUTFOLDER}» #copy headers, modules & info.plist of ARM64/X64 build into our framework cp -R «${ARM64PATH}» «${UNIVERSAL_OUTPUTFOLDER}/»if [ ! -d «$ARM64PATH» ]; then echo «error: Please on an iOS Device to create ARM64 build files» fiif [ ! -d «$X64PATH» ]; then echo «error: Please run on a Simulator to create X64 build files» fiARM64PATHAPPEND=»${ARM64PATH}/${FRAMEWORK_NAME}» X64PATHAPPEND=»${X64PATH}/${FRAMEWORK_NAME}»FULLPATH=»${PARENTDIR}/${BASEPATH}»lipo -create «${ARM64PATHAPPEND}» «${X64PATHAPPEND}» -output «${FULLPATH}/shared»

Позже я расскажу о функциях этого скрипта. Основное исполнение — это строка ./gradlew: shared: packForXcode. Эта строка кода запускает упаковочный агент, расположенный в build.gradle.kts, который находится в общей папке. Код выглядит так:

val packForXcode by tasks.creating(Sync::class) { group = «build» val mode = System.getenv(«CONFIGURATION») ?: «DEBUG» val sdkName = System.getenv(«SDK_NAME») ?: «iphonesimulator» val targetName = «ios» + if (sdkName.startsWith(«iphoneos»)) «Arm64» else «X64» val framework = kotlin.targets.getByName(targetName).binaries.getFramework(mode) inputs.property(«mode», mode) dependsOn(framework.linkTask) val targetDir = File(buildDir, «xcode-frameworks») from({ framework.outputDirectory }) into(targetDir) } tasks.getByName(«build»).dependsOn(packForXcode)

Я не буду углубляться в этот (стандартный) скрипт, за исключением того, что упомяну, что он различает сборки iOS Arm64 и x64. Это различие позволяет нам использовать компоненты KMM на реальном iPhone (с использованием процессора ARM) и в симуляторе. Вы можете узнать больше об архитектуре процессора здесь.

Важно: переместите сценарий выполнения в верхнюю часть этапов сборки!

У Run Script два процесса. Во-первых: он создает структуру сборки для данного процессора (ARM или x64). Во-вторых: он объединяет две платформы сборки в единую структуру, которая может обрабатывать как процессоры ARM, так и x64; назовем это нашим универсальным фреймворком.

Следующий шаг немного непонятен, но он создает правильную настройку и его нужно выполнить только один раз. Так что читайте внимательно!

• Запустите проект на любом симуляторе. Сборка завершится неудачно, и будет сказано: Команда PhraseScriptExecution завершилась неудачно с ненулевым кодом выхода. И это прекрасно! Теперь у нас есть структура симулятора (в shared> build> bin> iosX64> debugFramework).
• Запустите проект на своем iPhone. Сборка будет успешной, но ваше приложение упадет во время выполнения с ошибкой: Library not loaded: shared.framework.. И это опять прекрасно. Теперь у нас есть как фреймворк для iPhone (в shared> build> bin> iosArm64> debugFramework), так и созданный универсальный фреймворк (в framework> Debug-universal). Ошибка возникает из-за того, что универсальный фреймворк еще не привязан к нашему проекту.

Итак, приступим к импорту фреймворка!

2. Импорт нашего универсального ‘shared.framework’

Вы можете прочитать несколько руководств по KMM, в которых предполагается импортировать общий фреймворк из папки сборки.

Но мы создали нашу универсальную платформу как для симулятора, так и для iPhone, так что забудьте об этом! Наш фреймворк, совместимый с симуляторами и iPhone, вы найдете в разделе framework> Debug-universal> shared.framework. Теперь этот каталог должен быть связан с нашим проектом Xcode.

В Xcode вернитесь на вкладку General. Здесь вы видите раздел «Frameworks, Libraries, and Embedded Content».

Действие: Здесь мы добавляем shared.framework из каталога framework:

Теперь у вашего проекта есть доступ к объединенному shared.framework. Но в каталоге сборки есть еще один файл фреймворка, который нам тоже нужен.

3. И еще одно!

Перед запуском нашего проекта сейчас мы должны добавить конкретный путь в Framework Search Paths. Этот путь поиска необходим для того, чтобы проект нашел в Xcode фреймворк shared.framework. Перейдите в настройки сборки и найдите раздел «Search Paths».

Там вы найдете раскрывающийся список для Framework Search Paths.

Действие: Вставьте $(SCROOT)/../.shared/build/xcode-frameworks как в Debug, так и в Release, дважды нажав соответствующее поле справа, щелкнув значок плюса во всплывающем окне и вставив эту строку.

Как только это будет сделано, мы готовы запустить проект где угодно, будь то на вашем iPhone или в симуляторе.

Примечание. Если мы работаем на iPhone или симуляторе, будет повторно запущена только соответствующая общая папка сборки. Это сокращает процесс сборки вместо того, чтобы всегда запускать оба типа сборки.

Поздравляю!

Kotlin Multiplatform Mobile в iOS-проекте: отладка

Building for iOS Simulator, but the linked and embedded framework 'shared.framework' was built for iOS.

Это иногда случается, когда мы возимся с файлами сборки.

Чтобы исправить это, просто удалите shared.framework со вкладки General (Frameworks, Libraries и Embedded Content), снова выполните сборку на симуляторе iOS, а затем проделайте все манипуляции с shared.

framework, как на шаге 2.

Если у вас возникнут какие-либо другие ошибки или ошибки, напишите мне или оставьте комментарий, чтобы мы могли поделиться решениями.

Источник

Если вы нашли опечатку — выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.