Symptom
After updating from 5.9.2 to 5.9.3, iOS/iPadOS experiences gradual performance degradation during extended play sessions, eventually leading to app termination
This issue did not occur on 5.9.2
Suspected Code
In BrainCloudComms.cs - HandleResponseBundle, the following line was added in 5.9.3:

jsonData = JsonWriter.Serialize(JsonReader.Deserialize(jsonData));
Concerns
This performs a full deserialize → reserialize on every API response
Immediately after, DeserializeJsonBundle parses the same data again — effectively parsing every response twice
Each response generates a large number of temporary objects (Dictionary, List, boxed values, strings) that are immediately discarded
On iOS with IL2CPP (Boehm GC), could this repeated allocation/deallocation pattern cause managed heap growth over time?
Question
Could this code potentially contribute to memory-related issues on iOS during extended play sessions?

@Michael-Costa
The second option seems too narrow in scope for us, since it would
require us to apply it individually to each affected field, which
is not very practical in our case.

With the first approach, the raw response is now being normalized
back to the same format we were seeing in 5.9.2, so we will proceed
with that as our workaround for now.

Thank you

@Michael-Costa

    string responseData = JsonParser.GetString(response, "data", "response");
        if (!string.IsNullOrEmpty(responseData) &&    JsonParser.GetValue<int>(response, "status") == 200){

            ScoreData3 scoreData = JsonReader.Deserialize<ScoreData3>(responseData);
            Debug.LogError(scoreData.stage_rank); >>WORKING
            Debug.LogError(scoreData.tier);>>WORKING

We tested using the method you suggested, and with that approach
the double values started coming through as integers correctly.

However, another issue appeared because we are using Obscured
Values in our project.

When deserializing classes that contain Obscured types, those
fields are not converted correctly with this method.

The error we get is:

InvalidCastException: Invalid cast from 'System.String'
to 'CodeStage.AntiCheat.ObscuredTypes.ObscuredString'.

If we switch back to using a JsonConverter, the original double
problem happens again.

Currently we resolve the Obscured type conversion using:

JsonConvert.DefaultSettings = () =>
new JsonSerializerSettings {
Converters = { new ObscuredTypesNewtonsoftConverter() }
};

So my question is: does JsonReader provide a way to apply a
converter globally in a similar way, like JsonConvert.DefaultSettings?

@Paul-Winterhalder

The error we are seeing is:

JsonReaderException: Input string '4.0' is not a valid integer. Path 'tier', line 2

I tried the approach you suggested.

I parsed the response with JObject first and then
deserialized it again using JsonConvert.DeserializeObject.

However, the error remains the same.

JsonReaderException: Input string '4.0' is not a valid integer.

It appears that the raw response value is already coming
through as a double (e.g. 4.0). When Newtonsoft.Json tries
to deserialize it into an int field, it fails.

So simply passing the response through a
serializer/deserializer step does not seem to resolve the
issue in this case.

@Paul-Winterhalder Thanks for the clarification.

At the moment, I have not finished retesting everything yet
because I am handling several other tasks in parallel.
However, to give you an accurate answer, I am currently
reinstalling and testing again on 5.9.3.

For reference, this issue is not occurring with LitJson on
our side. The deserialization error is happening with
Newtonsoft.Json.JsonConvert.

More importantly, the root problem is not just which JSON
library is being used. The actual issue is that the raw
response itself is already coming through differently.
Before, this value came through as an integer, but in 5.9.3
it is coming through as a double-form value such as 7.0.

So from our perspective, the problem starts at the raw
response level, before deserialization into our class.

Ok I will try Thank you!

There are multiple leaderboards in the game separated by region, but aside from the region itself, they all use the same settings.

When creating them initially, cloning works fine. However, after they have been created, if I need to adjust various options, I have to edit each leaderboard one by one.

The main problem is that every time I save a change, the “Updated successfully” popup appears and covers the edit button, which makes consecutive edits across multiple leaderboards very inconvenient.

It would be much more efficient if there were a way to edit multiple leaderboards with identical settings at the same time. At the very least, moving the success popup to a location where it does not block the button would greatly improve usability.

When updating multiple leaderboards consecutively, the current UX becomes quite inconvenient.

Each time a leaderboard is updated, an “Updated Successfully” popup appears. The issue is that this popup shows up in the top-right area, which is also where the Edit buttons and most of the controls are located.

Because of this, the popup covers the edit buttons, and instead of continuing the workflow, the user has to close the popup first before editing the next leaderboard. When several leaderboards need to be updated in sequence, this becomes unnecessarily repetitive and slows down the process.

It would significantly improve usability if one of the following changes could be considered:

Move the success notification to a less intrusive location (for example, bottom-right or top-center of the screen).

Make the notification non-blocking, so it does not cover important UI elements.

Add the ability to edit multiple leaderboards at once, instead of updating them one by one.

Currently, since most of the actionable UI is concentrated in the top-right corner, displaying notifications in the same area creates unnecessary friction for tasks that require repeated edits.

This small UX change would make managing multiple leaderboards much more efficient.

Environment:

Unity (C#)
BrainCloud SDK 5.9.3 (upgraded from 5.9.2)
Issue:
After upgrading to BrainCloud SDK 5.9.3, integer values from cloud code script responses are converted to floats before being passed to the success callback.

Details:

The server-side cloud code script explicitly assigns integer values: var tier = 7;
The server JSON response correctly contains "tier": 7 (integer)
Before SDK 5.9.3: The callback received "tier": 7 (integer, as expected)
After SDK 5.9.3: The callback receives "tier": 7.0 (float, unexpected)
The SDK internally parses and re-serializes the response (likely related to the new JsonParser introduced in 5.9.3??), converting integers to floats in the process
This breaks JsonConvert.DeserializeObject<T>() when the target field is int, throwing: JsonReaderException: Input string '7.0' is not a valid integer
Only affects custom values set in cloud code scripts. BrainCloud's own API values (e.g. rank, score) are not affected.
Expected Behavior:
Integer values from cloud code scripts should remain as integers in the callback response string, same as SDK 5.9.

@Paul-Winterhalder Now, purchase validation proceeds normally regardless of the “Use App Store Server API for legacy receipts (optional)” option setting.

@Paul-Winterhalder Yes, that’s correct. It is a sandbox account.

After the patch, it would be good if existing receipts continue to work by default.

@Paul-Winterhalder

Hello

Project 14594
Tester ID 1b5c9fce-a890-4d86-86aa-dd71263d0fc1

App Store \Server API has been fully configured in the current BrainCloud settings, and “Use App Store Server API for legacy receipts (optional)” is turned OFF.
This option must be disabled for the legacy receipt flow to function, so it is intentionally kept turned off in order to use the current setup.

When checking Verify Purchase in the user ID logs, the client has not yet been updated, so it is not sending a transactionId and is instead sending the receipt, following the legacy receipt-based flow.

@Michael-Costa

"packetId": 13,
"responses": [
{
"data": {
"resultCode": 101,
"errorMessage": "Transaction id not found.",
"store": "itunes"
},
"status": 200
}
]
}

After configuring the App Store Server API, enabling “Use App Store Server API for legacy receipts (optional)” appears to cause legacy receipt validation to stop working. Instead, the system starts requiring a transaction ID.

In other words, checking it has the opposite effect.

We are currently running a live service using the existing receipt-based flow, so we have this option turned off—meaning we are effectively using it in practice (because enabling it breaks legacy). We are very concerned that if this behavior gets “fixed” later, it could cause issues in our live service. Please take this into account and ensure any patch/change does not introduce regressions for live operations.

@Paul-Winterhalder Hello, is there guide for this menu?

and what is "Use App Store Server API for legacy receipts (optional)"?

https://discussions.unity.com/t/unity-iap-5-0-2-ios-sandbox-same-receipt-returned-for-all-purchases-after-the-first-one/1692048/5

Due to the issue described in the Unity discussion above, we need StoreKit 2 support on iOS as soon as possible. Please prioritize StoreKit 2 integration

Hi @Paul-Winterhalder

I wanted to follow up regarding StoreKit 2 JWS receipt support.
At the moment, Unity IAP v5 relies on StoreKit 2 by default, but there are two major issues we’re facing in production:

VerifyPurchase currently only supports StoreKit 1’s PKCS#7 receipt format.
When StoreKit 2 is used (as in Unity IAP v5), the App Store often returns empty receipts in certain environments — especially on Apple Silicon (M-series) Macs running iPadOS compatibility mode — causing verification to fail and users to lose their purchases.

In addition, Unity IAP v5 has a known issue where after the first successful purchase, all subsequent purchases return the same receipt as the first transaction.
This makes it impossible for the server to distinguish or validate new purchases, since every transaction reuses the initial receipt data.

Both of these problems make proper validation impossible under StoreKit 2, and they directly affect live monetization and user trust.

If StoreKit 2 JWS receipt support could be prioritized or exposed as a secondary endpoint (for example, itunes2), it would help developers transition more safely.
Given the impact, we would really appreciate if this work could be accelerated.

Applied in version 5.6. Thank you.

@JasonL This is what I'm already doing, which is why I'm requesting a new feature, as it has the drawbacks listed above.

Looking at it again, I see you added time correction. I'll try it.

Currently, we are repeating push notifications by scheduling cloud codes 24 hours later with push notifications to repeat them at a set time every day for a specific segment.

The problem with this method is that the time gradually gets later due to server delays.

Also, there was an issue a while ago where calls were suddenly made at a time other than 24 hours due to a server error.

It would be nice to have a function that can repeat at a set time (UTC) rather than after N hours.