feat: using platform-specific apis (#3788)

docs/kr.tree

@@ -150,7 +150,7 @@
         </toc-element>
         <toc-element toc-title="Sharing code principles">
             <toc-element id="multiplatform-share-on-platforms.md" accepts-web-file-names="mpp-share-on-platforms.html"/>
-            <toc-element id="multiplatform-connect-to-apis.md" accepts-web-file-names="platform-specific-declarations.html,mpp-connect-to-apis.html,kmm-connect-to-platform-specific-apis.html,multiplatform-mobile-connect-to-platform-specific-apis.html"/>
+            <toc-element id="multiplatform-expect-actual.md"/>
             <toc-element id="multiplatform-hierarchy.md" accepts-web-file-names="migrating-multiplatform-project-to-14.html"/>
             <toc-element id="multiplatform-android-layout.md"/>
         </toc-element>

docs/topics/cross-platform-mobile-development.md

@@ -104,7 +104,7 @@ In our [Kotlin Multiplatform survey from Q1-Q2 2021](https://blog.jetbrains.com/
 
 ![How are users satisfied with the quality of their app after Kotlin Multiplatform Mobile adoption?](survey-results-q1-q2-21.png){width=700}
 
-Another concern is the inability to seamlessly support the native features of applications. Nevertheless, if you're building a multiplatform app that needs to access platform-specific APIs, you can use Kotlin's [expected and actual declarations](multiplatform-connect-to-apis.md). They allow you to define in common code that you "expect" to be able to call the same function across multiple platforms and provide the "actual" implementations, which can interact with any platform-specific libraries thanks to Kotlin interoperability with Java and Objective-C/Swift.
+Another concern is the inability to seamlessly support the native features of applications. Nevertheless, if you're building a multiplatform app that needs to access platform-specific APIs, you can use Kotlin's [expected and actual declarations](multiplatform-expect-actual.md). They allow you to define in common code that you "expect" to be able to call the same function across multiple platforms and provide the "actual" implementations, which can interact with any platform-specific libraries thanks to Kotlin interoperability with Java and Objective-C/Swift.
 
 These issues raise the question of whether the end-user will notice a difference between native and cross-platform apps.
 

docs/topics/multiplatform-mobile/multiplatform-mobile-integrate-in-existing-app.md

@@ -142,7 +142,7 @@ This is necessary for reusing the code for both Android and iOS.
    ![Warnings about platform-dependent code](warnings-android-specific-code.png){width=450}
 
 4. Remove Android-specific code by replacing it with cross-platform Kotlin code or connecting to Android-specific APIs
-   using [`expect` and `actual` declarations](multiplatform-connect-to-apis.md). See the following sections for details:
+   using [expected and actual declarations](multiplatform-expect-actual.md). See the following sections for details:
 
 #### Replace Android-specific code with cross-platform code {initial-collapse-state="collapsed"}
 
@@ -200,7 +200,7 @@ platform-specific functionality for this case.
 
 Provide the `expect` declaration for the `randomUUID()` function in the shared code and its `actual` implementations for
 each platform – Android and iOS – in the corresponding source sets.
-You can learn more about [connecting to platform-specific APIs](multiplatform-connect-to-apis.md).
+Learn more about [expected and actual declarations](multiplatform-expect-actual.md).
 
 1. Remove the `java.util.UUID` class from the common code:
 

docs/topics/multiplatform-mobile/multiplatform-mobile-ktor-sqldelight.md

@@ -236,7 +236,7 @@ directory. The generator will create an interface named `AppDatabase`, as specif
 
 To initialize `AppDatabase`, pass an `SqlDriver` instance to it. SQLDelight provides multiple platform-specific
 implementations of the SQLite driver, so you need to create them for each platform separately. You can do this by using
-[expected and actual declarations](multiplatform-connect-to-apis.md).
+[expected and actual declarations](multiplatform-expect-actual.md).
 
 1. Create an abstract factory for database drivers. To do this, in `shared/src/commonMain/kotlin`, create
    the `com.jetbrains.handson.kmm.shared.cache` package and the `DatabaseDriverFactory` class inside it:
@@ -294,7 +294,7 @@ Instances of these factories will be created later in the code of your Android a
 
 You can navigate through the `expect` declarations and `actual` implementations by clicking the handy gutter icon:
 
-![Expect/Actual gutter](expect-actual-gutter.png){width=500}
+![Expect/Actual gutter](expect-actual-gutter-sql.png){width=500}
 
 ### Implement cache
 

docs/topics/multiplatform-mobile/multiplatform-mobile-understand-project-structure.md

@@ -102,7 +102,7 @@ kotlin {
 
 The shared module contains the code that is common for Android and iOS applications. However, to implement the same logic
 on Android and iOS, you sometimes need to write two platform-specific versions of it.
-To handle such cases, Kotlin offers the [expect/actual](multiplatform-connect-to-apis.md) mechanism.
+To handle such cases, Kotlin offers the [expect/actual](multiplatform-expect-actual.md) mechanism.
 The source code of the shared module is organized in three source sets accordingly:
 
 * `commonMain` stores the code that works on both platforms, including the `expect` declarations

docs/topics/multiplatform/multiplatform-configure-compilations.md

@@ -345,7 +345,7 @@ If the source set `jvmMain` depends on a source set `commonMain` then:
 compiled into the same target binary form, such as JVM class files.
 * Sources of `jvmMain` 'see' the declarations of `commonMain`, including internal declarations, and also see the 
 [dependencies](multiplatform-add-dependencies.md) of `commonMain`, even those specified as `implementation` dependencies.
-* `jvmMain` can contain platform-specific implementations for the [expected declarations](multiplatform-connect-to-apis.md) 
+* `jvmMain` can contain platform-specific implementations for the [expected declarations](multiplatform-expect-actual.md) 
 of `commonMain`.
 * The resources of `commonMain` are always processed and copied along with the resources of `jvmMain`.
 * The [language settings](multiplatform-dsl-reference.md#language-settings) of `jvmMain` and `commonMain` should be consistent.