We have encountered at least one case where receipt validation failed on macOS for a user, but would have succeeded when using the primary MAC address retrieved the "old style" (before #79).

shouldValidateSignaturePresence, shouldValidateSignatureAuthenticity and rootCertificateOrigin might be joined in some enumy way

Receipt validation may fail with receiptSignatureInvalid for actually valid new receipts (after 14 Aug. 2023).

In this case update AppReceiptValidator

This issue is just kept around to give info if you run into it.

For info about the reason, fix and workaround see: #89 (comment)

Related: #89

Some of the example receipts used in the tests are signed by now expired certificates, leading the tests to fail.
Ideally the example receipts should be updated.

Whenever I try to build my project that requires AppReceiptValidator I guess this error:

On Xcode 12 (12A7208), if I build the project using with the old command line tool from Xcode 11.7, the Carthage build works but building the project in Xcode results in this error:
Module compiled with Swift 5.2.4 cannot be imported by the Swift 5.3 compiler

If I update the Command Line tools to Xcode 12 (12A7208), and run 'carthage update --platform iOS', I get a failure with the following message:

Task failed with exit code 65. ....
This usually indicates that project itself failed to compile.

From the log file:

[....]
building for iOS Simulator, but linking in object file built for iOS, for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

** BUILD FAILED **

The following build commands failed:
Ld /Users/EdouardBarbier/Library/Caches/org.carthage.CarthageKit/DerivedData/12.0_12A7208/AppReceiptValidator/0.7.3/Build/Intermediates.noindex/AppReceiptValidator.build/Release-iphonesimulator/AppReceiptValidator\ iOS.build/Objects-normal/arm64/Binary/AppReceiptValidator normal arm64
(1 failure)

Any idea how we can get this fixed?
Thanks in advance and let me know if I need to provide more detais.

Happens here. Looks like was missed in #3?

This issue is not an issue to be solved, but for documentation purposes to help users of the framework when upgrading

If you have previously used AppReceiptValidator in Xcode frameworks and App Targets, you may now experience a
build error similar:

Unexpected duplicate tasks

This is due to: #86 (release https://github.com/IdeasOnCanvas/AppReceiptValidator/releases/tag/1.1.0)

If you are expecting and embedding it as a dynamic framework,

• replace all AppReceiptValidator mentions in your pbxproj project files with AppReceiptValidatorDynamic
• or alternatively try removing the embedding of the AppReceiptValidator from your app target(s) (linking being enough) and see if it works

First and foremost, thank you for creating this useful library!

I’ve started integrating it into my project for performing on-device app receipt validation. Since I’d like to utilize StoreKit Testing in Xcode, I have to differentiate the certificate used for validation (see this section). In the README, you show a snippet for this configuration step. However, I checked the source code and noticed that the configured certificate in AppReceiptValidator.Parameters isn’t used at all. While the certificate (represented as Data) is passed to checkSignatureAuthenticity(…), the certificate that gets used is the one extracted from the receipt.

I was wondering whether there should be a check for the correct certificate. If I understand it correctly, it should now be possible to create a receipt using an arbitrary certificate, and as long as the fields are matching, the library would interpret it as valid. Is my understanding correct? What would be the recommended way to fix this?

According to this link:
https://developer.apple.com/news/?id=ytb7qj0x
A certificate will change.
Will this impact users of this framework?

originalAppVersion
AppVersion
bundleIdentifier
productIdentifier
receiptCreationDate
…?

• Use less optional pointers?
• Parse beforehand, evaluate later?

It would be great to use AppReceiptValidator for iOS13/Catalina Catalyst apps. One option would be library compiled as new Xcode 11 .xcframework.

From Xcode 11 Beta Release Notes
XCFrameworks make it possible to bundle a binary framework or library for multiple platforms —including iOS devices, iOS simulators, and UIKit for Mac — into a single distributable .xcframework bundle that your developers can use within their own applications. An .xcframework bundle can be added to an Xcode target’s Link Libraries phase and Xcode uses the right platform’s version of the included framework or library at build time. Creation of XCFrameworks is supported from the command line using xcodebuild -create-xcframework. Frameworks or libraries bundled in an XCFramework should be built with the Build Libraries for Distribution build setting set to YES.

Another option would be library as CocoaPod that compiles with the rest of code.

Currently it only supports pasting in base64.

It would be nicer to return a struct indicating which validations succeeded and which failed next to the parsed receipt (or nil) instead of a success/erro enum.

Hello,

I'm considering to change the business model of my app from paid up front to freemium. I was going to use AppTransaction in StoreKit 2 to check for the originalAppVersion. Unfortunately AppTransaction doesn't support the volume purchase program and triggers an Apple ID sign in when an app was purchased through the VPP.

I was looking at this library and it looks like it should be possible to check for UnofficialReceipt.provisioningType for ProvisioningType.ProductionVPP to check if the app was purchased through the volume purchase program.

1. Does anyone have a sample VPP app receipt file so I could check a real-world example of how this would look like?
2. Does a VPP app receipt file contain the originalAppVersion or is it nil?
3. AppTransaction of StoreKit 2 has a field originalPurchaseDate that contains the original purchase date of the app itself while I cannot find this in the Receipt struct - only in InAppPurchaseReceipt. Is this not available outside of StoreKit 2, or is this field just not yet added to this library? I'm asking because if a VPP receipt did not contain the originalAppVersion, we could use the originalPurchaseDate of the app receipt instead.

Thanks for your help!

• Since existence of property validations, which are not part of allSteps, it is not all steps.
• Maybe add a constructor with all arguments as well?

to make p & po nicer

comparing with info-plist?

Type inference is not working correctly reliably, better just have the validateReceipt(parameters:) based method then.

This is something I have noticed while testing AppReceiptValidator: it always retrieves the same receipt with the same inapp purchases, even if I change the sandbox user. Why is that? Very strange.

What I mean is this: I run the app, it asks me for the App Store credentials, I login with a sandbox user, let's say [email protected].

I purchase a few items.

I run the app again with another app store credentials, [email protected]

I retrieve the receipt and it shows the inapp purchases that were purchased by [email protected].

Aren't the purchases bound to a specific user?

I am testing this under macOS. I have tried to purchase something with the second sandbox user to see if the receipt would refresh. NOPE.

Also tried several exit(173) + macOS restarts. NOPE.

Receipt always comes with the purchases done by the first user who purchased inapps with the application.

I suspect this is an error from Apple, what is expected, given their lack of love for developers.

Hello,

I have been using this library for years now. Thank you!
Is there a way to know if the user is eligible for free trial?

Best,

When dealing with SPM , we usually assume static linking.

Since SPM supports resources, there is no need for explicit '.dynamic' type of the library

Easiest way is to get need new builds of OpenSSL.

Related:

• #55
• https://gist.github.com/letiemble/6710405
• https://blog.andrewmadsen.com/2020/06/22/building-openssl-for.html

Anyone managed to compile an app for macOS Big Sur (Xcode 12.2) with AppReceiptValidator?

carthage update fails with the following logs:

`
Build settings from configuration file '/tmp/static.xcconfig.NVALzV':
EXCLUDED_ARCHS = $(inherited) $(EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_$(EFFECTIVE_PLATFORM_SUFFIX)_NATIVE_ARCH_64_BIT$(NATIVE_ARCH_64_BIT)_XCODE$(XCODE_VERSION_MAJOR))
EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200 = arm64 arm64e armv7 armv7s armv6 armv8
EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_12B5044c = arm64 arm64e armv7 armv7s armv6 armv8

note: Using new build system
note: Building targets in parallel
note: Using codesigning identity override:
note: Planning build
note: Constructing build description
error: The linked library 'libcrypto.a' is missing one or more architectures required by this target: arm64. (in target 'AppReceiptValidator macOS' from project 'AppReceiptValidator')
error: The linked library 'libssl.a' is missing one or more architectures required by this target: arm64. (in target 'AppReceiptValidator macOS' from project 'AppReceiptValidator')
`

See

• https://twitter.com/depth42/status/1314179654811607041
• https://mjtsai.com/blog/2020/10/08/date-format-change-in-app-store-receipts/

If this is true, we need to check that we allow parsing of old and new.

Unneeded Break in Switch Violation: Avoid using unneeded break statements. (unneeded_break_in_switch)

Failing tests

Expired receipts

• hannes_mac_mindnode_2_receipt
• purchasing_experiments_sandbox_receipt.b64

Rename following final discussions…

• Repository and project to AppReceiptValidator
• Main type to AppReceiptValidator
• Update Readme.md
• Rename Targets
• Rename Folders
• Rename Hekate in code headers
• Add ideas on canvas to readme … is brought to you by IdeasOnCanvas, the creator of MindNode for iOS, macOS & watchOS.