Will App Review be able to test this, without waiting X days for your code to decide that the free trial has ended? If not, I believe they must reject it.

What exactly do you need to do with the data in each language? Do you need to be able to modify the data from both sides? Or is it written by one side and read by the other? Can you change the code on both sides? Or are you trying to bridge to existing code in one or other language that can't be modified? Looking at your C++ code: class Foo { public: Foo(const std::vector<uint8_t> & values) : _values(values) {} protected: std::vector<uint_8> _values; }; You are, of course, copying from values into _values in the constructor. But you also have the option of writing the ctor like this: Foo(std::vector<uint8_t>&& values): _values(std::move(values)) {} This will also copy in most cases, but unlike your version it elides the copy if the ctor is passed a temporary, i.e. Foo make_foo(); void f() { Foo fff( make_foo() ); } I mention this because (a) it's good practice generally, but also (b) it will be easier to adapt a C++ API that uses value semantics to work with Swift than a C++ API that uses reference semantics.

If you call into library code that says nothing about errno, you can’t assume that it preserves its value. But POSIX says that no function sets it to zero: https://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html No function in this volume of POSIX.1-2017 shall set errno to 0 Does macOS claim to comply with (this version of) POSIX?

So were you previously calling requestGeometryU-date… from a non-main thread? Most of UIKit must be called from the main thread. Did you get any warnings about that? If not, check your build settings to see if you have the UIKit main thread checker enabled.

Apple requires a US prescription if you wear glasses. Isn't this just a matter of translating mm to inches, or something?

If you want to send Apple a "Legal Notice", this is not the place to do it. See section 14.5 of the developer agreement: 14.5 Notices Any notices relating to this Agreement shall be in writing, except as otherwise set forth in Section 14.3. Notices will be deemed given by Apple when sent to You at the email address or mailing address You provided during the sign-up process. Except as set forth in Section 14.3, all notices to Apple relating to this Agreement will be deemed given (a) when delivered personally, (b) three business days after having been sent by commercial overnight carrier with written proof of delivery, and (c) five business days after having been sent by first class or certified mail, postage prepaid, to this Apple address: Developer Relations Legal, Apple Inc., One Apple Park Way, 37- 2ISM, Cupertino, California, 95014 U.S.A. You consent to receive notices by email and agree that any such notices that Apple sends You electronically will satisfy any legal communication requirements. A party may change its email or mailing address by giving the other written notice as described above.

Why? It sets a block size of 16 MiB for files that are larger than 16 MiB, or uses the file size itself for files that are smaller. What do you think happens for files that are smaller than the block size? Do you imagine that it somehow reads beyond the end of the file on the disk until it reaches the block size you have specified? No, it won't do that (for all sorts of reasons). But don't listen to me. You were doing benchmarks above. Continue to use benchmarks to determine what is best.

bsize = min(size, bsize) I'd be amazed if that made any difference.

Here's a quote from the docs: Automatic price updates help your global earnings stay consistent, customers aren’t incentivized to seek lower prices on certain storefronts, and pricing mistakes are reduced. Ha ha ha ha ha!

I've filed FB13529395; slightly edited below: Automatically generated prices round down to $x.99, eliminating my profit! If I set the price of an app or an IAP to GBP 1.39, with the "base country or region" set to United Kingdom, and enable automatic pricing for all other regions, then App Store Connect selects a price for the USA of USD 0.99. Proceeds from the GBP 1.39 sale are GBP 0.98. Proceeds from the USD 0.99 sale are USD 0.84. The current exchange rate is approx. USD 1 = GBP 0.79, so the US proceeds equal GBP 0.66. So my proceeds from a sale in the US are approximately two thirds of my proceeds from a sale in the UK. This is not what I expected from "automatic pricing". I had expected that this mode would set worldwide prices such that my proceeds would be almost equal from all regions. This was never an issue under the old, pre-2023 system; I therefore consider it a regression and a bug. It seems that the issue stems from your idea of "common pricing conventions", i.e. the idea that in the USA and elsewhere prices "commonly" are $x.99, and you round to these prices. I believe you need to change this: When the price that I've chosen in the "base country or region" is not a "round" price, there is no reason why the prices automatically selected for other countries should be round. If I chose a "not-round" base price, you should definitely consider using "non-round" automatic prices. (Though if I have chosen a "round" price, that may only be by chance, not by design.) When rounding prices, you should round up, not down! Or, not round down by more than a small and disclosed amount (e.g. 5%). You would probably want to make some of this configurable, since some users will have got used to the present system. 4.. This discovery came as a considerable surprise to me. I suggest that these aspects of the behaviour of automatic pricing needs to be better documented, and the web interface should present warnings i.e. "Warning: automatic proceeds range from -X% to +Y% compared to base price depending on country/region". I am now faced with the prospect of changing from automatic to manual pricing. This is a huge pain as it means that I need to track exchange rates and regularly update all my prices.

Why would a price of 1.49€, about 1.60$, round to 0.99$? Because the automatic only rounds to the standard tiers 0,99$, 1.99$. Why? I've checked the docs: https://developer.apple.com/help/app-store-connect/manage-app-pricing/set-a-price Automatically generated prices account for foreign exchange rates and certain taxes, and follow the most common pricing convention for each country or region. (My emphasis.) So the rationale is that they are using "common pricing conventions", i.e. in the USA it is common for prices to be $xx.99 but elsewhere xx.95 or xx.00 are more common, and Apple are doing us a favour by doing this so that we don't have to know what these conventions are. I guess that maybe it's true that a customer in the US will look at a price like $1.60 and say to themselves "What the fuck is $1.60? That's not a proper price! I'm not paying that. Why can't it be a proper price like $0.99 or $1.99 like everything else I buy?". But I doubt it. I don't really think that Apple is doing us a favour by rounding to these "common pricing conventions". Most importantly, it seems that they are rounding up or down to these prices. I would worry less if they were always rounding up to a "common pricing convention" price, but rounding down to $0.99 could remove all profit for some of my IAP items. Do file a bug!

Do you need to modify the file? Have you considered memory-mapping it?

I would set the prices manually but there seem no upload csv files Right. You need to use the App Store Connect API. It would be great if there were a trustworthy program you could use that would read from e.g. a csv file and talk to the API. But as far as I am aware, there is no such thing. The exchange rates seems to be completely off. Is this because it is only using the "round" $x.99 prices in the automatic currencies? If you look at $9.99 or EUR 10.00, are the results more sensible?

You need to visit the web site and click "accept" on the latest version of the developer agreement. Don't go to the "agreements" page. Go to the App Store Connect homepage and look for a banner with a yellow background.

You need to go to the website and click “accept” on the latest version of the developer agreement. If that doesn’t work, Wait 24 hours to see if something needs to time out. Then contact support.