What the Userorbit iOS and Android SDKs support, their requirements, and how analytics and in-app experiences work in mobile apps.
Userorbit ships native SDKs for iOS and Android. They send product analytics from your app and show Userorbit surveys, announcements, feedback forms and the support messenger natively, without a web view for the core screens. To install, go to Install the Userorbit SDK in an iOS app or Install the Userorbit SDK in an Android app.
Available SDKs
| Platform | Package | Current version | Source |
|---|---|---|---|
| iOS and iPadOS | Swift Package Manager product Userorbit | 0.1.0 | github.com/userorbit/userorbit-ios |
| Android | JitPack: com.github.userorbit.userorbit-android:userorbit-android and the optional userorbit-android-ui | 0.1.0 | github.com/userorbit/userorbit-android |
Both SDKs are open source under the MIT license. React Native and Flutter packages aren't available yet. If you build with one of those frameworks, you can call the native SDKs from platform code until dedicated packages ship.
Requirements
- iOS: iOS 15 or later and Xcode with Swift 5.9 or later. The package also builds for macOS 12 and tvOS 15, but the in-app screens (surveys, announcements, feedback and messenger) are available on iOS and iPadOS only.
- Android:
minSdk23 (Android 6.0). The built-in screens need Jetpack Compose and a host activity that extendsComponentActivity. Feedback screenshots need Android 8.0 or later. - Your workspace's public Account ID, shown in the install snippet under Settings → Channels → Widget. The Account ID is safe to ship in your app binary. Never put API keys or other secrets in mobile code.
What each SDK supports
| Capability | iOS | Android | Notes |
|---|---|---|---|
| Event and screen tracking | Yes | Yes | track and screen. Screens send $uo_screen_view. |
| User identification | Yes | Yes | identify, user properties and reset on sign-out. |
| Lifecycle events and sessions | Yes | Yes | Installed, updated, opened and backgrounded. Sessions end after 30 minutes idle. |
| Offline queue | Yes | Yes | Events are written to disk and retried until delivered. |
| Surveys | Built-in SwiftUI card | Built-in Compose card | Event triggers and branching. Advanced eligibility rules aren't evaluated on mobile yet. |
| Announcements | Native sheet | Native activity | Feed, detail, call to action, reactions and an unread count. |
| Feedback | Native form | Native form | Board picker and an optional screenshot of the current screen. |
| Messenger | Native sheet | Native activity | Ask AI, support conversations with live replies, and your help center in an in-app web view. |
| Product tours and checklists | No | No | Available in the web SDK only. |
How the SDKs work
Each SDK has a small core that queues events, tracks identity and sessions, and talks to the Userorbit API. Calls you make before setup finishes are buffered and keep their original timestamps, so you can track events from the first line of your app.
The in-app screens are built on the same core. You can use the built-in screens, or call the data methods (for example fetchAnnouncements or submitFeedback) and draw your own interface. Neither SDK swizzles methods or patches system classes.
Survey targeting, announcement content, feedback boards and messenger settings all come from your Userorbit workspace. You change them in Userorbit, not in app code, and they reach installed apps without a new release.