Nearby-Sharing-Mac
Issue to track the development of this app for macOS
There’s no ETA yet, but I definitely plan to port to different platforms in the future!
I’m currently building a custom cross-platform implementation with c# (See main branch).
For a rough schedule:
- nearby-sharing/android#8
- nearby-sharing/android#21
- Other platforms!!
Persistently wait for the macOS version as well (smile) But literally take your time, gentleman, I have got used to the cleavage of android and macOS, quite hoping there is an unique way to send and receive between win and macOS and android
There is Soduto and KDE Connect which works perfectly. For M1, you could check some of the forks.
That being said, I'm hoping this project builds up to being a modern alternative to KDE Connect platform which I believe (could be wrong) uses older stuff.
I really appreciate your ideas and trust in this project, but you have to think of a view things:
- I’m doing this on my own in my free time
- This project is meant to bring the Windows 10 / 11 “Nearby Sharing” component to other platforms (mainly Android!)
- I’m going to stick to the Microsoft Specs of the underlying protocol of the “Connected Devices Platform”
- I neither have a Mac nor do I have experience developing for Apple platforms
This means that…
- I would need someone with experience with Mac / iOS and .Net / c# to do development and testing with / for me
- In the near future only file / url transfer will be possible
The CDP provides additional capabilities we can and (hopefully) will use, but for now I have to finish the Android implementation. That does not mean it won’t happen, but rather that I need help and time…
I'm currently trying to apply for the Macstadium open source program but that seems to be on hold for now...
There is now a working cross-platform implementation of the Ms-NearShare Protocol in the master branch.
From here I "just" need someone who would like to create a UI and basic Bluetooth-PAL implementation for MAC using Xamarin.Mac (or MAUI if you can get Rfcomm to work with MacCatalyst)
I am unable to help you with development on macOS but I can for sure test things.
I'll also suggest you to build this app as a Menu Bar app for macOS which is the right place for utility kinds of apps. AFAIK, it's also easier to do Menu Bar apps for macOS.
Also, I use Android.
Mac support will initially only come as a cross-platform cli (In this new repo). This is still work in progress and will only support network transport for now (no bluetooth).
You can now test a very early version for mac / linux: https://cdn.shortdev.de/NearShare/macos/NearShare https://cdn.shortdev.de/NearShare/linux/NearShare
Warning
It's a cli so you have to run it from the terminal!
Can't be discovered yet from the phone.
@electr1fy0 There is currently no Bluetooth support. Make sure that you use the preview version on your phone and that both devices are on the same network.
Yes, they are on the same Wi-Fi.
@electr1fy0
- You can't send from Windows to Cli, because Windows does not advertise via Udp (it only discovers)
- Only the latest beta version does advertise via Udp.
I was trying to send from Android to macOS
@electr1fy0
- You can't send from Windows to Cli, because Windows does not advertise via Udp (it only discovers)
- Only the latest beta version does advertise via Udp.
@ShortDevelopment is not being able to send from Windows to Cli a temporary thing or is that just not possible ? I see that the android app can receive from Windows in Receive mode so not sure if I understand why the cli can't receive too.
The MS-CDP protocol is transport agnostic and supports (non-exhaustive) Tcp (Network) and Rfcomm (Bluetooth Classic).
The CLI currently only supports Tcp because a TcpListener is directly build into .NET and Tcp is available on all platforms.
As the Windows implementation (controlled by Microsoft) does not advertise itself via Udp (Network), the cli cannot receive from Windows.
This could be fixed by implementing a cross-platform Rfcomm (Bluetooth classic) transport into the cli.
Rfcomm is supported by Windows, Linux, Android and MacOs but not by iOS.
So someone has to write an implementation for Rfcomm and Ble (For advertisement) for every platform.
Maybe, we could use inthehand/32feet for that.
But I still don't (and won't) have a Mac for testing.
=> For most platforms, this is just a temporary issue.
ah got it, thanks for the explanation! I have been looking for some cross platform p2p over network file sharing solution that can be supported seamlessly across all platforms (I am not looking at iOS though, given how restrictive and closed down it is). Nearby Share by Google (now Quick Share) was a good candidate with OSS implementations for Linux and macOS, but it can never support sending from macOS due to the macOS BLE api lacking, if Nearby Sharing will not have this limitation then this would be the ideal candidate for a good cross platform solution.
I fear we got the same problem here ... I'll further investigate this.
For reference: https://github.com/grishka/NearDrop/issues/91
that's not good :/ But looks like Google's Nearby Share is preparing to work around this limitation, wasn't aware of that development, thanks for sharing the link :+1:
@electr1fy0
Can't be discovered yet from the phone.
Sry, that it took so long. There was an issue with the size of the PresenceResponse message (I tagged you in the issue).
You sould be able to use the same link I provided above to download a working version.
I got it to work with a MacOS-VM and my Android phone.
Still no windows receive support though...
I finally created an official release of the cli (linux and macos).
Further plans
The cli will not get bluetooth support.
Linux
There's a wip app for linux in a separate repo that already has some bluetooth support and hopefully will get WiFi-Direct support after the android app has support for it.
MacOs
MacOs will be partially supported via the cli for now (Local-Network only). In the future we might implement bluetooth support via IOBluetooth.
iOS
For now, no iOS support is planned as the user experience whould be bad due to not supported transport technologies (Rfcomm, SDP, WiFi-Direct)
Contributions
If someone is interested in contributing to the cli, linux app or a potential macos app please reach out to me!