Experiences FAQ 1

This article provides answers to common questions regarding the integration, content management, and performance of the Experiences solutions

SDK and technical Integration

Are WSC Sports native SDKs for iOS and Android compatible with mixed codebases (Obj-C/Swift or Kotlin/Java)?

Yes. The iOS SDK is written in Swift but is fully compatible with Objective-C via a bridging header. The Android SDK is written in Kotlin and is fully interoperable with Java. We provide sample apps for both platforms on our GitHub to demonstrate these implementations.

Can we get early access to the SDK?

Currently, we provide SDK access once a Statement of Work (SOW) is finalized or nearing completion.

How do I get an API key?

Contact your WSC Sports team to get an API key.

What are the minimum OS versions supported by the SDK?

The SDK supports iOS 15.0+ and Android 7.0 (API 24) and above.

Is there a guide for initializing and configuring the SDK (for example, API keys, authentication, content feeds)?

Yes. Our comprehensive Developer Hub provides detailed documentation on API key configuration, feed setup, and the initialize() methods for both iOS and Android platforms.

How customizable is the UI to match our app's design?

The SDK is highly customizable through a "widget-based" integration. You can customize the entry points (for example, "Story Circles"), progress bar colors, fonts, and call-to-action (CTA) buttons to align with your brand's style guide. A dedicated Delivery Manager will work with you to ensure the integration meets your specific UX requirements.

What dependencies does the SDK require, and could they conflict with our existing libraries?

The SDK includes its own modularized video player (based on ExoPlayer for Android and AVPlayer for iOS) and networking clients (like Retrofit or Alamofire). These dependencies are typically shaded or scoped to avoid conflicts with your app's existing libraries. We recommend testing for potential conflicts during the Proof of Concept (PoC) phase.

Can I change the language of the story player last-update label with BlazeStoryPlayerLastUpdateTextStyle?

No. BlazeStoryPlayerLastUpdateTextStyle controls appearance of the last-update label only: font, color, text case, and visibility on iOS, Android, and React Native. It does not set language, locale, or custom wording for that label.

To localize content text (title, description, subtitle, CTA):

• Add translations in the CMS Translations tab.
• Pass the viewer's language to the SDK with setPreferredLanguage on iOS and Android, or preferredLanguage / setPreferredLanguage on Web.

The last-update label is not a CMS localization field. See Text localization and What is not localized.

Content and Data Management

How do we fetch and display story content?

You do not need to fetch individual files manually. After initializing a "Content Feed" in the WSC Sports dashboard, the SDK automatically handles fetching and rendering via a specific FeedID (associated with "labels"). You can define as many labels as needed to organize your content.

What recommendations options are available, and how do you pass viewer data securely?

Recommendations in Experiences include Trending (global) and Personalization (viewer-specific).

• Explicit personalization: your app maps viewer signals to labels or ranked IDs.
• Implicit personalization (For you): the service ranks content from viewer behavior.

You pass a non-PII viewer ID per Viewer ID and optional signals per Viewer privacy considerations and privacy compliance. Labels power explicit personalization. Favorites and follows are examples of explicit signals. See Content recommendations.

Does the implementation include interactive elements like polls and quizzes?

Interactive elements like CTAs, polls, and quizzes are built into the SDK and can be managed through our CMS. No additional unique implementation is required beyond placing the appropriate label into a widget, which requires minimal development effort.

How is content caching and preloading managed?

The Blaze SDK handles caching and pre-fetching (the next 2-3 stories) automatically using an LRU cache to ensure gapless playback. No manual logic is required from your team, though caching policies can be adjusted to align with your app's preferences. Note that offline viewing is not currently supported.

What video and image formats does the SDK support?

The SDK is optimized for 9:16 vertical video and supports auto-play and intelligent mute/unmute states based on device hardware settings. We also recently launched a 16x9 video player; if you have 16x9 content plans, we can discuss the scope for integrating that as well.

Can the platform integrate with external data streams (for example, telemetry or timing APIs)?

Yes. External data can be ingested alongside live video to trigger automated clip creation and generate data-driven overlays (such as real-time speedometers).

How do I filter out content that has already been viewed by the user?

For most integrations, you don't need to filter read content manually. Widgets use shouldOrderWidgetByReadStatus, which is true by default. The Experiences SDK tracks read state per viewer and shows unread items first, with already-viewed items last in the widget.

