When uploading app screenshots, I have to provide a sourceFileChecksum and uploaded flag: https://developer.apple.com/documentation/appstoreconnectapi/appscreenshotupdaterequest/data/attributes But that's not the case for app event screenshots, I only have to provide the uploadedflag: https://developer.apple.com/documentation/appstoreconnectapi/appeventscreenshotupdaterequest/data/attributes The same is true for app previews and app event video clips. Why is this different?

When I open an iOS app in the App Store Connect website and disclose the Apple Watch section, it reads Apple Watch Ultra, Series 8, 6, 3, but the documentation for the API lists different versions: APP_WATCH_ULTRA APP_WATCH_SERIES_7 APP_WATCH_SERIES_4 APP_WATCH_SERIES_3 So the Watch Series don't seem to match. There is a similar issue with iPad Pro. The website reads iPad Pro (6th Gen) 12.9" Display and iPad Pro (2nd Gen) 12.9" Display, but the API reads APP_IPAD_PRO_3GEN_129 APP_IPAD_PRO_129 So again the Gen values don't seem to match. How should I interpret these values?

I would like to simulate pressing an arrow key on the hardware keyboard attached to an iPad. In a UI test for a macOS target I can do this: XCUIElement.typeKey(.rightArrow, modifierFlags: [.option, .command]) but this won't compile for a iOS target supporting iPhone and iPad. Is there an alternative? What I would like to achieve in the end is moving the text cursor at the beginning of a particular sentence by pressing Option-Command-Arrow left a certain number of times, but if someone knows a better way, I'd be happy to hear it.

In my UI test I'm trying to force the app's user interface style to be light or dark. On macOS, when the system appearance is light, I can force the app to be dark with this code: var app = XCUIApplication() app.launchArguments += ["-AppleInterfaceStyle", "Dark"] app.launch() Sadly, this doesn't work with a iOS target, and UIScreen.main.traitCollection.userInterfaceStyle is read-only. Is this not possible?

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") } }

