Hi everybody! With latest updates on Ventura around 13.9.X, Sonoma 14.5 and upper, and most probably Sequoia, we notice a change on how to retrieve BSSID. We know Airport is discontinue, but also other commands are impacted by new security policies. Now, to make any command work in the proper way we need to ask for Location Permission. But here is where we are finding some issues to make it compatible with the new requirements. We have a web desktop app (Built with Electronjs) that use an mach-o executable (built on C++). This executable runs IOREG to retrieve the BSSID. One of the tries we did is to request the Location Permission on the parent/GUI app, but by doing this, IOREG was not able to retrieve the BSSID. Then, we try to look for a way to make a little test only with our executable. But in the attempt to, we do not found a way to trigger the location permission request, either manually or by a command. Is there a way to prompt the user from a terminal executable or the right way is to prompt from the GUI? Do we need to stop using Mach-o executable in c++ and move to a native mach-o executable in swift to be able to prompt from it (This executable runs in the machine frequently, several times per minute)? We are open to change the command if need it.

Hi, I'm encountering an issue when trying to upload a build to App Store Connect. I'm receiving an 'Invalid Binary' error with the following message: ITMS-91093: Invalid Binary - The app contains a binary [path to a zip file] that cannot be processed. The error appears to be linked to a folder containing zip files that is referenced in the 'Build Phases' under the 'Copy Bundle Resources' section. Everything was working fine until a few days ago.

Hello. Icon fonts such as Font Awesome 6 and react-native-vector-icons are being rejected submission with the automated Invalid Binary error. ITMS-90853: Invalid font - There was an error validating the font named 'FontAwesome6Free-Solid' at 'private-app-name/FontAwesome6_Solid.ttf'. ‘glyf’ table instructions. These fonts have previously worked over the course of the last 3 years without issue and just stopped working on Monday. GitHub is filled with related issues and bug reports. This is likely affecting thousands of apps.

A little bit of background: If you make an app with no compiled Arm64 binaries in the Content/MacOS folder, MacOS erroneously identifies it as an Intel based app. After launching the app, MacOS will prompt the user to install rosetta, despite the app running fine natively. I found a simple solution to this issue, either include a do-nothing compiled binary to Contents/MacOS, or add <key>LSArchitecturePriority</key> <array> <string>arm64</string> </array> to the plist. The problem is this change only fixes the issue if you also change the BundleID. If you run the app even once with the bad configuration, MacOS seems to cache the intel flag somewhere based on the BundleID. It does not seem to be cached in the usual places. How to reproduce: (On apple silicon) You probably already have rosetta, and it is a pain to remove, so a VM is likely needed. Make an empty app with Script Editor, export with file format: Application. Replace Example.app/Content/MacOS/applet with a script of the same name. Make sure the old applet is gone, don't rename it and leave it in the directory. I used: #!/usr/bin/osascript display dialog "Hello, world" Make it executable sudo chmod +x ./Example.app/Content/MacOS/applet Run the app and observe that it asks you to install rosetta Add the previously mentioned fix to you plist, including the BundleID change Run it again and observe that it now works Change your BundleID back. Running this now raises the rosetta prompt despite the fact that it runs fine on a clean install of MacOS. Things I have tried: Rebooting, no effect Reforming the app, no effect Reboot in recovery mode, no effect lsregister -delete, no effect ~/Library/Preferences, ~/Library/Caches, /Library/Preferences, and /Library/Caches, none contain an entry for the BundleId defaults delete, domain not found

In one of our apps (not sandboxed) the user can choose a file that matches one of the following UTTypes using an NSOpenPanel: UTTypeApplicationBundle UTTypeUnixExecutable UTTypeShellScript The selected file will then be launched under certain circumstances. This works pretty well but from time to time we see internal support tickets where people complain because the selected file is not executed. This only affects files of type UTTypeUnixExecutable and UTTypeShellScript for which the Unix permissions are incorrect. They are therefore not executable. I would now like to check in the app whether the selected file is executable. With app bundles this works without any problems with isExecutableFileAtPath:, but with the other file types this does not work. What is the recommended way to test this for the other files? Is there a better way than checking the POSIX permissions (and owner/group)? Thanks.

