The Apple payments decision: a turning point for mobile observability?

The recent court ruling against Apple that made the app store’s 27% commission on external payments illegal in the US has upended the mobile app industry. Nearly every application developer is moving as quickly as possible to implement external payment mechanisms within their app given the “easy” increased revenue that can be achieved by doing so. Further, industry watchers speculate that a similar decision will impact the Google Play store in due time, thus broadening the impact considerably. As with any rapid software change, especially one with such large business/revenue implications, the realities of migrating to new payment systems are easier said than done. How will app developers track payment flows and success rates without robust Real User Monitoring (RUM) and client-side observability? Is this decision and the subsequent engineering work the turning point that makes it clear that client-side and end-user observability is indeed the most critical observability for any organization?

Server-side observability has matured considerably over the past 30 years. It would be rare to find an engineering organization that is not investing in some type of solution at this point, whether that be “observability 1.0” style logs, metrics, and traces, “observability 2.0” style wide logs, or more typically some combination of both. Considerable budget is typically allocated in the pursuit of a bunch of 9s and rigorous SLAs and SLOs. I already wrote extensively about the broad pushback on quite how extensive this budget is so I won’t cover it again here. Yet, as I like to say, a 99.99% success rate measured at the backend doesn’t mean much when an HTTP 200 OK spitting out bad JSON is crashing every mobile app, leading to a 0% real success rate as measured from the perspective of the actual users of the app. Of course, bad JSON leading to a 100% crash rate is an extreme example. However, more subtle examples lead to substantial differentials between the server-side success rate and the actual client success rate on important app flows. This might be due to application bugs, spotty networking and insufficient resilience, or any number of other issues. If this is the case, why have organizations not invested more in observing what is going on in the client? The answer, as I wrote previously, is that it is very, very hard. Coming back to payments, while it’s true that the “Apple tax” has taken potential revenue away from application developers, Apple (and Google) have spent many years building reliable payment infrastructure that developers can generally not worry about and “just works.” (Yes, a monopoly on the payment system also leads to feature stagnation and many complaints about functionality, but that is a different issue which I won’t cover here.) The move to external payments, even when aided by third party providers, puts a huge burden on application developers to get a lot of small details right, lest the revenue loss from a faulty implementation outweighs the theoretical 27% gain. Like any other large migration, without sufficient observability it’s going to be extremely difficult to understand the overall health of the payment flow and debug falloff points. But server-side observability is only going to help so much with this task. Robust client-side observability will be required! So, yes, I believe that the “great payment migration” may be the event that finally pushes the mobile observability rock to the top of the mountain and gets it rolling down the other side. How will a robust client-side observability solution help with a new payment system rollout?

Client-side metrics will help provide summary observability of overall success rate, flow counts, error counts, and so on.
User journey analysis will help analyze drop offs in the payment flow, making it substantially easier to understand where to focus further optimization efforts.
Session replay and tracing will help with deep analysis of individual sessions that drop off the flow or experience errors, making it easy to dig in and fix bugs on the path to payment perfection.

Further, bitdrift Capture is uniquely positioned to supply the needed mobile observability for this massive migration, and for many other application flows where suboptimal end-user experiences are inevitably leading to decreased sentiment and conversion. How so? Recall that Capture gives developers a novel twist on traditional observability – empowering devices to intelligently buffer and selectively send data – offering material cost savings and unprecedented flexibility for developers. You can send whatever logs, traces, and events you want from your apps (and update them in real time) without worrying about storing and paying for heaps and heaps of noisy data. We provide 1000x the data when you need it, and none when you don’t. Unlike other solutions which require either aggressive sampling (and thus make it incredibly difficult to understand the true state of the system and find exemplar sessions that require in-depth debugging) or require sending all data (to the detriment of both your company’s wallet and to your end-users where precious application network bandwidth is now competing with debugging/analytics traffic, thus reducing overall application performance globally), Capture gives you the best of both worlds: “perfect” sampling driven by local storage and client-driven workflows along with our real-time control plane get you the data you need, and none that you don’t. We view the inevitable focus on mobile observability that will result from the forthcoming payment migration as only a good thing for the industry as a whole. There are so many app issues, both small and large, that decrease end-user satisfaction and conversion, and will never show up in server-side observability solutions. Robust (and cost effective!) mobile observability is the only answer. Capture is changing the mobile observability game by adding a control plane and local storage on every mobile device, providing extremely detailed telemetry when you need it, and none when you don’t. If you are worried about making sure your mobile payments migration is successful, now is the time to give us a try! Interested in learning more? Check out the sandbox to get a hands-on feel for what working with Capture is like and then get in touch with us for a demo. Please join us in Slack as well to ask questions and give feedback!

Author

Matt Klein

May 27, 2025

Stay in the know, sign up to the bitdrift newsletter.