Good to know that there will be a fix. In the meantime, is there any workaround? We're working with the new StoreKit testing stuff that is only available on Xcode 12. Having to rely on NSLog-debugging is the ultimate productivity killer!

Saw that too. Rebooted the phone and it went away.

Hi Rich, does this limitation also apply to subscription offer codes introduced with iOS 14? Is there any way to test these before launching the app in production? Thanks, Ortwin

Thanks, Rich. Great answer. I've one followup though: You mention "The bundle id is the same". Do you mean it is the same as for an individual purchase (with each app having its own bundle id in the receipt) or the bundle id is the same for both apps in the bundle? I assume the first, but I wanna be 100% sure.

This causes big trouble for our "Where To?" app. Our POI finder app links to more than 80 different apps to get directions. The app's core functionality is POI search. To offer turn-by-turn directions or directions including ticket purchase for public transport, we link to third party apps. Currently, we support more than 80 apps. Some apps have country-based URL schemes, so we have a total of 230 entries in LSApplicationQueriesSchemes. We need the canOpenUrl API to determine if we can offer a 3rd party directions app as "installed" or whether we should link to the App Store instead (using SKStoreProductViewController). While I understand your goal to limit fingerprinting, in our case, a totally valid use case is destroyed by this policy. We feel that linking to 3rd party apps creates a vibrant ecosystem of apps working together and focusing on their respective core competencies. Such a business model should not be punished just because there might be some apps abusing the API for finger printing purposes. We suggest to solve the problem in App Review instead. You could install a new rule that entries in LSApplicationQueriesSchemes must not be used for fingerprinting purposes and each entry must be linked somewhere from the app. Then it would be possible to reliably link to 3rd party apps and prevent abuse at the same time. An additional entitlement permitting a larger limit would also be possible though not needed in our view. Logged as FB9660602.

Yes, I do use self-sizing cells and the code works fine 99% of the time. Seems like a race condition.

@Rincewind I do think this is a serious oversight. Particularly with assets preserving vector data, we really should have fine-grained control over the button image size, irrespective of the image's native size. Imo, UIButton.Configuration.contentsInsets doesn't behave as advertised. It's defined as the distance from the button's content area to its bounds. So the image should be resized to fit in the content area. I've logged FB12471726.

+1, seeing this in Xcode 15 beta 4 as well. I also need to have -ld64 in my Other Linker Flags to use the old linker because PLCrashReporter suffers from a linker error with the new linker (FB12592304). Not sure if that makes a difference.

Thanks for the background info, Quinn. What is your recommendation to solve the problem? Could we replicate the C macro from Swift, specifying the dso parameter? How could we set it to the macro invocation (rather than the macro implementation) location?

The problem is not in the logToFile, since as you mention, #file and #line do the right thing. The problem is on the OSLog side. The log.log("answer: \(42)") logs with the file and line number of the macro, not the calling site. So the linked code location is always in the macro, making the link useless.

I’ve the same issue. My .sqlite file is 88 MB and my sqlite-wal is 1.5 GB! I tried to run VACUUM and: storeDescription.setOption(["incremental_vacuum": "0", "wal_autocheckpoint": "100", "wal_checkpoint": "TRUNCATE"] as NSDictionary, forKey: NSSQLitePragmasOption) Nothing helped. When I set a different journal_mode (DELETE or TRUNCATE), the app timeouts after 240 seconds when setting up Core Data. Any idea?