I've updated my mac to Sequoia (MacOS 15) beta, my iPhone to iOS 18 beta, and Xcode to Xcode 16 beta. Only then, I realized I couldn't publish app updates with Xcode beta (error in AppStore Connect). I tried using the non-beta Xcode version but got "Invalid Binary" during app review: ITMS-90111: Unsupported SDK or Xcode version - App submissions must use the latest Xcode and SDK Release Candidates (RC). For details on currently supported versions, visit: https://developer.apple.com/news/releases. I really need to publish updates and I can't wait for September. I can't downgrade my devices because that would require me to erase both my Mac and my iPhone (for testing), which is not something I can do. Is there any option I didn't think about? How can I publish app updates in the current situation? It really should be more explicit before updating that you can't release updates with the beta versions...

We have developed a software called xxxxxxxxxx, using the "react-native-star-io10" library (version 1.3.0) to communicate with Star Micronic printers. In older versions, we utilized this library solely for local network printer communication. In an unreleased test version, we attempted to add Bluetooth printer connectivity to the project. However, due to prolonged validation and approval processes by Star Micronic, we opted to remove this feature from the current version of the project. Currently, we are facing a major issue: when we remove the Bluetooth permission keys from the Info.plist file and archive the project, upon upload, we encounter the error "The status of version x.x.x has changed to Invalid Binary." However, when we add the Bluetooth permission keys back to the application, archive the file, and upload it, the software ultimately gets rejected during the In Review phase. We are not utilizing Bluetooth in this version of the software and wish to deliver this version to our users. We plan to add the Bluetooth feature in a future release. Please advise on how we can resolve this issue or if there are specific changes needed in our project asap. Thank you for your attention.

I've tried uploading a build through xcode, and transporter app with no luck. I have waited hours and it never completes. Also, I have tried using fastlane our main way of uploading builds and have included a verbose flag to see why the build upload never finishes or errors out. The problem is an endless loop of the following error: DEBUG [2024-05-09 16:11:52.04]: [altool]: "LocalUploadTask &lt;EF4ED1D8-1CB0-47F7-876B-C126DF9A3696&gt;.&lt;302624&gt;" DEBUG [2024-05-09 16:11:52.04]: [altool]: ), NSLocalizedDescription=A server with the specified hostname could not be found., NSErrorFailingURLStringKey=https://northamerica-1.object-storage.apple.com/itmspod11-assets-massilia-200001/PurpleSource211%2Fv4%2F22%2F2d%2F17%2F222d1786-e205-57c4-7c62-a8e88503ff18%2FNRkOOpVWKZwGMd9KSYr92VImlIecE45alTBupZzt5Z0_U003d-1715285171894?uploadId=951d5230-0e3f-11ef-be19-783fd2f0b3f1&amp;Signature={REDACTED}&amp;AWSAccessKeyId={REDACTED}&amp;partNumber=1&amp;Expires=1715889972, NSErrorFailingURLKey=https://northamerica-1.object-storage.apple.com/itmspod11-assets-massilia-200001/PurpleSource211%2Fv4%2F22%2F2d%2F17%2F222d1786-e205-57c4-7c62-a8e88503ff18%2FNRkOOpVWKZwGMd9KSYr92VImlIecE45alTBupZzt5Z0_U003d-1715285171894?uploadId={REDACTED}&amp;Signature={REDACTED}&amp;AWSAccessKeyId={REDACTED}&amp;partNumber=1&amp;Expires=1715889972, _kCFStreamErrorDomainKey=12} DEBUG [2024-05-09 16:11:52.04]: [altool]: 2024-05-09 16:11:52.048 DEBUG: [ContentDelivery.Uploader] Created new upload task (0x139d071e0) for part 1. DEBUG [2024-05-09 16:11:52.04]: [altool]: 2024-05-09 16:11:52.048 DEBUG: [ContentDelivery.Uploader] Saving uploader state (CDUploaderStateUploadAssetDescription) for identifier 'com.apple.cds_0C29B49B-B8A0-45FA-BFF3-10A7424FE286'. DEBUG [2024-05-09 16:11:52.04]: [altool]: 2024-05-09 16:11:52.049 DEBUG: [ContentDelivery.Uploader] There are 2 parts remaining to upload. DEBUG [2024-05-09 16:11:52.04]: [altool]: 2024-05-09 16:11:52.049 DEBUG: [ContentDelivery.Uploader] LOST 0 bytes for part 2. DEBUG [2024-05-09 16:11:52.04]: [altool]: 2024-05-09 16:11:52.049 DEBUG: [ContentDelivery.Uploader] Adding upload task 302627 for part 2.

