Weekly platform, competitor and sector sweep for the Countly SDK fleet. Window 7 – 14 September 2026.
Apple shipped, and it moved our floor. iOS 27 and its siblings went GA today, App Store submissions opened on 9 September, and Xcode 27 no longer supports iOS deployment targets below 15.0. countly-sdk-ios declares .iOS(.v12); the Flutter and React Native bridge podspecs declare 10.0; the Unity project declares iOSTargetOSVersionString: 10.0. Every integrator who opens Xcode 27 now sees diagnostics pointing at us. In the same announcement Apple put a date on something this page has been carrying as an extrapolation for three weeks: from April 2027, App Store Connect requires the iOS/iPadOS/tvOS/visionOS/watchOS 27 SDKs. That is now a primary-sourced deadline, not a guess.
The more useful half of this edition is that two P1s carried for three consecutive weeks were never real, and the reason they were reported is now understood. This run read every baseline from origin/<branch> rather than the local branch, and the picture changed immediately. countly-sdk-cpp's CMake floor is 3.13...3.31, not 3.0 — fixed upstream on 19 August. Its vendored SQLite is 3.53.4, not the 3.29.0 from 2019 — the old vendor/sqlite submodule was replaced by a vendor/sqlite3 amalgamation with a new COUNTLY_USE_SYSTEM_SQLITE option. Local staging in that checkout sits at 2ec6f1f while origin/staging is at 1d9b27b. Four baseline versions in the reference table were also stale by a whole release line.
Elsewhere: Chrome 153 removed five Privacy Sandbox APIs on 8 September and we touch none of them — proven by grep, not assumed. countly-sdk-android now ships a consumerProguardFiles entry for the first time, which quietly closes half of a 2027 Play item. JDK 27 goes GA tomorrow and does nothing to us. React Native 0.88.0-rc.0 introduced a TurboModule RCTArrayBuffer contract worth reading before the next bridge cycle. And Sentry Cocoa's new Hints API is the cheap steal of the week.
Xcode 27 supports iOS deployment targets in the range 15.0 to 27.0 only. A target — or a dependency — declaring lower produces The iOS deployment target ... is set to 12.0, but the range of supported deployment target versions is 15.0 to ... on every build. Xcode 27 RC (27A266a) shipped 9 September and GA lands with iOS 27 today.
countly-sdk-ios · countly-sdk-flutter-bridge · countly-sdk-react-native-bridge · countly-sdk-unity
Read from origin/staging this run — every one of these is below the new range:
| Repo | File | Declares |
|---|---|---|
| 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-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 |
Downgraded from P0 deliberately. Two secondary sources disagree on severity: the upstream issues filed against Datadog, Adjust, Facebook and others describe warnings on every build, while a third-party write-up calls it a hard error. Apple's own Xcode 27 release notes would settle it and would not render through any fetch this run (see Could not verify). Historically Xcode clamps upward and warns. Treating this as noise-on-every-integrator-build rather than a break is the defensible reading until the primary source is in hand.
Where the ecosystem landed, read directly from each project's Package.swift today: Datadog iOS 15 / tvOS 15 / macOS 12.6 / watchOS 9. Sentry Cocoa iOS 15 / macOS 12 / tvOS 15 / watchOS 9. Firebase iOS 15 / tvOS 15 / watchOS 7. Amplitude iOS 13. Mixpanel still iOS 12 — we are not the last, but we are in the trailing pair.
platforms in Package.swift and the matching podspec targets to iOS 15 / tvOS 15 / watchOS 9 (macOS 12 if the watchOS bump is taken), then the two bridge podspecs and the Unity project setting. Deliberately not PR'd — raising a declared minimum platform version is a breaking change for integrators and a human decision, which is exactly the line this radar does not cross. It is also four repos and a release-notes story, not a mechanical one-liner.
Apple, 9 September: "Starting April 2027, apps and games uploaded to App Store Connect need to be built with the iOS 27 & iPadOS 27 SDK or later", with the same requirement for tvOS 27, visionOS 27 and watchOS 27. This page has carried ~2027-04 as a guess derived from the Xcode 26 floor's six-month lag since 26 August. It is now a stated date from Apple's own newsroom.
countly-sdk-ios · countly-sdk-flutter-bridge · countly-sdk-react-native-bridge · countly-sdk-unity
Note the asymmetry that keeps this off P0: the requirement binds apps uploaded to App Store Connect, not libraries. We ship source — Package.swift declares plain .target( entries with no binaryTarget or prebuilt XCFramework — so the integrator's toolchain, not ours, determines the SDK used. Our obligation is narrower but real: compile cleanly and pass tests under Xcode 27, well before customers are forced onto it. That work has still never been done against any Xcode 27 build.
The current in-force floor is unchanged and re-read this run: Xcode 26 and the 26-family SDKs, since 28 April 2026. developer.apple.com/news/upcoming-requirements/ has not yet been updated with the April 2027 entry — the date exists only in the 9 September news post at time of writing.
countly-sdk-ios's test suite under Xcode 27 GA, then the three wrappers. Seven months of runway; the cost of finding a problem in March 2027 is not seven months of runway. Pair it with the deployment-target decision above — they touch the same files and should ship as one release.
Countly 26.1.0 dies in 48 daysCarried unchanged, clock moved. NuGet.org expires every API key created before 17 August 2026 on 1 November 2026. Established last run and not revisited this run: Countly 26.1.0 was published on 13 August 2026, four days inside the cutoff, so the key in use is a long-lived pre-cutoff key. .github/workflows/ in countly-sdk-windows contains only release_notice.yml — there is no publish workflow, so releases go out by hand.
countly-sdk-windows
Countly/countly-sdk-windows, 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. 48 days.
countly-sdk-cpp does not exist and has not for a monthCarried as P1 for three consecutive editions on the strength of cmake_minimum_required(VERSION 3.0) at line 1. git show origin/staging:CMakeLists.txt reads:
cmake_minimum_required(VERSION 3.13...3.31)
Commit f6f3ef6, 19 August 2026, changed it from 3.0...3.31 to 3.13...3.31 — verified by diffing f6f3ef6 against f6f3ef6^. The only other tracked CMakeLists.txt in the repo is examples/qt_demo/CMakeLists.txt at VERSION 3.16. vendor/json is a git submodule, not an in-tree CMake project, so the "vendor/json at 3.1" half of the claim was reading a checked-out submodule rather than anything this repo declares. CMake 4.x configures this project. Nothing to fix.
countly-sdk-cpp is current, not seven years staleReported last week as vendor/sqlite pinned to SQLite 3.29.0 (July 2019) with a single 2019 commit, framed as an SCA-scan liability. That path no longer exists on the branch. git ls-tree origin/staging vendor/ shows two submodules — doctest and json — and one ordinary tree, vendor/sqlite3. Its sqlite3.h declares:
#define SQLITE_VERSION "3.53.4"
The submodule was replaced with a vendored amalgamation and a second escape hatch was added at the same time: option(COUNTLY_USE_SYSTEM_SQLITE "Link the system SQLite instead of compiling the vendored amalgamation" OFF), which routes through find_package(SQLite3 REQUIRED). SQLite support itself is still OFF by default. No stale dependency, and an integrator who wants to own the SQLite version now can.
originBoth clears above have one cause. In ~/GitHub/SDKS/countly-sdk-cpp, local staging is 2ec6f1f9 and origin/staging is 1d9b27b3. Last week's edition drew the correct lesson — "always read via git show <branch>:<path>, never the working tree" — but a stale local branch is no better than a dirty tree. The rule that actually holds is git fetch first, then read origin/<branch>.
The reference baseline table was wrong in four places for the same reason. Corrected from origin/staging this run:
| SDK | Table said | origin/staging says |
|---|---|---|
| countly-sdk-java | 24.1.6 | 26.8.0 +4 lines |
| countly-sdk-cpp | 26.1.0 | 26.8.0 |
| countly-sdk-react-native-bridge | 25.4.1 | 26.1.0 |
| countly-sdk-nodejs | 24.10.3 | 24.10.4 |
Two corollaries worth keeping. The React Native bridge's wrapped Android SDK moved from 25.4.4 to ly.count.android:sdk:26.1.2, so the "rn-bridge wraps an ancient Android SDK" half of the maintenance item is smaller than reported — both bridges now wrap 26.1.2 against an Android SDK at 26.1.5. And the Flutter bridge's pubspec.yaml declares sdk: ">=2.12.0 <4.0.0", not the >=2.19.0 in the table — a lower Dart floor than we have been claiming.
Chrome 153 went stable 8 September 2026 and deprecates or removes the Protected Audience API, Related Website Sets, the Shared Storage API, the Attribution Reporting API and document.requestStorageAccessFor. Swept countly-sdk-web (lib/, plugin/) and countly-sdk-js on origin/staging for all of: Protected Audience, joinAdInterestGroup, sharedStorage, attributionReporting, requestStorageAccess, requestStorageAccessFor, Related Website, browsingTopics. Zero matches in either repo.
The only hit anywhere in the sweep is navigator.sendBeacon, in plugin/boomerang/boomerang.min.js and plugin/boomerang/countly_boomerang.js — third-party bundled code, and sendBeacon is not among the removals. We never adopted the Privacy Sandbox surface, so the largest browser deprecation of the quarter is a non-event for us.
countly-sdk-android now ships consumer R8 rules — half a 2027 Play item closesThis page reported on 7 September that "we still ship NO consumerProguardFiles anywhere." As of commit 3615d7da1 / 0718fce22 on 8 September, sdk/build.gradle:36 reads consumerProguardFiles 'consumer-rules.pro' and the file exists. It is a set of -dontwarn directives, not keeps — for platform classes touched only behind Build.VERSION.SDK_INT guards (StorageStatsManager, Insets, DisplayCutout, WindowInsets$Type, WindowInsetsController, WindowMetrics) plus AGP's core-lambda-stubs MethodHandleInfo artefact.
That directly fixes a real integrator failure — an app on an older compileSdk running R8 would fail with "Missing class" against our AAR. It does not address the February 2027 Play requirement for 25% DEX optimisation coverage, because that requirement is measured on the app, not on our library. Which means the Play R8 row on the watchlist was always mostly a customer-support item. Narrowing it accordingly rather than dropping it.
Package.swift has no binaryTarget and the podspec is source — so there are no x86_64 slices of ours to strip. Our macOS 10.14 deployment target is an Intel-era number that will look increasingly odd, and it folds into the deployment-target decision above rather than standing alone.developer.apple.com/news/upcoming-requirements/ still lists the 28 April 2026 Xcode 26 floor as the current requirement and carries no April 2027 entry yet. Privacy-manifest and required-reason-API rules unchanged.scroll-axis-lock, new <camera> and <microphone> capability elements, XML parsing rewritten in Rust, Iterator Join, IAMF spatial audio, configurable WebAudio render quantum, WebGPU buffer_view. Removal of non-standard _current-targeted navigations, cited as minimal usage.RCTArrayBuffer ObjC type represents ArrayBuffer in TurboModules with an explicit byte-ownership contract. 'react-native/Libraries/Core/InitializeCore' is deprecated in favour of 'react-native/setup-env'. Core components no longer report legacy RCT-prefixed names in their view configs. And react-native/babel-preset platform inlining now requires an inlinePlatform option alongside platform.countly-sdk-react-native-bridge on origin/staging for InitializeCore, setup-env and root Touchable: the only hits are TouchableOpacity in example/CountlyRNExample/CountlyButton.tsx, which is the documented public component and not the removed undocumented root export. The bridge carries codegenConfig and both android/src/newarch and android/src/oldarch, so it is already New-Architecture shaped.classpath 'com.android.tools.build:gradle:7.0.1' and compileSdkVersion 35 in android/build.gradle. RN 0.88 consumers will be on far newer Gradle.countly-sdk-android is on AGP 9.3.2 with a Gradle 9.7.1 wrapper and compileSdk/targetSdk 37 — already clear of the floor. New in 9.4: strict 1:1 flavour-dimension parity between app and dynamic-feature modules, warnings now and fatal in AGP 10. We ship no dynamic features.countly-sdk-android staging in the window — SDK log gathering and a connection tester (e8dca88f), a breakpad fix, a Java 8 fix and the version bumps that brought consumer-rules.pro with them. The same log-gathering/connection-tester feature landed in countly-sdk-ios (1e2ba33) and countly-sdk-js (77f2bde) in the same window — a coordinated three-SDK feature, which is worth noting because cross-SDK simultaneity is rare enough to be a signal about how this one should be documented.Unsafe or assume a 96-bit header. countly-sdk-java does neither; it is a Java 8 source/target HTTP client. Java 8 source and target levels remain accepted by JDK 27's javac. This is an obsolescence clock, not an event.countly-sdk-java shipped 26.8.0 on 8 September (0b322fcf), plus a fix for multiple publish plugins. The baseline table had it four release-lines behind; see Cleared.engines. Re-read this run: countly-sdk-nodejs/package.json at 24.10.4 still has no engines field — fourth week running. Zero runtime dependencies, so it stays a genuinely one-line change, and it stays a P2 that this radar will not PR.headingLevel behaviour, and removal of describeEnum — none of which a bridge that ships no widgets touches. Still unreleased and still the one to watch: the migration to standalone material_ui and cupertino_ui packages, plus new restrictions on command-line flags for prebuilt Android release binaries.2020.3.20f1 continues to block any verification at all, and now also carries an iOS/tvOS target of 10.0 into the Apple finding above.10 September. sentry-cocoa 9.28.0 added beforeSendWithHint and beforeBreadcrumbWithHint callbacks, a hint parameter across the public capture methods on SentrySDK, auto-population of HTTP request and response data onto the hint for network operations, and access to screenshot and view-hierarchy attachments via hint.attachments.
Do we have it? Partially, and only for crashes. countly-sdk-android's CountlyConfig exposes crashes.setGlobalCrashFilterCallback(GlobalCrashFilterCallback) (with the older setCrashFilterCallback deprecated), and that is the whole of our before-send surface. There is no equivalent for events, no equivalent for requests, and no context object carrying the underlying raw data into the filter.
The headline feature is not the interesting part. A general hints system across every capture path is a cross-SDK contract and a large piece of work. The detail worth copying costs almost nothing: auto-populating the filter callback's payload with the HTTP request and response that produced the event. Today a customer writing a crash filter sees the crash and nothing about the failing network call underneath it, so redaction and suppression rules have to be written blind. Enriching the existing GlobalCrashFilterCallback payload is a one-SDK change with no new public type and no new init flag, and it is the thing that makes every later hints work land cleanly.
countly-sdk-android · countly-sdk-ios
SentryTraced now respects options.setIgnoredSpanOrigins and resolves owning transactions dynamically, one ui.compose span per initial composition instead of per recomposition, app-start consistency fixes, native SDK to 0.16.6. Maintenance. The hybrid-SDK APIs flagged here last week (InternalSentrySdk.captureEnvelopeNonTerminating, Session.State.Unhandled) landed in 8.55.0 on 3 September and remain the standing steal for our Flutter and RN bridges.Package.swift today. Amplitude is at 13. Mixpanel is at 12, with us. Whatever we decide, we are deciding it late rather than first.opentelemetry-js is still 2.11.0 and experimental 0.222.0 (31 August), with SdkLogRecord deprecated in favour of ReadWriteLogRecord, fail-fast construction from config files, and server-span query-parameter redaction. Semantic conventions unchanged at 1.44.0.countly-sdk-js:otel-telemetry-phase1 carries no OTel code, the real work sits uncommitted in a working tree, and ly.count.android:sdk-otel does not exist on Maven Central. A quiet upstream week is the cheapest possible week to fix that.| When | Platform | What |
|---|---|---|
| 2026-09-15 | java | JDK 27 GA. Non-LTS, 6-month support. No Countly surface — obsolescence clock only. |
| 2026-09-30 | android | Developer verification in BR, ID, SG, TH. No SDK surface; customer-question item. |
| 2026-10-01 | java/apple | Maven Central publishing limits go to hard enforcement. Same date: EU App Store business terms, Core Technology Commission replaces CTF. |
| 2026-10 | nodejs | Node 26 becomes Active LTS — the moment to declare engines. Fourth week with none. |
| 2026-10 | unity | Unity 6.0 LTS support ends. 6.3 LTS supported to 2027-12. |
| 2026-11-01 | dotnet | All pre-2026-08-17 NuGet.org API keys expire. Countly 26.1.0 was published 2026-08-13. 48 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. |
| 2027-02 | android | Play quality requirements: dynamic memory, background bitmap memory, 25% DEX optimisation via R8. Measured on the app, not the library — narrowed to a support item now that consumer R8 rules ship. |
| 2027-04 | apple | iOS/iPadOS/tvOS/visionOS/watchOS 27 SDK required by App Store Connect. Now announced by Apple, no longer extrapolated. |
| pending | apple | Xcode 27 deployment-target range is 15.0–27.0. Four repos declare below it. Human decision. |
| pending | otel | OTel initiative still has no shippable path: no committed branch, no published sdk-otel artifact. |
| pending | bridges | flutter-bridge AGP classpath 3.2.1, rn-bridge 7.0.1, both compileSdk 35. Both now wrap ly.count.android:sdk:26.1.2 against Android 26.1.5. |
| pending | rn/flutter | SwiftPM: Flutter has a swiftpm-support-ios branch, RN has neither Package.swift nor a branch. |
| pending | unity | Editor pinned at 2020.3.20f1, blocking all verification. CoreCLR replaces the scripting runtime in 6.8. |
| pending | competitors | Session replay across PostHog, Amplitude, Mixpanel, Sentry, Datadog RUM — zero of our 13 SDKs. Sentry's manual-control API is a published cross-platform contract. |
| pending | competitors | Cheap steals outstanding: Sentry hybrid-SDK non-terminating envelope APIs; PostHog route-template pageviews; Sentry Cocoa hint payload enrichment. |
| pending | dart | Dart 3.13 removed built-in fallback root certificates from the VM. Effect on countly-sdk-dart HTTPS still untested. |
| pending | hos | HarmonyOS unverified for a third week. Our targetSdkVersion 6.0.2(22); secondary sources suggest 6.1.1(24) current. |
developer.apple.com/documentation/xcode-release-notes/xcode-27-release-notes returned the page title and no body. The lead finding therefore rests on secondary sources: GitHub issues filed against Datadog, Adjust, Facebook and SDWebImage (which say warnings), a JetBrains Compose Multiplatform issue, and a third-party blog (which says error). The 15.0–27.0 range figure is consistent across all of them; the severity is not. Confirming error-versus-warning requires opening Xcode 27, which this radar cannot do.amplitude.com/docs/changelog and docs.mixpanel.com/changelog, both for the second consecutive week. Statsig, RevenueCat, Datadog RUM, Heap, Pendo, Segment and Embrace were not reached at all this run.countly-sdk-hos's standing against current API levels is genuinely unknown, not merely unchanged.origin/<branch> after git fetch in Arif's checkouts; no working tree was modified and no local branch was read.Countly 26.1.0 (13 August 2026) is carried from last week's verification and was not re-queried this run.