Weekly platform, competitor and sector sweep for the Countly SDK fleet. Window 5 October to 12 October 2026.
The Xcode 27 deployment-target P0 stopped being a hypothetical and acquired a consumer date. On 5 October Apple announced that iPhone Duo reaches customers on 23 October and told developers to recompile with Xcode 27.1, whose RC shipped the same day. Until now the Xcode 27 upgrade was voluntary and the floor was a thing that would bite eventually. A hardware launch eleven days out is what actually moves a fleet of app developers onto a new toolchain, and Xcode 27 is the one that turns a below-range deployment target from a warning into a hard build error. countly-sdk-flutter-bridge/ios/countly_flutter.podspec still declares s.ios.deployment_target = '10.0' on line 18 next to an s.resource_bundles entry on line 15, and that combination is the one the standard app-side post_install lift does not reach. The customer has no workaround.
The good news is that the board is working. Two of last week's findings came back as draft PRs opened by night workers rather than as repeated entries on this page: countly-sdk-ios #479 documents the PLCrashReporter / Enhanced Security incompatibility in CountlyConfig.h, and countly-sdk-react-native-bridge #506 raises the React Native side of the deployment-target floor. Neither is merged and neither covers the Flutter bridge, but the loop from radar to patch closed inside a week for the first time. The Maven migration, by contrast, did not move at all: maven.countly.com is still NXDOMAIN today and maven-test has not served a new dry run since 29 September.
The competitor week produced one finding sharper than its headline. mixpanel-js 2.84.0 added an on_track hook that sees every event with its merged properties and can rewrite it or return null to drop it; three days later posthog-ios 3.92.0 settled the matching policy question by letting per-event properties win over everything except a named reserved set, with beforeSend as the supported rewrite path. We already have exactly this shape, but only for crashes: ConfigCrashes.setGlobalCrashFilterCallback, while events get only a server-driven name blacklist. That makes it a small symmetric extension of an API we already shipped, and it is also the answer to the reserved-key audit this page has been carrying for two weeks. Zero PRs again, which remains the right outcome: the P0 is a minimum-version bump a human has to authorise, and the P1s are blocked on DNS, on a design call, and on authorship.
The mechanism is unchanged and was settled on 28 September: Xcode 27 turns a deployment target below the supported range into a hard build error, the range starts at iOS 15.0, and react-native #58555 established that the usual app-side post_install lift walks only target_installation_result.native_target, so a pod that also declares resource_bundles keeps the podspec's value. What changed this week is the timeline.
| Evidence, this week | Value |
|---|---|
| Apple Developer News, 5 October | "iPhone Duo will be available to customers starting October 23, 2026 … Recompile existing apps with Xcode 27.1, which adds development support for iPhone Duo." |
| Same item, submission deadline | "Starting April 2027, any apps or games submitted will need to include screenshots for iPhone Duo." |
| Apple release feed, 5 October | Xcode 27.1 RC, build 27A9275 |
countly-sdk-flutter-bridge ios/countly_flutter.podspec, read today from origin/staging | line 15 s.resource_bundles = { 'countly_flutter_privacy' => [… PrivacyInfo.xcprivacy] }, line 18 s.ios.deployment_target = '10.0' |
| Below-range files | Ten, across four repos. Unchanged on origin/staging for the third consecutive week |
countly-sdk-swift | Already in range: .iOS(.v15) .macOS(.v12) .tvOS(.v15) .watchOS(.v9) .visionOS(.v1) |
countly-sdk-flutter-bridge · countly-sdk-ios · countly-sdk-react-native-bridge · countly-sdk-unity
Why the date matters. A build error only fires when someone upgrades their toolchain. For eleven months Xcode 27 adoption has been a developer's own choice, which is why this has sat at P0 without anyone reporting it. A device shipping to customers on 23 October, with Apple explicitly instructing developers to recompile on 27.1 to support it, is the event that converts a slow drift into a wave, and every Flutter app in that wave that embeds us hits countly_flutter with an unliftable iOS 10 target.
Second data point, from the largest iOS SDK there is. firebase-ios-sdk 13.0.0 shipped on 7 October as a major, raising its minimum macOS to 11.0 and watchOS to 8.0, moving from C++14 to C++17, and landing a cluster of scene-delegate fixes plus a new FIRSceneFinder utility for locating active window scenes. Our Apple floors are macOS 10.14 and watchOS 4. Firebase moving is the clearest signal available that the bottom of the supported range is being abandoned by the ecosystem, not just by Apple's tooling.
Progress. countly-sdk-react-native-bridge #506 is open as a draft from the board, touching CountlyReactNative.podspec, ios/src/Countly.podspec, ios/src/Countly-PL.podspec and ios/src/Package.swift. That is four of the ten files. The Flutter bridge, the iOS SDK and Unity are still untouched, and the Flutter podspec is the only one of the ten with no customer-side escape.
Smallest fix Raise ios.deployment_target to 15.0 in countly-sdk-flutter-bridge/ios/countly_flutter.podspec, before the other nine. Still not a radar PR: §7 forbids bumping a minimum platform version, and the Flutter Apple files are carrying in-flight SwiftPM work on PR #399.
maven.countly.com still does not resolveNo commits in countly-sdk-android or countly-sdk-java touched the release pipeline this week, and the infrastructure is in exactly the state it was in on 5 October.
| Checked today | Result |
|---|---|
dig +short maven.countly.com | empty: NXDOMAIN, second week |
curl https://maven.countly.com/ly/count/android/sdk/maven-metadata.xml | HTTP code 000, connection never established |
maven-test.countly.com | Live, 104.21.9.244 / 172.67.161.200. Still only 0.0.1 and 0.0.2, lastUpdated 20260929094943: no new dry run in 13 days |
countly-sdk-flutter-bridge/android/build.gradle | line 6 and 17 mavenCentral(), line 11 classpath 'com.android.tools.build:gradle:3.2.1', line 42 implementation 'ly.count.android:sdk:26.1.2' |
countly-sdk-react-native-bridge/android/build.gradle | line 3 and 58 mavenCentral(), line 8 classpath 'com.android.tools.build:gradle:7.0.1', line 68 the same coordinate |
Knowledge Base/SDK Specs/Android-360037754031.txt | Still mavenCentral() ×2 and ly.count.android:sdk:26.1.5: now two versions behind the published 26.1.6 |
countly-sdk-android · countly-sdk-java · countly-sdk-flutter-bridge · countly-sdk-react-native-bridge
What breaks, unchanged. Nothing today: 26.1.6 is on Maven Central and the pipeline change sits under an unreleased ## XX.XX.XX heading. On the day the next version ships: every integrator who has not edited settings.gradle gets a resolution failure, which is the announced cost; our own two bridges cannot bump past 26.1.2 because neither declares a repository that will hold the artifact; and the published install instructions send customers to a repository we no longer publish to.
Smallest fix Unchanged and still in this order. (1) Make maven.countly.com resolve and serve: it is the only hard blocker on shipping the next release, and thirteen days of silence on the test host suggests nobody is currently working it. (2) Add the repository block to both bridges' android/build.gradle. (3) Update the Android and Java KB install snippets in the same week the release goes out. Both CHANGELOGs already carry paste-ready Gradle and Maven snippets.
No PR. A PR that adds a repository URL returning NXDOMAIN is worse than no PR.
Raised here on 5 October. A night worker picked it off the board on 6 October and opened countly-sdk-ios #479, a draft against staging touching two files: three @discussion lines on the shouldUseMachSignalHandler doc comment in CountlyConfig.h, and one CHANGELOG.md entry under the unreleased heading. Documentation only, no behaviour change, matching the header's existing @discussion / @c style.
countly-sdk-ios
What the PR explicitly does not cover, in its own words, the durable fix, vendoring and patching PLCrashReporter the way posthog-ios #863 did, or retiring the PL path, remains a design decision with no owner. And the KB half of the finding lives in Countly/countly-backup-documentation, a different repo, so it needs its own board card. That card is sent this week.
Nothing upstream changed. microsoft/plcrashreporter is still at 1.12.2, last commit 12 November 2025, with no issue about EXC_GUARD or Enhanced Security. The second affected SDK, KSCrash #956, is still open.
Smallest fix Review and merge #479, then open the KB note. The Mach handler stays incompatible with Enhanced Security either way; the documentation is what stops a customer losing a day to a silent launch-time abort with no diagnostic naming Countly.
countly-sdk-swift has no help centre article, eighteen days after its first releaseRe-verified today against countly-backup-documentation at HEAD, which advanced to 8 October with Zendesk sync commits and a Mattox versioning change. Knowledge Base/SDK Specs/ still holds exactly fourteen files and Swift is not one of them; grep -rl "countly-sdk-swift" "Knowledge Base/" still returns nothing; SDK_Repos_and_Features still omits it.
countly-sdk-swift · countly-sdk-js
The repo, by contrast, is busy. countly-sdk-swift merged four PRs this week: SQLite storage work (#7), review-phase findings (#9), and the log-gathering consent change (#8) with tvOS test fixes. A package that is actively changing and has no public documentation at all is a worse gap each week, not a stable one: the CHANGELOG that would be cheapest to restructure is itself drifting.
Smallest fix Unchanged. Restructure the 26.8.0 CHANGELOG, which is already close to an API reference, into an SDK Specs/ article covering the multi-instance entrypoints, the events / views / sessions / userProfile namespaces and the .countlyView(_:) SwiftUI modifier, then add the row to SDK_Repos_and_Features. Authorship, so a proposal rather than a PR. The secondary gap is unchanged too: there is still no countly-sdk-js article, only the one documenting countly-sdk-web.
Last week's watchlist put Chrome 155 at roughly 21 October. It beat that: chromiumdash gives a stable date of 6 October, and versionhistory.googleapis.com shows 155.0.8059.39 serving to 24.75% of Windows stable since 8 October, against 154.0.8037.98/.99 on the rest. The release contains margin-trim, a chrome.debugger enterprise-policy change, the final removal of the PdfViewerOutOfProcessIframeEnabled policy deprecated in 152, and a URL Standard conformance change that disallows spaces in non-file:// URL hosts. The last is the only one that is even URL-shaped, and a Countly server host never contains a space. No storage partitioning, cookie policy, sendBeacon or Storage Access API change in this milestone.
This page has carried “no Flutter release in window” as an inference for three weeks, because github.com/flutter/flutter/releases is abandoned at v1.16.3 (2024) and the docs release-notes page has a 2026-08-12 footer. raw.githubusercontent.com/flutter/flutter/stable/CHANGELOG.md works and is dated: it shows Flutter 3.47.7, tagged 8 October, two iOS accessibility hotfixes: OverlayPortal accessibility frames shrunk by the device pixel ratio so VoiceOver focus and XCUITest taps miss the controls, and ReorderableListView semantics focus jumping to the top-left. Neither touches a plugin. The inference becomes an observation.
Unity is the same story. unity.com/releases/editor/archive is a navigation page with no dates; services.api.unity.com/unity/editor/release/v1/releases returns a dated, stream-tagged list. It shows 6000.3.26f1 (LTS) and 6000.6.5f1 (Supported) on 8 October, 6000.7.0b4 beta the same day, and, new, a public Unity 7 alpha stream: 7000.0.0a7 on 6 October and 7000.0.0a8 on 8 October. Our editor is still pinned at 2020.3.20f1 and the SDK at 24.8.2, which is unchanged, but the Unity watch item now has a source that can be checked in one call instead of read off a forum thread.
Carried unresolved since 21 September, when a search returned Dart 3.12.2 (June 2026) as newest and contradicted the 3.13 claim. Settled from primary sources: storage.googleapis.com/dart-archive/channels/stable/release/latest/VERSION returns 3.13.5, dated 2026-09-29, and the tagged CHANGELOG.md at 3.13.5 opens its ## 3.13.0 section with "Released on: 2026-08-12". The root-certificate removal is in that changelog verbatim under Dart Runtime. The version question is closed; the consequence of that change is carried forward as a new P2 below.
Now inside its final month, so worth stating with the proof rather than carrying as a date. Play requires new apps and updates to target API 36 since 31 August 2026, with an extension available to 1 November 2026. Target API level is declared by the application's merged manifest, not by an .aar; a library's own targetSdk is discarded at merge. countly-sdk-android/sdk/build.gradle compiles and targets 37 with minSdk 21, which is above the requirement anyway, and the bridges' compileSdk 35 constrains only which APIs they can call: an app embedding them can and does compile and target 36. Nothing of ours has to change by 1 November.
Also now inside its final month. countly-sdk-windows ships net35-full, net45 and netstandard2.0 per nuget/Countly.nuspec, at version 26.1.0. None of those is a .NET 8 or .NET 9 target framework; an app on either runtime consumes our netstandard2.0 asset and keeps doing so on .NET 10 LTS (supported to 14 November 2028) and .NET 11, whose GA is scheduled for the same 10 November date. The residual worth watching is unchanged and is an ecosystem question, not a deadline: when our transitive dependencies stop shipping a netstandard2.0 asset.
posthog-ios 3.92.0 (10 October) lists "Send queued events, session replay snapshots, and logs when close() is called instead of holding them until the next SDK setup." That reads like a gap on our side and is not one. Countly.stop() on Android is documented in the source as stopping the instance without erasing anything: "the request queue, event queue, device ID and consent state stay on disk … anything recorded but not yet sent still gets sent" on the next init. halt() is the same plus a deliberate wipe, and is marked testing-only. A disk-backed queue makes the flush-on-close question moot by construction: the data was never only in memory. No change warranted.
READ_CALL_LOG for phone-call account verification, and geofencing removed as an approved foreground-service use case. None reaches an analytics library; all are permission declarations made by the host app.android.newDsl.optOut as a temporary per-module escape before the new Variant API becomes mandatory in AGP 10. countly-sdk-android is already on AGP 9 and clear; the bridges' 3.2.1 and 7.0.1 classpaths are not. P2v0.88.0-rc.4 published 7 October; npm latest is still 0.87.1 (26 August) and next is the rc. rc.4 itself is two lines: a TypeScript module-augmentation change and an Android accessibility fix.node_modules or following symlinks during component discovery, and the rc.3 fix stopping SwiftPM autolinking from recreating library package roots for libraries that ship their own Package.swift. Our bridge ships ios/src/Package.swift.--root-certs-file and --root-certs-cache options to the standalone VM may be used to provide certificates." countly-sdk-dart declares environment: sdk: ^3.0.0, so 3.13 is in range, and lib/src/networking.dart uses package:http, which on the VM resolves to dart:io HttpClient and the default SecurityContext: system roots only.scratch, distroless, a stripped Alpine image). HTTPS to the Countly server fails at handshake, and our SDK exposes no SecurityContext or HttpClient injection point for the integrator to fix it from the outside. Flutter apps are unaffected. Not tested here. See the unverified section.pubspec floor stays sdk: ">=2.12.0 <4.0.0", which is lower than the stale §1 baseline claims.7000.0.0a7 (6 October) and 7000.0.0a8 (8 October), alongside 6000.7.0b4 beta and 6000.3.26f1 LTS on 8 October. Our editor project is pinned at 2020.3.20f1 and the SDK at 24.8.2, the oldest in the fleet by both measures, with local branch fix_web_assemly parked since June. Nothing breaks today; the distance keeps growing.countly-sdk-nodejs is 24.10.4 on origin/staging with still no engines field, eighth week. The only movement in the repo was a Dependabot brace-expansion bump, a dev dependency we do not ship.countly-sdk-cpp's 3.13...3.31 range stays safe. Java: no OpenJDK or Maven Central policy change in window.targetSdkVersion is 6.0.2(22). This still rests on secondary coverage and needs a human with a Huawei developer account.| What shipped | Do we have it? | Call |
|---|---|---|
mixpanel-js 2.84.0 (6 Oct) adds on_track: "called for every tracked event with its merged properties. It can modify the event or return null to drop it." |
For crashes, yes. For events, no. ConfigCrashes.setGlobalCrashFilterCallback is exactly this shape. Events get only ModuleConfiguration's server-driven name blacklist/whitelist: drop-only, name-only, not developer-supplied. |
Worth it. Small on one SDK, and the API precedent already exists in our own codebase. See below. |
posthog-ios 3.92.0 (10 Oct): per-event properties now override registered super properties and SDK context properties, matching posthog-android and posthog-js, except $is_identified, $process_person_profile, $geoip_disable, $recording_status and $sdk_debug_*, which the SDK still owns. |
Open question. Which reserved keys a caller can shadow through our segmentation is still unaudited. | This is the answer to the audit. A named reserved set plus a filter hook for everything else. Two weeks ago posthog-android blocked two keys; this week they settled the general policy. |
dd-sdk-android 3.15.0 (8 Oct) adds a first-flags callback to the Flags client, with first-flags events isolated per subscriber. |
Half. ModuleRemoteConfig.removeDownloadCallback exists at line 828; registration is a config-time list with no handle and no replay. |
Worth it, and now corroborated. Second vendor in two weeks to ship replay-on-register. Carried from last week at the same priority. |
firebase-ios-sdk 13.0.0 (7 Oct): minimum macOS 11.0, watchOS 8.0, C++14 → C++17, mlmodeldownloader removed, scene-delegate handling reworked with a new FIRSceneFinder. |
Our floors are macOS 10.14 / watchOS 4. Scene handling we already do correctly in CountlyDeviceInfo.m, cleared on 5 October. |
Not an action by itself: evidence for the P0. The most-embedded iOS SDK in the world just abandoned the bottom of the range. |
amplitude Swift 1.19.3 and Kotlin 1.34.0 (both 8 Oct) independently "delete acknowledged event files/batches before callbacks" and add diagnostics for interrupted uploads. Kotlin also moved foreground tracking to process lifecycle. |
Unaudited. The ordering question, does our queue delete an acknowledged batch before or after running integrator callbacks, has not been checked. | Cheap audit, not a steal. Both their platforms shipping the same ordering fix in the same week is the signature of a duplicate-event bug found in production. |
sentry-cocoa 9.30.1 (7 Oct) fixes an app freeze during crash handling when attaching a screenshot or view hierarchy under a MainActor scene delegate, and truncates oversize NSException reasons to stay inside the 1 MiB ingestion limit. |
Not applicable: we attach no screenshot or view hierarchy at crash time. | Not worth it. The truncation detail is worth remembering if we ever add crash attachments. |
sentry-java 8.60.0 (7 Oct) adds device.connection_effective_type reporting the cellular generation, e.g. 4g / 5g, and a Navigation 3 integration for Android. |
Yes, on both mobile SDKs and for years, cleared on 5 October when sentry-cocoa added the same field. | Nothing to do. Second Sentry platform in two weeks to catch up to where we already are. |
sentry-javascript 11.5.0 (7 Oct) warns on a repeated Sentry.init() and unbinds the client on close(), so getClient() returns undefined afterwards. |
Different model. Our JS and Web SDKs are multi-instance by design with a named registry. | Not worth it as a change, but the warning is a good pattern for any SDK where a second init is almost always a mistake. |
posthog-ios 3.91.0 (8 Oct) adds $app_build_xcode and $app_build_sdk to install and update events: the Xcode version and SDK the host app was built with. |
No. | P3 Genuinely clever for exactly the kind of toolchain-floor question this page spent the week on: it tells you what your install base is actually compiled against. Cheap to add, hard to justify on its own. |
mixpanel-js 2.84.0 also moved its API reference docs to TypeDoc. |
Neither countly-sdk-web nor countly-sdk-js publishes generated reference docs. |
P3 Noted for the documentation section; not raised as a gap this week. |
Three vendors now expose one developer-supplied callback that sees every outgoing event with its final merged properties and may rewrite it or drop it: Sentry's beforeSend (long-standing), PostHog's beforeSend (now the documented rewrite path for properties the SDK reserves), and as of 6 October Mixpanel's on_track. It is the single point where key collisions, PII scrubbing, per-event sampling and last-mile redaction all get handled, instead of each becoming its own config flag.
Read from origin/staging today. countly-sdk-android has the pattern and the naming already: GlobalCrashFilterCallback as an interface, ConfigCrashes.setGlobalCrashFilterCallback as the setter, ModuleCrash holding and invoking it, and a deprecation on CountlyConfig.setCrashFilterCallback pointing at the new one. For events the only filtering is ModuleConfiguration's FilterList<Set<String>> currentVEventFilterList, fed from a server-sent blacklist or whitelist of event keys. That is a different thing: server-controlled, drop-only, matches on the key alone, and cannot see or change segmentation.
countly-sdk-android · countly-sdk-web
Smallest fix A GlobalEventFilterCallback on Android mirroring GlobalCrashFilterCallback exactly: it receives the event key and the merged segmentation immediately before enqueue, returns false to drop, and may mutate the map in place. Android first as the behavioural source of truth, then Web. Decide the reserved-key policy in the same change, which internal keys the callback and caller-supplied segmentation may not overwrite, and that closes the audit this page has carried for two weeks instead of leaving it open.
experimental/v0.223.0 (6 October) marks a breaking change: "clean up and deprecate network span utils … currently only used by the (deprecated) instrumentation-fetch and instrumentation-xml-http-request packages," with the utilities moved out of sdk-trace-web into web-common. Anyone starting browser OTel work today should not build on those two packages. Our countly-sdk-js:otel-telemetry-phase1 branch still carries no OTel code, so this costs nothing to know now and would be expensive to discover after a design. The two specs that would actually bind us are static: spec 1.61.0 (14 September), semantic conventions 1.44.0 (4 August), unchanged for ten weeks. P2posthog-js 1.438.6 (9 October) exports WebMCPExtensions from the slim extension-bundles entry point and fixes intent/model injection for schemas whose constraints the injected fields would violate. One vendor, shipped as an opt-in extension rather than a default, so no obligation on us, but it is the first time an analytics SDK's browser bundle has carried an agent-facing surface, and the delivery shape (separate extension bundle, not core) is the part worth copying if we ever do it. P3dd-sdk-android 3.15.0 added ANR-triggered profiling with an enableAnrTrigger opt-out and remote-configuration control of it, plus a pre-launch TTID module. Our standing gap is unchanged: no app-hang or ANR detection on any Apple SDK, and if we build it the entry point is MetricKit, not a watchdog thread. P3SDK Specs/ holds fourteen files for fifteen shipping packages, and the missing one is the newest.shouldUseMachSignalHandler now has an owner-shaped hole. PR #479 covers the header doc comment and says in writing that the KB half needs its own card because it lives in a different repo. That card goes to the board this week; without it the half that customers actually read never gets written.Knowledge Base/SDK Specs/Android-360037754031.txt still shows mavenCentral() and 26.1.5. The version is one release stale today, and the repository line becomes actively wrong the moment the self-hosted pipeline runs. Fixing both in one edit is cheaper than fixing them twice.Countly Internal Library/AI SDK/, nothing under Knowledge Base/, and @countly/ai-sdk-openai and @countly/ai-sdk-anthropic both public on npm at 0.0.6. Still needs one sentence from the owner: pre-release, or published with no public documentation.| When | What | Affected |
|---|---|---|
| 2026-10-23 | iPhone Duo reaches customers; Apple instructs developers to recompile on Xcode 27.1. The forcing function behind the deployment-target P0 | ios · flutter-bridge · rn-bridge · unity |
| 2026-11-01 | Play target-API extension deadline. Cleared: binds the app's merged manifest, not an .aar | android |
| 2026-11-10 | .NET 8 and .NET 9 end of support; .NET 11 GA the same day. Cleared: our TFMs are net35-full / net45 / netstandard2.0 | windows |
| 2026-11 | In-SDK Material/Cupertino formally deprecated in Flutter; the bridge ships no widgets, exposure limited to example/ | flutter-bridge |
| 2026-12 | iOS 27.2 alternative EU ATT prompt, mandatory in DE/FR/IT/PL/RO; cleared as an SDK item, support macro only | ios |
| 2027-02-01 | Apple Developer ID Sub-CA expires; cleared, we distribute no signed macOS installer | none |
| 2027-02 | Play quality requirements: dynamic memory, cached bitmap memory, 25% DEX optimisation via R8. Measured on the app, not the library | android |
| 2027-04 | App Store Connect requires the 27 SDKs; iPhone Duo screenshots mandatory on new submissions. The SDK requirement is still absent from the upcoming-requirements page, sixth week | ios · flutter-bridge · rn-bridge · unity |
| next release | maven.countly.com must resolve and serve; both bridges need the repository added before they can bump past 26.1.2 | android · java · flutter-bridge · rn-bridge |
| open | Xcode 27 deployment-target floor: ten files, four repos. RN PR #506 covers four of them; the Flutter podspec, the one with no workaround, is untouched | ios · flutter-bridge · rn-bridge · unity |
| open | PLCrashReporter Mach handler versus Enhanced Security. Draft PR #479 documents it; the vendor-or-retire decision and the KB note are both unowned | ios |
| open | countly-sdk-swift and countly-sdk-js have no KB article; the AI SDK family is documented internally only | swift · js |
| open | No developer-supplied event filter hook; GlobalCrashFilterCallback is the template. Reserved-key shadowing policy to be decided in the same change | android · web |
| open | Remote-config callbacks do not replay for a listener registered after the download. Corroborated by dd-sdk-android 3.15.0 | android |
| open | Dart 3.13 removed the VM's fallback root certificates; package:http on the VM has no CA bundle in a minimal container, and we expose no SecurityContext hook. Untested | dart |
| open | Web/JS fetch() sets no referrerPolicy: lib/countly.js:6985 and modules/CountlyClass.js:8282. One line each | web · js |
| open | Node SDK declares no engines range, eighth week | nodejs |
| open | Bridges: AGP classpath 3.2.1 and 7.0.1, both compileSdk 35, both wrapping ly.count.android:sdk:26.1.2 against 26.1.6. AGP 10 makes the new Variant API mandatory | flutter-bridge · rn-bridge |
| open | Unity editor pinned at 2020.3.20f1, SDK at 24.8.2; Unity 7 alphas now public | unity |
| open | React Native 0.88 still in RC; read the Codegen discovery and SwiftPM autolinking changes before the next bridge cycle | rn-bridge |
| open | HarmonyOS release notes unreachable for seven weeks; the API 24 claim rests on secondary coverage | hos |
| open | Flutter ios/countly_flutter/Package.swift comment claims the iOS SDK targets iOS 10; it targets 12. Wrong regardless of the floor decision | flutter-bridge |
| open | Amplitude shipped the same acknowledged-batch-deletion ordering fix on Swift and Kotlin in one week. Our queue's delete-versus-callback ordering is unaudited | android · ios |
Nothing in this edition was built, run or tested. No repo in the fleet was compiled, no app was launched under Enhanced Security, and no Xcode 27.1 build was attempted. Every claim about our own code is read from origin/staging after a git fetch, never from a working tree.
The Dart root-certificate finding is reasoned, not reproduced. The changelog text is quoted verbatim from the tagged 3.13.5 CHANGELOG.md, and lib/src/networking.dart importing package:http is read from source. The step in between, that package:http on the standalone VM resolves to dart:io HttpClient and therefore to the default SecurityContext, is inference from how those packages are layered, not something tested in a certificate-less container. Treat the severity as provisional until someone runs it.
Apple's Enhanced Security documentation still will not render. developer.apple.com/documentation/* returns title-only content, now across four runs and six attempts. The whole mechanism in the PLCrashReporter finding is quoted from two maintainer fixes, not from Apple.
Chrome 155's developer release notes were read second-hand. developer.chrome.com/release-notes/155 returns 404 even though the milestone is in stable rollout. The version and rollout numbers come from versionhistory.googleapis.com and chromiumdash, both primary; the feature and removal list comes from search results pointing at chromestatus.com/release-notes/155, which is secondary coverage.
HarmonyOS, seventh week. Not reached. The API 24 claim rests entirely on search summaries. This needs a human with a Huawei developer account, not another radar retry.
WebKit and Firefox were not reached. webkit.org/blog/ renders without dates, so a post cannot be placed inside a seven-day window at all; it should be replaced as a source rather than retried. Also not reached this run: Statsig, Heap, Pendo, Segment's non-Swift SDKs, LogRocket, OpenReplay, Adjust, AppsFlyer. Mixpanel's iOS and Android SDKs had no release in window, which is an observation, not a gap.
Two sources died and were replaced this week, recorded so they are not retried: github.com/flutter/flutter/releases (abandoned at v1.16.3, 2024) → raw.githubusercontent.com/flutter/flutter/stable/CHANGELOG.md; unity.com/releases/editor/archive (undated navigation page) → services.api.unity.com/unity/editor/release/v1/releases.