Weekly platform, competitor and sector sweep for the Countly SDK fleet. Window 14 to 21 September 2026.
The Apple deployment-target item stopped being contested and started being expensive. LaunchDarkly opened a PR on 16 September and merged it on the 17th raising iOS/tvOS 13 → 15, watchOS 6 → 9 and macOS 10.15 → 12, describing Xcode 27 as failing the build by default. React Native 0.88.0-rc.1, the same day, changed its SwiftPM manifests to derive the iOS floor from the app's deployment target instead of hardcoding iOS 15, meaning RN core was already sitting at 15. Meanwhile our own exposure grew: countly-sdk-flutter-bridge merged SwiftPM support on 15 September and shipped a brand-new Package.swift declaring .iOS(.v10), the lowest floor anywhere in the fleet, justified by a comment that is factually wrong about the SDK it vendors.
The finding with the shortest fuse is not Apple's. Sonatype changed the test for who has to pay to publish on Maven Central, and the deadline is 1 October: ten days. This page has carried that date for a month as "numeric limits unpublished, our cadence is far under them, monitor only." That framing is now wrong. As of an 8 September clarification, volume is only one of two triggers: Publisher Pro is also required if any artifact you publish "has a commercial nature," explicitly including "service-dependent SDKs … distributed as part of a commercial offering," regardless of volume. We publish ly.count.android and ly.count.sdk through the Central Portal. There is an escape hatch: Sonatype states that company maintenance alone does not make a project commercial, and offers per-group-ID review, but it has to be asked for, and nobody has asked.
Against that, five things were retired. AGP 10 will make the new Variant API mandatory and countly-sdk-android has no legacy Variant API to migrate: all ten tracked Gradle files swept, zero matches. Apple's new EU App Tracking Transparency prompt has no surface on us because our iOS SDK never calls ATT and never links AdSupport; it only accepts an IDFA the host app hands it. PostHog's back/forward-cache retry bug is not reproducible against our request queue. Chrome 154's HTTPS default gates navigations, not subresource fetches. And CMake 4.4.3 still configures countly-sdk-cpp fine. Zero PRs, and the cheap steal of the week is one line long.
New this week in effect, published 8 September. Sonatype's clarification of publisher tiers states that from 1 October 2026 Maven Central Publisher Pro is required if either condition holds: your organization exceeds the free publishing thresholds without an exemption, or (and this is the new part) "any artifact you publish has a commercial nature, regardless of your organization's publishing volume."
The definition: "An artifact has a commercial nature if it supports the adoption, integration, or operation of your organization's commercial product or service." The enumerated examples begin with "service-dependent SDKs" and go on through "generated clients, drivers, agents, integrations, platform components, build tooling, developer tools, and other software distributed as part of a commercial offering."
countly-sdk-android · countly-sdk-java
Read from origin/staging this run, both publish through the Central Portal, so both are inside the policy:
| Repo | Group ID | Publishing route | Publish workflow in .github/workflows/ |
|---|---|---|---|
| countly-sdk-android | ly.count.android | SONATYPE_HOST=CENTRAL_PORTAL | None: build/test, CodeQL, dependency-security, gradle-validator, release-notice |
| countly-sdk-java | ly.count.sdk | SONATYPE_HOST=CENTRAL_PORTAL | None |
Why this is P1 and not P0. Sonatype also writes that "Being maintained by a company does not automatically make an open-source project commercial in nature" and that the real question is whether the artifact participates in the company's commercial go-to-market. There is a genuine argument on our side: these SDKs are permissively licensed and work fully against Countly Community Edition, which is not a paid product. That argument is winnable, but it is an argument someone has to make, in a review request, before the date. Doing nothing and being classified the other way blocks publishing.
Volume is not our problem and stays that way. The published 90th-percentile figures are roughly 1,167 files, 78 MB release size and 7 releases per month; our cadence is nowhere near any of them, and Sonatype's enforcement is graduated: a grace period on first overage, blocking only on a sustained pattern. The volume half of this item can be retired. The commercial-nature half replaces it and is larger.
ly.count.android and ly.count.sdk, arguing genuine community open source, before 1 October. Fallback is to budget Publisher Pro for the org. Not PR'd and not PR-able: this is a nuget-style account action on the Central Portal, no file in any repo changes. 10 days.
Carried from last week, materially worse. Two dated, in-window data points from projects that actually opened Xcode 27:
ios-client-sdk #528: opened 16 September, merged 17 September. Raises iOS/tvOS 13 → 15, watchOS 6 → 9, macOS 10.15 → 12 across Package.swift, the podspec, the xcodeproj and the contract tests. The description states Xcode 27 "fails the build by default" with The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 13.0, but the range of supported deployment target versions is 15.0 to 27.0.countly-sdk-ios · countly-sdk-flutter-bridge · countly-sdk-react-native-bridge · countly-sdk-unity
Re-read from origin/staging today. One row is new since last edition:
| Repo | File | Declares | |
|---|---|---|---|
| countly-sdk-flutter-bridge | ios/countly_flutter/Package.swift | .iOS(.v10) | new 15 Sep |
| countly-sdk-ios | Package.swift | .iOS(.v12) .macOS(.v10_14) .tvOS(.v12) .watchOS(.v4) .visionOS(.v1) | |
| countly-sdk-ios | Countly.podspec | ios 12.0 · osx 10.14 · watchos 4.0 · tvos 12.0 · visionos 1.0 | |
| countly-sdk-flutter-bridge | ios/countly_flutter.podspec | ios 10.0 | |
| countly-sdk-react-native-bridge | CountlyReactNative.podspec | ios 10.0 · tvos 10.0 · watchos 4.0 · osx 10.14 | |
| countly-sdk-unity | ProjectSettings/ProjectSettings.asset | iOSTargetOSVersionString: 10.0 · tvOSTargetOSVersionString: 10.0 |
The new row deserves its own paragraph. countly-sdk-flutter-bridge merged PR #394 (swiftpm-support-ios) on 15 September and released 26.1.1. Good work, and the CHANGELOG correctly flags the Notification Service Extension path move as a minor breaking change. But the new manifest declares the lowest Apple floor in the entire fleet, and the comment justifying it says:
// Matches the vendored Countly iOS SDK (its Package.swift and podspecs all target iOS 10), // and this plugin's own CocoaPods podspec (10.0).
The parenthetical is wrong. countly-sdk-ios on origin/staging declares .iOS(.v12) in Package.swift and ios 12.0 in Countly.podspec. The vendored submodule's own floor is 12, not 10, so .iOS(.v10) advertises support for two OS versions the vendored source does not claim. The stated reason for the floor, "SwiftPM rejects a package minimum higher than the app target": is a real constraint, but it argues for matching the vendored SDK, not for going below it.
Still P1, not P0, and the reason is unchanged: the severity contradiction is unresolved. LaunchDarkly's PR and one third-party write-up say the build fails; Datadog's dd-sdk-ios #2978 describes the same diagnostic as a warning. One reconciliation fits both: the blog's quoted text reads "The iOS Simulator deployment target…", so simulator builds may error where device builds warn. That is a hypothesis, not a verified fact, and settling it requires opening Xcode 27, which this radar cannot do. Apple's own Xcode 27 release notes have now failed to render on four separate attempts across two runs, including through Apple's canonical developer.apple.com/go/?id=xcode-27-sdk-rn redirect.
platforms in countly-sdk-ios's Package.swift and podspec to iOS 15 / tvOS 15 / watchOS 9 / macOS 12, then the two bridge podspecs, the new Flutter Package.swift, and the Unity project setting. Deliberately not PR'd: raising a declared minimum platform version is a breaking change for integrators. The one piece that is not a breaking change and should happen regardless: correct the false claim in the new Package.swift comment, because the next person to weigh this decision will read it and be misled.
Countly 26.1.0 dies in 41 daysCarried, clock moved, one correction. NuGet.org expires every API key created before 17 August 2026 on 1 November 2026; new keys are capped at 30 days. Re-confirmed against Microsoft's announcement this run. Countly 26.1.0 was published on 13 August 2026, established two runs ago and still not re-queried: so the key in use is a long-lived pre-cutoff key.
countly-sdk-windows
Correction to last week. This page said countly-sdk-windows contains "only release_notice.yml." It also contains ci.yml, added 2 July 2026. Reading it changes nothing about the finding: it triggers only on pull requests into staging and does test and build work (net8.0-windows UI tests, then msbuild across net35/net45/netstd) with no publish or pack job and no NuGet push. Releases still go out by hand. What it does change is the effort estimate: there is now a working Windows CI file with .NET set up, so Trusted Publishing is a job appended to an existing workflow rather than a workflow invented from nothing.
countly-sdk-windows/.github/workflows/ci.yml (or a sibling release workflow) and register a Trusted Publishing policy on nuget.org, or accept a 30-day manual key-rotation cadence from November. Not PR'd: needs nuget.org owner access and a decision on whether Windows releases move to CI at all; a publish workflow is not a mechanical edit. 41 days.
countly-sdk-androidAGP 9.4.0 shipped this month (page last updated 18 September) and carries the migration warning: "Starting with AGP 10, the new Variant API is mandatory for all projects. To support a gradual migration, you can temporarily opt specific modules out of this requirement before AGP 10" via android.newDsl.optOut=:module in gradle.properties. That is the kind of notice that normally means work.
It does not here. Swept all ten tracked Gradle files on origin/staging: build.gradle, settings.gradle, sdk/, sdk-native/, app/, app-kotlin/, app-native/, app-benchmark/, upload-plugin/ and the CI init script, for libraryVariants, applicationVariants, variantFilter, androidComponents, onVariants and registerTransform. Zero matches. The single hit for the word "variant" anywhere is a prose comment in .github/scripts/dependency-report.init.gradle about unresolvable configurations. No android.newDsl.optOut is needed because there is nothing to opt out.
Headroom is comfortable in the other direction too. AGP 9.4 requires Gradle 9.6.0 minimum and JDK 17, and supports up to API level 37. We are on AGP 9.3.2, Gradle 9.7.1, Kotlin 2.4.10, compileSdk/targetSdk 37: above every floor and exactly at the ceiling. The AGP 10 legacy-DSL row on the watchlist, half-closed on 7 September, closes fully for the Android SDK itself. It stays open for the two bridges, which still pin AGP classpaths of 3.2.1 and 7.0.1.
Apple, 16 September: beginning with iOS 27.2 and iPadOS 27.2, developers get an alternative version of the ATT system prompt in the EU, arising from agreements with European competition authorities. Use of the alternative prompt is optional across the EU but mandatory for apps distributed in Germany, France, Italy, Poland and Romania. Apple is explicit that the rules for when permission must be sought are unchanged.
countly-sdk-ios is not in this path at all. Swept origin/staging across *.m, *.h and *.swift for ATTracking, AdSupport, advertisingIdentifier and trackingAuthorization: no import, no framework link, no call. Every IDFA reference is a value the host app hands us: CLYAttributionKeyIDFA in CountlyConfig.h, the idfa query key in CountlyConnectionManager.m, and the documented recordIndirectAttribution entry point. We never raise the prompt, so which prompt is raised is not ours.
The privacy manifest is consistent with that and needs no edit: PrivacyInfo.xcprivacy declares NSPrivacyCollectedDataTypeTracking = false on every collected type, and the only accessed-API reasons are UserDefaults (CA92.1) and disk space (7D9E.1). Support angle only: a customer shipping into those five countries who gets no ATT consent will hand us a zeroed IDFA, and their attribution numbers will move. That is worth a support macro, not a code change.
posthog-js shipped a fix on 14 September for "lost event retries after restoring a page from the back-forward cache." That is a general failure mode for any SDK with a single-flight send guard: the page freezes mid-request, the in-flight fetch is discarded, the guard is never released, and the queue is silently dead for the rest of the page's life.
Traced it in countly-sdk-web on origin/staging. The guard is #readyToProcess. It is set false immediately before dispatch and restored to true inside the #makeNetworkRequest callback, on both branches, success and error, before resolve(). The fetch path invokes that callback from three places: the response handler, a .catch(...) on the promise chain, and an outer try/catch around the whole attempt, the latter two both calling callback(true, params). A fetch aborted by bfcache entry rejects, the catch fires, the guard is released and the failed request stays at the head of the queue for the next attempt. No stall path found.
Adjacent and not a defect, but worth knowing: session end is wired to beforeunload, while pageshow/pagehide feed only the onchange visibility handler that starts and stops the session timer. beforeunload is the unreliable one on mobile Safari and Chrome. That is a pre-existing design question about session-duration accuracy, not something this week changed, and it is not what PostHog fixed.
Chrome 154 turns on Always use secure connections in its public-sites-only variant by default: Chrome attempts HTTPS first and shows a bypassable interstitial before loading a public site over HTTP. Private network addresses (router pages, local IPs) are exempt, which is the point of the "public sites only" variant.
The mechanism is top-level navigation. countly-sdk-web reaches the server through a subresource fetch() (and an image fallback), which has never been governed by HTTPS-First and is already governed by mixed-content blocking: an HTTPS page calling an HTTP Countly endpoint is blocked today, in every browser, and has been for years. Nothing in 154 changes what our transport can or cannot do. P3
Where it does land is a support question, and it is worth getting ahead of: a self-hosted Countly dashboard served over plain HTTP will start showing an interstitial to its own operators. That is a deployment conversation, not an SDK one.
countly-sdk-cppFollow-through on last week's clear, against the newest toolchain. CMake 4.4.3 was released 2 September 2026. The breaking rule is unchanged and dates to CMake 4.0: compatibility with versions older than 3.5 was removed, and a cmake_minimum_required() setting a policy version below that is now an error rather than a warning.
git show origin/staging:CMakeLists.txt line 1 reads cmake_minimum_required(VERSION 3.13...3.31), comfortably above 3.5, with an upper policy bound that keeps newer CMake behaving as tested. The only other tracked CMakeLists.txt is examples/qt_demo at 3.16. No action, and none expected until CMake removes pre-3.13 compatibility.
CountlyDeviceInfo.m reports the raw hw.machine identifier with no local lookup table, so a new model needs no SDK change; it needs a server-side mapping, or dashboards show a raw identifier. Screen-metric reporting on a two-display device is the open question nobody can answer without hardware.developer.apple.com/news/upcoming-requirements/ still does not list the April 2027 iOS 27 SDK floor, twelve days after Apple announced it in the newsroom. Current in-force requirement remains Xcode 26 / the 26-family SDKs since 28 April 2026. Third consecutive week this page has been checked and found not to carry it.android.enforceDynamicFeatureVariantMatching=true. P3 We ship no dynamic features and declare no flavour dimensions.countly-sdk-android landed setMaxValueSizePicture(int) on 17 September (PR #601) alongside CI fixes: a new internal-limits config for profile-picture URL length.node_modules or follows symlinks when discovering components, and SwiftPM manifests derive the iOS floor from the app's deployment target instead of hardcoding iOS 15. The first is a discovery-contract change and countly-sdk-react-native-bridge does declare codegenConfig. The second is precisely the design question the Flutter bridge just answered differently.Package.swift, no react-native.config.js and no branch in flight: re-verified on origin/staging. Flutter shipped theirs this week. RN is now the only Apple-facing wrapper with nothing.countly-sdk-flutter-bridge 26.1.1 shipped 15 September with SwiftPM support for iOS (PR #394), a parallel device tester, and a fix for async native callbacks crashing with an NPE after Flutter engine detach (hot restart, multi-engine). CocoaPods remains supported. The CHANGELOG correctly marks the Notification Service Extension header/implementation path move as a minor breaking change.docs.flutter.dev/release/release-notes still shows 3.47.x as newest and its own footer is stamped 12 August; the docs site has not moved in over a month. Treated as "no change," not as "verified current."pubspec.yaml declares sdk: ">=2.12.0 <4.0.0", a lower Dart floor than the >=2.19.0 the reference table claimed before last week's correction.countly-sdk-nodejs requires only os, http, https, fs, path and cluster and has zero runtime dependencies; none of this reaches us.package.json still declares no engines field. Re-read from origin/staging, version 24.10.4. Node 26 becomes Active LTS next month and v20 went EOL on 30 April 2026. A one-line "engines": {"node": ">=22"} would state a supported range for the first time. Still P2, still not PR'd: declaring a floor where none existed can fail an existing consumer's install, which makes it a maintainer's call rather than a mechanical fix.countly-sdk-js merged an in-house service-worker addition and the SDK log-gathering feature on 17 September (PRs #54, #55), completing the coordinated Android/iOS/JS log-gathering trio noted last week.countly-sdk-windows targets net35-full, net45 and netstandard2.0, none of which are the patched runtimes. The NuGet key deadline above is the live .NET item.countly-sdk-java remains Java 8 source/target on Gradle 8.14.5; javac 27 still accepts release 8. Obsolescence clock only. The live Java item is Maven Central, above.countly-sdk-unity is still on SDK 24.8.2, the oldest version in the fleet by a wide margin.targetSdkVersion of 6.0.2(22). Fourth week unverified.posthog-js, 14 September: "Default Fetch requests to strict-origin so referrers omit page paths and query strings."
countly-sdk-web's fetch() call passes method, headers, body and signal, and no referrerPolicy. The browser default is strict-origin-when-cross-origin. For the common case where the Countly server is a different origin that is harmless: only the origin is sent. For a same-origin deployment (app and Countly behind one domain, which self-hosters do routinely) the default sends the full URL including path and query string in the Referer header of every single request we make. That lands in the Countly server's access log, permanently, alongside whatever is in those query strings.
Worth it. Adding referrerPolicy: "strict-origin" to the fetch options is a one-line change with no behavioural consequence for analytics: we already collect document.referrer deliberately and separately, through #isReferrerUsable and the ignore_referrers config, and that path is untouched by a fetch-level policy. This is the rare case where the privacy improvement costs nothing. Not PR'd: P2 findings do not open PRs under the rules this radar runs on, and the same gap should be checked in countly-sdk-js before anyone touches either.
replayId now cleared from scope when Session Replay is stopped manually, crash mechanisms marked synthetic for cross-SDK grouping, mechanism.handled = false on crash reports lacking a mach context. Design signal We have no app-hang or ANR detection on any Apple platform at all: swept countly-sdk-ios for MetricKit, watchdog and hang handling and found nothing. If that gap ever gets filled, Sentry's move is the argument for starting at MetricKit rather than building a watchdog thread we would deprecate later.LocalSentrySpan for Compose and on not holding jar file handles open during manifest version detection.opentelemetry-js 2.11.0 and experimental 0.222.0, both 31 August; spec 1.60.0; semconv 1.44.0. The Jaeger propagator and the OpenTracing/OpenCensus shims are slated for removal in SDK 3.x, nominally "around September 2026", and 3.x has not shipped. Our side is unchanged from last week: countly-sdk-js:otel-telemetry-phase1 carries no OTel code, the real work sits uncommitted in the Flutter bridge working tree, and ly.count.android:sdk-otel still does not exist on Maven Central. Upstream being static is the cheap window to land our side; it has now been static for seven weeks.| When | Platform | What |
|---|---|---|
| 2026-09-26 | competitors | PostHog Product Tours stops working across all versions. Evidence against building in-product guidance. |
| 2026-09-30 | android | Play developer verification enforcement begins in BR, ID, SG, TH. No SDK surface; customer-question item. |
| 2026-10-01 | java/android | Maven Central: Publisher Pro required for any artifact of "commercial nature", regardless of volume. ly.count.android and ly.count.sdk both publish via Central Portal. Per-group-ID review must be requested before this date. 10 days. |
| 2026-10-01 | apple | EU App Store business terms take effect; Core Technology Commission 5% replaces the CTF. Host-app concern. |
| 2026-10-12 | react-native | RN 0.88 stable. Codegen no longer crawls node_modules/symlinks; bridge declares codegenConfig. Read RCTArrayBuffer first. |
| 2026-10 | nodejs | Node 26 becomes Active LTS. Fifth week with no engines field in package.json (24.10.4). |
| 2026-10 | unity | Unity 6.0 LTS support ends. 6.3 LTS supported to 2027-12; upstream now shipping 6.6 beta. |
| 2026-11-01 | dotnet | All pre-2026-08-17 NuGet.org API keys expire. Countly 26.1.0 published 2026-08-13. ci.yml exists but is PR-test only. 41 days. |
| 2026-11-10 | dotnet | .NET 8 and 9 end of support. Our TFMs unaffected; watch ecosystem drift off netstandard2.0. |
| 2026-11 | flutter | In-SDK Material/Cupertino formally deprecated. Bridge ships no widgets; exposure limited to example/. |
| 2026-12 | apple | iOS/iPadOS 27.2 brings the alternative EU ATT prompt, mandatory in DE/FR/IT/PL/RO. No SDK surface: support macro only. |
| 2027-02 | android | Play quality requirements: dynamic memory, background bitmap memory, 25% DEX optimisation via R8. Measured on the app: support item. |
| 2027-04 | apple | iOS/iPadOS/tvOS/visionOS/watchOS 27 SDK required by App Store Connect. Still absent from Apple's own upcoming-requirements page. |
| pending | apple | Xcode 27 deployment-target range 15.0 to 27.0. Five files across four repos below it, including the new Flutter Package.swift at .iOS(.v10). Error-vs-warning still unresolved. Human decision. |
| pending | apple | New Flutter Package.swift comment claims the vendored iOS SDK targets iOS 10; it targets 12. Correct it regardless of the floor decision. |
| pending | apple | iPhone Duo: dual-screen device, Xcode 27.1 beta. We report raw hw.machine, so mapping is server-side. Screen-metric behaviour on two displays untested. |
| pending | otel | OTel initiative still has no shippable path. Upstream static seven weeks: the cheap window. |
| pending | bridges | AGP classpath: flutter-bridge 3.2.1 (Gradle wrapper 4.10.2), rn-bridge 7.0.1 (wrapper 7.2), both compileSdk 35, both wrapping ly.count.android:sdk:26.1.2 against Android 26.1.5. AGP 10 item closed for the Android SDK itself, open for these two. |
| pending | react-native | SwiftPM: Flutter shipped 15 Sep, RN core actively maintains manifests, our RN bridge has no Package.swift and no branch. Now the only Apple wrapper with nothing. |
| pending | unity | Editor pinned at 2020.3.20f1, blocking all verification. SDK at 24.8.2, oldest in the fleet. CoreCLR in the editor at 6.8. |
| pending | web | Cheap steal, one line: add referrerPolicy: "strict-origin" to the web SDK's fetch() options. Check countly-sdk-js for the same gap. |
| pending | competitors | Session replay across PostHog, Amplitude, Mixpanel, Sentry, Datadog RUM: zero of our 13 SDKs. Sentry's manual-control API remains the published cross-platform contract. |
| pending | competitors | No app-hang/ANR detection on any Apple SDK. Sentry deprecated its watchdog for MetricKit on 17 Sep: start there if we ever build it. |
| pending | competitors | Cheap steals outstanding: Sentry Cocoa hint payload enrichment (auto-populated HTTP exchange); Sentry hybrid-SDK non-terminating envelope APIs; PostHog route-template pageviews. |
| pending | dart | Dart 3.13 removed built-in fallback root certificates from the VM. Effect on countly-sdk-dart HTTPS still untested. A check, not a finding. |
| pending | hos | HarmonyOS unverified a fourth week. Our targetSdkVersion 6.0.2(22); secondary sources put current at 6.1.1(24). |
developer.apple.com/go/?id=xcode-27-sdk-rn, which resolves to a page containing only the title "Xcode 27 Release Notes." The error-versus-warning question therefore remains open. Evidence for "error": LaunchDarkly PR #528 (merged 17 Sep) says Xcode 27 "fails the build by default"; a third-party write-up says the compiler stops. Evidence for "warning": dd-sdk-ios #2978 describes the identical diagnostic as a warning. Unverified reconciliation: the blog's quoted text names the Simulator deployment target specifically, which would fit simulator-errors/device-warns. That hypothesis is mine, not a source's. Settling it needs Xcode 27 on a machine.chromiumdash.appspot.com/schedule returned no readable content and developer.chrome.com/release-notes/154 404s; the version-specific URL that worked for 153 does not exist yet, which weakly favours the later date. No date is asserted above.developer.huawei.com/consumer/en/doc/harmonyos-releases/overview-611 timed out at 60s this run. The 6.1.1(24) / API 24 claim rests on search-result summaries of that page, not on the page itself. countly-sdk-hos's standing is genuinely unknown.amplitude.com/docs/changelog, docs.mixpanel.com/changelog). Statsig, RevenueCat, Datadog RUM, Heap, Pendo, Segment and Embrace not reached, second consecutive run. These URLs need replacing, not retrying.Countly 26.1.0 (13 August 2026) is still carried from two runs ago and has not been re-queried.origin/<branch> after git fetch in Arif's checkouts. No working tree was modified and no local branch was read.| SDK | origin/staging | Note |
|---|---|---|
| countly-sdk-android | 26.1.5 | AGP 9.3.2 · Gradle 9.7.1 · compileSdk/targetSdk 37 · minSdk 21 |
| countly-sdk-ios | 26.1.4 | iOS 12 / macOS 10.14 / tvOS 12 / watchOS 4 / visionOS 1 |
| countly-sdk-web | 26.1.3 | |
| countly-sdk-js | 26.1.3 | log gathering + service-worker addition merged 17 Sep |
| countly-sdk-nodejs | 24.10.4 | no engines field |
| countly-sdk-flutter-bridge | 26.1.1 ↑ from 26.1.0 | SwiftPM support · Dart >=2.12.0 <4.0.0 · AGP 3.2.1 · wraps android 26.1.2 |
| countly-sdk-react-native-bridge | 26.1.0 | AGP 7.0.1 · compileSdk 35 · wraps android 26.1.2 |
| countly-sdk-unity | 24.8.2 | editor pinned 2020.3.20f1 |
| countly-sdk-java | 26.8.0 | ly.count.sdk · Central Portal |
| countly-sdk-cpp | 26.8.0 | cmake_minimum_required(VERSION 3.13...3.31) |
| countly-sdk-windows | 26.1.0 | net35-full / net45 / netstandard2.0 |
| countly-sdk-dart | 26.1.0 | Dart ^3.0.0 |
| countly-sdk-hos | 26.1.0 | target 6.0.2(22) |