Post not yet marked as solved
Per WWDC videos and per what Apple has posted (e.g. “SwiftUI previews are immediately interactive”), the Xcode 14 beta might interest.
Post not yet marked as solved
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.
Post not yet marked as solved
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
Post not yet marked as solved
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
Post not yet marked as solved
Among other sources: https://formulae.brew.sh/formula/tcptraceroute#default
Post not yet marked as solved
FTP is older than IP. Yes, really. It's that old.
FTP severely allergic to firewalls and modern networks, and leaks credentials in cleartext. Firewalls have to sniff the FTP traffic to permit FTP to pass the firewall. And many firewalls just block FTP traffic.
If you're not using those FTP credentials (and since you're using FTP, the credentials are just going to leak), see if using HTTPS and UnityWebRequest works for your needs...
https://docs.unity3d.com/ScriptReference/Networking.UnityWebRequest.html
Post not yet marked as solved
Different hypervisor / virtualization vendors have different requirements, different storage formats, different expectations, and use very different paravirtualization schemes.
Virtualization Framework means the vendors can potentially avoid tying into the hardware directly, and quite possibly also conflicting with each other and with macOS.
VF means better abstractions both for the hypervisor vendors, and better flexibility for Apple. The hypervisors apps don't need quite as many details of lower-level processor hardware implementations. Apple then has opportunities around implementing lower-level and architectural changes, while disrupting fewer apps and vendors.
VF may mean the ability to dedicate parts of the hardware run-time environment to a specific app and its timing and resource requirements, dedicating virtual cores, rather than sharing cores and scheduling. This might provide a resource-intensive or latency-sensitive app with better timing, and interfering less with the rest of macOS.
VF also provides a path for vendors to reduce or eliminate kernel code, and which has been a long-time security and stability and control goal for Apple.
TL;DR: it makes hypervisors into something closer to standard apps, and rather further from hunks of the kernel written by others.
Post not yet marked as solved
Re-code the app to contend with what can and variously will happen here; that the app can quite possibly be suspended and resumed.
That re-coding might involve storing the data locally and/or queuing an event for later, or contacting a remote server and logging / tracking the activity there.
And as for your questions, no, and no.
https://developer.apple.com/documentation/uikit/app_and_environment/scenes/preparing_your_ui_to_run_in_the_background/about_the_background_execution_sequence
https://developer.apple.com/documentation/uikit/app_and_environment/scenes/preparing_your_ui_to_run_in_the_background/extending_your_app_s_background_execution_time
Post not yet marked as solved
This is centrally your decision. Considering this support question more generally, I’d be inclined to pick a smaller subset of (newer) that can be tested and supported and that can run your app with adequate performance and features, and then expand that list over time as warranted.
If you decide to support them, you’ll want to test with older and smaller (and slower) iPhone models, just so you know what your app looks like on those.
iOS 13, iOS 14, and iOS 15 do require iPhone 6s and newer. The features available with iOS 13, iOS 14, and iOS 15 further depend on the particular iPhone model. Older iPhone models such as iPhone 6s—though supported—lack access to certain newer features of iOS 13, iOS 14, and iOS 15. For details on these older models and associated feature limits, scan these footnotes.
Though it’s entirely your call, I wouldn’t spend all that much time with iOS 13 and iOS 14 support (to start with), as those versions tend to be used by folks either with insufficient storage, or with lackluster update practices. Folks that can potentially be support problems awaiting, in other words.
As for other considerations you might not have pondered, maybe also iPad, and maybe what your app looks like on Mac M1—if you want to enable that for your app.
With the upcoming WWDC, we’ll likely know more about what Apple plans for iOS support for the various models.
Again, your call, and your trade-offs.
Post not yet marked as solved
It's listed as a beta. Apple uses that phrasing when they expect or when they know gremlins await. If you can figure out any pattern to your disconnective discontrol discombobulations, log a radar bug report with Apple with any reproducer and details and hardware involved.
Post not yet marked as solved
Emulating x86-64 system hardware and processor on an Apple silicon Arm AArch64 system hardware and processor, sufficient to boot an operating system?
From Apple? Absolutely not going to happen. Rosetta 2 does user-mode x86-64 emulation, uses calls macOS itself to run the macOS code, and is not full hardware emulation.
From QEMU or such, maybe, possibly, probably. This with the older operating system booted as a guest, with both virtualization and emulation active. Won't be speedy.
More generally, it's time to update or to replace or to retire your remaining x86-64-only apps, or to lock down your hardware and software plans and accrue the spare parts necessary to remain on an older version and older hardware for the foreseeable future for whatever now-older apps are in use here.
Post not yet marked as solved
If somebody is deliberately issuing a force-quit or a SIGKILL against a daemon or agent (which mostly or entirely lack a UI, and quite possibly operating "behind" XPC) and you need to prevent that force-quit or SIGKILL, there are seemingly bigger issues with the app design, or with the administration of the Mac.
Might you be writing either security-related code (malware scanner, etc), or maybe code that's caching data when it probably shouldn't (and thus also potentially vulnerable to ill-timed power outages)? Remediating those two situations goes in very different directions...
For anyone here unfamiliar with the, um, background: Technical Note TN2083: Daemons and Agents
Post not yet marked as solved
Sería mejor preguntarle a Microsoft:
https://answers.microsoft.com/en-us/msoffice/forum/msoffice_excel?sort=LastReplyDate&dir=Desc&tab=All&status=all&mod=&modAge=&advFil=&postedAfter=&postedBefore=&threadType=all&isFilterExpanded=false&page=1
And the other part of that question...
Apple documents manual code-signing using the codesign tool and the command line in the Code Signing Guide.
You'll become quite familiar with the tools referenced in that document, too.
As a potential alternative, Xcode can use external build scripts for whatever tools or languages are involved in your app.
