If you have issues with your monitor profile, the preview would look different / weird / wrong.
But loading a tiff file and not doing anything to it and saving it again in sRGB should look (almost) like the input.
Make sure you do NOT touch input profile module (leave the working profile to linear rec2020).
The output is only used if you want your files to be in a certain profile , but generally this should be sRGB.
All the soft proof settings should also be left at default to get started.
What i know from macos, is that the os is doing the color management for apps , unless an app really requests 'i know what i am doing , let me draw my own pixels '.
So just to get started , you should not touch any setting (and for sure not set anything to adobergb , because that has no place except for an output profile ).
Open a tiff file , that has an ICC profile embedded in it (and for giggles , make sure it is not a CMYK profile ). Make sure all Darktable modules are disabled that can be disabled .
In the export , save it as a jpg , set it to sRGB output and relative mode . Export it , compare it to the input tiff in a color managed program (like Photoshop ). They should be similar (gamut limits and such not accounted for right now ).
Note that i completely ignore how the file looks inside of Darktable. The input and output are being checked .
If you have a monitor calibration profile and have it set in macos settings , you should not set it anywhere in Darktable is my guess (but I’m not 100%) on this.
Of that input - output check is being done correctly and is NOT ok, it looks like therenis a bug with the build you are using. Darktable’s color management is done with a library internal to Darktable (lcms2, not using macos libraries AFAIK) so it should work the same as any other build using lcms2.
What i learned from using a 2017 Macbook pro , is that of a program is not pretending to be color managed , macos interprets it as being sRGB, so macos will take whatever the program is drawing , and interprets it as sRGB and makes sure it looks ok on the profile in the OS display settings.
Now, if a program advertises itself to macos as being color managed , it gets more choices and can draw in bigger gamuts than sRGB for instance , but it has to do a lot by itself suddenly . I guess this would mean you would have to select the monitor profile somewhere in Darktable. Note, this is monitor profile . NOT soft proof profile , not input profile , not output profile , not working profile .
Also note that i can’t imagine you have to select adobergb anywhere in monitor profiles or soft proof profiles. The only use case would be if your monitor has an adobergb mode you are using , and you have NO monitor profile selected on system settings.
The moment you profile/calibrate your monitor , you select that monitor profile, not Adobe RGB or something.
You also don’t select it as working profile , be a use Darktable usually uses linear rec2020 as working profile which is fine. You don’t use it as an input profile , unless you know the input file is adobergb but it has NO adobergb profile embedded. Of this is the case , comparing in other apps would go wrong anyway since they don’t know the input is adobergb and would interpret it wrong. And you don’t select it as output profile unless you want your output file to be in adobergb. And you would know if this would be required / desired for your use case.
If you see a shift in the histogram in Darktable, I’m guessing something in the Darktable pipeline is still changing the values or pixels. On the other hand , still confused about what the histogram is displaying in Darktable (i would suspect ‘working profile’ but there have been bugs and I have been wrong before , so I’m absolutely not sure what it is doing these days ). If it’s displaying your input file in the working profile , then yes, it would look different to what you expect , because it is converting the input to linear rec2020.
The preview on your screen is rendered from this linear rec2020 to whatever Darktable is using for drawing. ND if you export , that linear rec2020 is converted to the output profile (either set in the output profile module per file , or overridden in the export settings ).
It’s also not really clear to me what you are comparing with preview.app (the built-in viewer in macos , for the uninitiated). Input tiff vs exported tiff / jpg? Your monitor profile / soft proof settings / macos settings should have no effect.
If it’s raw file as input vs what you get from Darktable as export , then yes , that would be different , as preview.app uses a completely different pipeline for displaying raw data (a raw file has no 'true, correct look. Only interpretations).
If you are comparing a tiff input file to how it looks inside Darktable, then maybe there is more to discover . If you are comparing how it looks in Darktable vs how the exported file looks in other software , then also there might be more to discover ).
. Short answer: What is your problem, Darktable’s output file compared to an input file? Or Darktable’s output file (in other programs) compared to how it looks inside Darktable itself? Can you share your input file for testing, so we can follow along? (And see if your Darktable version behaves the same compared to others?).