Overview
EncoreObjC is a thin @objc overlay over the Swift EncoreKit SDK, distributed as a source pod on CocoaPods. Every method is a translation shim — all business logic lives in EncoreKit — so the Obj-C surface mirrors the Swift API 1:1 semantically. Use this page to install the bridge, wire it up in an Obj-C AppDelegate, and map each method back to the Swift docs for full semantics.
When to Use
Use EncoreObjC if
- Pure Objective-C codebases
- Legacy iOS apps that haven’t adopted Swift
- Teams standardized on CocoaPods
- Mixed codebases where
.mfiles need direct access
Use EncoreKit (Swift) if
- Pure Swift or SwiftUI codebases
- Mixed codebases where Swift files drive integration
- You want
async/awaitand typed errors - You prefer Swift Package Manager
Both pods point at the same singleton. In mixed codebases, Swift files should
import Encore and call the typed Swift API — only .m files need @import EncoreObjC.Install
Add EncoreObjC to your Podfile
Target iOS 15.0 or later and enable The standard trunk form —
use_frameworks!. Install directly from the tagged Git release:Podfile
pod 'EncoreObjC', '~> 0.1' — is also available and is the recommended steady-state install once CocoaPods’ CDN shard index has refreshed for this release.The Git-ref form resolves by cloning the public repo at a specific tag, so it works immediately after a release — independent of CocoaPods shard-index propagation (which can lag 15–60 min after
pod trunk push). The '~> 0.1' trunk form is canonical once the CDN catches up and is preferred for consumers who want automatic patch bumps.Quickstart
Configure the SDK at launch, identify the current user, register a purchase handler, and present a placement. The full flow fits in oneAppDelegate.m:
AppDelegate.m
ViewController.m
API Mapping
Every Obj-C method forwards directly to the Swift SDK. Use the Swift SDK Reference for method-level semantics; the table below is your translation key.| Swift | Objective-C |
|---|---|
Encore.shared | [EncoreClient shared] |
configure(apiKey:options:) | -configureWithApiKey:options: |
identify(userId:attributes:) | -identifyWithUserId:attributes: |
setUserAttributes(_:) | -setUserAttributes: |
reset() | -reset |
placement(_:).show() (async throws) | -placement: → [builder showWithCompletion:] |
placement(_:).show() (fire-and-forget) | -placement: → [builder showAndForget] |
isActive(_:in:) (async) | -isActive:scope:completion: |
revokeEntitlements() (async throws) | -revokeEntitlementsWithCompletion: |
onPurchaseRequest { … } | -onPurchaseRequest: (block receives EncorePurchaseRequest * + void (^done)(NSError *)) |
onPassthrough { … } | -onPassthrough: |
EncoreError (enum) | NSError — see Error Handling |
Error Handling
All Obj-C completion handlers receive an optionalNSError *. Errors originating from EncoreKit use the domain published on EncoreErrorInfo and numeric codes defined by EncoreErrorCode:
EncoreErrorCodeTransportNetwork, EncoreErrorCodeTransportPersistence, EncoreErrorCodeProtocolHTTP, EncoreErrorCodeProtocolAPI, EncoreErrorCodeProtocolDecoding, EncoreErrorCodeIntegrationNotConfigured, EncoreErrorCodeIntegrationInvalidApiKey, EncoreErrorCodeIntegrationInvalidURL, EncoreErrorCodeDomain. The userInfo dictionary may include EncoreErrorInfo.statusKey, EncoreErrorInfo.apiCodeKey, and EncoreErrorInfo.messageKey depending on the error.
Known Constraints
Mixed Codebases
If your app has both Swift and Obj-C files, use each language’s native SDK from its own files — they share a single underlying singleton.UserSession.swift
LegacyBridge.m
Next Steps
Full API semantics — parameter defaults, threading, edge cases — live in the Swift SDK Reference. Use the API Mapping table above to translate each Swift signature to its Obj-C selector:configure(apiKey:)
Configuration options and initialization order
identify(userId:)
User identification and attribute behavior
placement(_:).show()
Placement presentation flow and results
onPurchaseRequest
Wiring StoreKit, RevenueCat, Adapty, or custom purchase logic
Swift reference docs apply to the Obj-C bridge with the mapping above. If a method isn’t listed in the API Mapping table, it’s not bridged in v0.1 — see Known Constraints.