Hi all, I'm attempting to generate an XCFramework that must maintain ABI stability. The framework is created from an SPM using the attached script generate-FK.sh. I does not work. Removing the flag BUILD_LIBRARY_FOR_DISTRIBUTION=YES and adding the flag -allow-internal-distribution to xcodebuild -create-xcframework everything is fine. Despite this resolves the problem, it results in the generated module not being ABI stable. However, when attempting the script approach, it generates the XCFramework but when used it raises an error in arm64-apple-ios-private.swiftinterface with no such file or module as soon as it encounters an import statement for ModuleX reading it. The package structure is attached as Package.swift and te obtained result XCFramework structure is as follows: MyLibrary.xcframework ├── Info.plist ├── ios-arm64 │ └── MyLibrary.framework │ ├── Headers │ │ ├── ModuleH-Swift.h │ │ ├── ModuleH.modulemap │ │ ├── ModuleC-Swift.h │ │ ├── ModuleC.modulemap │ │ ├── ModuleA-Swift.h │ │ ├── ModuleA.modulemap │ │ ├── MyLibrary-Swift.h │ │ └── MyLibrary.modulemap │ ├── Info.plist │ ├── Modules │ │ └── MyLibrary.swiftmodule │ │ ├── arm64-apple-ios.abi.json │ │ ├── arm64-apple-ios.swiftdoc │ │ └── arm64-apple-ios.swiftmodule │ └── MyLibrary └── ios-arm64_x86_64-simulator └── MyLibrary.framework ├── Headers │ ├── ModuleH-Swift.h │ ├── ModuleH.modulemap │ ├── ModuleC-Swift.h │ ├── ModuleC.modulemap │ ├── ModuleA-Swift.h │ ├── ModuleA.modulemap │ ├── MyLibrary-Swift.h │ └── MyLibrary.modulemap ├── Info.plist ├── Modules │ └── MyLibrary.swiftmodule │ ├── arm64-apple-ios-simulator.abi.json │ ├── arm64-apple-ios-simulator.swiftdoc │ ├── arm64-apple-ios-simulator.swiftmodule │ ├── x86_64-apple-ios-simulator.abi.json │ ├── x86_64-apple-ios-simulator.swiftdoc │ └── x86_64-apple-ios-simulator.swiftmodule ├── MyLibrary └── _CodeSignature └── CodeResources It's worth mentioning that the library must be compatible with both Objective-C and Swift, and Modules A, C, and H are imported into the MyLibrary module as @_exported modules, that is why I've included the headers and module maps. What is wrong? Thank you in advance for your assistance. Files: generate-FK.sh Package.swift

Hi all, I'm attempting to generate an XCFramework that must maintain ABI stability. The framework is created from an SPM using the attached script generate-FK.sh. I does not work. Removing the flag BUILD_LIBRARY_FOR_DISTRIBUTION=YES and adding the flag -allow-internal-distribution to xcodebuild -create-xcframework everything is fine. Despite this resolves the problem, it results in the generated module not being ABI stable. However, when attempting the script approach, it generates the XCFramework but when used it raises an error in arm64-apple-ios-private.swiftinterface with no such file or module as soon as it encounters an import statement for ModuleX reading it. The package structure is attached as Package.swift and te obtained result XCFramework structure is as follows: MyLibrary.xcframework ├── Info.plist ├── ios-arm64 │ └── MyLibrary.framework │ ├── Headers │ │ ├── ModuleH-Swift.h │ │ ├── ModuleH.modulemap │ │ ├── ModuleC-Swift.h │ │ ├── ModuleC.modulemap │ │ ├── ModuleA-Swift.h │ │ ├── ModuleA.modulemap │ │ ├── MyLibrary-Swift.h │ │ └── MyLibrary.modulemap │ ├── Info.plist │ ├── Modules │ │ └── MyLibrary.swiftmodule │ │ ├── arm64-apple-ios.abi.json │ │ ├── arm64-apple-ios.swiftdoc │ │ └── arm64-apple-ios.swiftmodule │ └── MyLibrary └── ios-arm64_x86_64-simulator └── MyLibrary.framework ├── Headers │ ├── ModuleH-Swift.h │ ├── ModuleH.modulemap │ ├── ModuleC-Swift.h │ ├── ModuleC.modulemap │ ├── ModuleA-Swift.h │ ├── ModuleA.modulemap │ ├── MyLibrary-Swift.h │ └── MyLibrary.modulemap ├── Info.plist ├── Modules │ └── MyLibrary.swiftmodule │ ├── arm64-apple-ios-simulator.abi.json │ ├── arm64-apple-ios-simulator.swiftdoc │ ├── arm64-apple-ios-simulator.swiftmodule │ ├── x86_64-apple-ios-simulator.abi.json │ ├── x86_64-apple-ios-simulator.swiftdoc │ └── x86_64-apple-ios-simulator.swiftmodule ├── MyLibrary └── _CodeSignature └── CodeResources It's worth mentioning that the library must be compatible with both Objective-C and Swift, and Modules A, C, and H are imported into the MyLibrary module as @_exported modules, that is why I've included the headers and module maps. What is wrong? Thank you in advance for your assistance.

