Summary of the issue:
After restarting the app, most settings persist, as is expected on iOS apps. However, the view settings do not.
How to reproduce the issue:
Set view settings to display the 4 stems. Restart app. View settings are reset back to displaying a single waveform.
Thanks for the details about your setup and the video @wasabidj. This is very helpful. Please confirm if you are using 5.1.2 or 5.2.1. I was able to reproduce this issue on my setup and have forwarded this to the engineering team to see if they can offer any suggestions. Iāll report back here when I have news. Thanks!
Yeah indeed - 5.2.1 
Hi @wasabidj
Thanks for bringing this up!
I think I had the same finding on the MacBook and recently wrote this Bug Report:
The answer was that is is expected behaviour.
@Slak_Jaw; maybe join these tickets together?
If theyāve already dismissed what is clearly undesirable behaviour as an undocumented feature in the previous report, Iām loathe to combine this with it as it implies an acceptance of their position.
Appleās HIG (to which I have been given to understand that Algoriddimās leadership holds its developers to respect) states in unqualified terms that this is incorrect behaviour. I will quote directly from chapter 5:
Restore the state of the app to that in use when the user last stopped using the application. People should not have to remember the steps they took to reach their previous location in your application.
If said developers who saw fit to disregard it off-hand as the classic āitās desiredā donāt have a link to hand, they can find Appleās HIG here: https://tableless.github.io/exemplos/pdf/guidelines-interface-mobiles/MobileHIG.pdf
I suggest they familiarise themselves with it as itās an exceptional document to be disregarded only when one desires to create a substandard app with an accordingly substandard user experience.
Ok, @wasabidj, thanks a lot for clearing this up.
You definitely know your stuff.
For me, as a user, it would just be logical that DJay remembers the last state of the app, including display and effect settings. Apart from the documentation, it simply makes logical sense.
From your perspective, I now clearly understand why you are not a fan of combining these tickets and I have no problem to leave it as it is.
In the end we both want te same.
Hi @wasabidj, thanks for your continued feedback on this. We greatly appreciate the input. I spoke with the dev team and they had the following to say:
We completely understand the userās perspective. This is precisely why feedback like this is valuableāit allows us to reassess the pros and cons. Here is some additional context on why this behavior has been designed like that (at least for now, while itās not set in stone).
The challenge here is that enabling Neural Mix waveforms isnāt just a simple view preference (though, of course, retaining preferences across launches is generally expected). Itās a somewhat hidden feature that users might activate by accident or just experiment with, which could make it difficult to locate again. The key issue is that enabling Neural Mix waveforms requires continuous STEM separation, which is demanding on the CPU of most devices. This was the primary reason why we initially chose not to preserve this setting.
The assumption on the product dev side is that you may want to enable/disable NM waveforms from time to time, depending on context. Similar to how you enter full screen in an application but that state is usually not retained across launches (depending on the type of app though). We also do not retain the Slip Mode āsettingā (located in the same popover), because again if you turn that on by mistake you are stuck in an unexpected state that may be hard to recover for a user.
Thanks to you and the dev team for the response.
I appreciate the technical challenge behind honouring the user interface implications, and for what its worth Djay seems to be the best in its class of integrating the latest AI technology while at the same time striving to retain a coherent user experience. Thereās a lot which could go wrong with integrating AI-dependent features like stems into a vinyl-esque interface and in most ways Djay seems to have got it right. Bravo.
IMO thereās really only this issue and that issue of providing bass-stem FX assignment which are needed to give Djay a baseline coherent user experience.
As for the comparison between visual stem separation and Slip Mode state, I totally appreciate that from the perspective of the code, theyāre both just application state and without deeper consideration then there is little to distinguish between how they should be handled.
Taking the Apple HIG strictly (which I think almost all developers should be doing unless they can muster an extremely strong argument to the contrary), then even the āsimulated deck buttonsā like Slip Mode could be expected to be persisted across restarts as Apple clearly intents a restart to be transparent to the user (unlike with more traditional platforms where a restart is understand by the user to be doing some sort of ācleanupā).
If we give ourselves the latitude to depart from a strict interpretation of Apple HIG, then the question is āwhat ācleanupā might most users expect to be done on a restart of an application which simulates a DJ deck?ā.
There is an argument to be made that the same sort of cleanup might be done as with a power-cycle on a DJ deck. Some decks might have a physical Slip Mode flip switch, others might have a digital button. So maybe if you argue that the physical deck which Djay is attempting to simulate (and thus honour a userās expectations over) has only a digital Slip Mode button then Slip Mode might escape persistence.
However, one thing which we can say with certainty would be expected to persist across a power-cycle is a view preference. This is because, as with all user-preferences, it represents a property of the user, not the tool. Going back to the Apple HIG, chapter 5 āStart Instantlyā:
Avoid asking people to supply setup information
By discarding the userās preference on what is intended to be user-transparent operation, Djay is not merely not persisting an element of application state: Djay is requiring that, on restart, the user must resupply their preferences to the application, one very specific thing Appleās Mobile HIG is very clear should not be done.
