I filed FB14215476, but it has been closed as "unable to diagnose with current information" - and no clue what additional information they think they need.

[quote='794483022, Engineer, /thread/759040?answerId=794483022#794483022'] In this case, the asset data is only accessible through the item provider, not the asset identifier. [/quote] OK. I'm using the localIdentifier within the app, and the cloudIdentifier in saved files, to identify photos. I'm not persistently copying photo image data into the app. It seems that this is not compatible with "limited access" permissions and PHPickerViewController. Is there a way to configure PHPickerViewController so that it only displays photos that the user has already granted access to, in "limited access" mode? Or alternatively, instead of presenting the PHPickerViewController I could call presentLimitedLibraryPicker - except this doesn't help in the (common?) case where the user wants to select a photo that they already granted access to. I guess I'll just not support limited access mode. I wonder how many users try to use it?

I have had a look at <complex> and <cmath>. It seems that <complex> has a lot of code that applies only during constant evaluation. So in your case, operator* calls std::__constexpr_isinf (and isnan, isfinite etc). Looking at the implementations of those, starting around line 570 of <math>, there are variations depending on whether the type is_floating_point and whether a builtin is available. Eventually, it calls either __builtin_isinf(), isinf(), or std::isinf(). Notably this is inside namespace std { .... }; so is there a difference between calling isinf() and calling std::isinf()? For extra excitement, earlier in the file there is using ::isinf, i.e. isinf() from the global namespace is being imported into std::. Answering my question in the previous post, your definition of your isinf is in your own namespace, not global. So... when __constexpr_isinf calls std::isinf, which it does for non-floating-point types, it won't find yours - though it would have found it if you had defined it in the global namespace. I've spent a while on this now and I have other things to do. I think if I were you, I'd now try to create a minimal example of the problem.

I would like to understand this error message: It is listing some of the candidate isinf functions that it has ignored while looking for one that matches your fixpnt type. It is correctly ignoring those functions, because they are enabled only for std::is_arithmetic types, which yours is not (correctly). It would make sense that as an plugin-type author you would want to support this overload I'm not sure exactly what you mean by that. You don't want those specific functions in math.h to match your type; that makes no sense. What you do want is your own isinf implementation to be found, and not ignored, by the caller. Have you checked if it works in C++20 mode? What namespace is your isinf defined in? This is something I recall getting wrong once. Should it be: namespace foo { class Number; constexpr bool isinf(Number); }; or namespace foo { class Number; }; constexpr bool isinf(foo::Number); ?

Please edit your posts to format the code properly! Try making those functions constexpr. I say this because in your original error message you have something like this: error: no matching function for call to 'isinf' in instantiation of function template specialization 'std::__constexpr_isinf<sw::universal::fixpnt<4, 0>>' It then lists all the overloads of isinf that it can't use, and yours isn't there. So either it can't see it for some reason, or it has seen it but it has excluded it. The name __constexpr_isinf gives a strong hint that it is a constexpr function, so it will only call other functions (i.e. isinf) that are also constexpr. I'm not totally confident of this, because I would have hoped for it to indicate that your isinf has been excluded due to not being constexpr. But you should make all those functions constexr anyway, because they obviously are constexpr and there is no disadvantage to doing so. Also, the fact that you're seeing this with an Xcode upgrade that has changed the default C++ variant to C++23, and that std::isinf etc. have become constexpr since C++23, is a clue.

I think the answer is No. I think I recall specific language about "doing business as" in the agreements. But it's a long time since I understood this stuff.

Does the library define isinf() for this fixpnt type?

I didn't apply for SSL just because I didn't have enough funds. Let’s Encrypt is free. https://letsencrypt.org

There is a limit of 10,000 IAPs per app. There are a few apps, including one of mine, that have thousands of IAPs. I don't know if this applies to subscriptions in the same way that it applies to non-consumable purchases. The docs don't seem to distinguish between subscriptions and other IAPs so I guess it does. See: https://developer.apple.com/help/app-store-connect/configure-in-app-purchase-settings/overview-for-configuring-in-app-purchases You can create up to 10,000 in-app purchase products per app.

Don't worry - that configuration is only for testing.

I recently launched a new app and uploaded a single faked 5.5" screenshot because of this issue. I've now noticed a couple of things: On the Search Ads web interface, where it shows examples of ads for the app, it uses the single 5.5" screenshot with a huge gap. I don't know if real search ads will do that - does anyone know? fnd.io uses the single 5.5" screenshot. I suspect there could be other places. If anyone else is considering faking 5.5" screenshots, it is probably worth making sure you fake at least three of them.

I want to pick up on this from a comment: I would rather use built-in functionality if possible Why? Seriously. Write it yourself. It will do exactly what you want with no confusion about whether it is borked or just "working as intended". Oh, and it will be portable, and it won't get deprecated in 2 years time.

I had a similar situation last week; the IAP was approved about 3 days after the app itself. I suggest you just wait.

Great that you finally got it working!

Maybe we have different cmakes? % cmake --version cmake version 3.24.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). % which cmake /opt/homebrew/bin/cmake I'm not aware of cmake keeping any state outside of the directory tree where it is run.