DropBox began as a nice way to provide sync services between iOS and Mac OS platforms before there was a capable native solution from Apple. As Apple’s own iCloud sync service has improved, however, supporting two services that accomplish identical purposes has proven to be awkward. We are therefore halting support for DropBox for these reasons:
We spend a not-insignificant amount of time troubleshooting DropBox issues for our customers.
Previously, integrating DropBox was as simple as including their library and adding some “glue” code to our project. Apple’s recent move to Apple Silicon on Mac OS X, however, means the old DropBox package no longer works. Recompiling the DropBox frameworks for our project now requires drastic changes to our project hierarchy as DropBox no longer provides a simple plug-and-play solution but rather asks developers to download their source-code and compile it separately using 3rd party code management tools that must also be integrated into the main project. This is invasive, time-consuming and error-prone.
Apple has now enabled iCloud support for apps that are not distributed via the App Store. This enables robust sync support for all of our products on every supported platform without additional 3rd parties.
There are 65535 possible ports. The only way to know which ones are open is to send requests and parse the answer. Depending on the network, the response can arrive quickly or not. If it takes too long for a response, the scanner may specify a time-out duration at which point the port is simply deemed closed.
“Fast” port-scanners either have a ridiculously short time-out, only scan common ports, or both. We take a pragmatic approach, which means we scan common ports first and display those results right away. Then we have a thorough sweep across the entire port range specified (use configurable). This takes time if the targeted device has a network interface configuration which does not respond immediately to portscan probes.
Since iOS 13, Apple has disallowed developers from obtaining the name of the currently connected Wifi network unless the user has explicitly opted-in to location sharing. While these two elements may seem unrelated, they are part of a greater push to preserve your privacy.
We don’t need to actually know where you are to run IP Scanner but we are obliged to request access to this information in order to read the name of your connected Wifi network. This is in turn essential for saving custom devices names and badges.
It is possible to run IP Scanner without this access, but the scan results are limited to our educated guesses about the nature of the scanned devices and you cannot fix or reassign names and badges.
With iOS 11, Apple has radically reduced access to underlying Unix routines that many networking apps rely on. As many of you have already noticed, it is no longer possible to obtain MAC address on iOS 11. Many folks have already detailed the problem in depth (e.g., https://netanalyzer.helpscoutdocs.com/article/119-mac-addresses-arent-available-under-ios-11) so we won’t go into all the ramifications here.
The one silver lining here is that the entire dev community is working with Apple to try to find a solution and as soon as one is found we will update IP Scanner to take advantage of it.
In the interim, we are in the privileged position of being multi-platform and have therefore implemented a way to transfer discovered MAC addresses from the Mac OS version of IP Scanner over to the iOS version, either through a direct data dump, or incrementally using iCloud sync.
To take advantage of this process, you can use any version of IP Scanner for the Mac. Launch the Mac app, then launch the iOS app. Look for the import option in the Scanner Tools.