Weekly platform, competitor and sector sweep for the Countly SDK fleet. Window 19 October to 26 October 2026.
The native iOS half of the Xcode 27 P0 is closed: countly-sdk-ios 26.8.0 shipped on 21 October with the iOS 15 / macOS 12 / tvOS 15 / watchOS 9 floor, the Mach-handler docs from PR #479, and an iOS KB article updated the same day. What is left is the two bridges. Both have the fix on staging, and both took the 26.8.0 iOS sources on 22 October (Flutter #409, RN #512). But the versions a customer can install are still pub.dev countly_flutter 26.1.1 (15 September) and npm countly-sdk-react-native-bridge 26.1.0 (4 May), both at ios.deployment_target = '10.0'. iPhone Duo went on sale on 23 October. It stays P0 until those two releases are out.
Most of the watchlist retired itself this week. Six carried items are cleared below, including the PLCrashReporter P1 and the Flutter merge-order risk. One new alarm was checked and dropped: CocoaPods trunk goes read-only on 2 December, but Countly stopped publishing there after 26.1.0 on purpose, and the iOS KB already says so. On the platform side the week was quiet. OpenTelemetry JS 3.0 is the one big release, and our OTel branch imports none of it. The monotonic-clock work from last week's cheap steal is now in progress as draft PRs on Android (#624) and iOS (#491). Datadog and Sentry each shipped another clock-change fix this week. Zero PRs: the P0 needs a release, not a patch.
Same mechanism: Xcode 27 makes a deployment target below iOS 15.0 a hard build error. The app's post_install lift does not reach a pod's resource_bundles target, and the published Flutter podspec has one (countly_flutter_privacy, line 15).
| Repo | On origin/staging | What a customer installs today |
|---|---|---|
countly-sdk-ios | 15 / 12 / 15 / 9 / 1 | Released. Tag 26.8.0 (21 Oct), Countly.podspec and Countly-PL.podspec both 15.0. Cleared below. |
countly-sdk-flutter-bridge | #405 merged 19 Oct: podspec 15.0, Package.swift .iOS(.v15). #409 (22 Oct) moves the vendored iOS SDK to 26.8.0. pubspec.yaml still says 26.1.1. | pub.dev 26.1.1 (15 Sep): resource_bundles plus ios.deployment_target = '10.0'. No app-side workaround. |
countly-sdk-react-native-bridge | Podspec takes the higher of RN's min_ios_version_supported and Countly's floor. #512 (22 Oct) moves the vendored iOS SDK to 26.8.0. package.json still says 26.1.0. | npm 26.1.0 (4 May): ios 10.0 / osx 10.14 / watchos 4.0 / tvos 10.0. |
countly-sdk-flutter-bridge · countly-sdk-react-native-bridge
Why it is still P0. A Flutter app that moves to Xcode 27.1 for iPhone Duo (Xcode 27.1 final shipped 15 October, build 27A9275) cannot build with any published countly_flutter. The RN bridge is in the same position, with the CountlyReactNative_Privacy bundle target.
Smallest fix Cut the Flutter bridge release (and its -np twin) and the RN bridge release from current staging. The iOS SDK they wrap is already out, so nothing blocks the order now. Not a radar PR: the code is merged, and what remains is a release decision.
countly-sdk-swift 26.8.0 still has no documentation, fifth weekcountly-backup-documentation origin/HEAD (24 October backup): Knowledge Base/SDK Specs/ holds the same 14 files, with no Swift article, and SDK_Repos_and_Features has zero mentions of Swift. This week the iOS article (21 Oct), the NodeJS article (19 Oct) and the C++ article (22 Oct) were each updated within a day of their releases. Swift is now the only shipping SDK without a page.
countly-sdk-swift
Smallest fix Unchanged. Turn the 26.8.0 CHANGELOG into a SDK Specs/ article, then add the row to SDK_Repos_and_Features. Authorship, so a proposal, not a PR. Board card C-30 is in review.
maven.countly.com still does not resolve, fifth week, nothing moveddig +short maven.countly.com returns nothing. Maven Central's newest is still ly.count.android:sdk 26.1.6 (30 Sep) and ly.count.sdk:java 26.8.0 (8 Sep). Android origin/staging has had no commit since 19 October. The Flutter bridge is on ly.count.android:sdk:26.1.6, the last Central version.
countly-sdk-android · countly-sdk-java · countly-sdk-flutter-bridge · countly-sdk-react-native-bridge
Smallest fix Unchanged. The board key was rejected on 6 October ("Not worth it now"), so this page reports it and does not resend the card. It becomes P0 on the day an Android release goes out with the repository entry and the host still does not resolve.
countly-sdk-ios 26.8.0, 21 October: "! Minor breaking change ! Raised the minimum supported deployment targets to iOS 15, tvOS 15, watchOS 9 and macOS 12 … for compatibility with Xcode 27." Both podspecs at the tag read 15.0 / 12.0 / 9.0 / 15.0. The iOS KB article, backed up on 22 October, now says "minimum Deployment Target iOS 15.0 (watchOS 9.0, tvOS 15.0, macOS 12.0, visionOS 1.0)". That also retires last week's "the iOS article will be wrong on release day" docs item. Board C-47 can close.
PR #479 merged on 19 October, before the 26.8.0 cut. The iOS KB article now mentions shouldUseMachSignalHandler / Enhanced Security three times, which covers the C-103 half. The default crash path was never exposed. C-90 is already done on the board.
PR #405 merged on 19 October. Grepping origin/staging android/src for the 18 removed names leaves two hits, and both are the new API: config.crashes.setCustomCrashSegmentation (CountlyFlutterPlugin.java:1824) and config.crashes.enableCrashReporting() (:1900). The bridge can take the next Android major. Board C-109 can close.
The CocoaPods read-only plan schedules a test run on 1–7 November and a permanent stop on 2 December 2026. Trunk's newest Countly is 26.1.0 (18 Feb). 26.1.1–26.1.4 and 26.8.0 were never pushed, and Countly-PL was never there. This looked like a new P0 until the iOS KB answered it: "CocoaPods is now obsolete. The last Countly iOS SDK version published to CocoaPods is 26.1.0. For newer versions, we recommend switching to Swift Package Manager or Git-based dependency resolution." The bridges ship their podspecs inside the pub/npm package and vendor the iOS sources, so they never resolve Countly from trunk.
Residual, P3. brain/sdks/standards/release-process.md still lists pod trunk push as the last iOS release step. Update it so the next release owner does not try.
opentelemetry-js 3.0.0 (20 Oct) removes sdk-trace-web, sdk-trace-base and sdk-trace-node in favour of one @opentelemetry/sdk-trace. It replaces the browser field with #platform subpath imports (webpack 5.54+), blocks deep imports through exports maps, and raises Node to >=22.15.0. None of it reaches us: the local otel-telemetry-phase1 branch of countly-sdk-js (last commit 8 July) has no diff against staging and no @opentelemetry import, and no SDK's staging depends on an OTel package. It is design input for whoever restarts that work (see Sector trends).
Chrome 156 went stable on 20 October (chromiumdash). Its only deprecation on chromestatus is the FencedFrame removal, which we do not use. Node's security release (26.12.1 / 24.22.1 / 22.23.4, 21 Oct) fixes TLS, DNS, HTTP-agent and zlib issues in the runtime. countly-sdk-nodejs ships no runtime, so customers get the fix by upgrading Node.
3.2.1, RN 7.0.1). P3.dart:io now uses the updatable Conscrypt APEX root store on Android 14+, and BoringSSL blocks "a number of compromised intermediate certificates". This softens C-105 (3.13 dropped the built-in fallback roots) for Android 14+ only. Older Android and other platforms are unchanged. Dart beta 3.14.0-315.3. P2, carried.countly-sdk-unity staging is untouched since 19 June, and the editor is pinned at 2020.3.20f1. P3.schedule.json).countly-sdk-nodejs 26.8.0 shipped on 19 October (npm latest). It is a big release: SDK behavior settings on by default, and storage moved to .countly-storage in the working directory. It still declares no engines, tenth week. A one-line "engines": {"node": ">=22"} would now match every supported LTS line. That bumps a declared floor, so it is a human call, not a radar PR.dotnet/core release in the window. .NET 11 GA and .NET 8/9 end of support on 10 November (cleared).countly-sdk-cpp 26.8.1 released on 20 October, carrying the monotonic-duration fix. No CMake release.countly-sdk-java merged a release-on-merge workflow (#326, 23 Oct). No platform news.| Release | What shipped | Do we have it? | Call |
|---|---|---|---|
| dd-sdk-ios 3.20.0 (19 Oct) | "Prevent incorrect RUM session expiration caused by device clock changes or cross-platform timestamp differences." | In progress: iOS #491 and Android #624 (both draft, 23 Oct). No Web PR yet. | P2 worth it, carried as C-108 |
| sentry-java 8.61.1 (22 Oct) | Bundles ISRG Root X1 and trusts it on API 25 and lower, because "Android 7.1.0 (API 25) and older don't trust the Let's Encrypt root certificate". Sentry moves to Let's Encrypt and GTS in February 2027. It also moved two more timers to a monotonic clock. | No. Our Android SDK (minSdk 21) uses the device store only. api.count.ly chains YR1 → Root YR → ISRG Root X1, and try.count.ly uses Sectigo. Customer servers vary. | P3 the cheap steal below |
| posthog-android 3.72.7 / posthog-ios 3.92.3 (21–23 Oct) | optOut() now stops replay, autocapture and other integrations, and optIn() restarts them in a new session, keeping a stop the app asked for. | Yes in spirit: removing a consent stops that feature, and our consent is per feature, which is finer. | have it |
| sentry-cocoa 9.31.0 (21 Oct) | Experimental MetricKit hang flame graphs. Also resolves app state at didFinishLaunching when the SDK starts from SwiftUI App.init, where a background launch was treated as active. | No hang detection (carried). The SwiftUI-init case is worth a test: our iOS 26.8.0 just fixed "macOS not starting a session when the app was not active at launch". | P3 |
| sentry-dart 10.2.0 (22 Oct) | Cellular generation (4g/5g) in device.connection_effective_type. Needs READ_PHONE_STATE on Android 11 and earlier. | No (corrected 19 Oct: we report connection type only). | P3 the permission cost makes it not worth it |
| Amplitude-Kotlin 1.36.0 (21 Oct) | Shared identity properties with an atomic setter. | Our user-profile calls batch on save already. | P3 |
| OpenTelemetry Android 1.8.0 (22 Oct) | "Session ID lookups no longer refresh background inactivity, so background telemetry no longer keeps a session alive." | Our sessions end on background, so this does not apply. | P3 a good design note for our OTel session mapping |
| Firebase iOS 13.1.0/13.1.1, Datadog browser 7.16.1, Statsig JS 3.33.6 (rrweb 2.1.7), sentry-javascript 11.9.0, RevenueCat 5.96–5.98, posthog-js/-flutter/-react-native patches | Firestore removed roots tied to compromised eMudhra intermediates, plus replay, Next.js and AI-logic work. | n/a. We embed no trust store. | P3 nothing to take |
Sentry's note states the mechanism plainly: Android 7.1.0 and older do not trust ISRG Root X1. Our Android SDK supports API 21. api.count.ly already serves a Let's Encrypt chain ending at X1, so any hosted customer domain with the same chain cannot be reached from those devices today. The SDK does not log this as anything other than a failed request. The fix Sentry chose (bundle one root, trust it in addition to the device store, only for its own host, only on API ≤25) is small. For us it is mostly an infra question: which ingestion hostnames Countly hosts, and which CA they use. Device share of API 21–25 is low, so this stays P3. It is not sent to the board.
@opentelemetry/sdk-trace package and marks sdk-logs stable, with a browser-only disableAutoFlushOnDocumentHide option. Together with the browser fetch/XHR instrumentation deprecation (C-106), anyone restarting the JS OTel work should start from 3.x, not 2.x. Spec 1.62.0 (22 Oct) adds Sampler.Shutdown and stabilises non-OTLP attribute representation. Nothing client-side changed.mavenCentral() and an older version. It becomes wrong in three ways on the next Android release (repository, removed calls, version).| When | What | Affected |
|---|---|---|
| now | Flutter and RN bridge releases carrying the iOS 15 floor. iPhone Duo has been on sale since 23 October | flutter, rn |
| 2026-10-28 | Node 26.x becomes Active LTS. Node SDK still declares no engines | nodejs |
| 2026-11-01 | Play target-API extension deadline (cleared). NuGet old API keys expire (rejected, date only). CocoaPods trunk test run 1–7 November (cleared: we left trunk) | android, windows, ios |
| 2026-11-10 | .NET 8 and 9 end of support. .NET 11 GA (cleared) | windows |
| 2026-11 | Flutter in-SDK Material/Cupertino deprecation. Exposure is example/ only | flutter |
| 2026-12-02 | CocoaPods trunk read-only (cleared, Countly stopped at 26.1.0 on purpose) | ios |
| 2026-12 | iOS 27.2 alternative EU ATT prompt (cleared as an SDK item) | ios |
| 2027-02 | Developer ID Sub-CA expiry (cleared). Play memory and DEX requirements (app level). Sentry's CA move shows how old Android and Let's Encrypt chains interact | ios, android |
| 2027-04 | iOS 27 SDK required plus iPhone Duo screenshots (still not on Apple's upcoming-requirements page) | ios, flutter, rn, unity |
| next release | Android/Java move to maven.countly.com, which still does not resolve | android, java, flutter, rn |
| open | Monotonic durations: Android #624 and iOS #491 drafts. Web has no PR yet | android, ios, web, js |
| open | RN opt-in legacy-interop removal flags become the default "in a future release" | rn |
Nothing in this edition was built, run or tested. Every claim about our code is read from origin/<branch> or a release tag after a git fetch, never from a working tree. The Flutter removed-API check is a text grep, not a compile.
The Xcode 27 "hard error" mechanism is carried from earlier editions, not re-derived this week. Xcode 27.1's final build date comes from xcodereleases.com, which is secondary. Apple's own release-notes pages still render title-only.
The ISRG Root X1 point rests on Sentry's changelog for the Android trust-store fact. Only api.count.ly and try.count.ly were inspected. Which hostnames Countly-hosted customers actually send to is unknown here.
The otel-telemetry-phase1 branch exists only locally (no remote branch found). If newer OTel work lives elsewhere, the "not exposed" call for OpenTelemetry JS 3.0 needs a re-check.
Chrome 156's deprecation list is secondary (chromestatus API). Android Play policy coverage is from the developers blog only, which has just moved off Blogger.
HarmonyOS, ninth week. Heap, Pendo, LogRocket, Mixpanel and Segment had no GitHub releases in the window or were not reached. Amplitude-TypeScript showed only codexsemantic-review-integration pre-release tags, which were ignored.