Weekly platform, competitor and sector sweep for the Countly SDK fleet. Window 24 – 31 August 2026.
Nothing broke our code this week. What moved is the layer underneath it: the package registries are tightening publishing credentials in unison. NuGet.org caps every new API key at 30 days and expires every key created before 17 August on 1 November; Maven Central's publishing limits go to hard enforcement 1 October; npm already revoked classic tokens and caps write-scoped granular tokens at 90 days. Three of the four registries we ship through changed their rules inside a month, and none of it shows up in a diff — it shows up the day a release fails to publish.
Two other dated things matter. iOS 27 goes GA around 14 September — beta 7 landed 24 August — and countly-sdk-ios has never been exercised against Xcode 27 here. And countly-sdk-cpp still opens with cmake_minimum_required(VERSION 3.0), which CMake 4.x refuses outright; CMake 4.4.3 shipped 25 August and 4.x is now the default on Homebrew and Fedora. That one is standing debt the radar has flagged before, but it is worth restating as a hard build failure rather than a footnote. On the good side: Play's API 36 deadline lands today and we are clear, Chrome deleted the Private Aggregation API and we touched none of it, and we already ship an MCP server in a week when two competitors made agent-facing tooling their headline.
NuGet.org reduced API key lifetime to a 30-day maximum for keys created on or after 17 August 2026, and all keys created before that date expire on 1 November 2026. The 365-day option is gone from the key-creation UI. The recommended replacement is Trusted Publishing over OIDC — supported on GitHub Actions and GitLab, not on Azure DevOps.
countly-sdk-windows
countly-sdk-windows publishes the Countly package from nuget/Countly.nuspec. Its .github/workflows/ contains only release_notice.yml — there is no publish workflow, so the release is pushed by hand with a human-held key. That key is almost certainly a pre-17-August one.
Countly package against a GitHub Actions workflow in Countly/countly-sdk-windows, or accept a 30-day rotation cadence. Not PR'd: this needs nuget.org owner access and a decision about whether Windows releases move to CI at all — neither is something the radar can do blind. Announced 3 August, in force 17 August; this run is the first to catch it.
countly-sdk-cpp does not configure on any CMake 4.xCMakeLists.txt:1 is cmake_minimum_required(VERSION 3.0). CMake 4.0 removed compatibility with CMake < 3.5 outright: a version or version-range that does not cover 3.5 is a hard error, not a warning — Compatibility with CMake < 3.5 has been removed from CMake. The same applies to vendor/json/CMakeLists.txt at VERSION 3.1.
countly-sdk-cpp
CMake 4.0 shipped March 2025 and 4.4.3 shipped 25 August 2026. Homebrew and Fedora both ship 4.x as the default cmake, so a developer on a current machine cannot configure this project at all without -DCMAKE_POLICY_VERSION_MINIMUM=3.5.
cmake_minimum_required(VERSION 3.5...3.31). The range form tells CMake the project needs at least 3.5 but is policy-compatible up to 3.31, which avoids a second round of policy churn. Not PR'd — raising the declared minimum is a floor bump, and the radar does not bump minimum platform versions without a human. vendor/json needs the same treatment or a vendored-dependency refresh.
iOS 27 was announced at WWDC on 8 June; developer beta 7 landed 24 August and general release is expected around 14 September 2026, alongside iPadOS 27, watchOS 27, tvOS 27 and visionOS 27. Xcode 27 is in beta now.
countly-sdk-ios · countly-sdk-flutter-bridge · countly-sdk-react-native-bridge · countly-sdk-unity
This is not a submission-floor deadline — the current floor is still Xcode 26 / iOS 26 SDK, unchanged since 28 April, and Apple has announced no iOS 27 requirement. Historically the next floor arrives roughly six months after GA, so expect that around April 2027. The near-term risk is the support wave: customers upgrade on day one, and countly-sdk-ios at 26.1.4 declares swift-tools 5.9 with floors of iOS 12 / macOS 10.14 / tvOS 12 / watchOS 4 / visionOS 1.
countly-sdk-ios test suite under Xcode 27 beta before 14 September, and do the same for the three wrappers that embed it. Nothing to change blind — this is a verification task, and it is exactly the kind the radar cannot perform.
The 31 August deadline arrives with no action on our side, as verified last week: countly-sdk-android/sdk/build.gradle is compileSdk 37 / targetSdk 37 with an explicit aarMetadata { minCompileSdk 34 }, and a library's own targetSdk does not participate in the app-module manifest merge. Dropping off the watchlist. The 1 November extension deadline stays, for any customer who requested one.
Chrome 152 went stable on 25 August and removes the Private Aggregation API along with related Privacy Sandbox APIs. A grep of countly-sdk-web/lib/ for privateAggregation, attributionReporting, browsingTopics, requestStorageAccess and sendBeacon returns zero hits — the web SDK touches no Privacy Sandbox surface and does not use sendBeacon at all. No exposure.
countly-sdk-android declares no consumerProguardFiles anywhere — the AAR ships zero keep rules, so integrators get no guidance from us. Mitigating: the SDK's only reflection is six call sites in messaging/UtilsMessaging.java and one ContentOverlayView lookup, and they all target Firebase and Huawei classes that those libraries keep via their own consumer rules. So the risk is a support-burden risk, not a known breakage.developer.apple.com/news/upcoming-requirements/ lists no iOS 27 requirement.private.icloud.com; existing privaterelay.appleid.com addresses keep working. This is a host-app account-system concern; Countly only stores whatever email the app hands us. 27 August — routine tax and price updates. Neither has an SDK surface.com.android.tools.build:gradle:3.2.1 with compileSdk 35 / minSdkVersion 21, and the podspec still declares an iOS 10.0 deployment target. The swiftpm-support-ios branch still exists, so SPM remains owned rather than open.android/build.gradle wraps ly.count.android:sdk:26.1.2 while the Android SDK is at 26.1.5, and pulls ly.count.android:sdk-otel:26.1.4 from mavenLocal(). That mavenLocal() dependency will not resolve for an outside contributor.spm.modules names instead of silently dropping a module, resolving Swift manifest naming collisions, reading spm.name from react-native.config.js, and fixing a Hermes bytecode-version mismatch in SwiftPM release builds.countly-sdk-react-native-bridge ships CountlyReactNative.podspec and has neither Package.swift nor react-native.config.js. Unlike the Flutter bridge, there is no branch in flight. This is the same finding shape as the Flutter SPM item, one platform behind.android/build.gradle pins AGP 7.0.1, compileSdkVersion 35 / targetSdkVersion 35 / minSdkVersion 21, and wraps ly.count.android:sdk:25.4.4 against an Android SDK at 26.1.5.UserAgentReduction enterprise policy, pushing sites to User-Agent Client Hints. Our web SDK's UA handling should be checked against UA-CH at some point, but nothing forces it this week.countly-sdk-nodejs still declares no engines field and sits at 24.10.3. Unchanged for a second week. Node 26 going Active LTS in October is the natural moment to write it.net35-full, net45, netstandard2.0 — are unaffected, and the nuspec's only shared dependency is Newtonsoft.Json 13.0.3.countly-sdk-java compiles at Java 8 source/target, which javac still accepts but marks obsolete; javac's "one + three back" policy means --release 8 support is finite, and no JEP in JDK 27 removes it. Not a break, but 24.1.6 is the oldest version in the fleet and this is the debt attached to it.cmake_minimum_required ranges below 3.5 — see Action needed. This is the same debt last week's edition mentioned in a one-line footnote; stating it properly, it is a hard configure failure on a current developer machine, not a style issue.countly-sdk-unity is still pinned to editor 2020.3.20f1 at 24.8.2.targetSdkVersion 6.0.2(22). Not asserting more than that until the primary page loads.*.count.ly, no. Worth it: yes, and it is cheap. The SDK side is free — every SDK already takes an arbitrary serverURL. The work is entirely server/infra: CNAME support and certificate issuance for customer-owned subdomains. Highest ratio of customer-visible value to SDK work on this list.Countly/countly-mcp-server is real and active, with 1.5.0 released 25 August. What we lack is the packaged skill layer on top. Small, and it lives outside the thirteen SDKs.Sentry.replay(): start() for a full-session recording, startBuffering() for a rolling buffer flushed on error, plus stop(), pause(), resume() and flush(). Explicit calls bypass the configured sample rates while sampling still governs automatic startup, and pause() survives background/foreground transitions and automatic restarts within the same process.session.?replay across all thirteen repos returns zero matches, re-verified this run. Replay now ships in PostHog, Amplitude, Mixpanel, Sentry and Datadog RUM.npx @posthog/wizard replay-vision setup command and wizard support for Go, Elixir/Phoenix, Rust and Java/Maven/Gradle projects. That is 68 new MCP tools from PostHog in three weeks.@sentry/browser at 29.6 KB, 47.4 KB with tracing, 85.9 KB with replay. We publish no size budget for countly-sdk-web. Adding one to the release process costs a CI step and gives us a number to defend when replay eventually lands.analytics-next last released 20 July. OpenReplay — last release 1.27.0 in May. Statsig (3.33.5, 27 Aug), RevenueCat (5.86.0–5.87.1, 24–27 Aug) and Embrace (9.2.0, 17 Aug) all shipped point releases with nothing that changes an SDK contract.npm login to a two-hour session token. NuGet capped new keys at 30 days on 17 August 2026 and expires all older keys on 1 November. Maven Central enforces publishing limits from 1 October 2026.countly-sdk-windows it currently does not.countly-mcp-server released 1.5.0 on 25 August. The gap is packaging: a skill or plugin layer that makes the MCP server usable without the user knowing what MCP is.opentelemetry-js last released 2.10.0 on 21 July. The carried semconv v1.44 finding is unchanged and still unaddressed on otel-telemetry-phase1, whose last real commit is 8 July.| When | What happens | Affected |
|---|---|---|
| 2026-09-14 | iOS 27 / iPadOS 27 / watchOS 27 / tvOS 27 / visionOS 27 expected GA. Validate under Xcode 27 beta before this date. | ios, flutter-bridge, react-native-bridge, unity |
| 2026-09-15 | JDK 27 GA. Java 8 source/target still accepted, but the obsolescence clock runs. | java |
| 2026-10-01 | Maven Central publishing limits go to hard enforcement. Our volume is well under; monitor only. | android, java |
| 2026-10 | Unity 6.0 LTS support ends. Node 26 becomes Active LTS — the moment to declare engines. | unity, nodejs |
| 2026-11-01 | All pre-17-August NuGet.org API keys expire. Also the Play target-API extension deadline, for any customer who took one. | 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 libraries 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 ship no consumerProguardFiles. | 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 six-month lag. Not announced. | ios |
| undated | AGP 10.0 removes the legacy Gradle DSL and the newDsl opt-out. AGP 9.3 still supports it, so the clock has not started. | flutter-bridge, react-native-bridge |
| undated | RN's SwiftPM migration. Bridge has no Package.swift and no branch in flight, unlike Flutter's. | react-native-bridge |
| undated | Unity 6.8 replaces the scripting runtime with CoreCLR. Our 2020.3.20f1 editor pin blocks verification entirely. | unity |
| undated | Session replay is table stakes across every primary competitor and absent from all thirteen of ours. Sentry 8.54.0 published a control API worth copying. | all |
| undated | semconv v1.44 reworked browser.web_vital; otel-telemetry-phase1 still floats and has not moved since 8 July. | js |
countly-sdk-windows before 1 November. This is the only item on the page with a hard date and a guaranteed failure if ignored. It also forces the useful side effect of putting Windows releases behind a CI workflow instead of a laptop.cmake_minimum_required in countly-sdk-cpp. One line, VERSION 3.5...3.31, plus the same in vendor/json. Held back only because it moves a declared minimum, which is a human's call — but it is a one-line call.consumerProguardFiles in the Android AAR. Ahead of Play's February 2027 DEX rule pushing integrators onto R8. Keep rules for the public API surface and the Firebase/Huawei reflection targets; it is a design task, not a mechanical one.serverURL already accepts anything — and the single cheapest way to close a real, ad-blocker-shaped data-loss gap that Mixpanel just monetised.countly-sdk-web per release, the way Sentry does. A CI step, and the number to defend before replay work starts.engines in countly-sdk-nodejs — carried from last week, unchanged. >=22 remains the defensible floor.VERSION 3.0. The hard-error behaviour rests on the CMake 4.0 release notes and the cmake_minimum_required documentation, both primary, plus corroborating downstream bug reports.developer.chrome.com/release-notes/153 returns 404 — M153 is mid early-stable rollout — so only Chrome 152's removals are asserted. The Chrome 145 UserAgentReduction removal comes from search-surfaced release-note text, not a direct fetch.