Recent Incident with SDKAnalytics Version 11.11.4 We recently released version 11.11.4 of SDKAnalytics for use in the SuperApp. This update introduced several significant changes since the last generated version, 11.11.0. The previous version's primary change was the migration of the integration pipeline and its identifier from OQ6 to FW6. Additionally, we performed refactoring and adjustments to the project's configurations.
In SDKAnalytics, we use XcodeGen to simplify project setup and minimize conflicts. We also rely on CocoaPods to create and manage our Pods/Frameworks.
The SuperApp, where SDKAnalytics is implemented, operates as a centralized ecosystem. Its products and user journeys are segregated into Pods/Frameworks, distributed across multiple repositories, following a multi-repo structure. Currently, the app includes over 300 Pods.
Starting from version 11.11.1 of our SDK, we implemented some important project changes. However, when we released version 11.11.4, which included a new feature for the SuperApp, we encountered a critical issue.
Incident Overview All SDKs implemented in the SuperApp have their loading times monitored. After updating SDKAnalytics from version 11.11.0 to 11.11.4, the loading time spiked from 200 ms to 3000 ms. Faced with this significant impact, we launched a task force to investigate and resolve the issue.
Investigation and Diagnosis After several days of investigation, we carefully reviewed the numerous pull requests merged between versions 11.11.0 and 11.11.4. As a strategy, we reverted the project.yml configurations from version 11.11.4 to match those of version 11.11.0. This rollback resolved the loading time issue, indicating that the problem stemmed from the project's configuration.
Upon deeper analysis, we identified the culprit: a single line of configuration. The Bundle ID for the SuperApp follows the pattern com.companyname.enterprise. However, in version 11.11.4, SDKAnalytics adopted a new Bundle ID format: com.companyname.SDKAnalytics. This change directly impacted the SDKAnalytics loading time when implemented in the SuperApp.
Solution To resolve the issue, we reverted this configuration. We modified the Bundle ID for SDKAnalytics to br.com.SDKAnalytics, removing the com.companyname prefix. After this change, the loading time returned to normal.
Reflection The lingering question remains: What is the logical explanation for this discrepancy in loading time caused by the Bundle ID configuration? This behavior is unexpected, and we plan to investigate further to understand the underlying technical reasons.