We do not currently have native iOS or Android SDKs. If you want to conduct studies with users recruited within your mobile application, there are two approaches that allow you to achieve this, which we go through below. Both approaches require you to first create a study that can be shared via a link. You'll then use that URL to display your study to your users. Find out more about creating studies that can be shared via a link.

Please note that both of these approaches will likely require development work from an engineer on your team.

⚠️

Reduced block support

Image and Prototype tasks are currently not supported on mobile devices.

Direct participants from your app to a linked study in a new browser window

The most straightforward way to direct your users to a Wondering study is to create a study that can be shared via a link, and then open this URL in the user's native browser when the user meets your required criteria.

Display your study in-app using a web view

If you would prefer to display your study in-app, instead of linking to your study in a new browser window, you can display your study in a web view. There are multiple options for doing so on both iOS and Android, and we've set out our advice below.

When displaying a study in-app in a web view, please note that you must ensure your application is able to request permission to access the microphone to avoid your application being forcibly terminated by the operating system.

Displaying studies in a web view on iOS

We recommending using SFSafariViewController (https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller) to display the study seamlessly without leaving your app. Using SFSafariViewController to open a linked study will display an embedded Safari view, with Safari handling the complexity of requesting microphone permissions, and means your users can make use of Safari's accessibility features if needed.

It is also possible to use WKWebView, however you must ensure your application is able to request permission to access the microphone (https://developer.apple.com/documentation/webkit/wkuidelegate/3763087-webview), and you must have set the NSMicrophoneUsageDescription key in your app’s Info.plist (https://developer.apple.com/documentation/bundleresources/information_property_list/nsmicrophoneusagedescription) otherwise your application will be forcibly terminated by the operating system. Your application will also need to be submitted to Apple for review when this permission is added to Info.plist.

Recommended reading

Should I use WKWebView or SFSafariViewController for web views in my app?

SFSafariViewController | Apple Developer Documentation

Displaying studies in a web view on Android

On Android, we recommend using a Custom Tab (https://developer.chrome.com/docs/android/custom-tabs/overview/) to display the study within your app seamlessly. This way, the Custom Tab will handle the permissions needed to access the microphone for you. Users will also be able to enjoy the same accessibility features they can access in their native browser.

You may also choose to implement a WebView (https://developer.android.com/reference/android/webkit/WebView), however you must ensure your application is able to request permission to access the microphone, otherwise your application can be forcibly terminated by the operating system. You must declare the RECORD_AUDIO permission in your app’s AndroidManifest.xml (https://developer.android.com/reference/android/Manifest.permission#RECORD_AUDIO).

Recommended reading

Custom Tabs | Chrome Developers

When should I use Custom Tabs?