Feature Request: Static or Mergeable XCFramework Distribution for KakaoMapsSDK

카카오맵 API (지도/로컬)
1

문의 시, 사용하시는 SDK 버전 정보와 디벨로퍼스 앱ID를 알려주세요.

Feature Request: Static or Mergeable XCFramework Distribution for KakaoMapsSDK

Issue title

Provide a static or mergeable XCFramework distribution for KakaoMapsSDK

Summary

The current KakaoMapsSDK iOS distribution is provided as a precompiled dynamic XCFramework. This requires applications to load KakaoMapsSDK as a separate dynamic image at runtime, which can add dyld and framework initialization overhead to application startup.

Please consider providing at least one of the following supported distribution formats:

  1. A static .xcframework distribution.
  2. A mergeable XCFramework built with Apple’s mergeable library support.
  3. A source distribution that application developers can build as a static or mergeable library.
  4. Official low-startup integration guidance for safely deferring SDK loading and initialization.

Background

The current CocoaPods release is:

  • KakaoMapsSDK 2.12.19

The current podspec describes the SDK as a vendored XCFramework and does not declare static framework support:

{
  "name": "KakaoMapsSDK",
  "version": "2.12.19",
  "vendored_frameworks": "KakaoMapsSDK.xcframework",
  "resources": ["KakaoMapsSDKBundle.bundle"]
}

The packaged SDK binary is a dynamically linked shared library:

Mach-O 64-bit dynamically linked shared library arm64

The simulator slice is also distributed as a dynamically linked shared library.

Why this matters

Application startup time can be affected by the number and size of dynamic framework images that dyld must process before the application becomes interactive. The relevant work can include:

  • dyld image discovery and loading
  • dependency graph resolution
  • symbol binding and rebasing
  • Objective-C class registration
  • static constructors and framework initialization
  • code-signature and filesystem work
  • resource bundle loading and lookup

Applications may use KakaoMapsSDK only in a subset of user flows, while still carrying the dynamic framework integration in the application package. A static or mergeable distribution would allow applications to reduce the number of independent dynamic images loaded during startup while preserving map functionality.

Requested improvements

Option A: Static XCFramework

Please provide a static variant of:

KakaoMapsSDK.xcframework

The static variant should be linkable into an application-owned framework or application binary without requiring KakaoMapsSDK to be embedded and loaded as a separate dynamic framework at runtime.

The static package should include clear guidance for:

  • CocoaPods integration
  • Swift and Objective-C module import
  • required system frameworks
  • required linker flags
  • resource bundle integration
  • simulator and device architectures
  • code signing and distribution

Because the SDK includes a resource bundle, please document how applications should locate KakaoMapsSDKBundle.bundle after static linking.

Option B: Mergeable XCFramework

Please provide an XCFramework built with Apple’s mergeable library support, including the required build setting:

MERGEABLE_LIBRARY = YES

The mergeable distribution should support merging KakaoMapsSDK into an application-owned framework or mergeable container while preserving:

  • public Swift and Objective-C APIs
  • map view creation and rendering
  • delegate and gesture callbacks
  • annotation and camera APIs
  • authentication and API key configuration
  • resource bundle lookup
  • Metal and OpenGL behavior where applicable
  • device and simulator architectures
  • all supported deployment targets

If the SDK depends on resources located relative to the original framework, please provide a supported resource bundle lookup mechanism. A public resource bundle provider or explicit bundle configuration API would be preferable to relying exclusively on Bundle(for:) after the framework has been merged.

Option C: Buildable source distribution

If prebuilt static or mergeable XCFrameworks cannot be distributed, please consider providing a supported source distribution or reproducible build package that allows application developers to build KakaoMapsSDK with:

MACH_O_TYPE = staticlib

or:

MERGEABLE_LIBRARY = YES

The build package should document all required compiler settings, linker settings, module maps, resource handling, architecture settings, and code-signing requirements.

Option D: Official low-startup integration mode

If static or mergeable binaries cannot be provided, please document an officially supported low-startup integration mode that explains:

  • whether KakaoMapsSDK can be safely loaded on demand
  • whether dlopen or another loading mechanism is supported
  • the required loading order for SDK dependencies
  • the earliest required authentication or API key initialization point
  • which APIs must be called on the main thread
  • whether the SDK uses +load, static constructors, or other pre-main initialization
  • whether initialization can be deferred until the first map screen
  • how to avoid unsupported runtime or symbol lookup workarounds
  • how to locate KakaoMapsSDKBundle.bundle when loading is deferred
  • whether the SDK can remain resident after first use without additional initialization

Compatibility requirements

A new distribution should preserve the existing KakaoMapsSDK API surface and runtime behavior, including the public map view, map rendering, camera, annotations, gestures, delegates, authentication, and resource APIs.

Please provide a compatibility matrix covering:

Item Required coverage
Device architectures arm64 device
Simulator architectures arm64 simulator and x86_64 simulator where supported
Minimum iOS version Same as the current SDK, or clearly documented
Swift compatibility Current supported Swift and Xcode versions
CocoaPods Podspec examples for dynamic, static, and mergeable variants
Manual integration Framework search paths, linker flags, embedding, and resources
Resource bundle Location and lookup behavior after static or mergeable integration
API key configuration Recommended initialization order and supported configuration API

Suggested validation

A static or mergeable release can be validated using standard Apple tooling:

file KakaoMapsSDK.framework/KakaoMapsSDK
otool -L KakaoMapsSDK.framework/KakaoMapsSDK

For a static distribution, the SDK binary should not be reported as a dynamically linked shared library and should not require a separate dynamic framework image at runtime.

For a mergeable distribution, the documentation should explain the expected MERGEABLE_LIBRARY behavior, supported container-linking workflow, resource bundle handling, and how to verify that the SDK has been merged successfully.

A sample application or integration test would help verify that the following remain functional after static or mergeable integration:

  1. API key configuration.
  2. Map view creation.
  3. Map rendering.
  4. Camera movement.
  5. Annotation creation and selection.
  6. Gesture and delegate callbacks.
  7. Resource bundle loading.
  8. Device and simulator builds.
  9. Cold-start and first-map startup behavior.

Acceptance criteria

A future KakaoMapsSDK release would address this request if it provides at least one of the following:

  • A documented static KakaoMapsSDK XCFramework.
  • A documented mergeable KakaoMapsSDK XCFramework.
  • A supported source build that produces static or mergeable binaries.
  • An official, tested, and documented on-demand loading mode with startup guidance.

Additional context

This request concerns SDK binary distribution and integration support. It does not request changes to map data, map rendering quality, API behavior, or product functionality. The goal is to reduce avoidable application startup overhead while preserving the existing KakaoMapsSDK API surface and runtime behavior.

2

[@tim.l @woody.ho]
cc. @Maps