The apps I'm most familiar with that do this are associated with Ubiquiti networking equipment, and those apps draw the network client data directly from the access points, in conjunction with the associated switch topology, combined with camera- and LIDAR-based room scanning. Apple exited the Wi-Fi router and access point business a while back, so you'll want to look into whatever is available from your particular mix of vendors' routers, APs, and switches. That's probably going to involve some mix of SNMP, ICMP, CDP, OSPF, and BGP, among other protocols. Other options seem to include SolarWinds Network Topology Mapper, or such. Pretty much any mid- or upper-range networking equipment vendor will have some options available for network mapping, too.

Chat with your manager about this. Why that chat? In many organizations, IT security would be minimally inclined to coach, or discipline, or potentially fire employees involved in misuse of the organization's computing resources. A built-in means to lock macOS involves a token-based login and a card reader: https://support.apple.com/guide/deployment/use-a-smart-card-on-mac-depc705651a9/web I would generally not suggest starting out with a problem related to IT security as your first project learning about development on macOS or Apple platforms. Apple has some intro material here: https://developer.apple.com/learn/curriculum/

For testing purposes, connecting via wired to a managed switch and mirroring the switchport is probably the easiest approach. With that, you can see all of the packet departures and without involving the host software or apps. Within macOS, it's probably possible to use pfctl for this logging if not also for port mirroring, but I don't have a way to test either right now. pfctl manages one of the macOS firewalls, so it's good at blocking stuff. Related: https://krypted.com/mac-security/a-cheat-sheet-for-using-pf-in-os-x-lion-and-up/ https://www.openbsdhandbook.com/pf/logging/

You've not told us which Mac, but no Mac models from 2015 can run current macOS 13 software, which means no app submissions and older tools. What roadblocks are being encountered, too? Cross-platform is always a hassle, too—and the cross-platform frameworks can simply move your app dependencies from the platform vendor to the cross-platform vendors, and the cross-platform vendors are always chasing all of the platform vendors. More generally, I'd start with a macOS upgrade to macOS 13 and to Xcode 14.3.1, which will provide the most recent set of roadblocks available. 😜 This upgrade will require a newer or new Mac. If purchasing newer and not new, stay within this list of Mac models. For this case, I'd avoid running any macOS or app or tool betas when learning and establishing your environment and apps, and particularly when a spare Mac is unavailable for testing. As experience is gained, and as a need to test apps for upcoming releases is acquired, then betas become more interesting. Any M1 or M2 will be fast enough for development, though I'd go for at least 16 GB, and preferably more SSD storage than you think you'll need as neither of those are expandable over the usable lifetime of the Mac. Probably the biggest difference among the M1, M1 Pro, M1 Max, M1 Ultra, M2, ... etc., processors (for most developers) is the number of displays supported, though there are other limits. The low-end processors support at most two displays, one of which is always the internal for laptops. Whether Mac desktop or Mac laptop is entirely your choice. I prefer bigger (and variously more) displays, and don't need to or want to develop apps while mobile (and thus can avoid the mobile-focused pricing and features and I/O ports tradeoffs involved), so Mac mini and Studio are locally the more interesting models for development. If you're mobile-focused, MacBook Pro is the usual choice. As for tooling, I tend to stay with Swift Packages, Homebrew, and Apple distributions, and Python from the distribution and not the package managers. I typically don't use npm, so there's that.

I see two issues with the app, based on what was posted. Fix your app code to show a message indicating the problem—"Due to [reasons], this app is only available within Belgium. For more information, please visit http://support.example.com" or some such message—when this case arises. Not partial or empty (white) views. The Apple reviewers are not going to be the only folks encountering this case with (presumably) IP country lookup, and y'all probably don't want to take all those support calls for un-obvious ip geolocation issues. You will also want to provide a path for the app review folks that bypasses the geolocation country check, such as a dedicated testing login. That testing login can't spend "real" money, but is otherwise identical to a real login. Maybe also a second testing login for Apple that does not bypass the country check, so they can verify that check. The logins can be enabled while the app is in Apple review, and disabled when not. I would not expect Apple to want or need to set up a VPN to test your app. I mean, they might, but I would not expect that of app review. That's something I'd consider to be part of my job as the app developer, not the least of which because I too am going to need to test all that.

Erase and reinstall macOS 13. Or erase and restore your pre-beta backup. If you have no pre-beta backups available, and if this Mac contains data that you need, there are no good paths available. There are not now and never have been macOS downgrades. You can stay on the beta, or can backup and erase and load macOS 13, and then manually copy over those files from the backup that were not modified by the beta.

Your usual options here are a maintaining an Intel Mac that will run Xcode 10.1, or an Intel Mac with a macOS version that will run Xcode 10.1 installed as a guest in a virtual machine, or moving support to "best effort with no rebuilds", or retiring and removing support for the older apps.

