MacOS Desktop build: Default font of material (SF UI) does not work on Mac OS 10.12

[hpoul]

Steps to Reproduce

Building a MacOS desktop app with default ThemeData (unchanged TargetPlatform) and running it on MacOS 10.12 seems to produce font problems.

Unfortunately I don't have a chance to test on MacOS 10.12, but a user report a weird font problem:

I have then tried to use Google Fonts to load alternative fonts, and this solved the issue. So it's definitely a problem with the default font of the theme.

Not sure if this is something which has to be fixed in flutter, since desktop is still just a preview and not sure if MacOS 10.12 should be "supported"(?). But I don't quite understand the problem, as the default theme on TargetPlatform.macOS uses SF UI and afaik this should be available since 10.11.

[VladyslavBondarenko]

Hi @hpoul with what flutter version is your app built?

[hpoul]

latest dev channel:

[✓] Flutter (Channel dev, 1.19.0-1.0.pre, on Mac OS X 10.15.4 19E287, locale en-AT)
[✓] Xcode - develop for iOS and macOS (Xcode 11.5)

[pedromassangocode]

Hi @hpoul Can you confirm if this still a valid issue?

[hpoul]

@pedromassangocode Not sure, i don't have a old Mac version available, it was reported by a user.. i fixed it by manually bundling a custom font. If there was anything that could have fixed it, i can try to get in touch with the user to try out a new build..

[pedromassangocode]

Please try it and let me know if this still a valid issue.

[hpoul]

@pedromassangocode I have now heard back from the user - seems like nothing changed (flutter master channel from August 9th)

[TahaTesser]

Hi @hpoul Can you please provide and a complete reproducible minimal code sample Thank you

[hpoul]

@TahaTesser running the default template example app from flutter create on macos 10.12 should do the job, is this not reproducible?

[stuartmorgan]

It may be that the exact font family names being used by blackCupertino and whiteCupertino aren't correct for 10.11 and 10.12. In fact, I think they are actually incorrect for macOS in general, because I see various "SFNS" fonts in /S/L/Fonts, which have similar family names but with NS instead of UI which suggests they may use Cocoa API-style naming for the fonts. And actually, running a trivial test application and querying the family name of NSFont.systemFont gives me AppleSystemUIFont (on 10.15)--although I don't see a font on disk actually called that, so perhaps that maps to SFNS?

@gspencergoog Do you know how the exact family name to use for iOS was determined so we can replicate that process?

[gspencergoog]

@stuartmorgan No, I don't, sorry. Maybe @xster or @cbracken knows?

[cbracken]

Oh yikes... it's been close to 4 years since I wrote that code. I can't remember how I ended up with those names. It would have been during the iOS 8 to iOS 9 transition though.

[stuartmorgan]

Based on discussion here it looks like some combination of .AppleSystemUIFont, .SF NS Display (or .SFNSDisplay?), and .SF NS Text (or .SFNSText?) is likely what we want going back to 10.11. I'll experiment, land something based on those that works on recent versions of macOS, and then we can see if that fixes older versions as well.

[stuartmorgan]

it looks like some combination of .AppleSystemUIFont, .SF NS Display (or .SFNSDisplay?), and .SF NS Text (or .SFNSText?) is likely what we want

Testing on 10.15 (with a custom engine that doesn't have a fallback font), only .AppleSystemUIFont works out of this list. In fact the .SF UI * fonts we're currently listing don't work either, so it looks like the theme actually doesn't work at all at the moment, and we're just getting the fallback (which is the system font, so it works out).

That leaves the question of what's happening on 10.11/12. The possibilities I see are: 1) They are returning some strange font (as seen in the screenshot) for .SF UI *, so we're not getting the system font fallback. 2) The fallback code doesn't work.

I'm pretty sure the problem is (2), based on discussion and patches in https://bugzilla.mozilla.org/show_bug.cgi?id=1201318 and https://bugs.chromium.org/p/chromium/issues/detail?id=521034 (especially the screenshot in the latter, which looks like the one here). However, I tried the PostScript workaround from the Mozilla bug in the fallback, and on 10.15 it fails due to new restrictions on using these pseudo-fonts:

CoreText note: Client requested name ".SFNS-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].

So I'm not yet sure how to implement the fallback in a way that works both in current versions of macOS and back to 10.11.

[stuartmorgan]

I suspect we'll need to get the system font, look at its name (or maybe even the OS version), and then do different follow-up logic in different cases. That will require experimentation on a 10.11 or 10.12 machine to find out what works there (hopefully the PostScript trick referenced above), and then conditionalization to avoid triggering it on newer OS versions that will fail with the workaround.

[hippyau]

Any progress on this? Have the same issue here: https://github.com/hippyau/rnc/issues/7

[gaodeng]

Shouldn't this be solved before announcing that flutter officially supports building macOS apps?

[hpoul]

I haven't tested it for a while, but for me it worked by simply changing the font prior to MacOS 10.15:

https://github.com/authpass/authpass/blob/6a835981e32b1e7bb17a59dea1c7cd59cb05ada8/authpass/lib/theme.dart#L86-L102

(at least I haven't heard any bug reports since then 😅)

[jmagman]

This was "fixed" by updating the minimum requirement to 10.13.

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.