A user of my software reports that it is not launching on MAC OS Monterey (Intel architecture, a model that cannot be upgraded to MAC OS Ventura). The error message is saying that "the application cannot be opened because it is not compatible with that particular type of Mac" (this is a paraphrase of the user, I haven't seen the actual message, I suspect it is in Portuguese). I am building my Java application as follows: Open JDK 17 Using jpackage for packaging the executable Signing and notarisation following best practice Distribution as a disk image (DMG) Building everything from a MacBook Pro with Ventura 13.4.1 This is working fine for distribution to (many) users with MAC OS Ventura, and it also works fine (with a different build process) for M1 Macs. I do not have an easy possibility to test and/or build with MAC OS Ventura and I do not have a theory where the problem could come from. Is there any way that Mac OS Monterey would not be compatible with a Java app built with the above parameters? If so, which? And: Can I tackle the problem from a MAC OS Ventura machine, or would I need yet another machine with MAC OS Monterey installed? Any pointers in the right direction would be greatly appreciated. Thanks, Thomas

I have testd with TestFlight but after I changed some code and info.plist, suddenly it says "Invalid Binary". Here are my info.plist changed which I got from my github repo. Diff code-block --- a/ios/Runner/Info.plist +++ b/ios/Runner/Info.plist @@ -2,22 +2,14 @@ <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> - <key>LSApplicationQueriesSchemes</key> - <array> - <string>https</string> - </array> - <key>NSPhotoLibraryUsageDescription</key> - <string>Enlingo needs access to your photo library to save your profile picture.</string> - <key>NSCameraUsageDescription</key> - <string>Enlingo needs access to your camera to take a profile picture.</string> - <key>NSMicrophoneUsageDescription</key> - <string>Enlingo needs access to your microphone to record your voice.</string> + <key>ITSAppUsesNonExemptEncryption</key> + <false/> <key>CADisableMinimumFrameDurationOnPhone</key> <true/> <key>CFBundleDevelopmentRegion</key> <string>$(DEVELOPMENT_LANGUAGE)</string> <key>CFBundleDisplayName</key> - <string>Enlingo</string> + <string>EnLingo</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> @@ -27,7 +19,18 @@ <key>CFBundleLocalizations</key> <array> <string>en</string> + <string>ja</string> <string>ko</string> + <string>hi</string> + <string>es</string> + <string>fr</string> + <string>de</string> + <string>pt</string> + <string>en</string> + <string>vi</string> + <string>zh_CN</string> + <string>zh_TW</string> + <string>zh</string> </array> <key>CFBundleName</key> <string>enlingo</string> @@ -54,8 +57,18 @@ <string>$(FLUTTER_BUILD_NUMBER)</string> <key>FLTEnableImpeller</key> <false/> + <key>LSApplicationQueriesSchemes</key> + <array> + <string>https</string> + </array> <key>LSRequiresIPhoneOS</key> <true/> + <key>NSCameraUsageDescription</key> + <string>Enlingo needs access to your camera to take a profile picture.</string> + <key>NSMicrophoneUsageDescription</key> + <string>Enlingo needs access to your microphone to record your voice.</string> + <key>NSPhotoLibraryUsageDescription</key> + <string>Enlingo needs access to your photo library to save your profile picture.</string> <key>NSSpeechRecognitionUsageDescription</key> <string>Enlingo needs access to your microphone to record your voice.</string> <key>UIApplicationSupportsIndirectInputEvents</key> @@ -69,15 +82,10 @@ <key>UISupportedInterfaceOrientations</key> <array> <string>UIInterfaceOrientationPortrait</string> - <string>UIInterfaceOrientationLandscapeLeft</string> - <string>UIInterfaceOrientationLandscapeRight</string> </array> <key>UISupportedInterfaceOrientations~ipad</key> <array> <string>UIInterfaceOrientationPortrait</string> - <string>UIInterfaceOrientationPortraitUpsideDown</string> - <string>UIInterfaceOrientationLandscapeLeft</string> - <string>UIInterfaceOrientationLandscapeRight</string> </array> </dict> </plist> any suggestion or help would be appreciated... and one more question... I tested with storekit in XCode with copy-scheme. Is it relevant to "Invalid Binary" that I have storekit cert and configuration? I know it sounds ridiculous - catch a straw....

We have a huge project. Until today we didn't use an .app but now we must in order to use Endpoint security and other stuff. Until today our binary sat in /opt/XYZ/binary.bin Now because of the .app, looks like it will have to be /opt/XYZ/Cool.app/Content/MacOs/binary.bin This change really breaks our code and will cause a massive code change. If I extract the binary from the app and place it in /opt/XYZ/binary.bin and run it, the process is killed. Is there a way to extract it from the app and run it from /opt/XYZ ? any tool, command, resource, etc' will be great.

I have a general question that confusing me. I am on M1 and I can build my app on Xcode (or create an archive) for device. Looking in to derived data I can see Debug-iphones (and simulators) folders, I can get the .app and drag/drop it to the simulator. When trying to run the app the app will crash with error: EXEC 14 Binary with wrong platform I understand that it wasn't build for simulators but rather it was build for devices and there fore the crash, but when thinking about it I dont understand why? (at least theoretically it shouldn't crash as it was build for arm64 ). Inspected the binary with lipo it was build for arm64. Comparing the binaries for simulator and device (with otool) I dont see a lot of difference except the rpath. So how does IOS knows it was build for device and not simulator (wrong platform)? is there a way to add some sort of relaxation (in the end both binaries were build for arm64).

