Weekly platform, competitor and sector sweep for the Countly SDK fleet. Window 28 September to 5 October 2026.
Countly is leaving Maven Central. Between 29 and 30 September, countly-sdk-android and countly-sdk-java both landed a complete self-hosted release pipeline on staging: roughly 2,800 lines of Python each, signing, SBOMs, consumer-probe builds, and uploads to a Cloudflare R2 bucket served at https://maven.countly.com. Both CHANGELOGs open with a !! Major breaking change !! telling integrators to add that repository by hand. Maven Central survives in the new pipeline only as a collision check: release.py fails a production run if the version is already on Central, and never publishes there. The Java repo deleted publishing.yml outright. This is the single largest change to how customers consume our SDKs in years, and it arrived with no PR of mine required and no announcement I can find outside the two CHANGELOG entries.
It also retires the item that has led this page for five weeks. Sonatype's commercial-nature test is no longer our problem, and the evidence is better than a policy reading: ly.count.android:sdk 26.1.6 published to Maven Central on 30 September, one day before the deadline, and the pipeline that replaces it does not target Central at all. The sharp edge that remains is smaller and very concrete: maven.countly.com does not resolve. NXDOMAIN today, while maven-test.countly.com is live behind Cloudflare and already serving dry-run artifacts 0.0.1 and 0.0.2. The production host has to exist before the first release ships, and both bridges need the repository added to their Gradle files before they can ever bump past 26.1.2.
The second new finding is Apple's. PostHog's iOS SDK shipped an emergency fix on 29 September for apps killed at launch under Apple's Enhanced Security capability, and KSCrash opened the same fix on 4 October: a process with Mach platform restrictions may only set exception ports as EXCEPTION_IDENTITY_PROTECTED, and PLCrashReporter registers EXCEPTION_DEFAULT. Our default crash path is not affected: it is NSSetUncaughtExceptionHandler plus seven signal() installs, no Mach ports anywhere. But Countly-PL plus shouldUseMachSignalHandler = YES is exactly the failing shape, and upstream PLCrashReporter has not had a commit since 12 November 2025. Zero PRs again: the Maven work is live under someone's hands, and the crash fix needs a vendored dependency.
maven.countly.com, and that host does not resolve yetRead from origin/staging today. Both repos now carry an identical release system under .github/release/ and .github/workflows/release.yml, added by turtledreams on 29 to 30 September (countly-sdk-android #606, countly-sdk-java #293).
| Evidence | Value |
|---|---|
.github/release/config.json → publicBaseUrl.production | https://maven.countly.com/ |
publicBaseUrl.test | https://maven-test.countly.com/ |
centralBaseUrl, only use | release.py:140: "is already on Maven Central", a pre-flight collision check. No publish step targets Central. |
| Transport | s3.py: aws s3api against <account>.r2.cloudflarestorage.com; index.py rewrites maven-metadata.xml from the bucket |
| Old pipeline | countly-sdk-java deleted .github/workflows/publishing.yml (35 lines removed) and release_notice.yml |
| Trigger | on: release: [published] plus workflow_dispatch with a production/test choice, tags only |
| DNS, checked today | maven.countly.com → NXDOMAIN. maven-test.countly.com → 104.21.9.244 / 172.67.161.200, serving ly/count/android/sdk/maven-metadata.xml with 0.0.1, 0.0.2, lastUpdated 20260929094943 |
countly-sdk-android · countly-sdk-java · countly-sdk-flutter-bridge · countly-sdk-react-native-bridge
What breaks. Nothing today: the change sits under an unreleased ## XX.XX.XX heading and 26.1.6 is on Central. On the day the next version ships, three things fail at once:
settings.gradle gets Could not find ly.count.android:sdk:<next>. That is the intended, announced cost of the move.countly-sdk-flutter-bridge/android/build.gradle declares rootProject.allprojects { repositories { mavenCentral(); google() } } and implementation 'ly.count.android:sdk:26.1.2'; countly-sdk-react-native-bridge/android/build.gradle declares a module-level repositories { mavenCentral(); google(); … } and the same coordinate. Neither can be bumped past 26.1.2 until the repository is added.Knowledge Base/SDK Specs/Android-360037754031.txt still shows mavenCentral() and ly.count.android:sdk:26.1.5; the Java article shows ly.count.sdk:java:26.8.0 with no repository block at all.Smallest fix Three parts, in order. (1) Make maven.countly.com resolve and serve: it is the only hard blocker on shipping the next release. (2) Add the repository block to both bridges' android/build.gradle; for Flutter the existing rootProject.allprojects block already reaches the app build, for React Native the module-level repositories block is enough for the module's own configurations. (3) Update the Android and Java KB install snippets in the same week the release goes out, not after.
No PR. §7 says skip a file carrying in-flight work. This pipeline landed four days ago and the production host does not exist; a PR adding a repository URL that returns NXDOMAIN would be worse than no PR.
Apps that adopt Xcode 26's Enhanced Security capability run with Mach IPC platform restrictions. Under those restrictions a process may only set exception ports with EXCEPTION_IDENTITY_PROTECTED, EXCEPTION_STATE or EXCEPTION_STATE_IDENTITY_PROTECTED; registering EXCEPTION_DEFAULT traps as EXC_GUARD with SET_EXCEPTION_BEHAVIOR and the app is killed inside SDK setup, before any user code runs.
EXCEPTION_IDENTITY_PROTECTED on iOS 15+/macOS 12+ and resolve the task through task_identity_token_get_task_port, weak-linked because that symbol is absent on iOS 13.countly-sdk-ios
Our exposure, read from origin/staging. The default path is clean: CountlyCrashReporter.m:169-178 installs NSSetUncaughtExceptionHandler plus signal() for SIGABRT SIGILL SIGSEGV SIGFPE SIGBUS SIGPIPE SIGTRAP, and a grep for task_set_exception_ports, EXCEPTION_DEFAULT and mach_port across the whole repo returns nothing outside the CHANGELOG. The exposed path is the opt-in one: Countly-PL.podspec's PL subspec depends on PLCrashReporter', '~> 1', and CountlyCrashReporter.m:237 selects PLCrashReporterSignalHandlerTypeMach when the integrator sets shouldUseMachSignalHandler.
Why this is not P0. Three conditions must all hold: the customer installs the Countly/PL subspec, sets shouldUseMachSignalHandler = YES, and enables Enhanced Security on their app. The BSD default is unaffected, so there is a one-flag workaround. Against that: it is a silent launch-time abort with no diagnostic pointing at us, and upstream PLCrashReporter's last release is 1.12.2 on 12 November 2025 and its last commit is the same day: there is no open issue there about EXC_GUARD or Enhanced Security, and no reason to expect a fix.
Smallest fix Document it first: a note on shouldUseMachSignalHandler in CountlyConfig.h and in the iOS KB article saying the Mach handler is incompatible with Enhanced Security, and that BSD is the supported choice there. The durable fix, vendoring PLCrashReporter the way PostHog did or retiring the PL path, is a design decision, not a radar PR.
Nothing moved this week. The ten below-range files across four repos are unchanged on origin/staging; countly-sdk-flutter-bridge/ios/countly_flutter.podspec still declares s.ios.deployment_target = '10.0' on line 18 alongside an s.resource_bundles entry on line 15, the shape the app-side post_install lift does not reach. countly-sdk-swift remains the one Apple repo already in range at .iOS(.v15) .macOS(.v12) .tvOS(.v15) .watchOS(.v9).
countly-sdk-flutter-bridge · countly-sdk-ios · countly-sdk-react-native-bridge · countly-sdk-unity
New supporting evidence, from a competitor. posthog-ios 3.87.0 (1 October) formally announces that "PostHog 4.0 raises the minimum iOS deployment target from 13.0 to 15.0. The macOS, tvOS, watchOS and visionOS minimums are unchanged." They are moving from 13 to 15; we would be moving from 10 to 15. Separately, dd-sdk-ios 3.19.0 (2 October) now "requires Swift tools version 6.2 (Xcode 26) or later" for its SwiftPM manifest. The floor is rising on both axes and the fleet is below both.
Smallest fix Unchanged: raise ios.deployment_target to 15.0 in the Flutter bridge podspec first, since it is the only file with no customer-side workaround. Still not a PR: §7 forbids bumping a minimum platform version, and the Flutter Apple files carry in-flight SwiftPM work.
countly-sdk-swift still has no documentation, eleven days after its first releaseRe-verified today against countly-backup-documentation at HEAD (3 October). Knowledge Base/SDK Specs/ still holds exactly 14 files and Swift is not among them. grep -rl "countly-sdk-swift" "Knowledge Base/" returns zero matches. SDK_Repos_and_Features still omits it. The repo has had no commits since the three that shipped 26.8.0 on 24 September.
countly-sdk-swift · countly-sdk-js
Smallest fix Unchanged, and still the cheapest it will ever be: the 26.8.0 CHANGELOG is already close to an API reference. Restructure it into an SDK Specs/ article covering the multi-instance entrypoints, the events/views/sessions/userProfile namespaces and the .countlyView(_:) SwiftUI modifier, and add the row to SDK_Repos_and_Features. Authorship, so a proposal rather than a PR.
This item led the page for five weeks. Two pieces of evidence close it. First, https://repo1.maven.org/maven2/ly/count/android/sdk/maven-metadata.xml lists 26.1.6 with lastUpdated 20260930073421: published to Central on 30 September, the day before enforcement, successfully. Second, the replacement pipeline described above does not publish to Central at all, so there is no future release for the Publisher Pro question to apply to. The board already carried this key as "Already fixed" on 28 September; the code landing a day later is what that referred to.
The §1 baseline has claimed cmake_minimum_required(VERSION 3.0) for countly-sdk-cpp since August, which would be a hard error on any CMake 4.x. origin/staging:CMakeLists.txt line 1 actually reads cmake_minimum_required(VERSION 3.13...3.31), and the only other one in the repo is examples/qt_demo at 3.16. Both are at or above CMake 4's 3.5 floor, and the ...3.31 policy max pins behaviour. CMake 4.4.4 shipped 2 October and changes nothing for us. The baseline table should be corrected rather than the repo.
Apple announced on 1 October that the original Developer ID Certification Authority Sub-CA expires 1 February 2027; .pkg files signed with an affected certificate stop installing on that date, and replacements must be issued from the G2 Sub-CA. We ship source through SPM and CocoaPods and distribute no signed macOS installer, so there is nothing of ours to re-sign. It is a customer-support answer for anyone shipping a Mac app that embeds us, not an SDK item.
posthog-ios spent three releases this week fixing foldable and resizable-window bugs: 3.85.2 (session replay kept the original screen size after a resize), 3.86.0 (added $hinge_status), 3.86.1 and 3.86.3 (survey sheets and $screen events sized or duplicated against the main screen). CountlyDeviceInfo.m already resolves the first UIWindowScene's window and uses window.bounds with window.traitCollection.displayScale, falling back to UIScreen.mainScreen only on pre-scene systems, the correct shape, written years before it mattered. The honest residual, not a bug: metrics are sampled at session start, so a fold mid-session is not reflected until the next session. No $hinge_status equivalent, which is a P3 gap, not a defect.
sentry-cocoa 9.30.0 added connection_type (wifi/ethernet/cellular/none) and connection_effective_type to its device context on 30 September. We have had the equivalent for years: CountlyDeviceInfo.m:424 +(NSUInteger)connectionType backed by CTTelephonyNetworkInfo, and DeviceInfo.java using ConnectivityManager and TelephonyManager. Nothing to build.
developer.apple.com/documentation/; the mechanism is quoted from the two maintainer fixes.developer.apple.com/news/ runs 2 October, 1 October, then back to 18 September. The April 2027 iOS 27 SDK requirement is still absent from the upcoming-requirements page, fifth week of checking.developer.android.com/about/versions/latest/behavior-changes-all now returns 404; the versions index still names Android 17 as latest and carries a 2025-06-10 footer. Another dead source to replace rather than retry.dl.google.com; everything past it is 9.5.0-alpha. No change to the AGP 10 Variant-API item for the two bridges.compileSdk 24 is enough again instead of 34. Four StrictMode violations fixed, and data:/zip:/intent: URI schemes now blocked by default in content, feedback and push links with setAllowedIntentSchemes(List) as the escape hatch.androidx.collection bump.Package.swift." Our bridge ships ios/src/Package.swift, a vendored copy of the iOS SDK's manifest, name: "Countly", swift-tools 5.3, .iOS(.v10). RN 0.88's SwiftPM autolinking discovers library Package.swift files; ours declares a deployment target Xcode 27 rejects. That is the existing P0 inventory item #9 acquiring a plausible delivery mechanism, not a new finding, and I did not read the autolinking discovery code, so treat the link as unproven.node_modules or following symlinks when discovering components, is still the thing to read before the next bridge cycle. Our bridge declares codegenConfig.flutter/flutter's master CHANGELOG.md still opens at 3.47, unchanged from last week, and the GitHub releases feed is abandoned at v1.16.3 (2024), so it is useless as a source. The official release-notes page footer is still 2026-08-12. "No release this week" stays an inference, for the third week running.iOSTargetOSVersionString 10.0 into the Apple P0.unity.com/releases/editor/archive is a nav page that returns nothing readable.referrerPolicy cheap steal is unchanged and still one line: countly-sdk-web/lib/countly.js passes only method, headers, body and signal to fetch(), so the browser default strict-origin-when-cross-origin sends the full page URL and query string in Referer on same-origin deployments.countly-sdk-nodejs is 24.10.4 on origin/staging with still no engines field, seventh week. Zero runtime deps, so the risk stays theoretical; radar will not PR a floor where none existed.developer.harmonyos.cool now 301s to developer.huawei.com/consumer/cn/. The API 24 claim still rests on search summaries. Our targetSdkVersion is 6.0.2(22). This needs a human with a Huawei developer account, not another radar retry.| What shipped | Do we have it? | Call |
|---|---|---|
| posthog-ios 3.87.0 (1 Oct): deprecates everything PostHog 4.0 hides, and announces iOS 15 as the 4.0 minimum, up from 13. | n/a: this is evidence, not a feature. | Use it. A direct competitor publicly moving to the same floor our P0 asks for, a full major version in advance. Worth citing in the deployment-target decision. |
posthog-ios 3.86.0 (30 Sep): $hinge_status (closed/partially_open/fully_open) on foldable iPhones, iOS 27.1 and Xcode 27.1 or later. |
No. CountlyDeviceInfo.m reports raw hw.machine with no lookup table and no fold state. |
Not yet. It needs an Xcode 27.1 build to even compile the API, and we cannot build. Revisit when the Apple toolchain decision is made; the resolution path is already correct (see Cleared). |
posthog-ios 3.89.0 (3 Oct): onFeatureFlags(_:) returning a PostHogFeatureFlagsSubscription with unsubscribe(), fired on the main thread and replayed if flags already loaded. |
Partly. ModuleRemoteConfig has removeDownloadCallback on Android, so the unsubscribe half exists, but registration is a config-time list, with no returned handle and no replay-on-register. |
Cheap steal of the week. The design detail is replay on register: a callback registered after flags loaded fires immediately instead of waiting for the next download. That removes the "did I miss it?" race every integrator hits, and it is a handful of lines in NotifyDownloadCallbacks. Android first. |
posthog-ios 3.88.0 (2 Oct): disableGeoIp config; events carry $geoip_disable and flag requests send geoip_disable, so the server does not infer location from IP. |
Different shape. We have location controls on the SDK side, but no single flag that tells the server to stop deriving geo from the request IP. | Worth a look, not this quarter. It is a server contract as much as an SDK one, so it is a cross-team item rather than an SDK change. |
sentry-java 8.59.0 (1 Oct): sendDefaultPii now formally deprecated in favour of per-category dataCollection, ahead of removal in 9.0. Also: direct Sentry.logger() calls now bypass the enable flag entirely. |
n/a: pattern, not feature. Already carried and already rejected on the board. | Keep as a pattern. The migration rule is the part to reuse: unconfigured keeps the old boolean's behaviour exactly; configure any category and the boolean is ignored. Use it the next time a Countly config option outgrows its type. |
| dd-sdk-ios 3.19.0 (2 Oct): RUM partial view updates on by default; attribute limit raised 256 → 1900; SwiftPM now requires Swift tools 6.2 (Xcode 26). | Partial updates do not map: our view model is start/stop with a duration, not a continuously-updated event. | Not worth it. The useful part is the floor datapoint for the Apple decision, not the feature. |
posthog-android 3.71.2 (28 Sep): event properties can no longer override $process_person_profile and $is_identified; per-event values are ignored, beforeSend is the supported rewrite path. |
Not applicable in this form, but the principle is: custom segmentation keys that collide with reserved internal keys. | Worth an audit, free. Check which reserved keys a caller can currently shadow through segmentation on Android and Web, and whether the SDK silently accepts it. Android is the behavioural source of truth, so decide there. |
sentry-cocoa 9.30.0 (30 Sep): connection_type/connection_effective_type; several experimental options promoted to stable with defaults unchanged; MetricKit attachments compacted to save quota. |
Connection type: yes, both mobile SDKs (see Cleared). | Nothing to do. The promotion-without-changing-defaults habit is a good one to copy when our own experimental config graduates. |
Still outstanding and unchanged: no session replay in any of our 14 SDKs; no app-hang or ANR detection on any Apple SDK; no rage or dead tap detection anywhere. The rage/dead-tap card was rejected on the board as "not worth it now", so it is not re-proposed: it stays here as a standing gap, not a task.
opentelemetry-swift 2.6.0 (1 October) continues to build out its session model: explicit session end and explicit linked reset both landed, alongside URLSession instrumentation fixes. That is the SIG nearest our own session semantics and it is the one place upstream is moving. The spec is at 1.61.0 (14 September), semconv still 1.44.0 (4 August) and opentelemetry-js still 2.11.0 (31 August): the two that would actually bind us remain static.countly-sdk-js:otel-telemetry-phase1 carries no OTel code, the real work is still uncommitted in the flutter-bridge working tree, and ly.count.android:sdk-otel does not exist on Maven Central. Note that a self-hosted Maven repo makes publishing an experimental sdk-otel artifact materially cheaper than it was last week.SDK Specs/Android-360037754031.txt shows mavenCentral() and 26.1.5; SDK Specs/Java-360037813891.txt shows ly.count.sdk:java:26.8.0 with no repository block. Both CHANGELOGs already contain the exact Gradle and Maven snippets to paste. This is the highest-value doc change available and it has a hard trigger date. P1countly-sdk-swift still has no article. Unchanged from last week, detailed above. P1Countly Internal Library/AI SDK/ gained 14 articles on 26 September and all of them were updated again on 29 to 30 September: OpenAI, Anthropic, Google GenAI, Cohere, LangChain, LlamaIndex, Mastra and Vercel AI SDK integrations, plus cost calculation, feedback collection and troubleshooting. The packages are real and public: @countly/ai-sdk-openai and @countly/ai-sdk-anthropic are both on npm at 0.0.6, published 2 August. Nothing is customer-facing, and the §1 baseline does not list them at all. Either they are pre-release and the internal home is correct, or we have a published SDK family with no public docs: worth one sentence from whoever owns it. P2countly-sdk-js article. The only JS article, Web_analytics_JavaScript_, documents countly-sdk-web. Carried. P2shouldUseMachSignalHandler. Small, and it is the only fix available until the dependency question is settled. P2| When | What | Affected |
|---|---|---|
| next release | maven.countly.com must resolve and serve before the first production release runs; both bridges need the repository added | android · java · flutter-bridge · rn-bridge |
| 2026-10-12 | React Native 0.88 stable; read the Codegen node_modules/symlink discovery change and the SwiftPM autolinking change before the next bridge cycle | rn-bridge |
| 2026-10-21 approx. | Chrome 155 stable (latest beta 8 October); nothing known yet that touches our transport | web · js |
| 2026-11-01 | All NuGet.org API keys created before 17 August expire; new keys capped at 30 days. Rejected on the board as not ours; kept as a date | windows |
| 2026-11-10 | .NET 8 and .NET 9 end of support; our TFMs unaffected, watch ecosystem drift off 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; .pkg files signed with it stop installing, replacements from the G2 Sub-CA. Customer-support answer, not ours to fix | 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 iOS/iPadOS/tvOS/visionOS/watchOS 27 SDKs. Still absent from the upcoming-requirements page, fifth week | ios · flutter-bridge · rn-bridge · unity |
| open | Xcode 27 deployment-target floor: ten files, four repos. P0 on the Flutter podspec | ios · flutter-bridge · rn-bridge · unity |
| open | PLCrashReporter Mach handler versus Apple Enhanced Security; upstream dormant since 2025-11-12 | ios |
| open | countly-sdk-swift and countly-sdk-js have no KB article; AI SDK family documented internally only | swift · js |
| open | Node SDK declares no engines range, seventh week | nodejs |
| open | Unity editor pinned at 2020.3.20f1, SDK at 24.8.2; Unity 6.7 beta is the last Mono release, Unity 7 announced | unity |
| open | Web/JS fetch() sets no referrerPolicy; one-line cheap steal | web · js |
| 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 | flutter-bridge · rn-bridge |
| open | HarmonyOS release notes unreachable for six weeks; API 24 claim unverified | hos |
| open | Dart 3.13 root-certificate removal versus a search result naming 3.12.2 as newest; still unresolved | dart |
| 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 |
origin/staging. The connection to Sonatype's commercial-nature policy is mine, drawn from the timing. No public statement says so.maven.countly.com does not resolve, so I could not fetch a single artifact from it. The test host works and serves dry-run artifacts; everything said about the production layout is read from layout.py and index.py, not observed.developer.apple.com/documentation/. The Enhanced Security mechanism (which exception behaviours are permitted, and task_identity_token_get_task_port) is quoted from the PostHog and KSCrash fixes and from a search summary of Apple's page, not from Apple's page.pod install, no Gradle sync, no Enhanced Security entitlement to test against. The claim that our Countly/PL + Mach configuration is the failing shape rests on reading our source and PostHog's bug report side by side.ios/src/Package.swift inside our bridge is unproven.unity.com. The editor archive remains a nav page.developer.android.com/about/versions/latest/behavior-changes-all now 404s; developer.apple.com/documentation/* renders title-only; developer.chrome.com/release-notes/155 404s because 155 has not shipped; unity.com/releases/editor/archive and webkit.org/blog/ remain unusable. gh api repos/<owner>/<repo>/releases remains the best competitor source by a wide margin.