Weekly platform, competitor and sector sweep for the Countly SDK fleet. Window 12 October to 19 October 2026.
The Xcode 27 deployment-target P0 is fixed in code and now needs a release. Three weeks of "unchanged" ended this week. countly-sdk-ios raised its floor to iOS 15 / macOS 12 / tvOS 15 / watchOS 9 in Package.swift, Countly.podspec and Countly-PL.podspec (commit a99e014, 13 October, merged through PR #483). countly-sdk-react-native-bridge went a different way: its podspec now inherits React Native's own min_ios_version_supported (PR #508, 18 October), and its draft #506 was closed. The Flutter bridge, the one case with no app-side workaround, has the fix in PR #405: podspec and Package.swift to 15.0, ready for review since 14 October. Unity, on closer reading, was never exposed. None of this is released, though, and iPhone Duo ships to customers on Thursday 23 October. It stays P0 until a customer can install the fix. The work left is release work.
This week's cheap find came from our own C++ SDK. countly-sdk-cpp merged a fix on 17 October for "session, view and timed event durations changing when the system clock was adjusted". In the same week, posthog-js 1.438.12 and dd-sdk-ios 3.16.1 shipped the same fix for clock-change bugs. Android, iOS and Web all still measure session duration as a difference of wall-clock readings (code cited below). One SDK in the fleet has already solved it, so the others can follow a known pattern. Separately, Android's removal of deprecated calls (PR #621) would break the Flutter bridge's current staging at 18 call sites. PR #405 already moves all of them, so the risk is merge order, not code. Zero PRs: the P0 needs a release, not a patch, and nothing else is both P0/P1 and mechanical.
Same mechanism as before: Xcode 27 makes a deployment target below iOS 15.0 a hard build error, and the app-side post_install lift does not reach a pod's resource_bundles target. What changed is the status of each of the ten files.
| Repo | Files | State on 19 October |
|---|---|---|
countly-sdk-ios | Package.swift, Countly.podspec, Countly-PL.podspec | Fixed on origin/staging: .iOS(.v15) .macOS(.v12) .tvOS(.v15) .watchOS(.v9) .visionOS(.v1); podspecs ios 15.0 / osx 12.0 / watchos 9.0 / tvos 15.0. CHANGELOG has it as a Minor breaking change. Latest release still 26.1.4 (11 August). |
countly-sdk-react-native-bridge | CountlyReactNative.podspec | Fixed on origin/staging by a different route: s.ios.deployment_target = defined?(min_ios_version_supported) ? min_ios_version_supported : '10.0'. The comment says this is for the privacy bundle target. Latest npm release still 26.1.0. |
countly-sdk-react-native-bridge | ios/src/Countly.podspec, ios/src/Countly-PL.podspec, ios/src/Package.swift | Not exposed. Still iOS 10 in the repo, but package.json "files" ships only ios/src/*.h, *.m, PrivacyInfo.xcprivacy, LICENSE and the dSYM script, so these three never reach a consumer. |
countly-sdk-flutter-bridge | ios/countly_flutter.podspec, ios/countly_flutter/Package.swift | Still '10.0' / .iOS(.v10) on staging. PR #405 (open, not a draft, review required) moves both to 15.0, plus scripts/no-push-files/countly_flutter_np.podspec, with the CHANGELOG line "Raised the minimum supported iOS version to 15 (previously 10)". |
countly-sdk-unity | ProjectSettings/ProjectSettings.asset | Cleared, see below. The asset is the SDK's own editor project. The consumer's Player Settings set the generated Xcode project's target. |
countly-sdk-ios · countly-sdk-flutter-bridge · countly-sdk-react-native-bridge
Why it stays P0. Every version a customer can install today still declares the old floor. A Flutter app moving to Xcode 27.1 for iPhone Duo still hits countly_flutter at iOS 10 with no workaround. Apple's 5 October news item is the trigger: "Recompile existing apps with Xcode 27.1, which adds development support for iPhone Duo."
Residual, P3. The RN fallback is still '10.0' when min_ios_version_supported is undefined. That happens only on React Native below 0.71, which is unlikely to be built with Xcode 27.
Smallest fix Merge Flutter PR #405, then cut releases of countly-sdk-ios, the Flutter bridge and the RN bridge. Ideally do it before 23 October, or as soon after as possible. The Flutter bridge wraps the iOS SDK, so the iOS release goes first. Then update the iOS KB article, which still says iOS 12. Not a radar PR: the code is done, what remains is a release decision.
maven.countly.com still does not resolve, fourth weekRe-checked today: dig +short maven.countly.com returns nothing and curl returns HTTP 000. maven-test.countly.com still serves only 0.0.1/0.0.2, lastUpdated 20260929094943: twenty days without a dry run. Maven Central's newest is still ly.count.android:sdk 26.1.6 (30 September) and ly.count.sdk:java 26.8.0. Android origin/staging keeps the "!! Major breaking change !! New SDK versions are published at https://maven.countly.com" entry at the top of XX.XX.XX, and this week that unreleased block grew a long list of removed deprecated calls.
New this week. Flutter PR #405 bumps the bridge to ly.count.android:sdk:26.1.6, the last version on Central, without adding the new repository. It is correct for now, and it is also the last bump either bridge can make until the repository block is added. The RN bridge is still on 26.1.2.
countly-sdk-android · countly-sdk-java · countly-sdk-flutter-bridge · countly-sdk-react-native-bridge
Smallest fix Unchanged. Make maven.countly.com resolve and serve, add the repository block to both bridges' android/build.gradle, and update the Android and Java KB install snippets in the release week. The board key was rejected on 6 October as "Not worth it now". This page reports it and does not resend the card.
countly-sdk-ios #479 is open, still a draft, and has not been updated since 6 October. It adds the @discussion lines on shouldUseMachSignalHandler. The KB half is board card C-103 and is still in the inbox. Our default crash path is still clean: NSSetUncaughtExceptionHandler plus signal(). The exposed path is opt-in through Countly-PL.podspec. iOS staging also improved crash handling this week: "The SDK's handlers now pass crashes on to the handlers they replaced, leave crash tools installed later and signals the app ignores … alone". That does not touch the Mach path.
countly-sdk-ios
Smallest fix Take #479 out of draft and merge it into the same iOS release that ships the iOS 15 floor. Then write the KB note (C-103).
countly-sdk-swift 26.8.0 still has no documentation, fourth weekRe-checked against countly-backup-documentation origin/HEAD (18 October backup). Knowledge Base/SDK Specs/ holds the same fourteen files, with no Swift article. git grep countly-sdk-swift -- "Knowledge Base/" finds nothing. The repo moved again: PR #10 (staging_review) merged 13 October. The Web team showed it can be done fast: the Web_analytics_JavaScript_ article was updated on 15 October, the day countly-sdk-web 26.8.0 shipped, and already documents push_vapid_public_key, track_form_values and global_content_segmentation.
countly-sdk-swift
Smallest fix Unchanged. Turn the 26.8.0 CHANGELOG, which already reads like an API reference, into a SDK Specs/ article, then add the row to SDK_Repos_and_Features. This is authorship, so it is a proposal, not a PR. Board card C-30 is in review.
ProjectSettings/ProjectSettings.asset (iOSTargetOSVersionString: 10.0, line 193) configures the SDK repo's own editor project. A consuming game imports Assets/Countly/, and the Xcode project Unity generates uses that game's Player Settings target. The only iOS native code we ship is four files under Assets/Countly/Plugins/iOS/ (CountlyNotificationService.{h,m}, CountlyPushHandlerInternal.{h,m}). They compile into the generated project at its target, and we ship no podspec or Package.swift. Board card C-50 is not resent.
v0.88.0 shipped 15 October and calls itself "a non-breaking release". (1) Codegen no longer crawls node_modules (39751d8). The commit scopes this to the walk inside a library's directory that looks for .mm Fabric component files. It does not touch how libraries are discovered. Our codegenConfig is {type: "all", jsSrcsDir: "src"}, a TurboModule with no components and no .mm files. (2) The SwiftPM autolinking fix for libraries that ship their own Package.swift does not apply: our ios/src/Package.swift is not in the published npm files list. One 0.88 change worth knowing: Android networking now sends app name and version as the default User-Agent. That applies to RN's own fetch stack, not to our native transport.
Android PR #621 (14 October) removes 40-odd deprecated calls from CountlyConfig, RemoteConfig, Views, Apm, Ratings and push. Grepping each bridge's android/src on origin/staging: RN is clean. Every call uses the replacement (config.crashes.enableCrashReporting(), CountlyPush.init(configPush), sdkInternalLimits.*), the result of RN PR #507. Flutter staging has 18 call sites to removed APIs, for example config.enableCrashReporting(), setCustomCrashSegment, setRemoteConfigAutomaticDownload, remoteConfig().updateForKeysOnly/updateExceptKeys/clearStoredValues/getValueForKey, setRecordAppStartTime, CountlyPush.getLastMessagingMethod and CountlyPush.init(Application, mode). On PR #405's branch (staging_review_fixes) the same grep finds zero. Remaining risk, sent as a P2 card: the bridge must not take the next Android major before #405 merges.
sentry-cocoa #9332 (9.30.2, 14 October) fixes EXC_BAD_ACCESS from bridging CTTelephonyNetworkInfo.serviceCurrentRadioAccessTechnology, which CoreTelephony returns uncopied and mutates on a private queue (issue #9312: ~116 crashes / 7 days across four apps, mostly iOS 26). On iOS origin/staging the only CTTelephonyNetworkInfo use is subscriberCellularProvider.carrierName (CountlyDeviceInfo.m:257), and only below iOS 16.4. connectionType (:424) reads getifaddrs interface names (pdp_ip0/en0).
Correction to the 12 October edition. It cleared device.connection_effective_type by saying we report cellular generation "for years". We do not. iOS reports Wi-Fi vs cellular from interface names. Android's DeviceInfo.java reads getNetworkOperatorName() and getActiveNetworkInfo().isConnected(), with no getDataNetworkType. The cellular generation (4G/5G) is a real P3 gap, and this week it also happens to be a crash-prone API to read.
chromiumdash: 156 stable 20 October. versionhistory already shows 156.0.8078.35/.36 at 0% next to 155.0.8059.80–85. The feature list (chromestatus, secondary) covers module-failure caching, compression dictionary transport, CSS random(), an IndexedDB SQLite backend, WebGPU and WebRTC logging, and the removal of FencedFrame. Nothing about cookies, partitioning, sendBeacon, Storage Access, Push or referrer policy. We use localStorage/sessionStorage, not IndexedDB, so the backend switch is invisible to us.
countly-sdk-web 26.8.0 was released 15 October (GitHub release and npm latest, 11:46 UTC). It has four Minor Breaking Changes: form-tracking redaction, a new content consent, a session on change_id only with track_sessions, and the in-flight queue moving to sessionStorage. It also adds web push. The KB article Web_analytics_JavaScript_ was updated the same day and mentions 26.8.0 seven times and push_vapid_public_key seven times. Nothing is stale, so there is no docs item.
RCT_REMOVE_LEGACY_MODULE_INTEROP / RCT_REMOVE_LEGACY_COMPONENT_INTEROP flags (off by default, "will become the default in a future release"). Our bridge has both newarch and oldarch sources, so check it before the default flips. P26000.0.85f1 LTS, 6000.6.6f1 Supported, 6000.7.0b5 beta, 7000.0.0a10 alpha (a9 on 13 October). The Unity 7 alpha cadence is now twice a week. Our editor is still pinned at 2020.3.20f1 and the SDK at 24.8.2.countly-sdk-nodejs still declares no engines field (ninth week), and nothing changed on staging since 24 August.11.0.0-rc2 plus 10.0.13 / 9.0.21 / 8.0.32 servicing on 13 October. .NET 8 and 9 reach end of support on 10 November, which was cleared earlier. countly-sdk-windows merged a fix on 16 October for "Windows 8.1, 10 and 11 reported as Windows 8 (6.2.9200)" on .NET Core 3.1 and older.countly-sdk-cpp declares cmake_minimum_required(VERSION 3.13...3.31), so it is safe. The C++ SDK also merged a COUNTLY_USE_SYSTEM_JSON option and static libcurl builds.| Release | What shipped | Do we have it? | Call |
|---|---|---|---|
| posthog-js 1.438.12 (15 Oct) | "Prevent backward device clock changes from subtracting client rate-limit tokens." | Same bug class, different symptom: see the steal below. | P2 worth it |
| dd-sdk-ios 3.16.1 (15 Oct) | "Prevents incorrect RUM session expiration caused by device clock changes or cross-platform timestamp differences." | No. iOS session length is a wall-clock difference. | P2 worth it |
| posthog-flutter 5.55.0 (13 Oct) | Experimental Windows and Linux support, on by default ("Existing apps will start tracking on Windows and Linux after upgrading"), with enableWindowsAndLinux = false to opt out. State under the app-support directory, in-memory fallback. | No. Our bridge declares android, ios, web only. countly-sdk-dart is pure Dart and could back a desktop platform. | P3 not now. On-by-default for a new platform is the part not to copy. |
| sentry-java 8.61.0 (14 Oct) | Defined what happens when a user callback throws: drop the item, report callback_error, never fail the host request. | Partly. Our uncaught crash path catches Throwable around recording and still delegates (ModuleCrash.java:279-292). On the handled path, recordException calls crashFilterCheck (:406) unguarded, so a throwing GlobalCrashFilterCallback escapes from recordHandledException into the app's own catch block. | P3 one try/catch. Do it when C-104 adds the event filter. |
| analytics-swift 1.10.3 (16 Oct) | "hold a background task for the duration of the background flush" | Yes: CountlyCommon.m:976 beginBackgroundTaskWithExpirationHandler. | have it |
| mixpanel-android 8.11.1 (16 Oct) | "restore Kotlin 2.0 consumer floor", an accidental Kotlin metadata floor raise, then reverted. | Not exposed: sdk/ has zero .kt sources, and sdk/build.gradle says dependencies are pinned to bring "no Kotlin standard library". | clear |
| posthog-react-native 4.81.2 (14 Oct) | Fatal JS crashes the JS handler missed (React render errors on iOS) now go through native crash capture. | RN staging now records an uncaught release-build JS error "once, as a fatal crash with its JS stack, instead of twice". A different fix, same area. | P3 noted |
| Amplitude-Kotlin 1.35.0 (16 Oct) | Autocapture of non-tap gestures and selectable Compose controls. | No autocapture on Android. | P3 |
| posthog-js 1.438.11 (15 Oct) | WebMCP failures now go to Error Tracking via ErrorTrackingExtensions in the slim bundle. | No WebMCP. | P3 continues last week's sector item |
| RevenueCat, Embrace (apple 7.0.0 tagged as a bare CI bump), AppsFlyer 7.0.3, Datadog browser 7.16.0, sentry-cocoa 9.30.2 / -dart 10.1.0 / -react-native 8.31.0 / -javascript 11.7–11.8 | Replay, profiling, bundler and integration work. | n/a | P3 nothing to take |
countly-sdk-cpp origin/staging, merged 17 October (PR #161): "Fixed session, view and timed event durations changing when the system clock was adjusted while the app was running." The other SDKs still use wall-clock differences:
ModuleSessions.java:198-200: System.currentTimeMillis() - prevSessionDurationStartTime_. UtilsTime already exposes System.nanoTime() (:62).CountlyConnectionManager.m:1290-1291: NSDate.date.timeIntervalSince1970 - lastSessionStartTime. CountlyCommon.m:878 is the same.lib/countly.js session (:4539), view (:8904) and timed-event (:5728) durations, all getTimestamp() - ….A clock moved back by NTP, by the user or by a timezone bug gives negative or zero session_duration. A clock moved forward gives hours of fake engagement. Neither is visible to the customer. Timestamps should stay wall-clock, because the server needs them. Durations should not.
countly-sdk-android · countly-sdk-ios · countly-sdk-web · countly-sdk-js
Smallest fix Copy the C++ change. Record a monotonic start next to each wall-clock start, and compute durations from the monotonic pair: SystemClock.elapsedRealtime() on Android, CACurrentMediaTime() / NSProcessInfo.systemUptime on iOS, performance.now() on Web. Android first. The changelog line can reuse the C++ wording.
opentelemetry-js-contrib Node instrumentation patches shipped. Last week's browser-instrumentation deprecation (C-106) stands.SDK Specs/ files for fifteen shipping packages.iOS_watchOS_tvOS_macOS-360037753511.txt still says iOS 12 twice. The release that fixes the P0 will make that wrong on day one. The Web team showed the same-day pattern works.mavenCentral() and 26.1.5 (two versions stale). The next Android release adds the repository change and removes 40-odd deprecated calls, and any of those still in the article's snippets will stop compiling. Do the three edits in one pass on release week.| When | What | Affected |
|---|---|---|
| 2026-10-20 | Chrome 156 stable (cleared). Node 24.x enters Maintenance LTS | web, nodejs |
| 2026-10-23 | iPhone Duo on sale. Xcode 27.1 is the recompile target. The deployment-target fix is merged for iOS and RN and in PR #405 for Flutter, but not released | ios, flutter, rn |
| 2026-10-28 | Node 26.x becomes Active LTS | nodejs |
| 2026-11-01 | Play target-API extension deadline (cleared 12 October). NuGet pre-17-August API keys expire (rejected, date only) | android, windows |
| 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 | 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 quality requirements (app-level) | ios, android |
| 2027-04 | iOS 27 SDK required plus iPhone Duo screenshots on new submissions | ios, flutter, rn, unity |
| next release | Android/Java move to maven.countly.com, which still does not resolve. Android also removes deprecated calls | android, java, flutter, rn |
| open | Merge order: Flutter #405 before the bridge takes the next Android major | flutter |
| open | RN opt-in legacy-interop removal flags will 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> after a git fetch, never from a working tree. The removed-API grep against the bridges is a text match of method names. It is not a compile, so overloads that survived the removal could still give false positives.
The monotonic-clock finding is reasoned, not reproduced. The code lines are read from source. Nobody moved a device clock during a session.
Xcode 27.1 final is unconfirmed. Search found only the 5 October RC. developer.apple.com/documentation/* still renders title-only. The Apple news link id for iPhone Duo came back as kkphp5qo in this week's fetch, against last week's k4id6cpb, so one of the two is a tool artifact.
Chrome 156's feature list is secondary (chromestatus). Dates and versions come from chromiumdash and versionhistory, which are primary.
countly-sdk-js 26.8.0 has no published artifact we could find. GitHub has no releases. The npm name countly-sdk-js belongs to a 2023 package whose repository points at countly-sdk-cordova (latest 22.9.0). Whether the modular SDK publishes under another name is unknown. P3.
HarmonyOS, eighth week. Statsig, Heap, Pendo and LogRocket were not reached: their GitHub release endpoints returned nothing in the window, or the repo was not found. Android Play policy comes from search summaries only.