For many product development teams, whether mobile or not, launch days have historically been some of the most chaotic and stressful days of our tenures. Weeks or months of design sessions, customer feedback, building, and testing are all on display with customers bringing the critical voice to opine and provide feedback on your decisions.
With the advent and widespread adoption of feature flags and feature experimentation, the way we deploy features has fundamentally changed, and the stress of launch day is a remnant of the past.
- Feature Flags allow you to segment and gradually release features to ensure a stable customer experience and roll back these features immediately should there be an issue or unexpected impact on user behavior.
- Feature Experimentation gives you the ability to utilize product telemetry to generate insights allowing your organization to better understand your application usage, the impact of this new feature on the metrics that matter the most to your business and ultimately power better product decisions.
Feature flags allow functionality to be deployed to production weeks in advance, and then tested in parallel with a subset of your customer base. With feature experimentation, the quantitative can be easily meshed with the qualitative, providing teams with the ability to release functionality to a percentage of their customer base, and understand the quantitative impact on the metrics that matter most to their team and their business.
However, the existence of mobile has re-complicated launch days adding in another medium which must be tested and coordinated. Whether you’re a mobile-only product or your product services both a mobile and web use case, the pain of application approval cycles, ensuring a consistent experience across mediums, and quality testing pre-release have slowed down and complicated product development processes.
This need to release safely and understand the impact on your customer experience extends beyond the web experience, across all user devices and touchpoints. Since launching Split’s Feature Flagging product and ensuing experimentation capabilities, our customers have continually asked for native mobile support.
At Split, our team has felt the pain of managing features across the mobile landscape. Today, our team is proud to announce the launch of native Android and iOS SDKs. Historically, we have held off on developing these SDKs, in preference for serving the mobile use case via our server-side SDKs or the Split Evaluator. This preference was rooted in security and performance concerns. In kicking off support for mobile, our SDK team spent time understanding the challenges of the mobile environment, today’s current solutions and iterated to ensure Split’s mobile SDKs solved for these challenges in the most performant manner with the lowest footprint.
Our SDK development team at Split has been hard at work to understand the challenges of each language, ensure we’ve addressed these challenges both in a performant and scalable manner, ensure consistency across our SDKs (Split natively supports multiple popular languages over 10 native clients), and most importantly, making them easy to integrate for our customers.
Mobile environments presented a unique challenge for our team. As with any of our other SDKs, the mobile SDKs were required to be lightweight and performant. However, the mobile world presented a few unique challenges as it pertained to intermittent or no connectivity, battery and network usage, and reusing user data. Below is a quick summary of the challenges in supporting mobile environments and how we addressed these challenges to make our SDKs performant, reliable, yet simple.
Intermittent or No Connectivity on Mobile Devices
In order to avoid glitches, the mobile SDKs maintain their configuration both in-memory, for speedy retrieval, but also on a disk cache. In the event the application is launched while there is no connectivity, the SDK will recover the last known configuration from disk. Once the device has re-established a network connection, the SDK will contact Split’s servers and update the configuration, in the event it has changed. This in memory and on disk fallback gives the SDK the ability to persist and maintain a known experience for a user, despite the device being in Airplane Mode or having low connectivity.
Also, the SDK looks to maintain the record of impressions that were generated as “getTreatment” is called. When trying to send impressions back to our servers, the SDK will first verify that our servers can be reached. In the event of poor connectivity, or none at all, the SDK will store the impressions on disk. Once the device has re-established a network connection, the SDK will recover the impressions from disk and send them to our servers in bulk.
Due to these fallbacks, the SDKs can maintain a steady experience for your users, in the event network connectivity and communication with the outside world is temporarily not available or limited.
Mobile Battery and Network Usage
Battery and network usage is a limited resource on mobile devices. With that in mind, Split’s mobile SDKs look to minimize its impact on the battery and the network usage of end devices on which it is installed.
The SDKs have background threads that are dormant a majority of the time. These background threads are only to be woken up sporadically to send impressions in bulk or to retrieve changes in the configuration. You can configure the time refresh of these background threads in order to optimize battery and network usage.
Reuse of Mobile User Data
With a traditional SDK that resides on a server, the same SDK will be used to determine the experience of thousands or even millions different users. In the mobile world, this is not the case, as one SDK will likely serve the same user over and over again.
As an example, consider your favorite social media application. The very first time you open it, you will enter your credentials. From that time on, every time you launch, resume or restart the app, the credentials are going to be used over and over again.
Split’s mobile SDKs, once initialized, will store the configurations of the particular user. As long as the user does not change, every time the application is launched or resumed, the SDKs will not require calling our servers, but will instead retrieve the configuration from the cache to be used immediately.
How to Get Started
If you’re developing a mobile application or developing across platforms, use Split Feature Flags to drive a consistent experience across devices and understand customer impact through Feature Experimentation. Check out our mobile and other language support here.
Any other challenges you face when developing SDKs similar to ours in the mobile world? We’d love to connect with you and see how we can continue to improve our SDKs. As with all of our SDKs, we’re continuously improving our functionality and performance. Please feel free to submit feedback on our GitHub repos for both of the Android and iOS SDKs.
To get started, read the documentation:
Get Split Certified
Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.
Switch It On With Split
The Split Feature Data Platform™ gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Switch on a free account today, schedule a demo, or contact us for further questions.