Thanks. I just wanted to acknowledge that this release (1.3.1) resolved my issue with the error message without having to remove the LSMinimumSystemVersion key. Thanks.
billdog
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Lacking any feedback on my comments, I proceeded with the suggested solution as the app was successfully delivered to the App Store Connect when this key was removed and still allows running on a Mac with Apple Silicon.
Yes, this seems to have resolved the error I reported by just removing it. I have not delivered the app to App Store Connect so I will hold off accepting the answer until I can perform this step. However, the documentation for LSMinimumSystemVersion seems to indicate it should be >= 11 if your iPad or iPhone app links against the iOS 14.3 SDK (or later) and can run on a Mac with Apple silicon. Can you comment/clarify on this?
BTW, I was able to restore the prior Transporter version (1.2.5) from a Time Machine backup before updating it from the App Store. So, that might be a workaround until this is resolved or the cause of the issue is known.
Thanks for the reply. So, if the suppression file is part of the bundle (note: this is not clear in the documentation), how is it referenced from the PERFC_SUPPRESSION_FILE environment variable? Is it just the name of the resource file? Or relative path? Can you provide an example? (1) I will open a bug report with the requested data/images. (2) the app is 100% Swift but I can provide the addiotnal information if that will help.
I can suppress them all by turning the Thread Performance Checker off...but there are other featires of that tool (QoS, etc.) where we may need to know as we progress. So I wanted to only supress the ones we will take care of later. And that doesn't seem to be working per the documentation.
xTIN, thanks for taking the time to reply.
I understand the warnings but, as I mentioned, the codebase is very large and it will take time to resolve many of these. So my thinking was to suppress the known warnings until such time they can be addressed as they will just be noise until we can tackle them. However, there may be some warnings that could be isolated and tackled sooner. So, it isn't a matter of fixing the problems...it is a matter of time and process to systematically fix them.