Proposal to set macOS 10.9 Mavericks as earliest supported macOS version for FLTK 1.5

[Manolo]

Proposal to set macOS 10.9 Mavericks as earliest supported macOS version for FLTK 1.5

Since FLTK 1.5 requires C++11, it's no longer usable on early versions of macOS
that don't support C++11. I believe the earliest such version is macOS 10.9 Mavericks
released in October 2013. That makes sense because C++11 can hardly be fully supported before 2011. Therefore, I propose to set macOS 10.9 Mavericks as the earliest supported macOS version for FLTK 1.5.

This would allow to remove a lot of code from file src/Fl_cocoa.mm and other source files.

Here is the experiment that supports this claim:
Using today's Xcode (version 26.2) and with $source set to today's FLTK head
and $build set to an empty build directory, run:

set TARGETS="-target x86_64-apple-macos10.9"
/Applications/CMake.app/Contents/bin/cmake -S $source -B $build \
-DFLTK_BUILD_GL=1 -DFLTK_BUILD_HTML_DOCS=0 -DFLTK_BUILD_FLUID=1 \
-DCMAKE_OSX_ARCHITECTURES="x86_64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=10.9 \
-DFLTK_ARCHFLAGS="$TARGETS"

make

It successfully builds FLTK for running on macOS 10.9 and above with x86_64 architecture.
In contrast, replacing 10.9 by 10.8 above stops very early at compile time with an error
on: #include <cstdint>

Furthermore, I arrive to the same conclusion using a copy of the clangV9 compiler I have

kept: it successfully compiles and builds for 10.9 but fails for 10.8.

What do fellow FLTK developers and users of macOS think of this proposal?

[Albrecht Schlosser]

On 1/31/26 12:42 Manolo wrote:

Proposal to set macOS 10.9 Mavericks as earliest supported macOS version for FLTK 1.5

Since FLTK 1.5 requires C++11, it's no longer usable on early versions of macOS
that don't support C++11. I believe the earliest such version is macOS 10.9 Mavericks
released in October 2013. That makes sense because C++11 can hardly be fully supported before 2011. Therefore, I propose to set macOS 10.9 Mavericks as the earliest supported macOS version for FLTK 1.5.

This would allow to remove a lot of code from file src/Fl_cocoa.mm and other source files.

+1, I agree. However, I would propose to go further and select a later version.

Rationale: If we support macOS 10.9 (released 2013) then we support hardware that's even older, which could get macOS updates to 10.9. What's Apple's policy? 5 year old hardware, or maybe less? Anyway, this would allow to use hardware built in 2010 or even earlier. Is this necessary, is this even realistic?

IMHO the more conditional code we can remove, the more stable and maintainable FLTK will be.

I believe we should define our own policy of supported OS versions. Beginning with macOS we could, for instance, say that we support macOS versions that have been released 8, 9, or 10 years before the release of the respective minor FLTK version (i.e. 1.5.0). Assuming that FLTK 1.5.0 will be released in 2026, the oldest supported macOS version could be one of the following versions (release dates from Wikipedia):

- OS X  10.11 (El Capitan),  September 30, 2015 (not suggested)
- macOS 10.12 (Sierra),      September 20, 2016
- macOS 10.13 (High Sierra), September 25, 2017
- macOS 10.14 (Mojave),      September 24, 2018     

Note that 10.12 was the first version officially called "macOS" rather than "OS X", which would be another (purely formal) reason to use at least 10.12.

We could also review the code and decide between versions 10.12, 10.13, and 10.14 depending on the amount of conditional code that can be removed. In short: if we can't achieve significant code savings, version 10.12 is sufficient. However, if we can remove considerably more code, we should choose one of the newer versions.

In general, I believe that 10-year-old versions would represent a good compromise. For even older hardware users could still use FLTK 1.4.x.

[Manolo]

Le samedi 31 janvier 2026 à 14:42:22 UTC+1, Albrecht-S a écrit :

+1, I agree. However, I would propose to go further and select a later version.

Rationale: If we support macOS 10.9 (released 2013) then we support hardware that's even older, which could get macOS updates to 10.9. What's Apple's policy? 5 year old hardware, or maybe less? Anyway, this would allow to use hardware built in 2010 or even earlier. Is this necessary, is this even realistic?

IMHO the more conditional code we can remove, the more stable and maintainable FLTK will be.

I'd like to argue for keeping support as extended in time as possible, for these reasons:

- Users of very old OS versions exist in real life, see issue #1286 from July 2025

reporting use of macOS 10.6.8 on the powerpc architecture.

- A very efficient procedure to produce forward and backward compatible source code

for the macOS platform is in place since day 1 of FLTK for macOS X. It doesn't cost

anything besides following the procedure for each change required by a new macOS

release. Finding the code compatible with the new macOS is necessary in all cases.

- Setting the limit at 10 (or any number of) years is arbitrary.

- In contrast, setting the limit at or after a version of macOS that's not compatible with an 

FLTK feature agreed upon (today, use of C++11) is unavoidable.

I propose an additional constraint that we could give us in terms of support of old versions:

an FLTK developer at least must be able to build FLTK with that old version as 

CMAKE_OSX_DEPLOYMENT_TARGET. This gives a solid indication that

no operation unsupported by that OS version is called by the source code.

I also add the same investigation should be done for our Windows platform.

[Albrecht Schlosser]

On 1/31/26 16:48 Manolo wrote:

Le samedi 31 janvier 2026 à 14:42:22 UTC+1, Albrecht-S a écrit :

+1, I agree. However, I would propose to go further and select a later version.

