Weekly platform, competitor and sector sweep for the Countly SDK fleet. Window 31 August – 7 September 2026.
No platform shipped anything that breaks us this week. The three P1s on this page are all carried from last week, and the only one whose clock actually moved is Apple: iOS 27 GA is now seven days out, the RC is expected around tomorrow alongside the 9 September event, and countly-sdk-ios has still never been exercised under Xcode 27. The NuGet key finding got sharper rather than resolved — Countly 26.1.0 was published to NuGet.org on 13 August 2026, four days before the cutoff, which converts last week's "the key is almost certainly pre-17-August" assumption into an established fact. The key dies on 1 November.
The more valuable output this week is three corrections to our own picture, all of which make the fleet look better than the radar has been reporting. The Flutter bridge's alarming mavenLocal() dependency on ly.count.android:sdk-otel — reported here last week as something that "will not resolve for an outside contributor" — is not on the branch at all. It is uncommitted work in Arif's local tree, alongside four untracked lib/src/otel*.dart files. Public staging is clean. Second: AGP 10's legacy-DSL removal, carried as an undated worry for both bridges, does not touch us — a sweep for every removed API across the four Gradle-built repos returns zero hits. Third: countly-sdk-windows is at 26.1.0, not the 25.4.3 this page has printed for three weeks.
One genuinely new item deserves attention even though nothing breaks: Chrome moves to a two-week release cycle starting with Chrome 153 on 8 September. The rate at which browser behaviour can change under countly-sdk-web doubles tomorrow, and beta lead time compresses to about three weeks. And a new find in the C++ SDK — the vendored SQLite amalgamation is 3.29.0, from July 2019, last touched in this repo in August 2019. It is opt-in and not remotely exploitable in our usage, but it will trip every enterprise dependency scanner it meets.
Apple announced a special event for 9 September at 10 a.m. PT on 26 August. Reporting converges on the iOS 27 release candidate arriving 8–9 September and GA around 14 September 2026, with iPadOS 27, watchOS 27, tvOS 27 and visionOS 27 alongside. Public beta 6 went out 31 August. Xcode 27 carries the iOS 27 SDK and Swift 6.4.
countly-sdk-ios · countly-sdk-flutter-bridge · countly-sdk-react-native-bridge · countly-sdk-unity
Re-verified this run: the submission floor is still Xcode 26 and the iOS/iPadOS/tvOS/visionOS/watchOS 26 SDKs, in force since 28 April 2026, and developer.apple.com/news/upcoming-requirements/ lists no iOS 27 requirement. This is not a compliance deadline. It is a support-wave deadline: countly-sdk-ios is at 26.1.4 with swift-tools 5.9 and floors of iOS 12 / macOS 10.14 / tvOS 12 / watchOS 4 / visionOS 1, and customers upgrade on day one.
countly-sdk-ios test suite under Xcode 27 beta before 14 September, then the three wrappers that embed it. This escalated from "about two weeks" to "seven days" since the last edition and is the only item on this page whose clock moved. Verification task — nothing to change blind, and nothing the radar can perform.
NuGet.org caps API keys created on or after 17 August 2026 at 30 days, and expires every key created before that date on 1 November 2026. Last week this page assumed our key predated the cutoff. It now does not have to assume: the NuGet registration index puts the publication of Countly 26.1.0 at 2026-08-13 — four days before the cutoff — and 25.4.3 at 2025-12-11. Both were pushed with a long-lived key that will be revoked.
countly-sdk-windows
.github/workflows/ in countly-sdk-windows still contains only release_notice.yml. There is no publish workflow, so the release is pushed by hand from a laptop with a human-held key. Trusted Publishing over OIDC is the recommended replacement and requires a CI publish workflow to exist.
Countly package against a GitHub Actions workflow in Countly/countly-sdk-windows, or accept a 30-day manual rotation cadence. Not PR'd — needs nuget.org owner access and a decision about whether Windows releases move to CI at all. 55 days left.
countly-sdk-cpp still does not configure on any CMake 4.xUnchanged, and re-verified: CMakeLists.txt:1 is cmake_minimum_required(VERSION 3.0), and CMake 4.0 made a version or range not covering 3.5 a hard error. vendor/json/CMakeLists.txt is at VERSION 3.1, same problem. No CMake release this week — 4.4.3 from 25 August is still current, there is no 4.5, and 4.x remains the default cmake on Homebrew and Fedora.
countly-sdk-cpp
cmake_minimum_required(VERSION 3.5...3.31), plus the same in vendor/json. Still not PR'd — raising a declared minimum is a floor bump and a human's call. Second week carried, and it will keep appearing until someone types the line.
mavenLocal() / sdk-otel dependency is not on the branchLast week's edition reported that countly-sdk-flutter-bridge/android/build.gradle pulls ly.count.android:sdk-otel:26.1.4 from mavenLocal() and that this "will not resolve for an outside contributor." That was a read of a dirty working tree, not of the branch. git show staging:android/build.gradle contains one Countly dependency — implementation 'ly.count.android:sdk:26.1.2' — with no mavenLocal() and no sdk-otel. The last commit to that file is be2d9835, 8 April 2026, and git log -S "sdk-otel" on it returns nothing. Public staging builds fine. No exposure, and the alarm was ours.
What is real and worth knowing: the OTel work is live as uncommitted local changes — modified android/build.gradle, CountlyFlutterPlugin.java, lib/countly_flutter.dart, lib/src/countly_flutter.dart, pubspec.yaml, plus four untracked files: lib/src/otel.dart, otel_flutter_instrumentation.dart, otel_internal.dart, otel_navigator_observer.dart. Not pushed, not branched. Two consequences: it is one rm -rf from gone, and ly.count.android:sdk-otel 404s on Maven Central — so publishing that artifact is a hard prerequisite before this can land anywhere.
Carried for two weeks as an undated worry against both bridges. AGP 9.4.0 shipped this month (with Android Studio Quail 4, stable 1 September), and its release notes plus the official DSL/API migration timeline enumerate exactly what AGP 10.0 removes: applicationVariants, libraryVariants, testVariants, unitTestVariants, variantFilter, registerJavaGeneratingTask, registerResGeneratingTask, the Transform API, and the android.newDsl / android.builtInKotlin opt-out flags.
countly-sdk-android · countly-sdk-flutter-bridge · countly-sdk-react-native-bridge · countly-sdk-java
A sweep of every *.gradle, *.kts and gradle.properties across those four repos for all nine of those symbols returns zero matches. We use none of the removed surface. AGP 9.4 also narrows the escape hatch from a global android.newDsl=false to a per-module android.newDsl.optOut=:module, which is irrelevant to us for the same reason. The bridges' ancient AGP classpath declarations (3.2.1 and 7.0.1) remain a separate and still-live concern — they constrain what Gradle a consumer can build the bridge with — but the AGP 10 API cliff is not our cliff. Dropping the DSL half off the watchlist.
countly-sdk-windows is at 26.1.0, not 25.4.3The baseline table and the last two editions printed 25.4.3. nuget/Countly.nuspec reads 26.1.0 on the local tree, on origin/staging and on origin/master (commit 4eec245, 10 August), and nuget.org lists 26.1.0 as the latest published version, released 13 August 2026. Baseline updated. Also re-read and confirmed unchanged: net35-full, net45, netstandard2.0, with Newtonsoft.Json 13.0.3 as the only shared dependency.
countly-sdk-android is on AGP 9.3.2 with a Gradle 9.7.1 wrapper, so it already clears the new floor and the bump to 9.4.0 is a one-line, zero-risk change whenever someone wants it. Not PR'd: routine maintenance, not P0/P1.android.newDsl.optOut=:example-lib1) and disappears with AGP 10.0. And dynamic-feature modules now get build warnings for flavour-dimension mismatches against the app module, becoming errors in AGP 10.0. We ship no dynamic features. See Corrections for why the removal list is a non-event for us.app/ demo modules are not published. There is no SDK-side surface — no manifest entry, no API, no version floor. It will still generate customer questions for the next three weeks, so it belongs in a support answer rather than a backlog item.ly.count.android:sdk-native:26.1.6-rc2 was published to Maven Central on 4 September (rc1 preceding it), while ly.count.android:sdk remains at 26.1.5 from 31 July. 26.1.6 is in flight on the native/NDK side.private.icloud.com, a host-app account-system concern with no Countly surface) and 18 August (EU business terms, effective 1 October — the Core Technology Commission replacing the Core Technology Fee). Nothing 1–7 September.countly-sdk-web or countly-sdk-js. What changes is a process assumption. A monthly "check the Chrome release notes" habit now misses half of them, and this radar's own web sweep needs to look at two release notes per edition rather than one. Worth a Chrome Beta smoke test in CI if we ever want early warning rather than incident-driven discovery.developer.chrome.com/release-notes/153 returns 404), so no 153 removals are asserted here. Chrome 152, stable 25 August, remains the last release whose contents this page has verified — and its Private Aggregation removal was cleared last week at zero exposure.countly-sdk-unity contains no native plugin files at all — a sweep for .jslib, .cpp, .mm, .so and .a returns nothing. It is pure C#, so a major Emscripten bump changes how Unity compiles our code, not what we hand it. That is Unity's compatibility problem before it is ours.ProjectSettings/ProjectVersion.txt reads 2020.3.20f1, so we cannot open a 6.6 project, let alone test against it — the SDK is at 24.8.2, the oldest-but-one in the fleet. And the local checkout sits on a branch literally named fix_web_assemly, whose last commit is 19 June 2026. Unity's Web target is where our stale editor pin and Unity's fastest-moving backend intersect, and that branch has been parked for eleven weeks.countly-sdk-cpp/vendor/sqlite/sqlite3.c declares SQLITE_VERSION "3.29.0" — released July 2019. git log on vendor/sqlite shows a single commit, da7720d, 31 August 2019. That amalgamation has not been touched in seven years and misses every SQLite fix since.CMakeLists.txt. First, option(COUNTLY_USE_SQLITE "Use SQLite" OFF) — it is off by default, compiled only for integrators who explicitly enable it. Second, SQLite's own position on its CVE history is that every reported vulnerability requires the attacker to either run arbitrary SQL or supply a maliciously crafted database file. Our usage is an SDK-owned local request queue with SDK-generated SQL, so neither precondition is met.compileSdkVersion 35 / targetSdkVersion 35 / minSdkVersion 21, wraps ly.count.android:sdk:25.4.4 against an Android SDK at 26.1.5, and still has no Package.swift for the SwiftPM migration. Expo, 3 September: Expo Go 57 now requires a login to run projects — a workflow change for app developers, no SDK surface.countly-sdk-dart (Dart SDK ^3.0.0) even though they predate the window: final/var are no longer allowed on non-declaring parameters, and built-in fallback root certificates were removed from the Dart VM — the latter is the one that could surface as a TLS failure on a bare host, and is worth a deliberate check rather than an assumption.countly-sdk-nodejs is at 24.10.3 and still declares no engines field — third consecutive week. It also declares zero runtime dependencies, which is the good news attached to that.countly-sdk-java compiles at Java 8 source/target, which nothing in JDK 27 removes. Its only runtime dependencies are org.json:json:20250517 — Maven Central is now at 20260814, worth a routine bump — and jsr305:3.0.2.targetSdkVersion 6.0.2(22) and compatibleSdkVersion 5.0.0(12). Nothing further asserted.SentrySDK.replay with start(), startBuffering(), pause() and resume() — the same shape sentry-java 8.54.0 shipped on 27 August. That is deliberate cross-platform API parity delivered inside ten days, and it upgrades last week's read: this is no longer one SDK's idea, it is a published cross-platform contract for manual replay control, which is precisely the artefact that is hardest to design and easiest to copy.maxFeatureFlags (default 100) and, notably, deprecated enableLogs and enableMetrics — manual log and metrics APIs are no longer gated behind those flags, and the flags go away next major. A clean read on config-surface design: the capability stays, the boolean that fragmented it does not.InternalSentrySdk.captureEnvelopeNonTerminating and updateSessionForDroppedEventNonTerminating — explicitly "for hybrid SDKs" — plus a Session.State.Unhandled for unhandled errors that do not kill the process. This one is directly relevant to us: that is the exact problem shape our Flutter and React Native bridges have when forwarding a Dart or JS error that the native layer must record without treating the session as crashed. Worth reading their implementation before we design ours.countly-sdk-android ships :sdk-native as a first-class module in settings.gradle, published as ly.count.android:sdk-native — currently at 26.1.6-rc2 as of 4 September — with an :upload-plugin module for symbol upload. This is PostHog reaching parity with us, not the reverse. Worth saying out loud, because the radar's default posture is to look for gaps.countly-sdk-react-native-bridge has no autocapture on any target. Worth it: not at this shape. RN Web is a narrow slice, and our RN bridge's real debt is AGP 7.0.1, an Android SDK two minors behind, and no SwiftPM support. Autocapture is a legitimate cross-SDK conversation; RN-Web-first is not the way into it./products/[id]. The latter is a genuinely good idea for countly-sdk-web and countly-sdk-js: unparameterised dynamic routes shred pageview aggregation, and every SPA integrator hits it. Small, and framework-adapter shaped rather than core-SDK shaped.Analytics-iOS and Analytics-Android reached end of support at the end of Q1 2026, with Analytics-Swift and Analytics-Kotlin as the replacements carrying auto-instrumentation, consent management and live plugins. Two of the four are features we do not have.countly-sdk-web without anyone reading a release note. This is a maintenance-model change disguised as a scheduling announcement.opentelemetry-js 2.11.0 and experimental 0.222.0. The experimental release deprecates SdkLogRecord in favour of ReadWriteLogRecord, makes SDK initialisation from config files fail fast across propagator, meter-provider, tracer-provider and resource creation, and adds sensitive-query-parameter redaction for server-side HTTP spans. Stable 2.11.0 adds per-call force-flush timeouts and attach() on the Node async-local-storage context manager. Separately, SDK 3.x is targeted for around September 2026 and will remove @opentelemetry/propagator-jaeger.browser.web_vital.* attribute rework carried since then is unchanged and unaddressed.otel-telemetry-phase1" in countly-sdk-js. It does not: that branch is at commit cf94eef — byte-identical to staging, zero diff, and git ls-tree finds no file with "otel" in its name anywhere on it. The actual OTel work is the uncommitted Flutter-bridge tree described in Corrections. So the initiative is real, is Dart-and-Android-shaped rather than JS-shaped, and exists only in a working directory. Given ly.count.android:sdk-otel 404s on Maven Central and has no module in countly-sdk-android on any local branch, there is currently no path by which any of it ships.| When | What happens | Affected |
|---|---|---|
| 2026-09-08 | Chrome 153 stable — two-week release cadence begins. Browser-change rate under the web SDK doubles; beta lead time drops to ~3 weeks. | web, js |
| 2026-09-14 | iOS 27 / iPadOS 27 / watchOS 27 / tvOS 27 / visionOS 27 expected GA, RC 8–9 Sept, event 9 Sept. Validate under Xcode 27 beta first. Submission floor stays Xcode 26. | ios, flutter-bridge, react-native-bridge, unity |
| 2026-09-15 | JDK 27 GA (RC since 20 Aug, feature set frozen). Java 8 source/target still accepted; obsolescence clock only. | java |
| 2026-09-30 | Android developer verification / app registration required in BR, ID, SG, TH across 7 stores. No Countly SDK surface — customer-question item only. Global 2027. | none |
| 2026-10-01 | Maven Central publishing limits go to hard enforcement. Our cadence is far under the qualitative criteria; numeric limits unpublished. Monitor only. Also: EU App Store business terms take effect. | android, java, ios |
| 2026-10 | Unity 6.0 LTS support ends (6.3 LTS runs to Dec 2027). Node 26 becomes Active LTS — the moment to finally declare engines, third week running. | unity, nodejs |
| 2026-11-01 | All pre-17-August NuGet.org API keys expire. Confirmed relevant: Countly 26.1.0 was published 13 Aug with such a key. Fix is Trusted Publishing, which needs a CI publish workflow that does not exist. | windows |
| 2026-11-10 | .NET 8 and .NET 9 end of support. Our TFMs unaffected; watch ecosystem drift off netstandard2.0. | windows |
| 2026-11 | Flutter's in-SDK Material/Cupertino formally deprecated. Bridge ships no widgets; exposure is the example/ app. | flutter-bridge |
| 2027-02 | Play memory, bitmap and 25% DEX-optimization requirements begin. Pushes every integrator onto R8; we still ship no consumerProguardFiles — re-verified this run. | android, and every wrapper |
| 2027-04 | Play zero-tap sign-in via the Restore Credentials API. No Countly surface, but customers will ask. | none |
| ~2027-04 | Expected iOS 27 SDK submission floor, extrapolated from the Xcode 26 floor's ~6-month lag. Not announced. | ios |
| pending | cmake_minimum_required(VERSION 3.0) is a hard configure error on CMake ≥ 4.0. Current CMake 4.4.3; 4.x is the Homebrew/Fedora default. One-line fix, held as a human floor decision. Not reproduced locally (local cmake 3.28.1 warns only). | cpp |
| pending | Vendored SQLite 3.29.0 (July 2019, single commit Aug 2019). Opt-in via COUNTLY_USE_SQLITE=OFF and not reachable in our usage, but it fails every SCA scan it meets. | cpp |
| pending | Bridges declare ancient AGP classpath versions — flutter-bridge 3.2.1 / compileSdk 35, rn-bridge 7.0.1 / compileSdk 35 — constraining what Gradle a consumer can build them with. The AGP 10 legacy-DSL removal is now cleared (zero usage); this row is the classpath half only. | flutter-bridge, react-native-bridge |
| pending | RN SwiftPM migration: bridge ships only CountlyReactNative.podspec, no Package.swift, no react-native.config.js, no branch in flight — unlike Flutter's swiftpm-support-ios. | react-native-bridge |
| pending | Unity 6.6 shipped 31 Aug (SDK Platform 37, Emscripten 4.0.19, Wasm64). Editor pin 2020.3.20f1 blocks verification entirely. fix_web_assemly branch parked since 19 June. CoreCLR replaces the runtime in 6.8. | unity |
| pending | OTel initiative has no shippable path. countly-sdk-js:otel-telemetry-phase1 is identical to staging (no OTel content). Real work is uncommitted in the Flutter bridge tree (4 untracked otel*.dart files). ly.count.android:sdk-otel 404s on Maven Central and has no module in the Android repo. semconv v1.44 browser.web_vital.* unaddressed. | js, flutter-bridge, android |
| pending | Session replay ships in PostHog, Amplitude, Mixpanel, Sentry and Datadog RUM; absent from all 13 of ours. Sentry has now published the manual-control API on both java (8.54.0) and cocoa (9.27.0) — a cross-platform contract to copy, not one SDK's idea. | all |
| pending | Bridges lag Android: flutter-bridge wraps sdk:26.1.2, rn-bridge wraps 25.4.4, Android is 26.1.5 with sdk-native:26.1.6-rc2 already on Central. | flutter-bridge, react-native-bridge |
| pending | Routine bumps, none urgent: AGP 9.3.2 → 9.4.0 (Gradle floor already met at 9.7.1), org.json:json 20250517 → 20260814. | android, java |
| CLOSED | 2026-09-07 · Flutter bridge mavenLocal()/sdk-otel alarm was a false positive — read from a dirty working tree, not on staging. Public branch is clean. | flutter-bridge |
| CLOSED | 2026-09-07 · AGP 10 legacy-DSL removal does not affect us — zero usage of any removed API across android, java and both bridges. | android, java, both bridges |
| CLOSED | 2026-09-07 · Windows baseline corrected to 26.1.0 (on master, and published to nuget.org 13 Aug), not 25.4.3. | windows |
ly.count.android:sdk-otel must exist on Maven Central — and as a module in countly-sdk-android/settings.gradle — before any of this can ship to a customer.countly-sdk-windows before 1 November. Now confirmed rather than assumed: the key that published 26.1.0 on 13 August is a pre-cutoff key. Useful side effect — it forces Windows releases behind CI instead of a laptop.cmake_minimum_required in countly-sdk-cpp. One line, VERSION 3.5...3.31, plus vendor/json. Third week carried, held only because it moves a declared minimum.captureEnvelopeNonTerminating and a session state for unhandled-but-not-fatal errors solve exactly the problem our Flutter and RN bridges have forwarding a Dart or JS error to the native recorder. Small, useful now, and independent of ever building replay./products/[id] item is a small framework-adapter change that fixes a real aggregation problem every SPA integrator hits.countly-sdk-web. From tomorrow there are twice as many stable releases per quarter; three weeks of beta lead time is only useful if something is actually watching it.consumerProguardFiles in the Android AAR ahead of Play's February 2027 DEX rule. Design task, not mechanical. Carried.engines in countly-sdk-nodejs — third week, unchanged, >=22 still defensible. Zero runtime dependencies makes this genuinely a one-line change.developer.chrome.com/release-notes/153 returned 404. Only the cadence change is asserted, from Chrome's own blog post. The 8 September stable date for 153 comes from that post.OFF default are all read directly from the repo; the "not reachable in our usage" judgement rests on SQLite's own stated CVE preconditions plus how our code uses it, and it deserves a second opinion before anyone repeats it to a customer.6000.6.0f1, which is primary, but the CoreCLR / .NET 10 / C# 14 framing repeated in secondary coverage was not confirmed there and is not asserted.countly-sdk-dart at runtime was not tested — that is the check being proposed, not a finding.~/GitHub/SDKS was modified. All reads were git show, git log, git status and file reads; no branch was checked out and no state was mutated.