Update your Mac to macOS 12.6 (macOS Monterey current) and try again? Failing that, update Xcode to Xcode 14 (current), and try again?

Try a Time Machine restore of the Keychain files in ~/Library/Keychains and restoring those into different filenames for access? More likely to work: restore your entire Mac from your Time Machine backup immediately prior to the errant deletions.

There isn't one best, as different folks have different requirements. Weight, screen size, numbers of I/O connections, etc. Visit an Apple Store. See the alternatives for yourself. For web development... Review the recommended configurations for whatever Web development apps and frameworks you prefer. If you're editing HTML and JavaScript in vim or emacs, you won't need a fast Mac. if you're using some more complex process, you'll need to account for those apps and requirements and likely increases over time. As for app development... Xcode requires lots of memory. 16 is minimal for that, and—with occasional exceptions—I'd expect Xcode memory and storage requirements will increase over time. If you're working on larger web or larger app development projects, you may or will want a larger internal display, or a connection to a larger external display. Budget for at least one external HDD of 4 to 6 TB for backups. You might want or need an external keyboard, mouse or trackpad, maybe a spare cable and charger for a second location where you might routinely also work, USB-C to USB-A adapters or a dock, a satchel or messenger bag or other carrying case, or other add-on gear in addition to the external backup storage. For Mac with Apple silicon more generally: minimally 16 GB memory and as much internal storage as you can afford, as neither can be increased over the lifetime of any portable Mac Apple is currently selling. And if you don't absolutely need mobility with your Mac, the desktop Macs can be a better value—I've worked with various folks that wanted and bought portables, but always used them on the same desk.

If there is an Open button shown, that usually means that the version of that app is already downloaded. It might not be stored in Applications. What Xcode version do you get when you tap Open?

To rephrase the above (correct) reply... TCP is a stream service, and not a datagram service. There is no correlation between the numbers of writes and the numbers of reads performed, just in the total volume of data transferred. Or you can get a network error when the transfer fails to complete, of course. Receiving an incoming kilobyte-sized transfer in one read, or obtaining that same arriving kilobyte data in a thousand single-byte reads, or anything between those two, are all equally valid and all possible. Your apps are responsible for finding the beginning and the end of your data in the stream. This includes potentially reading and receiving part of some subsequent kilobyte-sized hunk of data also arriving at the end of one of your previous reads, if you allowed enough room in your read for that data. Again, do not think of records or datagrams or numbers of reads and writes here. Not with TCP. Not with TLS, for that matter. As for servers receiving HTTP or HTTPS (slowly), there are attacks that leverage similar behaviors. Slowloris is an example.

You're seemingly headed for what is known as mandatory access controls with compartmentation; a trusted execution environment. Mandatory controls do get expensive to build and operate, and mandatory controls are gnarly to manage, too. And macOS doesn't particularly support mandatory controls for user apps, and particularly not after Xcode 9 and macOS High Sierra and TrustedBSD. The usual response to these requirements is multiple "system high" Macs, or maybe multiple guests in a VM if your local security policy allows that. Which also gets expensive, but less so. All as you seem to be aware. If you really need this isolation for your apps, then SELinux might interest. Intel tried providing something similar to your requirements with SGX, but has seemingly largely given up on this outside of servers. Apple doesn't offer anything similar to third-party developers. PS: For low-level information on macOS, the set of books comprising the New OSX Book might interest. PPS: You'll likely need to discuss these requirements with the folks managing the content filter and endpoint security on this Mac.

Data sent over an IP network uses IP packets. Only. If I ignore the (confusing to me) TCP and UDP phrasing you’ve used here, I’d consider an IP tunnel (usually TLS wrapped, maybe using GRE or stunnel, etc) connection, or creating a custom protocol router that extracts the app data and forwards that via TLS (stream) or DTLS (datagram). The former tunnel wraps (encapsulates) the existing IP traffic, the latter router preferably sends only the app data. The choice of stream or datagram depends on the details of the LAN-local (Bluetooth) data. If the data is status data and periodic updates and some can (rarely) be lost (read: datagram), then UDP or (preferably, secure) DTLS. If some of the data can’t be dropped (read: stream), then TCP or QUIC or (preferably, secure) TLS.

If you’re asking whether Core Data is a good choice for a local object persistence across platforms, no. If you’re looking for remote data or object persistence, S3, Firebase, and other options exist. There are frameworks such as Parse that avoid being tied into one backend hosting vendor, as well. Programming language choices and local or backend data storage choices all factor into these decisions.

Please post a standalone reproducer for the syntax problem; there seems to be some code missing. Please also use the code-block tags to avoid formatting errors when posting the reproducer here.

Per WWDC videos and per what Apple has posted (e.g. “SwiftUI previews are immediately interactive”), the Xcode 14 beta might interest.

I'd suggest using your own real and registered domain, or using a subdomain of a real and registered domain of yours. Making up bogus TLDs is getting tougher by the day too, with the thousands of new TLDs ICANN has been adding in recent years. For this case, I'd suggest avoiding re-use of an RFC-reserved domain, as getting creative with .local (e.g. ali.ourseventh.local) tends not to end well. Leave all of .local to mDNS. Using your own domain or subdomain, set up your own authoritative DNS server, set up DHCP for your local client MAC addresses or (workable, but less desirable) set up static addresses on the clients, and allocate consistent IP addresses for hosts with certificates. Then load and trust your private root public certificate onto each client, and load your leaf certificates onto the servers.

Start here: Revive or restore a Mac with Apple silicon using Apple Configurator: https://support.apple.com/guide/apple-configurator-mac/revive-or-restore-a-mac-with-apple-silicon-apdd5f3c75ad/mac

Network Framework? Don't think that'll work. ICMP is too far down the network stack. You're probably for CFSockets, as described here: https://www.rderik.com/blog/building-a-server-client-aplication-using-apple-s-network-framework/ Some related information and apps: https://pwhois.org/lft/ https://dublin-traceroute.net https://developer.apple.com/support/prepare-your-network-for-icloud-private-relay

In years past, the answer to this was no. Admins had access to chats. For details, there's a StackOverflow 2018 thread entitled End to end encryption with Firestore with some background. More generally, if you're not prepared to be subpoenaed into some court or committee somewhere to defend your answer and your implementation should things go sideways, then "no" is the safest answer. That, or check with your local legal staff, if you have one. Rather than Telegram or WhatsApp, Signal would likely be the most likely comparison. Telegram didn't (and may still not) default to encrypted 1:1 chats, unless the user selected the "secure chat" setting. See page 177 and following for Apple's answer for iMessage, and the considerations cited by Apple: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf

Among other sources: https://formulae.brew.sh/formula/tcptraceroute#default