I need to quote each value with either an apostrophe or a double quotation mark, not an escaped one. Your values are quoted with apostrophes. The apostrophes are being escaped when you print the array. What are you really trying to achieve here? I imagine that printing the array of strings is not your final objective.

What output do you want when you print the array of strings? I guess that printing an array is using the elements' debugDescription, rather than their description. Or something of that sort. If you want a particular format you should write explicit code to do that.

So I filed a bug. I attempted to post the bug number here, twice, but the posts never appeared. Presumably they hit a spam filter, or something. Anyway, I see that the bug has been closed as "Investigation Complete - Unable to diagnose with current information". And no hint what additional information they need. I had attached screenshots very much like the ones @mediaspree posted at the top of this thread. This is beyond frustrating. Apple, WFT? The existence of the bug is bad enough, but just closing my bug report is so rude.

I have applied the changes as you have recommended but the other app still seems to "override" my app. Any suggestions on how to overcome this challenge? I don't think it's fixable. "File a bug" ha ha ha ha ha ha ha ROFL. It's worth checking exactly how this other app has defined its UTI. This is difficult, unless it is installable on your Mac; in that case you should be able to inspect its info.plist. FYI here is an Apple-recommended UTI for GPX, supplied to me by DTS in 2019: <key>UTImportedTypeDeclarations</key> <array> <dict> <key>UTTypeIdentifier</key> <string>com.topografix.gpx</string> <key>UTTypeReferenceURL</key> <string>https://www.topografix.com/gpx.asp</string> <key>UTTypeConformsTo</key> <array> <string>public.data</string> </array> <key>UTTypeTagSpecification</key> <dict> <key>public.filename-extension</key> <array> <string>gpx</string> </array> </dict> </dict> </array> I asked about the lack of a MIME section; they said that adding that would "not affect the comparison of the two types", which I took to mean that it is safe to add.

It's important that all apps that use GPX files use the same UTI definition. If they don't, issues like this can occur. My guess is that on one of your devices you have an existing GPX-supporting app with a slightly different UTI definition and on the other you don't. http://www.topografix.com/GPX/1/1 That's the XML namespace URL, which is not what you want. The recommended UTI reference URL is: https://www.topografix.com/gpx.asp You should probably also change the UTTypeConformsTo to public.data, though I believe this is not critical. If you search the forum you might find old threads where this was discussed. I believe it was first a problem in the iOS 13 era.

Has anyone filed a bug?

Has anyone else had a reply from Apple? I've just received a useless FAQ-style reply from them. No acknowledgement of a bug in sales & trends.

You've asked this question before: https://developer.apple.com/forums/thread/730747 Firstly, go and read something about floating point. The issues you are seeing are inherent to how floating point works. I bet there are some great explanations out there if you search, better than anyone could write here. Using an exact decimal data type can solve some of your problems. Specifically it can fix 0.1 + 0.2 = 0.3 and your other example, because these are a consequence of the number base - 0.1 is a terminating exact value in decimal, but a recurring fraction in binary - 0.0001100110011001100.... But it can't help with functions like sqrt and sin because the results of those functions cannot be exactly represented in any number base. Mostly likely you will want to show approximations to those values by limiting the number of significant digits.

See also: https://developer.apple.com/forums/thread/760995

READ THIS THREAD: https://developer.apple.com/forums/thread/760399 It seems that the numbers in Trends for the problematic period change dramatically if you change the timezone from UTC to PDT !!!!!

Here is a simple way to tally your sales against your recent payment showing in Payment and Financial Reports For me, it's close but not exact; it's about 1% out. I guess that could be explained by time zones, or something.

One problem with custom URL schemes is that anyone can provide an app that implements them. So if your banking app relies on bankofme: URLs opening its app, it's in trouble because some free cookiedumpster game with billions of installs could have a handler for bankofme: and scam the users. Universal links don't suffer from this problem. I don't know about redirecting to the app store based on a custom URL scheme; I don't think that's possible but I may have missed something. Redirecting to the app store when a Universal Link is not opened by an app is certainly possible though. As you note, this does require a website. It can be a rather trivial one though, easily implemented in an S3 bucket for pennies a month, or similar.

So still wondering about the "missing" $400. Do you see only even numbers for daily sales for the period June 20 - June 29 ?

What I observed and fascinating is that every unit number showing in Trends report from Jun 20 to Jun 30 is exactly double compared to actual sales showing in our in-app subscriptions management system Ah-ha! Well I don't have anything to compare with, but all of my sales for that period are even numbers! Do we think that they've not paid us at all for the last week, or do we think they've paid the correct (half) amount? I still think they've paid us just for the 3-week period but I could be wrong. I launched something new in the middle of all this which makes it more difficult to see what is going on.

Oh wow. I believe they have paid us for the period ending a week earlier, i.e. ending June 22, not June 29. For most of my apps & IAPs, I see numbers in the financial reports that are about 75% of the numbers in Sales & Trends. But in the case of one new item that I added towards the end of June I see only 10% of the expected number, which I think is a "smoking gun". Time to ask what's going on!