By following the documentation, in Info.plist I have added UIApplicationSupportsPrintCommand = true, but when tapping the navigation item's title and selecting Print, printContent(_:) is never called. On the other hand, when selecting Move, move(_:) is called as expected. What's the problem?
The issue can be reproduced by using the code below in a newly created Xcode project with the App template.
class ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
navigationItem.title = "asdf"
navigationItem.documentProperties = UIDocumentProperties(url: URL(fileURLWithPath: "/asdf"))
navigationItem.titleMenuProvider = { suggestions in
return UIMenu(children: suggestions)
}
}
override func move(_ sender: Any?) {
print("move")
}
override func printContent(_ sender: Any?) {
print("printContent")
}
}
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
According to the App Store Connect API documentation we can get the Default App Clip Experience for an App Store Version, and since on the App Store Connect website we have a single App Clip section for an iOS App, it seems that an App Store Version can have 0 or 1 Default App Clip Experience.
But there is no direct way of getting the Advanced App Clip Experiences. The only way I can see is by getting the App Clip object first for the App, then listing all Default and Advanced App Clip Experiences for that App Clip.
This makes me wonder: are Advanced App Clip Experiences not directly linkes to an App Store Version like the Default App Clip Experience? Does the list of Default App Clip Experiences returned from an App Clip object always contain a single object, or can it be more than one (perhaps older versions linked to old App Store Versions)? What is the relationship between App Store Version, App Clip Default Experiences and App Clip Advanced Experiences?
When using NSTextLayoutManager.addRenderingAttribute(.backgroundColor, value: NSColor.red, for: range), the background color for a line is only drawn as far as the last visible character. There is also a thin space between the lines where the background color is not visible.
Whe using NSLayoutManager.addTemporaryAttribute(.backgroundColor, value: NSColor.red, forCharacterRange: range), the background color is drawn also for newline characters and soft line wraps.
I would like to achieve the effect of using NSLayoutManager.addTemporaryAttribute(.backgroundColor, value: NSColor.red, forCharacterRange: range), but since I'm targeting TextKit 2, I have to avoid using NSLayoutManager. Is there a way to achieve this with NSTextLayoutManager or one of the other related classes in TextKit 2?
In a Simulator instance running iOS 15, I am able to tap and hold an app in the Dock and drag it to the left or right screen border to create a new window of that app. But when doing that in a Simulator instance running iOS 16 or 17, after tap and holding an app in the Dock, I cannot drag it anywhere, it just stays in the Dock. Is this a bug or is there another solution?
In my macOS app I'm encoding and restoring the state of a view between app launches. It used to work fine until I updated to macOS 14 and Xcode 15. Now Xcode logs this error when calling coder.decodeObject(forKey: "string"):
*** -[NSPersistentUIKeyedUnarchiver validateAllowedClass:forKey:] allowed unarchiving safe plist type ''NSString' (0x1dfa40918) [/System/Library/Frameworks/Foundation.framework]' for key 'string', even though it was not explicitly included in the client allowed classes set: '{(
)}'. This will be disallowed in the future.
The following sample code reproduces the issue:
class ViewController: NSViewController {
override func viewDidAppear() {
invalidateRestorableState()
}
override class func allowedClasses(forRestorableStateKeyPath keyPath: String) -> [AnyClass] {
return [NSString.self]
}
override func encodeRestorableState(with coder: NSCoder) {
coder.encode("asdf", forKey: "string")
}
override func restoreState(with coder: NSCoder) {
print(coder.decodeObject(forKey: "string") as! String)
}
}
What am I doing wrong?
When promoting my app or a significant update at https://developer.apple.com/contact/app-store/promote I have to fill out a Target Submission Date and a Target Release Date. The release date is when I want the app or update to be released to the public on the App Store, but what is the submission date? Can the submission date in relation to the release date influence the likelihood of my app or update being considered for a promotion? Should the interval between the submission and release date be as large as possible?
Topic:
App Store Distribution & Marketing
SubTopic:
General
Tags:
App Review
App Store
App Submission
Xcode contains several crash reports downloaded from users of my app. Thread 0 apparently crashes after calling NSApp.runModalForWindow(_:) (within the redacted stacktrace rows 17-19 that are locations in my own code). All the other threads only contain calls to system code.
What could cause such a crash?
...
Code Type: ARM-64
Parent Process: launchd [1]
User ID: 501
...
OS Version: macOS 13.5.2 (22G91)
...
Crashed Thread: 0
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x000000018800c728
Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Terminating Process: exc handler [61015]
Thread 0 Crashed:
0 AppKit 0x000000018800c728 -[NSApplication _crashOnException:] + 240 (NSApplication.m:6808)
1 AppKit 0x0000000187e54a10 __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke + 644 (NSCATransaction.m:98)
2 AppKit 0x0000000188530cfc ___NSRunLoopObserverCreateWithHandler_block_invoke + 64 (AppKit_Internal.h:745)
3 CoreFoundation 0x0000000184b059f0 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 36 (CFRunLoop.c:1789)
4 CoreFoundation 0x0000000184b058dc __CFRunLoopDoObservers + 532 (CFRunLoop.c:1902)
5 CoreFoundation 0x0000000184b04f14 __CFRunLoopRun + 776 (CFRunLoop.c:2944)
6 CoreFoundation 0x0000000184b044b8 CFRunLoopRunSpecific + 612 (CFRunLoop.c:3418)
7 HIToolbox 0x000000018e356df0 RunCurrentEventLoopInMode + 292 (EventLoop.c:455)
8 HIToolbox 0x000000018e356a80 ReceiveNextEventCommon + 220 (EventBlocking.c:311)
9 HIToolbox 0x000000018e356984 _BlockUntilNextEventMatchingListInModeWithFilter + 76 (EventBlocking.c:171)
10 AppKit 0x0000000187d2b97c _DPSNextEvent + 636 (CGDPSReplacement.m:818)
11 AppKit 0x0000000187d2ab18 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716 (appEventRouting.m:407)
12 AppKit 0x0000000187f63bd0 -[NSApplication _doModalLoop:peek:] + 216 (NSApplication.m:3469)
13 AppKit 0x0000000187f62ad4 __35-[NSApplication runModalForWindow:]_block_invoke_2 + 56 (NSApplication.m:3516)
14 AppKit 0x0000000187f62a80 __35-[NSApplication runModalForWindow:]_block_invoke + 108 (NSApplication.m:3516)
15 AppKit 0x0000000187f62364 _NSTryRunModal + 100 (NSModal.m:25)
16 AppKit 0x0000000187f62224 -[NSApplication runModalForWindow:] + 292 (NSApplication.m:3516)
...
20 AppKit 0x0000000187ed34cc -[NSApplication(NSResponder) sendAction:to:from:] + 440 (appEventRouting.m:1888)
21 AppKit 0x0000000187ed32e4 -[NSControl sendAction:to:] + 72 (NSControl.m:1459)
22 AppKit 0x0000000187fda170 -[NSTableView _sendAction:to:row:column:] + 116 (NSTableView.m:9022)
23 AppKit 0x0000000187fd8d70 -[NSTableView mouseDown:] + 4224 (NSTableView.m:11191)
24 AppKit 0x0000000187ecdef0 -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 3476 (winEventRouting.m:1003)
25 AppKit 0x0000000187e58b2c -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 364 (winEventRouting.m:402)
26 AppKit 0x0000000187e587ec -[NSWindow(NSEventRouting) sendEvent:] + 284 (winEventRouting.m:257)
27 AppKit 0x0000000187e57b30 -[NSApplication(NSEvent) sendEvent:] + 1556 (appEventRouting.m:0)
28 AppKit 0x00000001880a7c48 -[NSApplication _handleEvent:] + 60 (NSApplication.m:3342)
29 AppKit 0x0000000187d1efa0 -[NSApplication run] + 500 (NSApplication.m:3430)
30 AppKit 0x0000000187cf63cc NSApplicationMain + 880 (NSApplication.m:9413)
31 MyApp 0x0000000102980cd0 main + 128 (main.swift:12)
32 dyld 0x00000001846cff28 start + 2236 (dyldMain.cpp:1165)
...
Xcode contains several crash reports downloaded from users of my app. Thread 0 apparently crashes at [CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink], but there's not a single stacktrace line that contains code within my app, so I have no idea what this means or how to reproduce it.
What could cause such a crash?
Code Type: X86-64 (Native)
Parent Process: launchd [1]
User ID: 501
...
OS Version: macOS 14.0 (23A344)
...
Crashed Thread: 0
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4
Terminating Process: exc handler [1920]
Thread 0 Crashed:
0 AppKit 0x00007ff81c3730c1 -[NSApplication _crashOnException:] + 289 (NSApplication.m:7290)
1 AppKit 0x00007ff81c175ea5 __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke + 853 (NSCATransaction.m:98)
2 AppKit 0x00007ff81cc43339 ___NSRunLoopObserverCreateWithHandler_block_invoke + 41 (AppKit_Internal.h:760)
3 CoreFoundation 0x00007ff818a13836 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 (CFRunLoop.c:1789)
4 CoreFoundation 0x00007ff818a1375a __CFRunLoopDoObservers + 493 (CFRunLoop.c:1902)
5 CoreFoundation 0x00007ff818a12cdc __CFRunLoopRun + 850 (CFRunLoop.c:2946)
6 CoreFoundation 0x00007ff818a12372 CFRunLoopRunSpecific + 557 (CFRunLoop.c:3420)
7 HIToolbox 0x00007ff82327e9d9 RunCurrentEventLoopInMode + 292 (EventLoop.c:455)
8 HIToolbox 0x00007ff82327e616 ReceiveNextEventCommon + 201 (EventBlocking.c:311)
9 HIToolbox 0x00007ff82327e531 _BlockUntilNextEventMatchingListInModeWithFilter + 66 (EventBlocking.c:171)
10 AppKit 0x00007ff81c01a0c5 _DPSNextEvent + 880 (CGDPSReplacement.m:806)
11 AppKit 0x00007ff81c90b150 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1304 (appEventRouting.m:410)
12 AppKit 0x00007ff81c00b63a -[NSApplication run] + 603 (NSApplication.m:3488)
13 AppKit 0x00007ff81bfdf670 NSApplicationMain + 816 (NSApplication.m:10105)
14 MyApp 0x0000000100627071 main + 129 (main.swift:12)
15 dyld 0x00007ff8185b03a6 start + 1942 (dyldMain.cpp:1269)
Thread 1:
0 libsystem_kernel.dylib 0x00007ff8188f9a2e mach_msg2_trap + 10
1 libsystem_kernel.dylib 0x00007ff818907e4a mach_msg2_internal + 84 (mach_msg.c:201)
2 libsystem_kernel.dylib 0x00007ff818900b6e mach_msg_overwrite + 653 (mach_msg.c:0)
3 libsystem_kernel.dylib 0x00007ff8188f9d1f mach_msg + 19 (mach_msg.c:323)
4 CoreFoundation 0x00007ff818a14475 __CFRunLoopServiceMachPort + 143 (CFRunLoop.c:2624)
5 CoreFoundation 0x00007ff818a12ee5 __CFRunLoopRun + 1371 (CFRunLoop.c:3007)
6 CoreFoundation 0x00007ff818a12372 CFRunLoopRunSpecific + 557 (CFRunLoop.c:3420)
7 AppKit 0x00007ff81c1773e0 _NSEventThread + 122 (NSEvent.m:5493)
8 libsystem_pthread.dylib 0x00007ff818939202 _pthread_start + 99 (pthread.c:904)
9 libsystem_pthread.dylib 0x00007ff818934bab thread_start + 15
I've noticed that depending when I call NSApp.runModal(for:), the table view contained in the presented window is unresponsive: it either doesn't scroll at all, or the content only updates after one or two seconds, presumably after the inertial scrolling has ended.
In the sample code below I call NSApp.runModal(for:) in 3 different ways:
with a direct call
inside the callback to perform(_:with:afterDelay:)
inside the callback to DispatchQueue.main.async.
Only method 2 works. Why?
@main
class AppDelegate: NSObject, NSApplicationDelegate {
func applicationDidFinishLaunching(_ aNotification: Notification) {
// Insert code here to initialize your application
let window = NSWindow(contentViewController: ViewController(nibName: nil, bundle: nil))
// 1. doesn't work
runModal(for: window)
// 2. works
// perform(#selector(runModal), with: window, afterDelay: 0)
// 3. doesn't work
// DispatchQueue.main.async {
// self.runModal(for: window)
// }
}
@objc func runModal(for window: NSWindow) {
NSApp.runModal(for: window)
}
}
class ViewController: NSViewController, NSTableViewDataSource, NSTableViewDelegate {
override func loadView() {
let tableView = NSTableView()
tableView.addTableColumn(NSTableColumn())
tableView.dataSource = self
tableView.delegate = self
let scrollView = NSScrollView(frame: CGRect(x: 0, y: 0, width: 500, height: 500))
scrollView.documentView = tableView
view = scrollView
}
func numberOfRows(in tableView: NSTableView) -> Int {
return 100
}
func tableView(_ tableView: NSTableView, objectValueFor tableColumn: NSTableColumn?, row: Int) -> Any? {
return "\(row)"
}
func tableView(_ tableView: NSTableView, viewFor tableColumn: NSTableColumn?, row: Int) -> NSView? {
let cell = NSTableCellView()
cell.addSubview(NSTextField(labelWithString: "\(row)"))
return cell
}
}
On iOS I can create a UIFont that automatically adapts to the font size chosen in the Settings app by the user:
label.font = UIFont.preferredFont(forTextStyle: .body)
label.adjustsFontForContentSizeCategory = true
(Copy-pasted from here.) I couldn't find a similar API for macOS. In the Accessibility settings I can change the font size and some apps react to it, like System Settings and Finder automatically increase the labels. Is there a way to create NSFont or NSTextField that automatically adapts to the chosen font size?
I currently have a toolbar item group with 3 items, but clicking on any of the items doesn't do anything. Also none of the items appear to be highlighted, not even when manually setting NSToolbarItemGroup.selectedIndex. What am I missing? Setting the action property on the individual items rather than the group makes the items clickable, but still none of them appear to be selected.
class ViewController: NSViewController, NSToolbarDelegate {
let toolbarItemIdentifier = NSToolbarItem.Identifier("group")
let toolbarItemIdentifierItem1 = NSToolbarItem.Identifier("item1")
let toolbarItemIdentifierItem2 = NSToolbarItem.Identifier("item2")
let toolbarItemIdentifierItem3 = NSToolbarItem.Identifier("item3")
override func viewDidAppear() {
let toolbar = NSToolbar()
toolbar.delegate = self
view.window!.toolbar = toolbar
view.window!.toolbarStyle = .expanded
}
func toolbarAllowedItemIdentifiers(_ toolbar: NSToolbar) -> [NSToolbarItem.Identifier] {
return [.flexibleSpace, toolbarItemIdentifier]
}
func toolbarDefaultItemIdentifiers(_ toolbar: NSToolbar) -> [NSToolbarItem.Identifier] {
return [.flexibleSpace, toolbarItemIdentifier, .flexibleSpace]
}
func toolbar(_ toolbar: NSToolbar, itemForItemIdentifier itemIdentifier: NSToolbarItem.Identifier, willBeInsertedIntoToolbar flag: Bool) -> NSToolbarItem? {
switch itemIdentifier {
case toolbarItemIdentifier:
let item1 = NSToolbarItem(itemIdentifier: toolbarItemIdentifierItem1)
item1.image = NSImage(named: NSImage.addTemplateName)!
item1.label = "add"
let item2 = NSToolbarItem(itemIdentifier: toolbarItemIdentifierItem2)
item2.image = NSImage(named: NSImage.homeTemplateName)!
item2.label = "home"
let item3 = NSToolbarItem(itemIdentifier: toolbarItemIdentifierItem3)
item3.image = NSImage(named: NSImage.pathTemplateName)!
item3.label = "path"
let group = NSToolbarItemGroup(itemIdentifier: itemIdentifier)
group.subitems = [item1, item2, item3]
group.selectionMode = .selectOne
group.selectedIndex = 0
group.target = self
group.action = #selector(selectItem(_:))
return group
default:
return nil
}
}
@objc func selectItem(_ sender: Any) {
print(0)
}
}
I have a table view where each row has two labels, one left-aligned and one right-aligned. I would like to reload a single row, but doing so causes the right-aligned label to hug the left-aligned label.
Before the reload:
After the reload:
Reloading the whole table view instead, or disabling automatic row height, solves the issue. Can a single row be reloaded without resorting to these two workaround?
class ViewController: NSViewController, NSTableViewDataSource, NSTableViewDelegate {
override func loadView() {
let tableView = NSTableView()
tableView.translatesAutoresizingMaskIntoConstraints = false
tableView.dataSource = self
tableView.delegate = self
tableView.usesAutomaticRowHeights = true
let column = NSTableColumn()
column.width = 400
tableView.addTableColumn(column)
let scrollView = NSScrollView(frame: CGRect(x: 0, y: 0, width: 500, height: 500))
scrollView.translatesAutoresizingMaskIntoConstraints = false
scrollView.documentView = tableView
view = scrollView
Timer.scheduledTimer(withTimeInterval: 2, repeats: false) { _ in
print("reload")
tableView.reloadData(forRowIndexes: IndexSet(integer: 2), columnIndexes: IndexSet(integer: 0))
// tableView.reloadData()
}
}
func numberOfRows(in tableView: NSTableView) -> Int {
return 5
}
func tableView(_ tableView: NSTableView, viewFor tableColumn: NSTableColumn?, row: Int) -> NSView? {
let cell = NSTableCellView()
let textField1 = NSTextField(labelWithString: "hello")
textField1.translatesAutoresizingMaskIntoConstraints = false
let textField2 = NSTextField(wrappingLabelWithString: "world")
textField2.translatesAutoresizingMaskIntoConstraints = false
textField2.alignment = .right
let stack = NSStackView(views: [
textField1,
textField2
])
stack.translatesAutoresizingMaskIntoConstraints = false
stack.distribution = .fill
cell.addSubview(stack)
NSLayoutConstraint.activate([stack.topAnchor.constraint(equalTo: cell.topAnchor, constant: 0), stack.leadingAnchor.constraint(equalTo: cell.leadingAnchor, constant: 0), stack.bottomAnchor.constraint(equalTo: cell.bottomAnchor, constant: 0), stack.trailingAnchor.constraint(equalTo: cell.trailingAnchor, constant: 0)])
return cell
}
}
Swift loop execution time is 20x slower when adding print statement that is executed once at the end
My Swift app iterates over two Array<String> and compares their elements.
Something very strange is going on. I have the impression the compiler is doing some optimizations that I cannot understand: commenting out the print statement in MyInterface.run() improves the runtime from about 10 seconds to below 0.5 seconds, and that print statement is executed only once at the end of the program. Even commenting out the if above it has the same effect.
I'm running the app in Xcode Instruments. When debugging it in Xcode, there is no difference when commenting out any of those two lines.
Instruments shows that most of the time is spent in protocol witness for Collection.subscript.read in conformance [A], Array.subscript.read and similar, which in turn call different malloc, initialize, free and release methods.
What's the problem with this code?
import Cocoa
@main
class AppDelegate: NSObject, NSApplicationDelegate {
func applicationDidFinishLaunching(_ aNotification: Notification) {
let x = Array(repeating: "adsf", count: 100000)
let y = Array(repeating: "adsf", count: 100000)
let diff = MyInterface(x: x, y: y)
diff.run()
}
}
class MyInterface<List: RandomAccessCollection & MutableCollection> where List.Element: Comparable, List.Index == Int {
private let algorithm: Algorithm<List>
init(x: List, y: List) {
algorithm = AlgorithmSubclass(x: x, y: y)
}
func run() {
algorithm.run()
if (0..<1).randomElement() == 0 {
print(algorithm.x.count) // commenting out this line, or the if above, makes the program 20x faster
}
}
}
class Algorithm<List: RandomAccessCollection> where List.Element: Equatable, List.Index == Int {
var x: List
var y: List
init(x: List, y: List) {
self.x = x
self.y = y
}
func run() {
}
}
class AlgorithmSubclass<List: RandomAccessCollection>: Algorithm<List> where List.Element: Equatable, List.Index == Int {
override func run() {
var count = 0
for _ in 0..<1000 {
for i in 0..<min(x.endIndex, y.endIndex) {
if x[i] == y[i] {
count += 1
}
}
}
let alert = NSAlert()
alert.messageText = "\(count)"
alert.runModal()
}
}
In my previous post I asked why copyfile is slower than the cp Terminal command. In this other post I asked how I can make copyfile faster by changing the block size.
Now I discovered that the cp implementation on macOS is open source and that when copying regular files it doesn't use copyfile but fcopyfile. In a test I noticed that fcopyfile by default seems to be faster than copyfile.
When copying a 7 GB file I get about the same results I observed when comparing filecopy to cp:
copyfile: 4.70 s
fcopyfile: 3.44 s
When setting a block size of 16_777_216, copyfile becomes faster than fcopyfile:
copyfile: 3.20 s
fcopyfile: 3.53 s
Is this expected and why is it so? I would have expected that they both have the same performance, and when changing the block size they would still have the same performance.
Here is the test code. Change #if true to #if false to switch from fcopyfile to copyfile:
import Foundation
import System
let source = "/path/to/source"
let destination = "/path/to/destination"
#if true
let state = copyfile_state_alloc()
defer {
copyfile_state_free(state)
}
//var bsize = 16_777_216
//copyfile_state_set(state, UInt32(COPYFILE_STATE_BSIZE), &bsize)
let sourceFd = try! FileDescriptor.open(source, .readOnly)
let destinationFd = try! FileDescriptor.open(destination, .writeOnly)
if fcopyfile(sourceFd.rawValue, destinationFd.rawValue, state, copyfile_flags_t(COPYFILE_ALL | COPYFILE_NOFOLLOW | COPYFILE_EXCL | COPYFILE_UNLINK)) != 0 {
print(NSError(domain: NSPOSIXErrorDomain, code: Int(errno)))
}
try! sourceFd.close()
try! destinationFd.close()
#else
source.withCString { sourcePath in
destination.withCString { destinationPath in
let state = copyfile_state_alloc()
defer {
copyfile_state_free(state)
}
// var bsize = 16_777_216
// copyfile_state_set(state, UInt32(COPYFILE_STATE_BSIZE), &bsize)
if copyfile(sourcePath, destinationPath, state, copyfile_flags_t(COPYFILE_ALL | COPYFILE_NOFOLLOW | COPYFILE_EXCL | COPYFILE_UNLINK)) != 0 {
print(NSError(domain: NSPOSIXErrorDomain, code: Int(errno)))
}
}
}
#endif
Recently I realized that even though I was able to add my app's intents in the Shortcuts app, selecting any of the parameters didn't show the popup list of suggestions (the ones declared by DynamicOptionsProvider in the AppIntent subclass) and running it showed an error.
In the image you can see the two suggestions for the working app version ("asdf" and "bla") that would not be there in the non-working version.
I knew that when I had added this functionality, it worked, so I found the app version that caused the App Intents Extension to stop working. Apparently, the problem was that I had removed the Swift files declared in the app extension from my main app's target. Probably when I first added the App Intents Extension I had noticed that adding the extension's source files to the main target made it work, but later thought that it shouldn't be necessary and didn't test if it still worked.
Today I created an empty project with a new App Intents Extension and confirmed that the Shortcuts app was correctly showing the parameter popup suggestions, even without including the extension's source files in the main target. Then during the course of almost an entire day I gradually reduced my original Xcode project to this new sample project to find what else would make the extension work, other than including the extension's source files in the main target.
My very last resource was changing the bundle identifier, which solved the issue. My original project's targets have identifiers like org.domain.OriginalApp and org.domain.OriginalApp.AppIntent, while the sample project's targets have identifiers like org.domain.SampleApp and org.domain.SampleApp.AppIntent.
How could including the App Intents Extension's source files in the main target or changing the bundle identifiers cause the Shortcuts app to correctly show the parameter popup suggestions?