I've downloaded the CRT Creator through the TestFlight link from its website. It has potential, although frankly I found it very hard to use, hence not very useful as an "app".You should have an introduction in the app of what is a CRT - a short 1-3 screen "welcome" dialog that is showed automatically at first run (only) and subsequently accessible through a menu or button buried somewhere deep within the app.It's also not clear on how to link one node to the next, in order to create something like the example CRT that you've provided. Furthermore I can't seem to unlink nodes - even when I did the same gesture to link one node to the other (i.e tapping one node and then tapping another).You might want to take cue from mind-mapping apps like MindNode or Scapple and see how they present the interface to the user.For example, you could try having a drag gesture from one node to another to link it, and the same drag gesture would break an existing link between two nodes. You could also provide an option in the node detail to link the node to another – would probably be useful for a larger CRT.Also you could provide import/export - maybe even print functionality (which is essentially export to PDF for iOS' AirPrint).Again, mind-mapping and diagramming tools are valid cases of an "app" and I see yours as a special case of "highly structured diagramming tool" – it's just a matter of making it easier for the user to create and maintain such diagrams and convincing App Review of its value.You might want to review this guide which may provide some further idea to extend your app further.

You could ask your own UIKit components to display the action sheet.Use view controller containment to enclose your SwiftUI view. Have your own UIViewController subclass to enclose SwiftUI's view controller. In turn, have a property in the SwiftUI struct that is a closure that gets called to invoke the action sheet. Finally, initialize this closure from the enclosing UIViewController subclass to display that action sheet – in the closure you should have easy access to a UIView instance.

Is the time delay (e.g. 100 milliseconds) really necessary? Would just re-setting the "real" value of the array in the next run loop cycle be sufficient?

The problem is that WKWebView can't do anything until the view is properly loaded and initialized. You might want to move the "load..." call into a Dispatch.async... call. That way it'll be called after the web view has been returned (and hopefully has been initialized).Here is a quick playground example.import SwiftUI import WebKit import PlaygroundSupport struct WebView: UIViewRepresentable { func makeUIView(context: UIViewRepresentableContext<WebView>) -> WKWebView { let view = WKWebView() DispatchQueue.main.async { let url = URL(string:"https://example.com")! let request = URLRequest(url: url) view.load(request) } return view } func updateUIView(_ uiView: WKWebView, context: UIViewRepresentableContext<WebView>) { // } typealias UIViewType = WKWebView } struct ContentView : View { var body: some View { WebView() } } // Present the view controller in the Live View window PlaygroundPage.current.liveView = UIHostingController(rootView: ContentView())

The desired intent is to normalize any CGImage into an RGB24 vImage buffer. I have no control on the source image format, and hence couldn't use the vImageConvert_xxxx without going through hoops.

Yes I saw that tutorial before.The point I was trying to make is that the code snippet works fine for JPEG, PNG, and some other image files. However when it came to HEIF it failed.

You need to make the app provide functionalities that goes beyond a progressive web application can do.Some ideas include:Integrate with the user's PIM data – contacts, calendar, music, etc – where it makes senseAdd support for voice commands – SiriKitCreate app extensions to add functionalities to other apps.Of course only add native features where it makes sense to your app.

Have you taken inventory of the app's functionality and see what cannot be done should the app was implemented as a progressive web application? A lot can be done through JavaScript in the browser nowadays – that also includes getting the user's current location (which I presume relevant for showing the local weather). Aguing with the reviewer using precedents (i.e. app X was approved) isn't going to bring your app closer to approval.Should your app have these platform-leveraging functionalities, have you make sure that App Review know about these features and understand how to use it? An intro screen highlighting these features may prove useful as app reviewers has only about five minutes to glance through your app.That said, have a look at these tips on how to design an app that can pass "minimum functionality" clause.

It sounds like the Catalyst side is slow to send out change notifications. Is this the case?You might want to try calling CloudKit libraries from an AppKit-linked bundle. That is have a non-Catalyst framework bundle (that doesn't link to UIKit) that exclusively talk to CloudKit. In turn the rest of the Mac/Catalyst app uses this bundle for anything Cloud-Kit related. Read this article for the details.

Have you tried adding these into the entitlements of your Java app's application bundle:<key>com.apple.security.cs.allow-jit</key> <true/> <key>com.apple.security.cs.allow-unsigned-executable-memory</key> <true/> <key>com.apple.security.cs.disable-executable-page-protection</key> <true/> <key>com.apple.security.cs.disable-library-validation</key> <true/> <key>com.apple.security.cs.allow-dyld-environment-variables</key> <true/>Source from here.

Use "altool" to notarize and check notarization status. There is an option for the tool to output XML as its results. This is an XML Property List that has a well-documented format and should be parseable easily.Use "spctl" to verify notarization results and check the process' error level returned.I've put together a shell script implementing the full packaging and notarization flow. You can directly integrate this into a pre-existing build system or modify as needed. Have a look at the script to see how to parse notarization tools' results.

This is odd. Have you tried creating a dummy Swift project (choose one of Xcode's starter template projects that uses Swift) then code-sign and notarize it using the same pipeline that you use for your "normal" app? This is to eliminate the issues coming from your developer account or your system. A sample project should get notarized just fine and run without gatekeeper issues.Furthermore I see that you're using a .zip file as your end product. As these can't be stapled (i.e. have embedded notarization results), is it possible to switch to either .dmg or .pkg distribution instead? Then staple the notarization results before you validate it using spctl.It is also possible that the notarization result was not yet available to Gatekeeper when you run spctl. That is, notarization talks to server A whereas Gatekeeper talks to server B. In turn A haven't told B of your just-notarized package. If you staple the notarization results into your redistributable product, Gatekeeper won't need to make a network request to validate notarization of the product.

Suppose the command-line application doesn't have hardened runtime enabled (some open-source projects can be quite complicated to build, or perhaps its a vendor-supplied component). Can the OP notarize the containing application bundle and have it work on other people's machines? Given that the containing app can have hardened runtime enabled, but the helper can not.

External dependencies could be a problem. Mac App Store apps must not require the user to install anything else as a pre-requisite. Have a look at App Review Guideline 2.4.5 (ii) and (iii):(ii) They must be packaged and submitted using technologies provided in Xcode; no third-party installers allowed. They must also be self-contained, single application installation bundles and cannot install code or resources in shared locations.(viii) Apps should run on the currently shipping OS and may not use deprecated or optionally installed technologies (e.g. Java, Rosetta)Hence if your app requires MongoDB (for example), it needs to contains a copy of that software within its own application bundle, manage its process lifecycle (i.e. start it only after the app starts and stop it before the app quits), and make sure it works within a sandboxed environment.Next you'll also need to make sure that the reviewers understands your app. Provide intro materials, videos, etc, as part of the app bundle so that the reviewer can get a feel of what your app does within five minutes or less. For more details, have a look at how to pass Guideline 4.2.

In-app purchases must only be used for virtual goods (and vice-versa). Apple Pay would be usable for purchasing goods and services "in real life" and desirable but not mandatory.