Rationale: If we support macOS 10.9 (released 2013) then we support hardware that's even older, which could get macOS updates to 10.9. What's Apple's policy? 5 year old hardware, or maybe less? Anyway, this would allow to use hardware built in 2010 or even earlier. Is this necessary, is this even realistic?

IMHO the more conditional code we can remove, the more stable and maintainable FLTK will be.

I'd like to argue for keeping support as extended in time as possible, for these reasons:

- ...

Please don't understand me wrong, I'd be fine with that too. My proposal was just an option.

I propose an additional constraint that we could give us in terms of support of old versions:

an FLTK developer at least must be able to build FLTK with that old version as 

CMAKE_OSX_DEPLOYMENT_TARGET. This gives a solid indication that

no operation unsupported by that OS version is called by the source code.

OK.

I also add the same investigation should be done for our Windows platform.

What investigation do you mean?

[imm]

On Sat, 31 Jan 2026, 22:02 'Albrecht Schlosser' wrote

I also add the same investigation should be done for our Windows platform.

What investigation do you mean?

FWIW, there are a few windows API that work for Win10 that aren't supported by Win7, for example.

So maybe that sort of thing?

I tripped over one of those the week before last, took a bit of tweaking to resolve.

Though I can't recall off-hand what the problem was, now...

--
Ian
From my Fairphone FP3
 

[Manolo]

Le samedi 31 janvier 2026 à 16:48:19 UTC+1, Manolo a écrit :

…

I also add the same investigation should be done for our Windows platform.

One thing I had in mind is our checks for availability of several dynamic libraries

at run-time. Many (if not all) checks are useful only on very old versions of Windows.

Example: to use OS function AlphaBlend() we check for presence of Msimg32.dll

but that function and that dll are available since Windows 2000 that's older than Windows XP

(see https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-alphablend).

Do we still want 1.5 to support Windows 98? Are we sure it would run on Windows 98?

[Manolo]

I have committed at e0405d2 a first step towards removing the code related to support of old macOS versions 

that are not compatible with C++11. This step removes support for macOS 10.3 and 10.4 that are definitely out

of reach of C++11. It removes nearly 900 lines of code!

This commit makes no assuption about what our final decision for the oldest supported macOS version will be.

I'd like to read Matthias and Greg's opinions on this topic.

[Greg Ercolano]

On 2/1/26 07:40, Manolo wrote:

I'd like to read Matthias and Greg's opinions on this topic.

    I'm fine with dropping 10.4 and back. IMHO if the most "up-to-date" browser for an OS can't open google.com correctly, it's "dead".
    I've kind of forgotten where the dividing line is for that with MacOS, but apparently the furthest back Firefox with HTML5 support goes is 10.5.
    Pretty sure my customers don't use anything older than 10.5, and that'd be for reliable back end servers that they don't want to upgrade, and still want to run my product's GUIs on.

    Regarding windows, I'll weigh in below this handy MacOS version table:

    Regarding Windows I'd hope we can continue to support running on Windows 7 at minimum. I still build on more modern releases (Win10Pro), but expect that to run on the older OS's. I think all of my customers are long off XP, and TMK, all that I've talked to simply skipped over Windows Vista.

    As a personal opinion, Win7 is the last version of Windows I thought was "familiar" to me, with simple "File/Edit" menubars, and relatively free of creepy subscription/cloud tie-ins, allowing me to think the machine is still "mine", and not "theirs". In Win10 I feel more lost in their newer interfaces, and not so sure the machine is still "mine". With Win11 I'm sure the machine isn't "mine" any longer, and try to avoid using it, unless there's a client requirement.

[Manolo]

Le dimanche 1 février 2026 à 18:41:00 UTC+1, er...@seriss.com a écrit :

    I'm fine with dropping 10.4 and back. IMHO if the most "up-to-date" browser for an OS can't open google.com correctly, it's "dead".
    I've kind of forgotten where the dividing line is for that with MacOS, but apparently the furthest back Firefox with HTML5 support goes is 10.5.
    Pretty sure my customers don't use anything older than 10.5, and that'd be for reliable back end servers that they don't want to upgrade, and still want to run my product's GUIs on.

Thanks Greg for this information.

A remaining open question is: what is your position about FLTK 1.5? 

I believe FLTK 1.5 can't be built for anything older than macOS 10.9 because of C++11.

Can we agree that compatibility with running on macOS 10.5 is only for 1.4-based software,

and that future updates will have more stringent minimum platform requirements?

[Greg Ercolano]

    Sure, I think that's fine. For my purposes I'm sticking with fltk 1.4 as much as I can.
    The oldest MacOS system I'm running 24/7 is 10.10.x, so I think for fltk 1.5 a MacOs 10.9 minimum is OK.

[Manolo]

I've found that I can build and also run FLTK 1.5 for macOS 10.7 and SDK 10.7

with both the i386 and x86_64 architectures.

I therefore propose now to set at 10.7 the required minimal version of macOS 

to build and run FLTK 1.5.

That's been committed to git (95e5b1b and commit before).

Altogether, moving the minimal supported version from 10.3 to 10.7 removed 1134 code lines.

[Albrecht Schlosser]

On 2/2/26 13:22 Manolo wrote:
> I've found that I can build and also run FLTK 1.5 for macOS 10.7 and
> SDK 10.7
> with both the i386 and x86_64 architectures.
> I therefore propose now to set at 10.7 the required minimal version of
> macOS
> to build and run FLTK 1.5.

Great, thanks for trying it.

> That's been committed to git (95e5b1b and commit before).

+1, I'm fine with that.

> Altogether, moving the minimal supported version from 10.3 to 10.7
> removed 1134 code lines.

Awesome. Thanks for all your work on that.