Currently the `iOS` version identifier is predefined by the compiler when targeting iOS. This is fine. In druntime and Phobos the version identifier `Darwin` is used to include macOS, iOS, tvOS and watchOS. This is set manually when needed.

I have started to use the `AppleARM` version identifier to indicate iOS, tvOS and watchOS. This is set manually when needed. This is not a good name because on the simulators `iOS`, `TVOS` and `WatchOS` should be defined as well, but the simulators are running x86(-64). Therefore I would like to come up with a better name.

In the Apple SDK there's a header file, `TargetConditionals.h` [1] which defines a bunch of target specific preprocessor defines. Here's an extract of the relevant documentation:

TARGET_OS_MAC       - Generated code will run under Mac OS X variant
   TARGET_OS_OSX    - Generated code will run under OS X devices
   TARGET_OS_IPHONE - Generated code for firmware, devices, or simulator
      TARGET_OS_IOS - Generated code will run under iOS
      TARGET_OS_TV  - Generated code will run under Apple TV OS
      TARGET_OS_WATCH     - Generated code will run under Apple Watch OS
      TARGET_OS_BRIDGE    - Generated code will run under Bridge devices
      TARGET_OS_MACCATALYST    - Generated code will run under macOS
   TARGET_OS_SIMULATOR      - Generated code will run under a simulator

`TARGET_OS_MAC` is defined for any kind of Apple platform. We're currently using `Darwin` for this. `TARGET_OS_OSX` is defined for macOS, we're using `OSX` for this. `TARGET_OS_IPHONE` is defined for iOS, tvOS or watchOS. This is what I have used `AppleARM` for, so far.

Would it be better to rename `AppleARM` to `iPhone`? I'm hesitating a bit since I think `iPhone` sounds a bit misleading. It probably has that name in the header file due to backward compatibility.

When it comes to the simulators. Should we define one version identifier for each simulator device, like `iOSSimulator` and `watchOSSimulator`. Or should we just define one version identifier, like `AppleSimulator`, for all of them?

[1] https://github.com/theos/sdks/blob/master/iPhoneOS11.2.sdk/usr/include/TargetConditionals.h

-- 
/Jacob Carlborg

On Sunday, 23 February 2020 at 14:26:45 UTC, Jacob Carlborg wrote:
>
> Would it be better to rename `AppleARM` to `iPhone`? I'm hesitating a bit since I think `iPhone` sounds a bit misleading. It probably has that name in the header file due to backward compatibility.

I have no experience with these OSes, so my opinion doesn't count for much here. Maybe repost in the General forum to get more input?

The "ARM" part of AppleARM is also misleading (maybe more so). Intuitively, I feel there may be some benefit in naming things similar to how they are in C source. In the reserved version identifier documentation (the table) you can say that it applies to WatchOS etc. aswell...

(pretty cool you are working on this btw :))

cheers,
  Johan

On 2020-02-23 15:50, Johan Engelen wrote:

> The "ARM" part of AppleARM is also misleading (maybe more so).

That's the whole reason I started this discussion :)

> Intuitively, I feel there may be some benefit in naming things similar to how they are in C source. In the reserved version identifier documentation (the table) you can say that it applies to WatchOS etc. aswell...

I was think about `iOSDerived` as a possible name as well.

> (pretty cool you are working on this btw :))

Thanks.

-- 
/Jacob Carlborg

On Sunday, 23 February 2020 at 14:50:46 UTC, Johan Engelen wrote:
> The "ARM" part of AppleARM is also misleading (maybe more so). Intuitively, I feel there may be some benefit in naming things similar to how they are in C source. In the reserved version identifier documentation (the table) you can say that it applies to WatchOS etc. aswell...

No strong opinion either, but I agree and could live with a `version (iPhone)`, if that's what they chose for C.

I hope there's no need for extra simulator versions; if there's need for special-casing, I hope the arch version can be re-used.

On 2020-02-23 20:36, kinke wrote:

> I hope there's no need for extra simulator versions; if there's need for special-casing, I hope the arch version can be re-used.

You mean to use `iOS` and `x86_64` to identify the simulator? I don't think that will be sufficient. There's also the Catalyst platform (or what to call it). It's iPad apps compiled for macOS. I haven't looked in to this platform yet but I would assume it would have both `iOS` and `x86_64` defined.

-- 
/Jacob Carlborg

On Monday, 24 February 2020 at 18:39:21 UTC, Jacob Carlborg wrote:
> On 2020-02-23 20:36, kinke wrote:
>
>> I hope there's no need for extra simulator versions; if there's need for special-casing, I hope the arch version can be re-used.
>
> You mean to use `iOS` and `x86_64` to identify the simulator? I don't think that will be sufficient. There's also the Catalyst platform (or what to call it). It's iPad apps compiled for macOS. I haven't looked in to this platform yet but I would assume it would have both `iOS` and `x86_64` defined.

I assumed druntime etc. don't need to know whether the program runs in a x86 simulator or natively, and in case they do in 1-2 places, that the arch can be used to differentiate. E.g., on Android we apparently don't need any simulator versions (e.g., even the x86[_64] `long double` format corresponds to the AArch{32,64} one - double or quad precision). But hey, I have no idea about and interest in Apple stuff.

On Monday, 24 February 2020 at 19:37:14 UTC, kinke wrote:

> I assumed druntime etc. don't need to know whether the program runs in a x86 simulator or natively

Yeah, perhaps that's not needed. I guess it's better to wait and see instead of speculating :).

--
/Jacob Carlborg

AppleSmartDust if you're trying to differentiate proper computers.