Repository navigation
Description
Is your feature request related to a problem? Please describe.
Summary
We are migrating from AWSPinpointAnalyticsPlugin to AmplifyKinesisClient (v2.54.0) as recommended by the Pinpoint end-of-support docs. The Kinesis client handles transport well (batching, caching, retries), but there is no replacement for the enrichment layer that Pinpoint provided automatically.
What's missing
When using AWSPinpointAnalyticsPlugin, every event was automatically enriched with:
- Device metadata (make, model, OS, locale, timezone)
- Application metadata (app ID, version, SDK version, Cognito pool ID)
- Client identity (persistent client ID, Cognito identity ID)
- Session lifecycle (start/stop/pause/resume tied to app foreground/background state)
- Structured event envelope (the JSON format delivered to S3 via Pinpoint event streaming)
AmplifyKinesisClient provides none of this. It accepts raw Data and sends it to a stream. Our downstream pipelines depend on the Pinpoint event envelope structure. Migrating currently requires manually reimplementing all of the above, including the session state machine (SessionClient.swift, PinpointSession.swift) from InternalAWSPinpoint.
Environment
Amplify Swift 2.54.1
Affects: iOS and Android
Describe the solution you'd like
Request
Provide a higher-level analytics plugin for Kinesis that replicates Pinpoint's event enrichment and session tracking. The logic already exists in InternalAWSPinpoint. Decoupling it from the Pinpoint API transport and making it usable with AmplifyKinesisClient would make the migration practical.
Describe alternatives you've considered
Manually reimplementing Pinpoint's device metadata collection, session state machine, endpoint tracking, and event envelope construction in our app's analytics provider. This works but is a significant effort for every Pinpoint customer migrating to Kinesis, and duplicates logic that already exists in InternalAWSPinpoint (SessionClient.swift, PinpointSession.swift). Ideally this logic would be decoupled from the Pinpoint API transport and made reusable with AmplifyKinesisClient.
Is the feature request related to any of the existing Amplify categories?
Analytics
Additional context
Related to Pinpoint - Kinesis migration
Activity
ekjotmultani commentedon Mar 29, 2026
Hi @sdorairaj-tab, thank you for raising this issue, we are aware of these issues and have been actively discussing our way forward here, we understand kinesis really only solves one particular part of what pinpoint used to provide (sending events). When we have more details about our exact replacements or solutions we will return here with that information
github-actions commentedon Mar 29, 2026
This has been identified as a feature request. If this feature is important to you, we strongly encourage you to give a 👍 reaction on the request. This helps us prioritize new features most important to you. Thank you!
sdorairaj-tab commentedon Mar 31, 2026
Thanks for confirming this is being worked on. Two concerns:
Timeline - If a solution ships close to the October 30 deadline, we won't have enough runway. Any rough estimate on "weeks" or "months" would help us decide whether to wait, or pursue alternate solutions.
Extending Pinpoint Analytics support - Given there is currently no equivalent functionality in Kinesis for event details and session tracking, has there been any consideration to extending the Pinpoint Analytics API (putEvents, event streaming) beyond October 30, 2026 until a replacement is available?
We've been on Pinpoint since 2016 and our entire telemetry pipeline is built on it. This is a critical piece for our business. If it would be helpful for your product team to hear directly how this impacts our production app at scale, I'm happy to get on a call.
mattcreaser commentedon Apr 8, 2026
Hi @sdorairaj-tab I've let our product team know about your request. We're working on some ideas about how to fill the missing gaps. I don't have any timeline information yet but it would be something we'd try to get out quickly to give you adequate time for migration.
Just to confirm: if you have something that enriches events in the ways highlighted above and then pipes those events through to Kinesis and/or Firehose, your existing telemetry pipeline could ingest the events from one of those sources?
sdorairaj-tab commentedon Apr 9, 2026
Hi @mattcreaser. Thanks for following up. To answer your question, We'll still have to make some changes to our downstream pipeline - Pinpoint was adding an "arrival timestamp" field, which I guess isn't possible in a data stream service like Kinesis.
For the most part, having the other enriched fields would mean fewer changes to our pipelines.
mattcreaser commentedon Apr 9, 2026
Thanks for the confirmation @sdorairaj-tab. We are looking into this and hope to have something to share soon.
3 remaining items
ekjotmultani commentedon Jul 31, 2026
Hello @sdorairaj-tab, we will have a release and documentation coming soon for enriching events, I would also encourage checking out the latest release for the Connect client which can replace some of the functionality of Pinpoint
sdorairaj-tab commentedon Sep 24, 2026
@ekjotmultani
Following up now that the EventEnrichment client has shipped (amplify-swift #4243 / aws-amplify/amplify-android#3337) — thanks for building it.
One piece of the session tracking still isn't reaching the wire: session
stop_timestampanddurationare never emitted.The client computes them —
stopSession()populatesstopTimestamp/durationandEnrichedEvent's serializer writes them when present — but nothing ever hands a stopped session to the sink. The onlysink.send()lives inrecord(), which always stamps the active session (nil-stop on iOS; a freshly-restarted session on Android).stopSession(), the background-timeout expiry, andclose()mutate state only and never emit, and there's no_session.stop/ session-end event.Net effect: every emitted record's
sessionis just{ id, start_timestamp }— session duration and any session-end signal never ship. This is a regression from the Pinpoint_session.stopbehavior this client replaces, and it's the same on both iOS (amplify-swift) and Android (amplify-android), including the latest releases (2.62.0 / 2.42.0).Is emitting a session-end record — or exposing the stopped session via a public API/callback — something you'd consider? Or is this intended?
sdorairaj-tab commentedon Oct 1, 2026
@mattcreaser @ekjotmultani Checking in to see if the
stop_timestampanddurationfor session tracking in the new EventEnrichment client are on your radar. I'm happy to file this as a new issue if that helps with tracking.ekjotmultani commentedon Oct 1, 2026
Hi @sdorairaj-tab, apologies for the delayed response, these are on our radar and we are preparing changes to add these to the enriched events
sdorairaj-tab commentedon Oct 22, 2026
Thanks @ekjotmultani, I see the fix is up for review now: amplify-swift#4396 and amplify-android#3496 (
_session.start/_session.stopwithstop_timestampandduration). That closes the gap I reported.The problem is the timing. Pinpoint ends October 30, 2026, 8 days from now. Even if these ship this week, we still have to adopt the new SDK, validate it, and release an app update through App Store / Play review. Many of our users won't update right away, so app versions already in the field will keep sending to Pinpoint after Oct 30 and that telemetry will be lost.
Two questions:
PutEventsand event streams to Kinesis/Firehose) for existing customers, even as a limited grace period, so app versions already in the field keep delivering telemetry while users migrate? The migration docs sayPutEventsingestion only continues "until the Amazon Pinpoint end of support date".If this has to go through AWS Support or an account team rather than this thread, tell us what to include and we'll open that today. Happy to join a call with your product team if it helps.
ekjotmultani commentedon Oct 22, 2026
Hi @sdorairaj-tab,
If you require further or more detailed assistance you may go through the AWS support route to get in touch with us, please do not hesitate to reach out
github-actions commentedon Oct 23, 2026
This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.
ekjotmultani commentedon Oct 24, 2026
Sorry, this ticket closed itself after merging the PRs, just posting here that we have released the session start and stop on the swift and android enrichment clients