Integrating Native SDKs (Payments, Maps, Analytics) Without Bloating the App
A retail client's app request list included Stripe for payments, Google Maps for store locator, three different analytics SDKs (two legacy from prior vendors, one new), a customer support chat widget SDK, and a marketing automation SDK — each individually reasonable, collectively adding roughly 35MB and 400ms of cold-start time once we measured the fully-integrated build against a bare baseline app.
We push back on redundant SDKs specifically, not on integrations broadly. In this case, two of the three analytics SDKs covered near-identical functionality left over from vendor changes nobody had cleaned up; consolidating onto one saved 6MB and, more importantly, removed a second SDK independently initializing on app launch and making its own network calls, which was a real contributor to the startup time hit.
Lazy initialization was the single highest-leverage technical fix. Several SDKs, the chat widget and the marketing automation tool, don't need to be ready at cold start — they're only used deep in specific flows. We deferred their initialization to the first screen that actually needs them instead of the App Delegate or Application class's onCreate, which cut measured cold-start time by about 150ms without removing any functionality.
For maps specifically, we evaluated whether a full native Google Maps SDK was necessary versus a lighter static-map-image approach for screens that only needed to show a fixed pin, an order confirmation screen showing delivery address, for instance, rather than an interactive map. Reserving the full interactive SDK for the one screen that actually needed pan, zoom, and search cut the maps-related binary weight roughly in half.
The process change that's stuck across projects since is a standing rule that any new third-party SDK request goes through a quick size-and-startup-cost estimate before approval, presented alongside the feature request rather than discovered after integration. Clients almost always still want the SDK, but knowing the cost upfront changes conversations about lazy-loading, alternatives, or removing an older redundant SDK to make room.