Yes; you need precise location. That entitlement and that permission gets you SSID and BSSID, and those are accurate and unique values. Or in short, yes, list precise location. It's axiomatic: you need to have precise location to use the API (text swiped from another reply): * @method fetchCurrentWithCompletionHandler:completionHandler: * @discussion This method returns SSID and BSSID of the current Wi-Fi network when the * requesting application meets one of following 4 requirements -. * 1. application is using CoreLocation API and has user's authorization to access precise location. * 2. application has used NEHotspotConfiguration API to configure the current Wi-Fi network. * 3. application has active VPN configurations installed. * 4. application has active NEDNSSettingsManager configuration installed. * An application will receive nil if it fails to meet any of the above 4 requirements. * An application will receive nil if does not have the "com.apple.developer.networking.wifi-info" entitlement.

Same issue with the Apple SwiftUI AboutMe example, also on macOS 13.4.1 Intel with Xcode 14.3.1. /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/libexec/promotedcontentd Is crashing with EXC_BAD_INSTRUCTION (SIGILL) And I'm not (intentionally) blocking that iadsdk.apple.com domain. A traceroute to the iadsdk.apple.com host is not working, too. Seems a routing issue lurks somewhere. Gets to the edge of my ISP's network and ICMP timeouts with 200+ ms delays. Mostly for grins, I've added an A record into local DNS for iadsdk.apple.com zone and host (to 127.0.0.1, 5 minute TTL), just to see if that reduces the crashing. So far, I'm not seeing the repeating crashes.

There's never been a downgrade. This whether reverting from a beta or reverting from an update or upgrade to a released macOS. Restore your pre-Sonoma backup. If you don't have a backup, reverting means you're left to wipe and reload Ventura and start over, or wipe and reload Ventura and pull across just the apps and documents that haven't been modified. Testing on any computer you need to work, with any data you need available and consistent, and with any Apple ID and its associated iCloud data you need available and consistent... is not recommended.

macOS does have a setting to disable debugging: https://developer.apple.com/library/archive/qa/qa1361/_index.html (and which itself can be circumvented) and does offer hardened run-time: https://developer.apple.com/documentation/security/hardened_runtime If you're already using that and want "more"... There are papers and write-ups on reverse-engineering and anti-reverse-engineeringposted around the 'net. Some folks will use a licensing dongle, whether USB or NFC or otherwise. Some vendors will use a support-based licensing scheme, and which requires periodic contact with servers you control. If the crack is loading exploit code at run-time (and somehow the hardened run-time isn't an option or isn't working for your case), you could submit known-bad license keys from various spots in the code (after the first "real" check, and fail (and preferably failing well after the good and bad checks, and preferably failing with an obscure run-time error selected from a list of reserved-for-cracks error codes, and with a request for the user to contact your support organization) when a bad license check succeeds. Various ways to build on this, too. You could have your legal folks have a discussion with the GitHub legal folks too, but the code will move elsewhere. But if your servers are down when an online registration happens, or when your copy-protection mis-triggers, legitimate customers will be cranky. Cracks will always exist, and expending time and effort thwarting those is, unfortunately, wasted effort. And effort that can cause paying customers to be prevented from accessing your app. For some background on past cracks, look up the history of a pre-Y2K crack known as DeCSS.

Is persistence possible? Sure. Is persistence likely? No. Persistence is a very expensive exploit, per published exploit pricing. Existing malware has tended to re-infect, and not persist, per available reports. Most of the reported security shenanigans involve passcode and password compromises, and down-revision devices and down-revision iOS, and similar. Usually not iOS or app compromises. If you are a target of a very well-funded entity and one with access to the exploit tooling you're concerned about here, you'll want to acquire tailored help for your particular situation, risks, and security requirements. For what Apple suggests doing: https://support.apple.com/guide/personal-safety/welcome/web (There's a PDF at the bottom of that webpage.)

Have a look at callable cURL as a potential option. https://curl.se The command converter tool might be helpful in stitching together the code, too. https://curlconverter.com/swift/ More common would be HTTPS transfers via REST (and not file transfers via ssh as sftp does); whether using Alamofire or otherwise. Depending on your deployment environments, also make sure TCP 22 is going to be open, too. Some environments block that sort of thing.

OpenGL support was retired back around macOS 10.14. Various of the GL support was retired back around OS X 10.9, and GLUT (OpenGL Utility Toolkit) was then used. How much code-level work do you want to do here? You can try setting your deployment target version back in Xcode. Maybe that gets you working? Or can make some code changes: maybe one or the other of the following helps pick up the necessary GL definitions: #include <GLUT/glut.h> #include <OpenGL/gl.h>

Maybe try the NSProcessInfo property operatingSystemVersion? That returns NSIntegers for majorVersion, minorVersion, and patchVersion. I don't have an easy way to test the patchVersion update; to see when (if?) that gets incremented.