Investigate supporting visionOS

[lawrence-forooghian]

A customer has asked if we support visionOS. I did a very brief investigation into it, here's what I found:

• It already runs on "Apple Vision Pro (Designed for iPad)" — see AblyPushExample app
• Briefly tried getting it working for native apps too
  • tried adding to Package.swift and adding to the AblyPushExample app, but refused to compile and wasn't immediately obvious why
  • I think that we need to sort out the conditional compilation and add #if TARGET_OS_VISIONOS
• we probably should run the tests for it, and do the same for watchOS whilst we're at it, this would mean creating new Xcode targets
• and when you change the Package.swift to the tools version needed for visionOS, it says the other platforms we're trying to build for are deprecated
• there are other deprecation warnings that you get when you try and build for visionOS (probably because even the earliest visionOS is a lot newer than the oldest platforms we support)
• we'd ideally want to do some manual smoke testing to confirm that things like push notifications are working

The aim of this task is to get a better idea of how much work it would be to add visionOS support. If there are any useful changes that come out of this investigation, please push them to a branch so that we can pick them up if / when we decide to proceed with adding visionOS support.

┆Issue is synchronized with this Jira Task by Unito

[maratal]

WIP branch 2045-visionOS-research

[maratal]

This is what I got when trying to install ably-cocoa Carthage dependencies for visionOS:

It's easy to add visionOS targets for delta-codec-cocoa and msgpack-objective-C since they already have multiple targets in their Xcode projects, but Nimble doesn't:

WDYT @umair-ably @lawrence-forooghian

Also I can run the PushExample on visionOS simulator (see 2045-visionOS-research branch) without installing Carthage dependencies, but creating tests target for visionOS requires it.

[lawrence-forooghian]

Not sure I understand why you talk about "visionOS targets", what's the significance of "target" there? From the second screenshot you posted it seems that visionOS is supported by Nimble, no?

And then, if we weren't able to build our visionOS test dependencies using Carthage, is there some other mechanism by which our tests could get hold of the dependencies? For example, by telling the Xcode project to get its dependencies from SPM instead of from Carthage?

[maratal]

Not sure I understand why you talk about "visionOS targets", what's the significance of "target" there? From the second screenshot you posted it seems that visionOS is supported by Nimble, no?

I've meant that I have an idea how to get rid of errors on screenshot 1 for delta-codec-cocoa and msgpack-objective-C. I haven't tried yet, but I think errors will be gone if I add visionOS target there similar to other targets of those two projects. But in case of Nimble it's not clear for me why Carthage can't figure out that it supports visionOS because it does so for iOS, macOS and tvOS already.

[maratal]

And then, if we weren't able to build our visionOS test dependencies using Carthage, is there some other mechanism by which our tests could get hold of the dependencies? For example, by telling the Xcode project to get its dependencies from SPM instead of from Carthage?

Will look into https://github.com/ably/ably-cocoa/issues/2034

[lawrence-forooghian]

Will look into https://github.com/ably/ably-cocoa/issues/2034

