In article , Alan Browne
wrote:

System settings should contain system related settings.

App settings should contain app related settings.

both methods are valid.

Because you can 'do' it that way, does not make that way the best or
correct way.

Violates structured design principles for s/w design and u/i design.

putting settings all in one place is structured, just differently.

Badly structured.

structured *differently*.

as i said, both methods are valid.

Nope.

wrong. both are valid.

having a central location for settings makes sense in some cases.

the problem is that neither method is enforced, so there's a mix of
both and users aren't always sure where to look.

having it in settings is less clutter for the app. the problem is that

What belongs to an app should be in the app. Period. That's just
structured design.

except that some settings are system related, such as whether to
display notifications, whether the app should use cellular data. if
location services is active or if the app has access to the camera,
microphone, etc.

That's fine, because they are system related.

they're app related, with each app having its own configuration.

contrast that with systemwide enable/disable notifications, cellular
data, location, etc. for *all* apps.

But an app setting, such
as whether the compass displays magnetic or true heading certainly is
not - that belongs in the app as it is part of the app.

except that particular setting is rarely changed, if at all, so there's
no reason to clutter up the app for only one toggle.

*many* ios apps are single view apps.

if you disagree, write your own compass app and put whatever settings
you want wherever you want.