Is Using a Platform SDK Always the Best Option?

One of the core reasons to explore alternatives to the standard Platform SDK for a device is a lack of control that can lead to challenges in the development process and compromises in the application experience — or unnecessary rework.

Why?

Well, a common frustration that arises in the development process is the restrictions of specific platforms’ SDKs, where certain choices have been made for you to simplify the process of building applications. Commonly, the following decisions will have been baked into a platform SDK:

• Threading model or thread density for helper tasks
• Image handling for dynamic controls such as lists
• Prioritization of interface events and background events
• Streaming model for data population from Content Management Systems

What does that mean for developers working on these SDKs?

In the development process, designs will be documented and sent to their respective expert teams: iOS, Android, PS4, Xbox, etc. Each team will then begin to build components as they are typically handled within each platform’s given SDK constraints. For example, if the design calls for a list, each platform SDK will have a standard approach to handling that list, which will be the go-to for developers on that platform and will be implemented on the project.

The challenges inherent in taking a platform SDK development approach will usually arise mid-project, once many of the core development tasks have been handled. At this point, there will be a design review or a business review, and a discrepancy will be flagged between the original designs and the current behaviour of the application. For example, there may be requests to eliminate stutter in the UI, or populate the list with placeholders while waiting for the intended images to load. Due to the differences in the platform controls, the behavior will also be different across platforms, and outside of the control of the developer to correct against the original design.

Those issues — UI stutter, placeholder images, and others — are determined as part and parcel of the platform SDKs, by choices made about image handling and threading at said SDK level. At this stage, once you have implemented the standard application structures as is accepted within the platform’s development paradigms, there is little you can do from a development standpoint to meaningfully change the issues that are being raised by the business and design teams.

It becomes a choice between de-scoping the requested interaction or a lengthy development process to find a workaround within the SDK. There are often cases where the business and design teams have raised an issue that is non-negotiable, necessitating said development rework.

Imagine two different applications that employ a list view.

The first is a medical application, used by physicians to view patient-specific medical images. As the physician scrolls through the list, there is no use for them to see placeholder images populating on the screen, even if it means the UI is responsive and smooth. The value in their experience is derived from viewing only the accurate patient scans, and they would prioritize that over responsive user inputs in the interface and smooth scrolling. In this case, you would want to prioritize image loading and de-prioritize interface responsiveness.

Contrast that example with the use case of a video application, and a user who is scrolling through the same list view with similarly-sized images to find the show they’re looking for. In this different use case, the user will likely be perfectly happy to have placeholder content loading in place of most of the shows in the list, in exchange for smooth, responsive UI elements that allow them to scroll through the alphabetical list to find “The Walking Dead.” If they had to wait for each image to load before continuing to scroll, it would become a very frustrating experience.

Beyond even that, consider the implications for development in a cross-platform environment, where a user may interact with your application across multiple platform SDKs, each of which provides a different experience due to differences in threading, image handling and prioritization of events.

If you’ve ever run up against the limitations inherent in a platform SDK development approach while developing a cross-platform application, I’d love to hear more about your experiences.

If this is something you enjoyed reading, please hit the Recommend button so others can join in on the fun.

Twitter: You.i TV.