I have a document-based app which displays a view controller with a navigation bar (i.e. it's inside a navigation controller) which is also the detail view controller of a split view controller. I'm using this sample code to just show a back button in the navigation bar of the document view controller: class DocumentViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() splitViewController!.presentsWithGesture = false navigationItem.backAction = UIAction(handler: { _ in }) } } In a regular width, this works as expected: only the back button is displayed. In a compact width such as a portrait iPhone, the split view seems to display the navigation bar button to show the master view controller (the one with the icon to the right of the back button, labeled “Root View Controller"). According to the documentation of presentsWithGesture: When this property is false, the split view controller doesn’t install a gesture recognizer for changing the display mode. The split view controller also doesn’t display a button to change the display mode. Is this a bug, or an error in the documentation, or am I doing something wrong?

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?

I'm using this code to get the path of an executable from the audit token provided in NEFilterDataProvider.handleNewFlow(_:), forwarded from the Network Extension to the main app via IPC: private func securePathFromAuditToken(_ auditToken: Data) throws -> String? { let secFlags = SecCSFlags() var secCode: SecCode? var status = SecCodeCopyGuestWithAttributes(nil, [kSecGuestAttributeAudit: auditToken] as CFDictionary, secFlags, &secCode) guard let secCode = secCode else { throw SecError(status) } var secStaticCode: SecStaticCode? status = SecCodeCopyStaticCode(secCode, secFlags, &secStaticCode) guard let secStaticCode = secStaticCode else { throw SecError(status) } var url: CFURL? status = SecCodeCopyPath(secStaticCode, secFlags, &url) guard let url = url as URL? else { throw NSError(domain: NSOSStatusErrorDomain, code: Int(status)) } return nil } But it seems that some processes like trustd, rapportd, nsurlsessiond and timed have a non-nil path. For these executables I have to resort to this code, which I have read is not as secure: private func insecurePathFromAuditToken(_ auditToken: Data) throws -> String? { if auditToken.count == MemoryLayout<audit_token_t>.size { let pid = auditToken.withUnsafeBytes { buffer in audit_token_to_pid(buffer.baseAddress!.assumingMemoryBound(to: audit_token_t.self).pointee) } let pathbuf = UnsafeMutablePointer<Int8>.allocate(capacity: Int(PROC_PIDPATHINFO_SIZE)) defer { pathbuf.deallocate() } let ret = proc_pidpath(pid, pathbuf, UInt32(PROC_PIDPATHINFO_SIZE)) if ret <= 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } return String(cString: pathbuf) } return nil } This seems to happen with both NEFilterFlow.sourceAppAuditToken and sourceProcessAuditToken. Is this expected? Can it really be that some executables shipped with macOS are not signed?

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?

I keep getting crash reports in Xcode for one of my macOS apps published on the App Store. Actually it's not the main app that crashes, but the embedded Finder Sync extension. The crash reports indicate that this source code line static var appGroupSaveDirectoryUrl = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: identifier)!.appendingPathComponent("Library/Application Support/somedata") crashes with error Swift runtime failure: Unexpectedly found nil while unwrapping an Optional value + 0 (<compiler-generated>:0) That line is a static variable defined in a class that is included in the main app as well as the Finder extension. The documentation reads In iOS, the value is nil when the group identifier is invalid. In macOS, a URL of the expected form is always returned, even if the app group is invalid If the documentation says that the method call can never be nil, why am I getting this crash? Is it a bug or is the documentation wrong, or am I doing something wrong? And why does the Finder Sync extension crash and not the main app? I cannot reproduce this crash with the App Store app or within Xcode and Console shows no crash reports for the app on my Mac.

I cannot find in the documentation if using NEFilterDataProvider.apply(_:) has any advantage over manually inspecting incoming flows in handleNewFlow(_:) other than being a shortcut. Or are those rules guaranteed to be applied even if the network extension crashes or similar? If it has no practical advantages, then manually inspecting each flow allows to set up more flexible dynamic rules.

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?

I'm testing my NEFilterDataProvider system extension by building it in Xcode and then copying the built app into the Applications folder. When I do changes to the extension's code, obviously the system extension process currently running needs to be shut down or restarted when I launch the new app version. Increasing the app version and build numbers each time always seem to trigger the system extension update in macOS, but that's not so convenient and at the latest when publishing the update those numbers cannot just make arbitrary jumps. I've read that moving an app to the trash should uninstall any attached system extensions, and this seems to be confirmed by the alert that macOS shows when doing so, but even after clicking Continue and authenticating with Touch ID to confirm the uninstall and emptying the trash, it sometimes happens that when launching the next version of my app from the Applications folder the old system extension is still running, which I notice e.g. because the app crashes since it's using different IPC method signatures than the system extension. When checking in Activity Monitor the system extension is also still listed. Even restarting the Mac doesn't always solve the issue, so when this happens my only solution is to increase the build and version numbers to make it work, and then reset them later when moving the app to the trash correctly uninstalls the system extension again. Is this a bug or am I missing something? Or is there a workaround that doesn't involve booting into safe mode and manually uninstalling the system extension? P.S.: I just tried booting into safe mode and moving the files from /Library/SystemExtensions to the trash as suggested on discussions.apple.com, but I got an alert saying that I didn't have the privileges to do so.

Since NEFilterFlow.identifier is documented as The unique identifier of the flow., I thought I could use it to store the flow by its identifier in a dictionary in order to retrieve it later. I do this when the system extension pauses a flow because it needs to ask the user whether the flow should eventually be allowed or dropped. But then I noticed that sometimes when allowing a previously paused flow, identified by its identifier, my system extension doesn't find that flow anymore. After some debugging it turned out that this happens because I stored at least one other flow with the same id which, when confirmed, is removed again from the dictionary, so there is no more flow with that identifier waiting in the dictionary. Is it expected that the identifiers are recycled for different flows, or does it mean that the same flow is effectively being passed to .handleNewFlow(_:) multiple times, such as if the extension waited "too long" between pausing a flow and allowing or dropping it? What does this mean?

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) ...