iOS (device+simulator) support?

[cyrille-legrand]

Hi there, I can't seem to find how to integrate this in an Xcode 11 project, targeting iOS 13, with SPM. Maybe it's related to CSSH declaring its providers as "brew" and "apt" only, but Xcode can't link the project to libssh2.
I tried building libssh for iOS (device + simulator) using github.com/Frugghi/iSSH2 but it gives me a .a instead of a .dylib and I am clueless as to how link this to CSSH and ultimately Shout.
Has anyone here had success building Shout for iOS?

[nocsi]

@cyrille-legrand we have a repo to generate static library libssh2.xcframework for iOS/maccatalyst and simulator @ https://github.com/nocsi/ngit-lib. So far it works fine if you use it as a drop-in for CSSH.

[jakeheis]

This lib is only built to work on macOS -- I'd love to see it work on iOS, but I'm not exactly sure what it would entail. If someone would like to look into this and make a PR, I'd gladly merge it in!

[cansurmeli]

Hey.

I actually would like to see this library on iOS! Currently, I'm developing an iOS application that should make use of SSH and build on top of it to interface with *nix systems to help manage them.

Also, it would be nice to indicate on the homepage with a badge that this library is macOS only. It took me a while to figure that out. 🙃

Thanks.

[mdelaney]

I recently managed to get this working on iOS. That said, it's still, well, a bit hacky. I might be able to clean this up and put it into a PR at some point in the near future, but no point making other wait if this can be useful :-P Here is what was needed

First, compile the libraries

Use https://github.com/Frugghi/iSSH2 to compile for the various architectures. This was a bit tricky to get working correctly. Simply doing something like ./iSSH2.sh --archs="arm64e arm64 x86_64" --platform=iphoneos --min-version=14.0 worked for me on Intel based macs; however, I still haven't been able to get this working on ARM based macs for the simulator (but running on physical devices worked quite well). The script wasn't built with ARM based macs in mind. The tricky bit there is that when you run lipo to consolidate the different architectures into a single library file it works great when you have x86_64 as the host architecture when running the simulator but on ARM based macs, well, this doesn't work as there is already an ARM64 library. I suspect the trick here is to have this bit be compiled as needed by xcode and using the relevant platform (simulator vs device) be injected on demand.

@jakeheis - not sure how you feel about this, but maybe it could be possible to have such an auxiliary script to download and compile libssh and openssl bundled with this package? I saw a PR to include a 3rd party pre-compiled library, this may be a more transparent/secure option. Maybe there is a more idiomatic way of doing this with Swift? (I may end up spending some time digging into this at some point, happy to contribute any findings or PR if I do this)

Second, modify Shout

This bit is more straightforward and maybe can be cleaned up by someone more familiar with Swift than me :)

In module.modulemap, link to openssl's crypto library

  link "crypto"

Now, for the ugly part (maybe someone more familiar with xcode and swift can clean this up). I can't get xcode to locate the headers for libssh2, so I end up converting the #include statements to "user" includes with the absolute path to the headers instead of "system" includes. Like the following:

#include "/Users/someuser/blablabla/libssh2/include/libssh2.h"
#include "/Users/someuser/blablabla/libssh2/include/libssh2_sftp.h"
#include "/Users/someuser/blablabla/libssh2/include/libssh2_publickey.h"

(yea, I've tried setting the header search paths in Build Settings but it seems to be ignored here, no clue why)

Now, to make this work in your xcode project....

Set the Library Search Paths for your various targets to the compiled libraries generated by the first step above. It's worth pointing out, if this is a universal app with a macOS and iOS target you will need different library search paths for each target as they would be compiled differently.

Last, make sure you're linking with zlib. Again, as a Swift and xcode newbie, I'm sure there is a better way to do this... buuut, simply include zlib

import zlib

If you fail to do this, you'll see 6 or so compression related symbols that aren't able to be resolved.