This is a desired behavior since Flash SMS has been abused to send marketing messages. Moreover, some telcos themselves are abusing these Flash SMS and use this method to send their own marketing messages.

This remains true as per Xcode 15.1 The folder "~/Library/Developer" needs to be a real folder, not a symlink to somewhere else.

You could have another copy of your app (and thus, extension) installed that is not built for debugging. The Photos app could have loaded that one instead of the one made by Xcode. In this case, you could temporarily move all other copies of your app to the Trash and re-launch Photos in Xcode to debug your app extension.

You should create a new Apple ID, ideally one that’s not associated to a person. Generate an App-Specific password using that new account. Finally invite the new Apple ID into the business account’s Apple Developer Program as a Developer role. Alternatively you could also create an API Key file and use that one for authentication. Search the web for “How to Securely Provide Apple ID Password into Notarization Build Jobs” for more details on using a dedicated Apple ID for notarization or creating and using an API key for that purpose (obviously I can’t link it here due to forum restrictions).

Have you raised a DTS? What was the conclusion?

What was the conclusion on this? Have you filed a bug? What is the policy on submitted notarization data? Confidentiality level of the submitted binaries (and disk images, which includes non-binaries). What is the data retention policy and duration? Is there a way to un-notarize a binary (i.e. remove copy on Apple’s servers) when there’s a need for that? (e.g. EU’s “right to forget” should a DMG contain data on a natural person, license expiration of contained photographs or clip-arts, etc)

What’s preventing you from separating out that user-specific slight difference out from the application bundle? That way you could notarize just one application bundle for all users.

Yes you can. Have the watchOS app embedded into the iOS app but only activated when the user has purchased the corresponding iAP from the iOS app. Examples of apps which does this includes Nano and 1Password. Search the web for “How to Sell watchOS Applications as an In-App Purchase” for more information.

How did it went? FWIW, you could send TestFlight copies to the complainant such that they could approve the resolution of the dispute before sending it for App Review.

Have you tried appealing to the Review Board? The appeal message could contain / reference the e-mail that you've sent to AppStoreNotices@apple.com (preferably attach copies of the e-mail and resolution reply, if any).

Open-source support for Apple Silicon is mainly held back by GCC’s (the GNU Compiler Collection) lack of support for the architecture. There are work progressing, but as with all open source, that would be in a “time available” basis. Likewise Docker support is progressing, but again there is no timeline. Moreover if you’re depending on x86 Docker images, you would likely need to wait longer for it to provide Intel emulation. Since Rosetta 2 does not support virtualizing x86 systems, Parallels and VMWare would also need to come up with their own emulation software to support running Intel operating systems on Apple Silicon hardware. If you really need to run x86 Docker images, a good alternative would be to buy an Intel Compute stick (a ~$100 USB-powered computer) and install Linux on it. Then you could ssh into the machine to do “Linux stuff” (including testing your server software) and run x86 Docker images. Yet keep most of your tools on the Mac. You could also set up a Terminal profile to run command-line software in “Intel mode” by default. This include gcc and most of Homebrew – until they natively support Apple Silicon. Search the web for “How to Run Legacy Command Line Apps on Apple Silicon“ to get instructions how to do this.

Apple hasn’t develop any publicly-available Fortran compiler to date, and there is no indication that would change. Furthermore lack of gcc (the GNU Compiler Collection) support for Apple Silicon seems to be holding back Fortran as well, since many open source Fortran project seems to depend on that. In any case, you could run gcc (and thus Fortran) under Rosetta 2. Many CPU-oriented Benchmarks has shown that the M1 already runs Intel apps faster than most portable Macs that came before it. Search the web for “How to Run Legacy Command Line Apps on Apple Silicon“ to set up a Terminal profile that runs Intel apps by default so that you can continue using Fortran in “Intel mode” until native support finally arrive.

The biggest hurdle for Data Science on Apple Silicon is gcc (the GNU Compiler Collection). The compiler hasn’t supported Apple’s ARM architecture (instruction set, calling convention, object format, etc) since an ancient version of iOS. Work on that is in progress, but as with all open-source efforts, there is “no timeline” since commitments are done on a “time-available” basis. Lack of GCC implies lack of FORTRAN support. The other notable FORTRAN compiler is Intel’s, and the latter is very unlikely to be ported to Apple Silicon. No FORTRAN also means a lot of numerical libraries are being held back (e.g. SciPy, BLAS, LAPACK, etc). In any case, you could probably run your data science workloads under Rosetta 2 (i.e. Intel emulation/translation). Geekbench has shown that the M1 processors are faster than many Mac portables that came before it, even when running Intel apps. Search the web for “How to Run Legacy Command Line Apps on Apple Silicon” to set up your Terminal sessions to prefer running Intel applications.

For the record (and now since M1 units are released), Thunderbolt 3 is supported but not eGPU. The M1 SOC does not support external graphics processors as of macOS 11.0. Moreover apparently the corresponding eGPU kernel extensions are present and installed in the operating system partition, but only compiled for Intel.

The problem is that you've submitted a pre-existing app as a new app. That would put a "this account is a spammer" flag on to your developer account. Once that mark is placed, is hard to get it removed. My suggestion would be: Remove the second app (which is stuck at "in-review" anyway). Do a competitor analysis and ensure that your app isn't similar to any pre-existing app nor it is a "saturated" app genre (such as horoscope apps). Update the first app with the new design / code / functionality. In first try, you would likely get rejected anyway regardless of what you uploaded. Then appeal to the App Store review board to get more senior members of the team to review your app. If it's really unique and worthy of the app store, you should get the update approved.