Switching to using SPM for running tests is, I think, a big task. My question was whether we could continue to use the Xcode project for now but tell it to get its dependencies using SPM (this seems like less work, and would be a good step on the road to #2034).

[lawrence-forooghian]

@maratal I did an example of this for you: https://github.com/ably/ably-cocoa/tree/xcode-proj-dependencies-from-SPM

There's an issue due to Nimble's deployment target being iOS 13 but ours being iOS 10, will let you think about what we could do about that

[lawrence-forooghian]

(There's also the option of getting rid of Nimble, we've had an issue for that for a while: https://github.com/ably/ably-cocoa/issues/1577)

[maratal]

@maratal I did an example of this for you: https://github.com/ably/ably-cocoa/tree/xcode-proj-dependencies-from-SPM

There's an issue due to Nimble's deployment target being iOS 13 but ours being iOS 10, will let you think about what we could do about that

Thanks Lawrence, looks like something that should be done for a while.

(There's also the option of getting rid of Nimble, we've had an issue for that for a while: #1577)

Good idea, will start working on it then (there are a lot of Nimble assertions though).

[lawrence-forooghian]

@maratal a couple of thoughts on this, just so as not to send you down the wrong path:

• Whilst I wholeheartedly am behind us getting rid of Nimble, I don't think we should make the current issue dependent on doing so unless we really have no choice. It might be that we can address the deployment target issue I mentioned in https://github.com/ably/ably-cocoa/issues/2045#issuecomment-2813883996 by doing something as simple as increasing the deployment target of our Xcode test targets.
• I think that before going ahead with a change like 1e8e2f0bb36f1ae8f02353b05f868469f2c83fce (getting the non-testing dependencies from SPM instead of Carthage), you need to check whether this will break anything for people who install ably-cocoa using Carthage. Depending on this, it might be best only to apply this change for new platforms for which we don't intend to support Carthage (i.e. visionOS).

[jhgroenjes]

Following...

[maratal]

* you need to check whether this will break anything for people who install ably-cocoa using Carthage. Depending on this, it might be best only to apply this change for new platforms for which we don't intend to support Carthage (i.e. visionOS).

It breaks "a bit", two versions of dependency classes ended up in the bundle which causes runtime warnings:

So I've proceeded with the second option - using SPM only for visionOS and tests which works, but for that we will need to rewrite ARTOSReachability and ARTSRPinningSecurityPolicy which can't be compiled under visionOS. Also the new CI workflow can't find Ably-visionOS for some reason (fastlane works fine locally for me), so if you have any ideas I would appreciate.

So to answer the initial question for this task "to get a better idea of how much work it would be to add visionOS support" the answer would be to rewrite two classes and sort out CI job for the tests. wdyt @lawrence-forooghian @umair-ably

[lawrence-forooghian]

ARTSRPinningSecurityPolicy

I imagine this is something we can get rid of; we don't offer support for certificate pinning via the SDK's public API.

[lawrence-forooghian]

Also the new CI workflow can't find Ably-visionOS for some reason (fastlane works fine locally for me), so if you have any ideas I would appreciate.

I've pushed https://github.com/ably/ably-cocoa/pull/2050/commits/0ee75ea83fe927bf585f357101e27481b90cf8c5 to your branch, which fixes it not being able to find the scheme. There's an error re not being able to find simulator, will leave that to you to look into.

[maratal]

I've pushed 0ee75ea to your branch, which fixes it not being able to find the scheme. There's an error re not being able to find simulator, will leave that to you to look into.

Thanks, wasn't expecting that from Xcode.

[maratal]

It works now https://github.com/ably/ably-cocoa/actions/runs/14605835033/job/40974535750?pr=2050

[lawrence-forooghian]

@maratal you said that we'd need to rewrite ARTOSReachability because it doesn't compile on visionOS. Please could you:

• explain why it doesn't compile? does it rely on something that's been removed from the Apple SDK? (I remember seeing something at some point saying that reachability is deprecated)
• look into what we'd need to replace it with (I assume something from the Network framework)
• try to get an idea of the effort required to replace it? is it possible to write a drop-in replacement or do we require a broader rethink of how we handle Internet connectivity?

[maratal]

@maratal you said that we'd need to rewrite ARTOSReachability because it doesn't compile on visionOS. Please could you:

* explain why it doesn't compile? does it rely on something that's been removed from the Apple SDK? (I remember seeing something at some point saying that reachability is deprecated)

* look into what we'd need to replace it with (I assume something from the `Network` framework)

* try to get an idea of the effort required to replace it? is it possible to write a drop-in replacement or do we require a broader rethink of how we handle Internet connectivity?

Yes, it says it was deprecated in visionOS 1.1 and also gives this suggestion:

Replace 'SCNetworkReachabilityCreateWithName' with 'Use URLSession or NWConnection to create connections that dynamically handle changing networks. Use NWPathMonitor to enumerate available network interfaces.'

So yeah, I believe there is no easy replacement for our ARTOSReachability implementation.