That is reordering, not removal. Read content can still appear in the widget and in the player when the viewer scrolls or opens the feed.

To hide already-viewed content entirely, the app owner must maintain a list of viewed content IDs (for example, from player callbacks or your backend) and pass only unviewed IDs into the widget data source. That pattern adds integration and maintenance complexity. See Ordering and item limits and IDs data source.

Performance and viewer experience

What is the SDK's impact on app size and performance?

The impact is minimal, with an estimated binary size increase of 2–5MB. It utilizes hardware acceleration for video decoding to maintain low CPU and battery consumption. Prefetching and caching policies can be further tuned from the app side.

Does the Stories view handle different screen sizes and notches?

Yes. The SDK is "Safe Area" aware for both iOS and Android, automatically adjusting for notches, punch-holes, and various aspect ratios. It also intelligently manages orientation, limiting rotation where content is vertical-only.

Are there built-in analytics for engagement?

Yes. The SDK tracks key events like story_open, swipes, and completions. These can be integrated with your internal analytics tools (for example, Firebase) via our listener/callback interface. Our CMS also provides a comprehensive engagement dashboard.

Is accessibility supported (for example, VoiceOver, TalkBack, subtitles)?

Yes, the SDK UI elements are accessibility-ready. Subtitles and captions can be delivered as sidecar files, and burned-in caption support is on the roadmap for H1 2026.

What gesture controls are supported?

The SDK supports standard gestures: tap-to-advance, swipe-down-to-exit, and long-press-to-pause. Some of these can be toggled or customized in the configuration.

Security, Compliance, and Maintenance

What app permissions are required?

Only standard Network/Internet access is required. The SDK does not require sensitive permissions like Camera or Microphone for the standard viewing experience.

What is the update process for the SDK?

Updates are distributed through standard repositories like CocoaPods and Maven. We follow semantic versioning to ensure backward compatibility and prevent breaking changes during minor updates.

Is there documentation for mixed-language apps?

Yes, our GitHub repository includes sample apps specifically demonstrating implementations in both pure-native and mixed-language (Obj-C/Swift) environments.

Does Apple's App Tracking Transparency prompt apply to the Experiences SDK?

No. App Tracking Transparency governs the IDFA and tracking a person across other companies' apps and websites. The Experiences SDK doesn't use the IDFA or any advertising identifier. A viewer who signs in to your app, whose in-app behavior personalizes content in that same app, is your own first-party data.

The practical consequence is that you shouldn't wire the SDK's consent settings to the ATT prompt. Set doNotTrack from your own app's consent state, and send the viewer ID for every logged-in viewer who has consented in your app, whatever they answered to ATT. Deriving either from the ATT status means viewers who decline that prompt silently lose personalization they already agreed to. Your own privacy obligations are still yours to determine with your legal advisors. See Viewer privacy considerations and privacy compliance.

If you serve ads, ATT still matters, but for the ads and not for viewer identification. Ad requests through Google Ad Manager pass resettable device identifiers, and on iOS 14.5 and later Google reads a non-zero IDFA as the viewer's consent to tracking, so a viewer who declines the ATT prompt affects ad targeting and fill. That is separate from the viewer ID and from doNotTrack, and the two shouldn't be wired together. See GAM ads VAST macros.

Can we use a device identifier as the viewer ID?

No. The viewer ID must identify an account, not a device. Advertising IDs, IDFV, install UUIDs, and push tokens all belong to a device, so the same person looks like two different viewers on their phone and tablet, and looks like a new viewer after reinstalling your app. Session-scoped values such as access tokens and JWTs have the same problem because they rotate.

Send an identifier from your own account system that stays the same for that account on every platform and device. See Viewer ID.

Business and Rollout

How long does a typical integration take?

A standard home-screen integration typically takes 4–6 weeks. For specific complex integrations, we estimate approximately 8 weeks. We have successful references with major partners like NASCAR, LaLiga, and the Premier League.

Can stories be placed on pages other than the home screen?

Yes, the SDK is flexible. While the home screen is common, "Story Widgets" can be placed in any View or Fragment. For example, you could place driver-specific highlights on individual driver pages using dynamic labels.

How do we test the feature during development?

WSC Sports provides a staging environment and a sandbox "App ID" for your development and UAT builds, ensuring test content never reaches production viewers.

What happens if content fails to load?

The SDK is designed to fail silently. If no content is available, it will return a zero-height view or remain hidden, ensuring your app's layout remains clean and unaffected.