Re: Apple embedded OSes

[Jeffrey Walton <noloader@gmail.com>]

On Sun, Dec 27, 2020 at 7:20 AM Bruno Haible <bruno@clisp.org> wrote:
>
> Hi Jeffrey,
>
> > Just an FYI in case you have not hit this wall (yet?)... The exec
> > family, posix_spawn and friends are _not_ available on all Apple
> > platforms. Be sure to check availability before using them.
> >
> > For example, the iPhone/iPad SDKs has them, but the WatchOS and TvOS
> > SDKs lack them. To further complicate matters, you have to include
> > <TargetConditionals.h> before you can check for the SDK.
>
> There are 3 questions:
>
> 1) Do you think it is technically possible to support the iOS variants
>    in Gnulib?

I think Yes, it is technically feasible in most instances.

I think initial support can simply be recognizing the problem
platforms and disabling code paths or returning ENOSYS (not
implemented).

I believe Apple wants folks to use NSTask or NSThread on AppleTV and
AppleWatch. So there is an upgrade path for those who are initiated.

> 2) Do you think it makes sense for the GNU project to support the iOS
>    variants?

Well, I think iOS is one of the most popular platforms, so it would be
wise to try to support it.

Android has about 70% mobile market share, and iOS has about 28%
mobile market share. I don't know the breakdown of iOS variants. But
28% is non-trivial, so I would try to support it.
https://gs.statcounter.com/os-market-share/mobile/worldwide.

iPhone and iPads should cause the least pain because they mostly
behave like you expect. Gnulib and other GNU projects already support
them.

AppleTV and AppleWatch can be more painful because they are crippled.
SOme programs and libraries won't have any problems. For those who are
using a missing function, maybe initial support for them can be a
replacement posix_spawn that simply returns ENOSYS.

> 3) Do you think we need to document that Gnulib doesn't support the iOS
>    variants?

Yes. It is a sharp edge. I imagine developers searching for "Gnulib
posix_spawn iOS" or "Gnulib posix_spawn AppleTV" to see what is going
on when they encounter a compile error.

> My take on these questions would be:
>
> 1) For an OS that does not have files with file names, it's pointless to
>    even think about open(), exec(), and so on.

For AppleTV and AppleWatch, I believe the crippled-ness is limited to
forking a new process. That's why posix_spawn and the exec family are
missing.

I think you will be OK with the other operations, like file or socket ops.

What I have found in practice is, the test suites have the most
trouble because developers fork a server to test something related to
a socket. The libraries and programs ported to AppleTV and AppleWatch
are usually OK.

> 2) Anyone buying and using these devices has surrendered their entire
>    freedom and privacy to Apple. There is no point for GNU to help make
>    these devices more widely spread by porting software to it.

Yeah, I'm not a big fan of Apple either. I stopped joining their
Developer Program years ago when they started forcing people into
their iCloud and wanted folks to indemnify their officers. Buy a
fucking insurance policy if you want indemnification...

I now support Apple platforms to poke Apple in the eye. Anything I can
do to make free software a better alternative is usually a high
priority for me.

> 3) I would think that the communities of POSIX / C users and iOS / Swift
>    users are disjoint. Hence no need to document.

Yeah, I would document it for users. Documentation is cheap.

The groups may be disjoint, but there's no sense in penalizing an iOS
user because of what Apple does. At least let iOS users know there are
technical limitations behind the lack of full support.

Jeff