Per Quinn's suggestion, TSI Case-ID: 4368872 submitted

I've got the same problem (https://developer.apple.com/forums/thread/738801) - Per Quinn's suggestion, TSI Case-ID: 4368872 submitted

@Shiv Sharma DTS discovered if I used a filename with a non-number as its first character, then it exports (and was able to verify that and get exports)

@Shiv Sharma Try starting your file name with a non-number. DTS got back to me with a workaround, have a letter at the front of your filename, and it'll export correctly.

It's a leaky abstraction, implementation details about UDSZ have escaped and affect our choice of filenames (courtesy of DTS: a requirement of the USD spec, see the documentation here: https://openusd.org/dev/api/group__group__tf___string.html#gaa129b294af3f68d01477d430b70d40c8) Feedback reported: FB13240732

It's a leaky abstraction, implementation details about UDSZ have escaped and affect our choice of filenames (courtesy of DTS: a requirement of the USD spec, see the documentation here: https://openusd.org/dev/api/group__group__tf___string.html#gaa129b294af3f68d01477d430b70d40c8) Feedback reported: FB13240732 (and Shiv, I bet your code works 40% of the time, when you have a hex digit as the start of your UUID. Guess you lucked out getting a bad file name to start out with! :-) )

(for anyone finding this from a search - there's other discussions around here on this topic) File names for CapturedRoom export cannot start with a number - it's a leaky abstraction, implementation details about UDSZ have escaped and affect our choice of filenames (courtesy of DTS: a requirement of the USD spec, see the documentation here: https://openusd.org/dev/api/group__group__tf___string.html#gaa129b294af3f68d01477d430b70d40c8) Feedback reported: FB13240732

Same problem on Instruments Version Version 15.0.1 (15A507), iPhone 15 Pro Max iOS 17.1.1, M1 MBP Ventura (13.6.2 (22G320)), and Intel MBP (Sonoma 14.0).

Same here. Deployment target of iOS 16, no working breakpoints. Change it to 17, and breakpoints work again.

And to follow up. With a sandbox account in the simulator. I'm on (e.g.) version 65 I purchase the app. Then re-run get originalAppVersion of 65 I bump my app version to 66 and re-run originalAppVersion now returns 66. So I'm unable to tell that I've actually purchased. Do I have to run this on a device and/or off of TestFlight to get it use the version when I do a fake purchase? thanks!

PEBCAK - need to upgrade both the version numbers for it to stick. Getting these values when running on the device (testflight not involved): version 2.8.4 / 72 - "bought" version 2.8.5 / 73 - returned 72 (so interpret as purchased) version 2.8.6 / 74 - returned 74 (so interpret as free version) version 2.8.7 / 75 - returned 75 (so interpret as free version)

The app compares the originalAppVersion value with the constant. But, as I have discovered, in sandbox situations, the originalAppVersion always returns 1.0. Is it possible to test this stuff before releasing it?

It is a shame, we'll be unable to use the Apple API at all because we have users on beefy phones but aren't LIDAR/phone, and will need to use a third party library. Kind of lose-lose overall.

(And Prior reply went into the bit bucket) - thanks for the reply! It would have been nice if the PhotogrammetrySession.isSupported documentation mentioned anything along those lines, but that's a radar for another day :-)