While not using XPC, The code in the following repo - https://github.com/johnboiles/obs-mac-virtualcam demonstrates how to communicate between a DAL plugin and a user space application. The code uses Foundation's distributed objects - https://developer.apple.com/documentation/foundation/object_runtime/distributed_objects_support?language=objc and it is very straightforward and easy to understand. Edit: Oh, I missed the part which says that distributed objects is deprecated :(

I had a somewhat different but similar issue when building on M1 MBP with Xcode running with Rosetta. Some of Apple's APIs failed and together with failing there is this error printed to the console. In my opinion this is some kind of a simulator bug and it is present as of Xcode 12.3. Maybe 12.4 solves it, but I did not try. Anyway, what solved it for me was to download iOS 13.7 simulator runtime and create a new simulator with this iOS version.

I found a workaround for this. I converted the SVG files to PDFs. It seems that the code which does the PDF rendering consumes less memory.

In the first paragraph, I meant to write [AVSpeechSynthesizer writeUtterance:toBufferCallback:].

I found a workaround, not sure if this is the correct way. The following will return the format which mainMixerNode will accept. [self.engine.mainMixerNode inputFormatForBus:0]

I experience the same error message with iPhone 11 Pro and other selected few models. It happens with extremely short assets encoded with MPEG-4 Part 2, using ffmpeg's -c:v mpeg4 option.

It looks like what I need was added in iOS 16 beta https://developer.apple.com/documentation/coregraphics/cgpath/3994964-intersection?changes=latest_minor&language=_5 So I guess I was right and currently it is not available. However for my particular case, I did not need the intersection path itself, only to stroke it so a colleague suggested to clip one path by the other and stroke the result and then switch roles and stroke the other part. Together the intersection path is approximately stroked (with some visual artifacts at intersection points)

It's June 2024, 2.5 years after this issue was reported and this issue still exists in Xcode 15.4! I know it is the same issue because closing the tabs like it was recommenced here solved it for me. This is a big disgrace for Apple that a bug in the most basic functionality of their editor which affects productivity of all of the developers does not get the priority it deserves. Xcode is already a can of bugs but this is a new level of pissing on its users.

Here is my non expert take on this. Deciding what to do with an unverified transaction is a business decision. You can ignore verification and unlock the content, although I have no idea why would someone decide to do this. In StoreKit 1, the equivalent of verifying a transaction required sending a receipt to your server. App developers who did not want to maintain a server and were willing to take the risk of hacking, simply handled all transactions. You should call finish() only after you unlocked the content. If you do not plan unlocking the content for unverified transactions, do not call finished(). Apple's example you provided is supporting this theory. I would cautiously speculate that the app should almost never encounter an unverified transaction unless the user is trying to do something funny with the device or a bug on Apple's side. Also notice that in a rare case transaction can change from unverified to verified. See this: https://developer.apple.com/documentation/storekit/verificationresult/verificationerror/revokedcertificate

Long shot and probably too late, but did you call finish() on these transactions?

I recommend to start by trying to run Apple's food truck example. Does it work when you run it? https://developer.apple.com/documentation/swiftui/food_truck_building_a_swiftui_multiplatform_app Although the example does not use beginRefundRequest, but instead use refundRequestSheet, if it does not work as well you can deduce the issue is with your environment and not with the code you wrote.

From the documentation: Call finish() to complete a transaction after you deliver the purchased content or enable the purchased service. Assuming you do not unlock the content for failed transactions, you should not finish them. I believe failed transactions can resolve eventually, so that's why they persist.

I had the same issue, and what resolved it was removing the quotation marks in the command. I see in your example, the quotation marks are not really quotation marks but a different unicode character. Notice the difference: correct: " incorrect: ” I think this happened because you copied the command from a website where they had them around placeholder arguments, and you wrote your AppleID etc in side those "quotation" marks. To resolve the issue, simply remove all quotation marks (or replace them with the correct version)

Is the issue that there is no transaction for this product in the entitlements, or is the issue that the originalPurchaseDate is not what you expect? To understand this, you need to get telemetry from your app (by either writing to a log and asking the user to export and send bit to you or by sending events to a server) I would recommend sending the current date, originalPurchaseDate and just in case also the purchaseDate (to see if there is any difference). However, my first suspect would be the time difference calculation. Maybe you took into account timezone differences where it is not required? The user who had an issue might be on a different time zone. Ask someone to review the code. Regarding your overall strategy, you should consider two things (which might not be real issues, depending on the popularity of your app and the motivation to "hack" it): Using the system time (eg Date.now) allows users to change the devices clock to a previous date. If they do it each time before launching your app they could get a "free trial" indefinitely. I believe originalPurchaseDate and purchaseDate do not take refunds into account. So a user might request a refund and re-purchase the IAP. This new transaction will have a later originalPurchaseDate and the old one will not appear in currentEntitlements anymore.

For the benefit of those who search for a solution for a similar problem and find this post through search. As I understand, Image takes all available space, however in this case the image is wider than the screen and has .resizable and scaleToFill modifiers which will make it to take more space than offered by the container. The container will resize accordingly, extending beyond the boundaries of the visible screen, and then offer more space to the other children including the text. To solve this, use .background modifier instead of a ZStack. I think adding .containerRelativeFrame([.vertical, .horizontal]) to the image will also work, though I suspect not as well if you want the background image to ignore safe areas.