User Profile

When I generate an xctestrun file using Xcode 14 with: xcodebuild build-for-testing -project UITestTesting.xcodeproj -scheme UITestTesting -destination 'id=00008020-000545362EE1002E' -derivedDataPath ./build I'm able to see the xctestrun file at "/Users/noahmartin/Desktop/UITestTesting/Build/Build/Products/UITestTesting_iphoneos16.0-arm64.xctestrun" However, I can't use it to run tests on my iOS 16 iPad. I'm trying to invoke the test like this: xcodebuild test-without-building -xctestrun "/Users/noahmartin/Desktop/UITestTesting/Build/Build/Products/UITestTesting_iphoneos16.0-arm64.xctestrun " -destination 'id=00008020-000545362EE1002E' -derivedDataPath ./build And getting this error: xcodebuild: error: Unable to find a destination matching the provided destination specifier: { id:00008020-000545362EE1002E } Available destinations for the "Transient Testing" scheme: { platform:macOS, arch:arm64e, id:00006001-0012198A0102801E } { platform:macOS, arch:arm64, id:00006001-0012198A0102801E } { platform:macOS, arch:x86_64, id:00006001-0012198A0102801E } { platform:macOS, arch:arm64e, variant:Mac Catalyst, id:00006001-0012198A0102801E } { platform:macOS, arch:arm64, variant:Mac Catalyst, id:00006001-0012198A0102801E } { platform:macOS, arch:x86_64, variant:Mac Catalyst, id:00006001-0012198A0102801E } { platform:macOS, arch:arm64e, variant:DriverKit, id:00006001-0012198A0102801E } { platform:macOS, arch:arm64, variant:DriverKit, id:00006001-0012198A0102801E } { platform:macOS, arch:arm64, variant:Designed for [iPad,iPhone], id:00006001-0012198A0102801E } { platform:iOS Simulator, id:3113F5B7-7358-4ADE-9660-667872D113A7, OS:16.0, name:iPad (9th generation) } { platform:iOS Simulator, id:D7232872-AC19-4DF1-BF18-D23C2C2A5BFE, OS:16.0, name:iPad Air (5th generation) } { platform:iOS Simulator, id:EE6444F9-2664-4907-9481-08CE44D028E9, OS:16.0, name:iPad Pro (9.7-inch) } { platform:iOS Simulator, id:10063708-10B3-4510-A41F-E948B2D09DB3, OS:16.0, name:iPad Pro (11-inch) (3rd generation) } { platform:iOS Simulator, id:794714E1-25E0-474A-BA79-F5E0EFA3E646, OS:16.0, name:iPad Pro (12.9-inch) (5th generation) } { platform:iOS Simulator, id:809FAD25-CFE5-44CA-B642-0FF2A0E638E5, OS:16.0, name:iPad mini (6th generation) } { platform:iOS Simulator, id:055D580A-859B-42F8-B306-BD8CB68BF1CC, OS:16.0, name:iPhone 8 } { platform:iOS Simulator, id:228440FE-9536-401D-9221-E909761468FE, OS:16.0, name:iPhone 8 Plus } { platform:iOS Simulator, id:D2F30B3E-32F9-44B2-9B02-20A1B6FEDFC3, OS:16.0, name:iPhone 11 } { platform:iOS Simulator, id:1677A963-4BBC-4DE3-896B-2D93FBF10A1B, OS:16.0, name:iPhone 11 Pro } { platform:iOS Simulator, id:67F569A4-B422-406F-961A-C9093F4EA861, OS:16.0, name:iPhone 11 Pro Max } { platform:iOS Simulator, id:927F62C4-CB4E-487A-B021-0A986B9B700A, OS:16.0, name:iPhone 12 } { platform:iOS Simulator, id:AAAE026B-A40E-4D84-9447-91B2034B6FDA, OS:16.0, name:iPhone 12 Pro } { platform:iOS Simulator, id:96E6D2AB-140B-496F-8C31-71A12412AB0C, OS:16.0, name:iPhone 12 Pro Max } { platform:iOS Simulator, id:B68ACAB0-A87A-4384-B9F8-63ECF09D9564, OS:16.0, name:iPhone 12 mini } { platform:iOS Simulator, id:E6FFBA89-6B9E-4A76-A99E-0510E1EFE97B, OS:16.0, name:iPhone 13 } { platform:iOS Simulator, id:0ECA5023-8C7B-4CFA-B264-E0539509E61A, OS:16.0, name:iPhone 13 Pro } { platform:iOS Simulator, id:203AC07C-503F-476E-9F14-DA7FA4D63131, OS:16.0, name:iPhone 13 Pro Max } { platform:iOS Simulator, id:16AA1AE3-1D75-4358-A4FB-8A73141A0551, OS:16.0, name:iPhone 13 mini } { platform:iOS Simulator, id:FAC28F61-2CF8-40C1-AB2D-64CE6F11B96B, OS:16.0, name:iPhone SE (3rd generation) } Ineligible destinations for the "Transient Testing" scheme: { platform:iOS, id:dvtdevice-DVTiPhonePlaceholder-iphoneos:placeholder, name:Any iOS Device } { platform:iOS Simulator, id:dvtdevice-DVTiOSDeviceSimulatorPlaceholder-iphonesimulator:placeholder, name:Any iOS Simulator Device } { platform:macOS, name:Any Mac } { platform:macOS, variant:Mac Catalyst, name:Any Mac } { platform:tvOS, id:dvtdevice-DVTiOSDevicePlaceholder-appletvos:placeholder, name:Any tvOS Device } { platform:tvOS Simulator, id:dvtdevice-DVTiOSDeviceSimulatorPlaceholder-appletvsimulator:placeholder, name:Any tvOS Simulator Device } { platform:watchOS, id:dvtdevice-DVTiOSDevicePlaceholder-watchos:placeholder, name:Any watchOS Device } { platform:watchOS Simulator, id:dvtdevice-DVTiOSDeviceSimulatorPlaceholder-watchsimulator:placeholder, name:Any watchOS Simulator Device } I am able to launch the test directly from xcode, or with the "project" and "scheme" flags and xcodebuild test but I can't get the xctestrun file to work with iOS 16. This method works fine for iOS 15/Xcode 13. Is there anything I'm missing to make this work with the new betas? Also filed as FB10129497

