# Mendix FAQ

## Which Studio Pro version does the Pushwoosh module require?

Studio Pro 11.12.3 or newer. The module package is built with that version of the model format, and Studio Pro refuses to open a package produced by a version newer than itself.

There is a second reason not to go lower. Mendix moves Studio Pro, the native template and React Native together, so the Studio Pro version decides which React Native version your app runs on, and the module is built against React Native 0.84. The authoritative mapping is [`mendix_version.json`](https://github.com/mendix/native-template/blob/master/mendix_version.json) in the native template repository.

## Why does nothing happen after I add the module?

The app is most likely running in the Make It Native app, which cannot contain third-party native code, so every Pushwoosh action fails silently. Build a custom developer app or a real native build instead.

If the app is already a native build, check that the **Pushwoosh events** widget is on the page that loads first and that its **Application Code** property is filled in. Without a valid Application Code the SDK does not start.

## Why do notifications stop arriving on Android?

Two notification services are registered for the same Firebase event and shadow each other.

Pushwoosh replaces the built-in push notifications of a Mendix app rather than working next to them. In the Native Mobile Builder, set the capabilities as follows:

- **Push notifications**: off.
- **Firebase Android**: on, so that `google-services.json` is still picked up.

Only one service may be registered for `com.google.firebase.MESSAGING_EVENT`. If your app contains another plugin that also registers one, see [Using Pushwoosh SDK with other FCM services](/developer/pushwoosh-sdk/android-sdk/android-faq/#using-pushwoosh-sdk-with-other-fcm-services).

## Do I need to call Initialize when I use the Pushwoosh events widget?

No. The widget initializes the SDK itself from its **Application Code** property. The `Initialize` action exists for apps that start the SDK from a nanoflow instead of placing the widget, for example when the Application Code is not known until the user has signed in.

Calling both is harmless, but the widget has already done the work by the time your nanoflow runs.

## How do I pass JSON to SetTags or PostEvent from a Mendix expression?

Write the JSON in single quotes, so the double quotes inside it stay unescaped:

```
'{"Language":"en","Level":7}'
```

A string in a Mendix expression is delimited by single quotes, which leaves the double quotes of the JSON free to be used as they are. Doubling them or escaping them with a backslash produces a string the action cannot parse, and the action rejects it with a parse error.

## How do I stop the system alert while the app is open?

By default a notification that arrives while the app is open is shown by the system as an alert, and the **On push received** nanoflow of the widget runs as well. Call the `SetShowForegroundAlert` action with `false` to suppress the alert and handle the notification only in the nanoflow, for example by showing a message of your own or refreshing a list.

Call that action on iOS only. The Android SDK does not expose the setting, and the JavaScript wrapper calls the native method unconditionally, so on Android the action raises an error rather than doing nothing.

## Can I build the native app with Studio Pro for Mac?

Not with the Native Mobile Builder, which ships only with the Windows version of Studio Pro. Everything else works on the Mac build, including writing the module, placing the widget and exporting the app.

On macOS, configure the native template with the [`@mendix/native-mobile-toolkit`](https://www.npmjs.com/package/@mendix/native-mobile-toolkit) command line tool, which sets the capabilities, the runtime URL, the app identifier and the native dependencies from a configuration file. Then build the generated iOS and Android projects locally with Xcode and Gradle.

## How do I send a test notification to one specific device?

Call the `GetHwid` action to get the [HWID](/developer/api-reference/api-identifiers/#hardware-id) of the device, and address that HWID from the Pushwoosh Control Panel or the [server API](/developer/api-reference/messages-api/). Registering the device as a test device is the other way to do it, described in [Test your integration](/developer/first-steps/test-your-integration/).