Building FLTK for iOS

[Mo_Al_]

Hello

The fltk port to android works quite well (after adapting to some resolution issues). It would be great if fltk would also target iOS.
My initial trial to build fltk for iOS, some issues appear. Some headers aren’t available on iOS like:
- ApplicationServices, however most functions and types are also present in the CoreGraphics header.
- The Cocoa header will have to be replaced with UIKit headers.
- Most Cocoa types have an NS prefix while corresponding UIKit types have a UI prefix. Maybe this could be addressed with some ifdefs or by conditional compilation using the cocoa header for macos vs the uikit header for ios, this can be done by including the TargetConditionals header, then checking for TARGET_OS_OSX vs TARGET_OS_IOS. Or maybe by creating a separate ios driver, however the cmake scripts would have to replace APPLE with CMAKE_SYSTEM_NAME STREQUAL Darwin/iOS.

I would be interested to know if anyone was able to build for iOS and if they could provide input.
Thank you

[Greg Ercolano]

On 2020-10-22 16:43, Mo_Al_ wrote:
> It would be great if fltk would also target iOS.

When this question came up in 2014, Ian wrote:

---
The view (as I remember it) was that an IOS port is unlikely to be acceptable
to Apple's app store guidelines, so even if it existed it would probably not gain
any traction.
---

I don't know if this is still the case; did Apple relax their guidelines
on the app store for insisting on native widget apps only?

Android never had this problem, hence the evolution of that OS's support
in FLTK.

[Mo_Al_]

I don’t know of Apple’s cureent stance. Currently, however, as far as non-native gui toolkits targetting iOS the only 2 out there that I’m aware of are flutter and Qt QML.  The other frameworks targetting iOS either target UIKit’s native widgets such as Xamarin and React Native, or target iOS’s webview and are basically hybrid web apps, ionic, cordova and the likes, which also don’t have a native look and feel by Apple’s standards. 

Fltk  can be styled in a way, like the other solutions, to have an iOS style (white window, cupertino colors, flat buttons, the works). 

From my previous experience publishing an iOS app using Cordova, the app store review process checks for the bytecode and asks for a presentable screenshot for the app store. A qml app was refused because they require static linking. 

[Ian MacArthur]

On 23 Oct 2020, at 14:21, Mo_Al_ wrote:
>
> I don’t know of Apple’s cureent stance. Currently, however, as far as non-native gui toolkits targetting iOS the only 2 out there that I’m aware of are flutter and Qt QML. The other frameworks targetting iOS either target UIKit’s native widgets such as Xamarin and React Native, or target iOS’s webview and are basically hybrid web apps, ionic, cordova and the likes, which also don’t have a native look and feel by Apple’s standards.
>
> Fltk can be styled in a way, like the other solutions, to have an iOS style (white window, cupertino colors, flat buttons, the works).
> From my previous experience publishing an iOS app using Cordova, the app store review process checks for the bytecode and asks for a presentable screenshot for the app store. A qml app was refused because they require static linking.

I don't have a clue what Apple would do...

As I recall (and this is just from memory, so likely to be flawed!) our concern at the time was that Apple would always reject fltk-based apps, even if they were tailored to look exactly like native, because of the way we use the underlying API’s, which ISTR was liable to violate their terms...

Whether the rules have changed in the intervening time, I do not know.

The upshot was that no one wanted to put a lot of effort into a port that was likely to been unusable in practice!

[Greg Ercolano]

As an aside, some considerations I think we'd have to address before even starting an IOS port
is the issue of "sandboxing" on the iphone.

FLTK does have some features that would probably be considered unsafe; file browsers,
preference files (e.g. the Fl_Preferences stuff), and anything that accesses the file system,
I'd imagine.

We'd have to be careful, I think, how we build the library for IOS to prevent the app from accessing
system calls it shouldn't (like system(), fork()/exec()), and may have to provide linking flags that disable
such features in the final compiled lib.