Weekly platform, competitor and sector sweep for the Countly SDK fleet. Window 21 to 28 September 2026.
The Apple deployment-target item is no longer contested, and it is no longer a P1. Two maintainers filed issues on 16 September carrying the same verbatim error text, from projects that actually opened Xcode 27. Apache Cordova's is already closed; React Native's is still open and is the one that matters to us. It establishes the mechanism precisely: Xcode 27 turns a below-range deployment target from a warning into a hard build error, the supported range starts at iOS 15.0, and CocoaPods resource-bundle targets keep the value from their podspec because the standard app-side post-install lift only walks native_target. countly-sdk-flutter-bridge's podspec is exactly that shape: s.ios.deployment_target = '10.0' together with an s.resource_bundles entry for its PrivacyInfo bundle. A Flutter app that installs our plugin on Xcode 27 fails to build, and the workaround every app template ships does not reach the target that fails.
Re-reading origin/staging today also showed last week's count was low. Ten files across four repos declare a deployment target below the Xcode 27 floor, not five. The new rows are the legacy Countly-PL.podspec pair and the whole vendored ios/src/ tree inside the React Native bridge, which carries its own copy of the iOS SDK's podspecs and Package.swift at iOS 10. Against that, countly-sdk-swift is the one Apple-facing repo already in range at .iOS(.v15) .macOS(.v12) .tvOS(.v15) .watchOS(.v9), which is worth saying out loud: the target state already exists in the fleet, in a repo that shipped this week.
That repo is also the week's documentation finding. countly-sdk-swift 26.8.0 landed on 24 September as an "Initial release" with a very large public API, and the knowledge base contains zero mentions of it. Not an article, not a row in the SDK repos table, not a string anywhere under Knowledge Base/. Meanwhile the shortest fuse in the building is still Sonatype's: three days to the Maven Central commercial-nature deadline, unchanged and re-verified against the source today. Zero PRs, because the one P0 needs a minimum-platform decision a human has to make.
Escalated from P1. Last week this page said the severity was contested: a LaunchDarkly PR called it a build failure, a Datadog issue called the same diagnostic a warning, and Apple's own Xcode 27 release notes would not render. Two maintainer-filed issues dated 16 September settle it, both quoting the same error string:
error: 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.x
deployment-target preference "helps only partially. It fails on Pods.xcodeproj." That is the confirmation that a dependency's declared target, not just the app's, triggers the error.react_native_post_install lifts pod targets through ReactNativePodsUtils.updateOSDeploymentTarget, but "that method only iterates target_installation_result.native_target. Each pod's resource_bundle_targets (PrivacyInfo bundles, asset bundles) are never visited, so they keep the podspec value and Xcode 27 rejects them."countly-sdk-flutter-bridge · countly-sdk-ios · countly-sdk-react-native-bridge · countly-sdk-unity
Why the Flutter bridge is the P0 and the rest are P1. For a plain source pod, the app's post-install hook lifts the pod target and the build survives; the customer has a workaround. Our Flutter podspec is the exception, read from origin/staging today:
| Line | ios/countly_flutter.podspec |
|---|---|
| 15 | s.resource_bundles = { 'countly_flutter_privacy' => ['countly_flutter/Sources/countly_flutter/countly-sdk-ios/PrivacyInfo.xcprivacy'] } |
| 18 | s.ios.deployment_target = '10.0' |
A privacy resource bundle plus a below-range deployment target is the precise failure shape RN #58555 describes. The bundle target inherits 10.0, the post-install lift never visits it, and the build stops. What breaks: any Flutter app building against Xcode 27 with countly_flutter in its Podfile. By when: already, for anyone who has updated Xcode.
The full below-range inventory, re-read from origin/staging this run. Ten files, four repos, against last week's five:
| Repo | File | Declares | |
|---|---|---|---|
| countly-sdk-flutter-bridge | ios/countly_flutter.podspec | ios 10.0 + resource_bundles | P0 shape |
| countly-sdk-flutter-bridge | ios/countly_flutter/Package.swift | .iOS(.v10) | |
| countly-sdk-ios | Package.swift | .iOS(.v12) .macOS(.v10_14) .tvOS(.v12) .watchOS(.v4) | |
| countly-sdk-ios | Countly.podspec | ios 12.0 · osx 10.14 · watchos 4.0 · tvos 12.0 | |
| countly-sdk-ios | Countly-PL.podspec | ios 10.0 · tvos 10.0 · watchos 4.0 | newly counted |
| countly-sdk-react-native-bridge | CountlyReactNative.podspec | ios 10.0 · tvos 10.0 · watchos 4.0 · osx 10.14 | |
| countly-sdk-react-native-bridge | ios/src/Countly.podspec | ios 10.0 · tvos 10.0 · watchos 4.0 | newly counted |
| countly-sdk-react-native-bridge | ios/src/Countly-PL.podspec | ios 10.0 · tvos 10.0 · watchos 4.0 | newly counted |
| countly-sdk-react-native-bridge | ios/src/Package.swift | .iOS(.v10) .macOS(.v10_14) .tvOS(.v10) .watchOS(.v4) | newly counted |
| countly-sdk-unity | ProjectSettings/ProjectSettings.asset | iOSTargetOSVersionString: 10.0 · tvOSTargetOSVersionString: 10.0 |
Two corrections to last week follow from this. First, the count. Second, last week's note that the React Native bridge has "no Package.swift, nothing" was wrong in letter though right in spirit: ios/src/Package.swift exists and has since 25 September 2024, but it is a vendored copy of the iOS SDK's manifest (name: "Countly", swift-tools-version:5.3), not an SPM manifest for the bridge. The accurate statement is that the bridge still has no SwiftPM manifest of its own, and the vendored one adds a below-range file.
One repo is already correct. countly-sdk-swift's Package.swift declares .iOS(.v15) .macOS(.v12) .tvOS(.v15) .watchOS(.v9) .visionOS(.v1) at swift-tools-version:5.9, and ships no podspec at all. It needs nothing.
ios/countly_flutter.podspec only, because that is the one a customer cannot work around. No PR opened. §7 forbids the radar from bumping a minimum platform version: it is a breaking change and a human decision. The flutter-bridge Apple files are also carrying in-flight SwiftPM work merged on 15 September, so a radar commit there would collide.
Re-verified against Sonatype's 8 September clarification today. Nothing has moved: no amendment after 15 September, no extension, no softening of the test. From 1 October 2026, Publisher Pro is required if either you exceed the free thresholds or "any artifact you publish has a commercial nature, regardless of your organization's publishing volume."
countly-sdk-android · countly-sdk-java
The definition is unchanged and still leads with our exact shape: "An artifact has a commercial nature if it supports the adoption, integration, or operation of your organization's commercial product or service," with the enumerated examples beginning "service-dependent SDKs." Both repos publish through SONATYPE_HOST=CENTRAL_PORTAL, as ly.count.android and ly.count.sdk, with no publish workflow in either repo: releases are manual.
The escape hatch is also unchanged and is still the whole argument: "Being maintained by a company does not automatically make an open-source project commercial in nature. The relevant question is whether the artifact is part of a commercial product, service, or go-to-market motion." Organizations publishing a mix "may request per-artifact or per-group-ID review for the community artifacts."
ly.count.android and ly.count.sdk before 1 October, arguing genuine community open source against Community Edition. Fallback: budget Publisher Pro. Not PR-able: a Central Portal account action, no repo file changes. 3 days.
Queried api.nuget.org directly this run rather than resting on the 7 September check. The Countly package's publish history:
| Version | Published | |
|---|---|---|
| 26.1.0 | 2026-08-13 | Before the 17 August cutoff → key expires 1 November |
| 25.4.3 | 2025-12-11 | |
| 25.4.2 | 2025-11-10 |
countly-sdk-windows
What breaks: from 1 November 2026 every NuGet.org API key created before 17 August 2026 expires, and new keys are capped at 30 days. Our most recent publish predates the cutoff, so whatever key performed it dies on that date and the next release cannot be pushed. Note the nuspec on origin/staging reads 26.1.0, matching what is live: there is no unreleased version waiting.
ci.yml (it already builds net35/net45/netstandard2.0 but has no pack or push step) and register the matching policy on nuget.org. Not PR'd: the workflow half is mechanical, but it is inert without the nuget.org policy, which needs package-owner access the radar does not have. Opening half of it would be a draft that cannot be tested. 34 days.
New this week. countly-sdk-swift merged PR #5 on 24 September across three commits, and CountlyConsts.swift on origin/staging now reads static let version = "26.8.0". Its changelog opens "Initial release of the Countly Swift SDK." The surface is not small: multi-instance entrypoints, instance lifecycle, and separate events, views, sessions and userProfile namespaces, plus a new CountlySwiftUI.swift exposing a .countlyView(_:) view modifier. The same PR pair added roughly 1,200 lines of crash-handling and view-tracking work with matching tests.
countly-sdk-swift
Verified against ~/GitHub/countly-backup-documentation by listing and grepping, not by assuming:
| Check | Result |
|---|---|
Article under Knowledge Base/SDK Specs/ | None. 14 files; Swift is not one of them |
grep -rl "countly-sdk-swift" "Knowledge Base/" | Zero matches anywhere in the knowledge base |
Row in SDK_Repos_and_Features | Absent. The table still lists retired cocos and appcelerator-titanium entries, and omits swift, js and hos |
Per the standing rule that a newly published SDK with no doc is the highest-value gap we can have, this is the one to write. It is also the cheapest it will ever be: the changelog for 26.8.0 is already written as a near-complete API reference, so the article is largely a restructuring job rather than a discovery job.
Knowledge Base/SDK Specs/ article for the Swift SDK, seeded from the 26.8.0 changelog, and add swift, js and hos rows to SDK_Repos_and_Features while removing the retired ones. No PR: §5 is explicit that writing a doc is authorship, not a mechanical fix, so this is a proposal. DocC is a cheap follow-on, since the package is SPM-only and already at swift-tools-version:5.9.
Carried since the 0.88.0-rc.0 sweep as a contract change the bridge would have to read before its next cycle. 0.88.0-rc.2, published 22 September, reverts it: "0.88 is a non-breaking release, and the change stopped modules that adopted ObjC ArrayBuffer support in 0.87 from compiling." The companion codegen rejection of ArrayBuffer as a TurboModule EventEmitter payload was reverted for the same reason. rc.2 also restored the .js fallback for legacy react-native/Libraries/* deep imports under the react-native-legacy-deep-imports condition. Our bridge declares codegenConfig but touches neither ArrayBuffer nor InitializeCore, so both reverts are neutral for us: what they retire is the obligation to check. 0.87.1 is still the latest stable; 0.88 stable is due 12 October and stays on the watchlist for the node_modules crawling change, which was not reverted.
posthog-android 3.71.0 (25 September) added a compression config (PostHogCompression.GZIP / NONE) "so an app can send request bodies uncompressed, e.g. when a managed Android work profile alters the compressed body in transit." That is a real and unpleasant field failure, and worth knowing about. Swept origin/staging for gzip, GZIPOutputStream and Content-Encoding across countly-sdk-android/sdk/src/main, countly-sdk-ios sources and countly-sdk-web/lib/countly.js: zero matches in all three. We send uncompressed bodies everywhere, so the failure mode cannot occur and the new config has nothing to configure. The inverse observation is the one to file rather than this one, and it is P3 below.
Last week the date was carried as unverified: a two-week cadence implied 22 September, press coverage said "October", and developer.chrome.com/release-notes/154 was still 404. The page now resolves and gives 22 September 2026. Reading it end to end, nothing in 154 changes our transport. The HTTPS-by-default prompt is confirmed as governing navigations, which was already the basis for closing it. The fetch change exposes an AbortController reason on Response methods, additive. Background Fetch now enforces CORS and requires Local Network Access permission, and we do not use Background Fetch anywhere. No mention of referrer policy, cookies, storage partitioning, sendBeacon or CSP.
Worth stating rather than omitting, because four separate Apple items are carried. developer.apple.com/news/ has no item dated between 20 and 28 September: it runs 18 September (iPhone Duo resources, Xcode 27.1 beta), then 16 September three times (iOS 27.2 betas, subscriptions, the EU ATT change), then jumps back to 9 September. So the April 2027 SDK requirement, the EU ATT prompt and the iPhone Duo items are all unchanged, and the silence is the finding.
sentry-cocoa 9.29.1 (24 Sep) added "experimental support for the new URLSession HTTP loader for automatic network instrumentation." Noted only because it implies iOS 27 ships a new URLSession loader path; we consume NSURLSession but do not instrument it, so there is no surface. 9.29.2 (25 Sep) fixes a MetricKit crash when statically linked without -ObjC.android.newDsl.optOut escape from the new Variant API is likewise moot: countly-sdk-android has zero legacy Variant API usage. Nothing reopens.countly-sdk-web/lib/countly.js's fetch() call passes method, headers, body, signal and nothing else, so the browser default strict-origin-when-cross-origin sends the full page URL and query string in Referer on same-origin Countly deployments. countly-sdk-js has no referrerPolicy either. posthog-js moved theirs to strict-origin on 14 September. Our deliberate referrer collection is a separate code path and unaffected.countly-sdk-nodejs on origin/staging reads 24.10.4 in package.json, with still no engines field, sixth week. Unchanged call: the radar will not PR this, because declaring a floor where none existed can fail an existing consumer's install. It is a release-time decision for a human.countly-sdk-unity is still pinned to editor 2020.3.20f1 and still at SDK 24.8.2, the oldest version in the fleet. The pin is what makes every Unity claim on this page unverifiable by building, and it is what carries iOSTargetOSVersionString: 10.0 into the P0 above.--release 8, so countly-sdk-java's Java 8 source/target is unaffected this cycle. Its gradle.properties reads VERSION_NAME=26.8.0 on origin/staging, bumped 8 September.countly-sdk-dart HTTPS still untested.cmake_minimum_required(VERSION 3.13...3.31) remains above the 4.x floor.What it is. From posthog-android v3.68.0, Android apps can opt into semantic interaction autocapture and frustration signals independently of session replay. Two opt-in switches: captureElementInteractions emits privacy-safe $autocapture events with element types, resource IDs / test tags, hierarchy position, touch event type and window-local coordinates in dp, and explicitly never text or input values. Separately, rage and dead tap detection covers both Views and Jetpack Compose.
The heuristics, which are the whole point. $rageclick fires on four nearby taps on the same target within one second, with bounded history and one emission per continuous burst. $dead_click fires after three seconds without an observed meaningful UI response. Neither requires ordinary interaction events, and neither requires replay.
countly-sdk-android · countly-sdk-ios · countly-sdk-web · countly-sdk-js
Do we have it? No. Grepped origin/staging for rageClick|rage_click|deadClick|dead_click across countly-sdk-web, countly-sdk-js, countly-sdk-android and countly-sdk-ios, excluding vendored and test trees: zero matches in all four. The only touch handling anywhere in countly-sdk-android/sdk/src/main is ContentOverlayView.java, which belongs to the content feature.
Worth it: yes, and this is the cheapest thing on the page. The standing session-replay gap is a cross-SDK contract we are not about to close. This is the opposite: a tap-timestamp ring buffer and two thresholds, emitting an ordinary custom event through the queue we already have. No new endpoint, no new module, no storage format, no server change beyond naming two events. The design detail worth copying verbatim is the decoupling PostHog deliberately made frustration signals work with replay off, which is what turns it from an infrastructure project into a small feature. Effort: small, one SDK, Android first per the Android-as-canonical convention.
sentry-java 8.58.0, 23 September. Adds dataCollection, "a fine-grained replacement for sendDefaultPii, for controlling data collected automatically by SDK integrations," with sendDefaultPii marked for removal in the next major. Categories are individually configurable: userInfo, cookies, httpHeaders.request, httpHeaders.response, httpBodies, urlQueryParams, graphql.document, graphql.variables, databaseQueryData, filePaths. Several support three modes OFF, deny-list, allow-list defaulting to deny-list with an empty term list.
The migration design is the part worth stealing, independently of the feature: when dataCollection is unconfigured the old boolean's behaviour is preserved exactly; configuring any category makes the new config the sole source of truth and the old boolean is ignored. That is a clean way to replace a coarse flag without a breaking change, and we will need exactly that pattern the next time a config option outgrows its type.
Worth it: as a pattern, yes. As a feature, not yet. Countly's consent model is feature-group-based, which answers "may we collect analytics" rather than "which fields may an automatic integration attach". The gap only becomes real once we have automatic integrations rich enough to attach headers and bodies which is the same place the Hints API steal from sentry-cocoa 9.28.0 points. Effort: large, cross-SDK contract. File as a design note, not a task.
23 September. The release opens: "The goal of this release is to be better compatible with OpenTelemetry … and make span streaming and more permissive data collection the default." Three breaking changes matter to our own OTel work, all of them naming decisions:
http.* span attributes" and "Rename deprecated net. span attributes" a major vendor taking a breaking release to move onto OTel semantic-convention names.skipOpenTelemetrySetup with enableOpenTelemetrySetup" the negative opt-out flag became a positive opt-in flag.>=20.19.0.countly-sdk-js
Worth it: yes, as a constraint on the work already in flight. We are pre-1.0 on OTel, so we get the renames for free by naming attributes to semconv from the start, and we get the flag shape for free by making OTel setup a positively-named opt-in. Sentry paid a major version for both. Effort: free, if applied before anything ships.
dd-sdk-ios 3.18.0 (21 Sep) adds CPU-time samples alongside wall-time for launch and continuous profiling, and migrates DatadogProfiling to Swift 6. dd-sdk-android 3.14.1 (21 Sep) propagates crashReportingEnabled from remote configuration into core config.unified, session-replay-browser and the Segment replay plugin (25 Sep). Nothing substantive.This page has said for several weeks that OTel upstream was "static seven weeks: spec 1.60.0." That was wrong. Queried through the GitHub releases API this run:
| Component | Newest | Published |
|---|---|---|
| opentelemetry-specification | v1.61.0 | 2026-09-14 |
| semantic-conventions | v1.44.0 | 2026-08-04 |
| opentelemetry-js | v2.11.0 / experimental 0.222.0 | 2026-08-31 |
Reading 1.61.0's contents, though, the conclusion survives the correction. It is metrics-, resource- and Prometheus-facing: view_matching_mode on MeterProvider, maxExportBatchSize clarified and stabilised on the periodic metric reader, a service resource detector fallback, an AttributeValueDepthLimit for nested attribute values, and Prometheus content-negotiation stabilisation. The one context change is softening "recommend instead of require global propagators." Nothing in it changes a client-side or RUM contract. Semantic conventions and the JS implementation are both genuinely static since August, and those are the two that would bind us.
So the standing read holds: a quiet upstream is the cheap window to fix our side, and our side still has no shippable path. countly-sdk-js:otel-telemetry-phase1 carries no OTel code, the real work is uncommitted in the flutter-bridge working tree, and ly.count.android:sdk-otel does not exist on Maven Central. Sentry JS 11's semconv renames above are the free lesson to apply while that is still true.
Beyond the Swift P1 above, the coverage audit turned up a second gap and one piece of rot. Verified by listing Knowledge Base/SDK Specs/ and grepping, not by assuming:
| Gap | Severity | Evidence |
|---|---|---|
countly-sdk-swift has no article and no mention anywhere | P1 | 0 files, 0 grep hits; initial release shipped 24 Sep |
countly-sdk-js has no article of its own | P2 | 0 grep hits under SDK Specs/. Only Web_analytics_JavaScript_ exists, and that documents countly-sdk-web. The modular ESM SDK is undocumented, including the service-worker addition merged on 17 September |
SDK_Repos_and_Features is stale in both directions | P3 | Lists cocos and both appcelerator-titanium repos; omits swift, js and hos, the last of which does have an article |
Twelve of the fourteen shipping SDKs have an article, and HarmonyOS correctly has one despite being the newest. The two missing are both JavaScript-and-Swift-shaped, which is to say both are the newer, modular rewrites rather than the legacy SDKs. That is the pattern to watch: our docs track the old surface well and the rewrites not at all.
countly-sdk-js article out of the Web article, or state explicitly in the Web article that the modular SDK exists and where it lives.SDK_Repos_and_Features in one pass: add swift, js, hos; drop cocos and titanium.| When | Platform | What happens |
|---|---|---|
| 2026-09-30 | android | Play developer verification enforcement begins in BR, ID, SG, TH. No SDK surface; expect customer questions |
| 2026-10-01 | java/android | Maven Central commercial-nature test takes effect. Per-group-ID review must be requested before this date |
| 2026-10-01 | apple | EU App Store business terms; Core Technology Commission 5% replaces CTF. Host-app concern |
| 2026-10-12 | react-native | RN 0.88 stable. Remaining item is Codegen no longer crawling node_modules or following symlinks; the ArrayBuffer items were reverted in rc.2 |
| 2026-10 | nodejs | Node 26 becomes Active LTS. countly-sdk-nodejs still declares no engines, sixth week. P2, not PR-able |
| 2026-11-01 | dotnet | All pre-17-Aug NuGet API keys expire. Countly 26.1.0 published 2026-08-13, confirmed pre-cutoff |
| 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 27.2 alternative EU ATT prompt, mandatory in DE, FR, IT, PL, RO. Cleared as an SDK item; support macro only |
| 2027-02 | android | Play quality requirements: dynamic memory, background bitmap memory, 25% DEX optimisation via R8. Measured on the app |
| 2027-04 | apple | App Store Connect requires platform 27 SDKs. Fourth week: the upcoming-requirements page still does not list it. Binds apps, not libraries |
| 2027-12 | unity | Unity 6.3 LTS support ends. 6.6 is now the current Supported release, not a beta |
| open | apple | P0. Ten below-range deployment-target declarations across four repos. Needs a human minimum-bump decision; ship with Xcode 27 verification as one release |
| open | apple | Wrong comment in flutter-bridge ios/countly_flutter/Package.swift: claims the vendored iOS SDK targets iOS 10, but countly-sdk-ios declares 12 in both Package.swift and Countly.podspec. Fix alongside the floor decision |
| open | react-native | Bridge still has no SwiftPM manifest of its own. ios/src/Package.swift exists but is a 2024 vendored copy of the iOS SDK's manifest |
| open | docs | P1. No Swift SDK article. P2: no countly-sdk-js article. P3: SDK_Repos_and_Features stale both directions |
| open | web | One-line referrer steal: no referrerPolicy on the fetch() in countly-sdk-web or countly-sdk-js |
| open | competitors | Rage/dead tap detection: zero of fourteen SDKs. PostHog's thresholds are 4 taps/1 s and 3 s no-response, replay not required |
| open | competitors | Session replay: still zero of fourteen. No app-hang/ANR detection on any Apple SDK. Hints API and hybrid-SDK envelope steals from Sentry still outstanding |
| open | otel | No shippable path on our side. Upstream semconv and opentelemetry-js static since August; spec moved to 1.61.0 on 09-14 with nothing client-side |
| open | bridges | Flutter AGP classpath 3.2.1 / wrapper 4.10.2, RN 7.0.1 / wrapper 7.2. Both compileSdk 35, both wrapping ly.count.android:sdk:26.1.2 against Android SDK 26.1.5 |
| open | unity | Editor pin 2020.3.20f1 blocks all verification. SDK still 24.8.2, oldest in the fleet |
| open | dart | Dart 3.13 root-certificate removal still untested against countly-sdk-dart, and the 3.13-vs-3.12.2 contradiction is unresolved |
| open | debt | HarmonyOS unverified, fifth week. Huawei release notes timed out again. Needs a different access route, not another retry |
developer.apple.com/documentation/xcode-release-notes/* and the canonical redirect both return title-only markup. Every Xcode 27 claim on this page rests on maintainer-filed GitHub issues quoting the compiler's own error string (cordova-ios #1723, react-native #58555), which is convergent but is not Apple's documentation.native_target but not resource_bundle_targets is quoted from React Native's CocoaPods script. Flutter ships its own post-install helper, which this run did not read. If Flutter's helper happens to walk resource bundles, the P0 drops to P1. The below-range declarations themselves are read directly from origin/staging and are not in doubt.pod install, no Gradle sync. Everything above is read from source and from upstream release notes.targetSdkVersion is 6.0.2(22).CHANGELOG.md, which carries no dates.unity.com; the editor archive is a nav page that returns no readable content.