Commit your preferences changes back from this Editor to the Android.Content.ISharedPreferences object it is editing. This atomically performs the requested modifications, replacing whatever is currently in the SharedPreferences.
Note that when two editors are modifying preferences at the same time, the last one to call apply wins.
Unlike ISharedPreferencesEditor.Commit, which writes its preferences out to persistent storage synchronously, ISharedPreferencesEditor.Apply commits its changes to the in-memory Android.Content.ISharedPreferences immediately but starts an asynchronous commit to disk and you won't be notified of any failures. If another editor on this Android.Content.ISharedPreferences does a regular ISharedPreferencesEditor.Commit while a ISharedPreferencesEditor.Apply is still outstanding, the ISharedPreferencesEditor.Commit will block until all async commits are completed as well as the commit itself.
As Android.Content.ISharedPreferences instances are singletons within a process, it's safe to replace any instance of ISharedPreferencesEditor.Commit with ISharedPreferencesEditor.Apply if you were already ignoring the return value.
You don't need to worry about Android component lifecycles and their interaction with apply() writing to disk. The framework makes sure in-flight disk writes from apply() complete before switching states.
The SharedPreferences.Editor interface isn't expected to be implemented directly. However, if you previously did implement it and are now getting errors about missing apply(), you can simply call ISharedPreferencesEditor.Commit from apply().