I'm investigating why the download size reported by the App Store (shown in an alert when downloading an app on low data mode) is a larger size than I get locally. I've copied the example from https://developer.apple.com/documentation/accelerate/compressing_file_system_directories to compress my already thinned .app with LZFSE. The resulting file size is about 10MB smaller than what I see on the app store. However, if I do this same process for an app that has a binary of about the same size, but fewer resource files in the app bundle, my local archive is within 1MB of the App Store download size. The app thinning report built into Xcode seems to have similar inaccuracies with app bundles containing many files. I know the app store builds have additional code signing and encryption, but this is only a problem with apps that contain lots of files (specifically localizable strings) and isn't much of an issue with apps that are mostly a binary file. Are there any other differences between what is downloaded on the app store and my local .app that could cause the larger app store download size? Also, is the App Store using LZFSE or another algorithm like GZIP?

I'm using xcrun xctrace export --output results.xml --input test_trace.trace --xpath '//trace-toc[1]/run[1]/data[1]/table' to export data from a test run with instruments as part of my app's CI. With Xcode 12 this resulted in an xml file that I could parse relatively quickly, but now with Xcode 13 the export process itself is taking 90+ seconds and generating a 160mb xml file for a 10 second recording. I noticed the table that has increased is the time-sample schema. Just attempting to export this table with --xpath '//trace-toc[1]/run[1]/data[1]/table[4]' takes quite a while. The table has about 790 thousand rows. I'm using a custom instrument based off the time profiler, and still have about the same number of stack trace samples in my output. Did anything change in Xcode 13 that caused instruments to include many more time samples that aren't corresponding to a stack trace? Is it possible to disable this to have fewer time samples in my trace (while preserving the stack trace frequency) so the xml can be parsed quicker?

I'm trying to profile app launch of an iOS app running on an M1 Mac. After downloading a Mac compatible app from the iOS App Store (Airbnb) I'm able to select it in instruments by selecting the .app in /Applications This allows me to launch the app and profile it by pressing the record button Now I want to do this in an automated way with xctrace so I ran : xcrun xctrace record --template 'App Launch' --device CE3D229D-A2BF-5455-8923-5D49498F06DC --launch -- '/Applications/Airbnb.app' Using the id of my Mac returned from xcrun xctrace list devices. This attempts to launch the app but it immediately crashes with an error about an invalid code signature: If I try the same process with a MacOS app like Twitter, instead of an iOS app running on Mac, I'm able to launch it with xctrace. I'm also able to attach to Airbnb using the --attach PID option, but this doesn't help for testing app launch. I also tried launching the internal iOS .app using: xcrun xctrace record --template 'App Launch' --device CE3D229D-A2BF-5455-8923-5D49498F06DC --launch -- '/Applications/Airbnb.app/Wrapper/Airbnb.app' but got the same crash. How can I use the command line to launch an iOS app for profiling instruments? This is using Xcode 12.5.1 on macOS 11.5.2

I've been experimenting with chained fixups now that they're the default on iOS 15 and saw about 1.3mb reductions in app size because the data used by dyld to find fixup locations is much more compact. It looks like the -fixup_chains linker flag enables LC_DYLD_CHAINED_FIXUPS and LC_DYLD_EXPORTS_TRIE even pre iOS 15. I was able to launch an app with this linker flag on iOS 14.6 and iOS 13.4.1 without a problem. However, the Xcode 13 release notes say This uses different load commands and LINKEDIT data, and won’t run or load on older OS versions. It appears that it actually does run on older OS versions, what problems (if any) are there with using these load commands as far back as iOS 13.0?