What are the file differences between the IPA I created with Xcode, uploaded to the App Store, and the one downloaded to the end user's phone? Does any process other than encryption, re-signing, and app thinning cause changes in these files?

Hi, our app - that has been successfully being updated every few weeks on Testflight for years now - suddently (although still compiling and running fine on a device connected to Xcode) fails validation & upload to Testflight. The error message does not give any info, other than "Asset validation failed - The app contains one or more corrupted binaries. Rebuild the app and resubmit (ID: 718a52a4-fed6-49ac-a025-8d62f6285cd2)". The follow up email, says : We identified one or more issues with a recent delivery for your app, "Name of app" 1.23 (1.23). Please correct the following issues, then upload again. ITMS-90338: Non-public API usage - The app contains one or more corrupted binaries. Rebuild the app and resubmit.. If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. For further information, visit the Technical Support Information at http://developer.apple.com/support/technical/ ITMS-90426: Invalid Swift Support - The SwiftSupport folder is missing. Rebuild your app using the current public (GM) version of Xcode and resubmit it. There are no method names "listed above" whatsoever in our case. Have tried restarting, deintegrating pods and reinstalling, restarting xcode and computer, cleaning derived data etc - nothing works. In other SO or web similar cases, it seemed to be an Xcode issue that got resolved by Apple on their back end. Is that the case, if so what's ETA for fix? Otherwise any idea on where to search for the solution or what could be the issue? Thanks

After updating from MacOS 14.0 to 14.1 we got permission errors within an app we developed. We got an "operation not permitted" error if the app tries to access files on a samba network share which is mounted by another tool. Additionally, we got a "Permission denied" if the app tries to run programs outside the app, for example /usr/local/bin/ip. The app works fine on Catalina, Big Sur, Monterey, Ventura and Sonoma 14.0. The app and its components are codesigned and the app is notarized, no entitlements. In the Info.plist the NSNetworkVolumesUsageDescription key is set. Any ideas? Could it be that the app is sandboxed by default on MacOS 14.1? And we have to disable sandboxing via entitlement? Thanks for any input!

Since version 14, Instruments cannot find the binary to show disassembly of executable or library. It says: Error - Binary file for selected symbol is expected to be here: /Users/<user>/Library/Developer/Xcode/DerivedData/<project>/Build/Products/Release/<project>. The thing is that the path shown by Instruments is actually the right one, and of course the binary exists in this directory. Am I missing something somewhere ?