Hello everyone. We have an app that has been on the App Store for several years, originally distributed for iOS and iPadOS only. Recently, we enabled Mac (Designed for iPad) and started distributing macOS-compatible builds. Current situation: The app is available and downloadable from the macOS App Store and runs correctly on Apple Silicon Macs. The same app/build appears in TestFlight on macOS, but cannot be installed. TestFlight shows the message: “This app can only be tested on an iOS device.” This suggests the app itself is Mac-compatible, but TestFlight is treating the build as iOS-only. Environment and checks performed: Mac is Apple Silicon. App Store Connect app-level availability for Mac (Designed for iPad) is enabled. The app is not Mac Catalyst; it is a UIKit iOS/iPadOS app. Distribution is done via GitLab CI. CI uploads use an App Store provisioning profile (Apple Distribution), not development or ad-hoc. iPhone and iPad TestFlight installs work as expected. Info.plist verification: UIRequiredDeviceCapabilities was originally present (armv7) and has since been: removed entirely, build number incremented, new builds uploaded to TestFlight. No other hardware capability requirements are declared. LSRequiresIPhoneOS = true remains unchanged. No other plist keys that should exclude macOS are present. CI / build considerations: The same uploaded build is accepted by App Store Connect and distributed successfully on the macOS App Store. This tells us the binary itself is valid for macOS, but TestFlight applies additional or different eligibility checks. At the moment we think that TestFlight eligibility may depend on build metadata, scheme/configuration flags, or internal App Store Connect state that differs from App Store distribution. Questions: Are there known cases where a build is valid for macOS App Store distribution but not eligible for macOS TestFlight installation? Does anyone know if TestFlight applies stricter or different platform gating than the App Store for “Mac (Designed for iPad)” apps? Are there specific build settings (e.g. SUPPORTS_MAC_DESIGNED_FOR_IPAD, TARGETED_DEVICE_FAMILY, scheme/config mismatches) that can affect TestFlight macOS eligibility independently of App Store eligibility? Is there an authoritative way in App Store Connect to inspect why a specific TestFlight build is marked as “iOS-only” for macOS? Any insight into TestFlight-specific eligibility rules for “Mac (Designed for iPad)” would be appreciated, especially given that App Store distribution for macOS is already working. I hope we're missing something very basic, and not that the app can't be tested as is for the mac, because it's useful to have our QA team test it on the mac.

We have initiated the development of a new application, which is exclusively compatible with Apple silicon chips. As our application utilizes artificial intelligence, it is not operational on Intel-based systems due to specific technical constraints. Using the Transporter app, we tried to submit a package that only supports arm64 but we received the following message: "Validation failed (409) Invalid bundle. The “live-mac.moises.ai.pkg/Payload/Moises Live.app” bundle supports arm64 but not Intel-based Mac computers. Your build must include the x86_64 architecture to support Intel-based Mac computers. For details, view: https://developer.apple.com/documentation/xcode/building_a_universal_macos_binary. (ID: 8b93f8c7-ac3d-4665-934a-e1a81832cc18)" Upon reviewing your documentation, I noticed that: "To only support Macs with Apple silicon, your application must require a minimum OS version of macOS Monterey 12 or later and must never have supported Intel-based Macs." Given that we launched a universal package as our initial version, I would like to inquire if there are any alternative approaches that would allow us to limit the distribution of this application to exclude Intel chips.

Hi all, I’m trying to understand what’s possible with App Store Connect when using Universal Purchase across iOS and tvOS. We currently have an app that’s set up as a universal purchase for iOS and tvOS. What we’d like to do is: Keep the iOS app fully discoverable and available to new users in the App Store. Make the tvOS app not appear for new users (e.g., not show up in search / categories / product page for users who don’t already own it). Is there a supported way to effectively “hide” or remove the tvOS app from sale for new customers only, while keeping the iOS app live and discoverable, and while existing tvOS users are unaffected? If this isn’t possible at a platform level, are there any recommended best practices for deprecating the tvOS version of a universal purchase app without impacting the iOS listing or existing tvOS users? Thanks in advance for any guidance or pointers to official docs!

Hello, I'm wondering if there is a way to prevent a previously-Universal Mac Catalyst app from being available to Intel devices? I can't identify a mechanism that works from build to submit to review.

I have a MacCatalyst app that is published on the Mac AppStore. All seems fine and dandy on the released version. However, when I try to test a build on my Intel based Macbook using the TestFlight app it says it's not compatible. I've looked at the build on AppStore connect and I can see that it's a universal build with x86_64, arm64 architectures. I'm at a loss as to why Test Flight reports it as incompatible yet the Mac App Store says it is compatible.

My app encountered problems when trying to open an x86 audioUnit v2 on a Silicon Mac (although Rosetta is installed). There seems to be a XPC connection issue with the AUHostingService that I don't know how to fix. I observed other host apps opening the same plugins without problem, so there is probably something wrong or incompatible in my codes. I noticed that: The issue occurs whether or not the app is sandboxed. The issue does no longer occur when the app itself runs under Rosetta. There is no error reported by CoreAudio during allocation and initialization of the audio unit. The first notified errors appears when the unit calls AudioUnitRender from the rendering callback. With most x86 plugins, the error is on first call: kAudioUnitErr_RenderTimeout and on any subsequent call: kAudioComponentErr_InstanceInvalidated On the UI side, when the Cocoa View is loaded, it appears shortly, then disappears immediately leaving its superview empty. With another x86 plugin, the Cocoa View is loaded normally, but CoreAudio still emits kAudioUnitErr_NoConnection from AudioUnitRender, whether the view has been loaded or not, and the plugin produces no sound. I also find these messages in the console (printed in that order): CLIENT ERROR: RemoteAUv2ViewController does not override - and thus cannot react to catastrophic errors beyond logging them AUAudioUnit_XPC.mm:641 Crashed AU possible component description: aumu/Helm/Tyte My app uses the AUv2 API and I suspect that working with the AUv3 API would spare me these problems. However, considering how my audio system is built (audio units are wrapped into C++ classes and most connections between units are managed on the fly from the rendering callback), it would be a lot of work to convert, and I’m even not sure that all I do with the AUv2 API would be possible with the AUv3 API. I could possibly find an intermediate solution, but in the immediate future I'm looking for the simplest and fastest possible fix. If I cannot find better, I see two fallback options: In this part of the doc: “Beginning with macOS 11, the system loads audio units into a separate process that depends on the architecture or host preference”, does “host preference” means that it would be possible to disable the “out of process” behavior, for example from the app entitlements or info.plist? Otherwise, as a last resort, I could completely disable the use of x86 audioUnits when my app runs under ARM64, for at least making things cleaner. But the Audio Component API doesn’t give any info about the plugin architecture, how could I found it? Any tip or idea about this issue will be much appreciated. Thanks in advance!

In the beta of Icon Composer, I see macOS, iOS, and watchOS icons, but there is nothing about visionOS and tvOS. Those icons are particularly hard and it would be great if this app worked for developing icons for all Apple platforms. I tried asking this in a WWDC group lab, but they didn't get to it and suggested posting to the forum.

My apps are using UIRequiresFullScreen = YES in the info.plist. Now that this is deprecated for iPadOS 26+, I'm updating my apps and using the UIWindowScene's sizeRestriction property to ensure a certain minimum size of the window. I've enabled all orientations support for iPads in the plist as well as the supportedInterfaceOrientations property of the ViewController. On iPadOS 26, the following line works - windowScene.sizeRestrictrions?.minimumSize = CGSize(480,720) The window does not resize below the above threshold and everything works as expected. However on the iPad simulators for 18.x (with Stage Manager enabled), the above sizeRestrictions property is never set. It shows up as nil even after the views have been laid out. The simulator allows me to drag the window handle and shrink the window to well below the specified threshold, all the way down to a width of 375. Is there anyway I can set the sizeRestrictions for iPadOS 18.x and lower?

Only people using iPhone 15 and iPhone 15Pro (don't know about iPhone 15 plus or iPhone 15 pro max) are having problems with my App. All seems fine on 13, 14 and 16 as well as iPad The app is in testflight now. I cannot replicate the issue in MAC via virtual iPhone 15 , 15 plus, pro, or promax. What I see happening - it looks like users are seeing labels disappear, sometimes buttons are disappearing on the 15 pro and 15. I have an ingredient selection page where you can select the ingredients that you have. These are outlined and grouped to make choosing ingredients intuitive. I have a profile selector where you can choose by flavor, strength, body or mood. At the bottom I have three buttons , button one lets you choose if drinks are sorted or strictly matched. The last button allows the user to see the drinks they can make based on ingredients they have.This is done by matching the ingredients with a locally placed drinks list which contains a drink id, drink name, ingredients and profile information. Clicking the last button opens a flatlist. Users on iPhone 15 and iPhone 15Pro iOS 18 sometimes experience the three buttons at the bottom being gone altogether. then returning. After clicking the Drinks Available button the button label should change to hide available drinks, but sometimes that label disappears. The drinks flat list has space for many drinks but the labels for those drinks are not present until halfway down the list where one drink shows up. No other device behaves this way. It might be more common when there are large number of ingredients selected ....e.g., if about 50% of 211 ingredients selected it might be more likely to happen. This needs to be tested to verify,

Our app is currently live on the App Store as a universal app (iPhone + iPad) and supports a subscription model — meaning users with an active subscription can access the app on both devices. We recently redesigned the iPhone UI and would like to push an iPhone-only update, without affecting the existing iPad experience (which remains unchanged). The goal is to prevent iPad users from receiving the new update, while iPhone users get the latest UI enhancements. Questions: Is it possible to release an update that targets only iPhone devices while keeping the current version available for iPad? If yes, what are the proper deployment or App Store Connect configurations required to achieve this? Any guidance or clarification would be greatly appreciated. Thanks in advance!

Hello guys! I faced a problem with building... My device suddenly updated to iOS 15.4.1, my Xcode was 13.2 and I had to update it to the latest version (13.3.1) to build the app. After the update, I had a few problems which were successfully solved but one of them stopped me for a few hours. The problem is with Bridging Headers or Swift Compiler, I really don't know what I did badly, and what causes problems. On several forums I often read that is important to set: Build Settings > Build Options > Build Libraries for Distribution But in any case it doesn't work, on yes: error: using bridging headers with module interfaces is unsupported on no: (line with import framework SWXMLHash) /Users/blablabla/SSLModel.swift:9:8: error: module compiled with Swift 5.5.1 cannot be imported by the Swift 5.6 compiler: /Users/blablabla2/Build/Products/Debug-iphoneos/SWXMLHash.framework/Modules/SWXMLHash.swiftmodule/arm64-apple-ios.swiftmodule import SWXMLHash It will be important that I use Carthage. What should I do? Clone all 10 frameworks that I use and re-build them with a new Xcode which includes compiler 5.6? That may be a bad solution... Any answers on similar topics don't help..

I have hosted my AASA file in https://powerbrowser.app/.well-known/apple-app-site-association in signed format as per documentation. I still can not see open in app button when open a link by long press. By the way i have activated 'Associated Domains' and put proper entitlements as per documantation.

"Rosetta was designed to make the transition to Apple silicon easier, and we plan to make it available for the next two major macOS releases – through macOS 27 – as a general-purpose tool for Intel apps to help developers complete the migration of their apps. Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks." What will happen to Rosetta 2 then? Most importantly, will the ability to emulate x86_64 containers and binaries in virtual machines persist? Will Rosetta 2 be blocked only from the App Store? Will apps be barred from Rosetta, only games be able to use it? Will it only support frameworks?

I am worried that Rosetta 2 will eventually be removed. I rely on it to run x86-64 Docker containers as well as Windows games through the Game Porting Toolkit. I also use CrossOver very often, which relies on Rosetta. I also use an old version of MuseScore that needs it, and every now and then, I download a legacy Intel Mac app. Thus, I'm worried that Apple will no longer offer it for download in future macOS versions. Are there any plans to remove Rosetta? Since Rosetta is only installed on demand, I have a slight bit of reassurance that it might be offered for download indefinitely, since most casual users naturally won't install it in the future as most general consumer apps are compiled natively for ARM, and the on-demand install cuts down on the bloat included with macOS by default. I hope Rosetta could be offered indefinitely, since many pro-users and gamers rely on it very often, even 10 years from now when Intel Macs are completely unsupported. If Rosetta is removed, I might have to switch back to Windows for many tasks, so I really hope for the continued offering of Rosetta.

This is recipe I used to do. Create new project. eg. Storyboard, Objective-C Select Project, Go to Build Settings > Architectures Change "Build Active Architecture Only" to "NO". Build... Go to build directory and check with "lipo" command > lipo -info Products/Debug/my-test.app/Contents/MacOS/my-test Architecture in the fat file: Products/Debug/my-test.app/Contents/MacOS/my-test are: x86_64 arm64 This has been working for Sonoma. However, I followed the same procedure in Sequoia, (Sequoia 15.5 Xcode 16.2), it's showing arm64 only. Architecture in the fat file: Products/Debug/my-test.app/Contents/MacOS/my-test are: arm64 Does anyone have any idea how to build Intel compatible binary in Sequoia dev environment?

Hi, I have developed iOS app using Cordova platform, now I am trying to open the upi app which is not happening. Can anyone guide me how to do this. From my app i am hitting the below URL location.href='phonepe://'

The product archive package's signature is invalid. Ensure that it is signed with your "3rd Party Mac Developer Installer" certificate. (90237) I'm receiving this error, despite the fact that I'm using this certificate when creating the pkg (with electron-forge) My configuration is shown below - note the 3rd Party Mac Developer Installer identity when using new MakerPKG. const config: ForgeConfig = { packagerConfig: { asar: true, name: 'Deep Focus', icon: 'resources/icon.icns', osxSign: { identity: 'Apple Distribution: Timeo Williams (3Y4F3KTSJA)', type: 'distribution', provisioningProfile: '/Users/timeo/Desktop/Deep Focus/deepWork/distribution.provisionprofile', preAutoEntitlements: false, // eslint-disable-next-line @typescript-eslint/explicit-function-return-type optionsForFile() { return { entitlements: 'build/entitlements.mas.plist' } } }, extendInfo: 'build/info.plist', osxUniversal: { mergeASARs: true }, appCategoryType: 'public.app-category.productivity', appBundleId: 'com.electron.deepfocus', extraResource: [ 'resources/.env', 'resources/icon.icns', ] }, rebuildConfig: {}, makers: [ new MakerSquirrel({}), new MakerZIP({}), new MakerRpm({}), new MakerDeb({}), new MakerDMG({ appPath: './out/Deep Focus-darwin-arm64/Deep Focus.app', name: 'Deep Focus', icon: './resources/icon.icns', format: 'ULFO', overwrite: true, contents: (opts) => [ { x: 130, y: 220, type: 'file', path: opts.appPath }, { x: 410, y: 220, type: 'link', path: '/Applications' } ] }), new MakerPKG({ name: 'Deep Focus', identity: '3rd Party Mac Developer Installer: Timeo Williams (3Y4F3KTSJA)' }) ], plugins: [ new VitePlugin({ build: [ { entry: 'src/main.ts', config: 'vite.main.config.ts', target: 'main' }, { entry: 'src/preload.ts', config: 'vite.preload.config.ts', target: 'preload' } ], renderer: [ { name: 'main_window', config: 'vite.renderer.config.mts' // Path to Vite config for renderer process } ] }), new FusesPlugin({ version: FuseVersion.V1, [FuseV1Options.RunAsNode]: false, [FuseV1Options.EnableCookieEncryption]: true, [FuseV1Options.EnableNodeOptionsEnvironmentVariable]: false, [FuseV1Options.EnableNodeCliInspectArguments]: false, [FuseV1Options.EnableEmbeddedAsarIntegrityValidation]: true, [FuseV1Options.OnlyLoadAppFromAsar]: true }) ] } Yet, I'm getting the error from Transporter that it's invalid?

TestFlight on Mac shows that the App only supports iOS, but support for Mac has been enabled in Xcode configuration and on the web page. Even if I build directly with a version from a few months ago, I still have the same problem. The minimum macOS version of the build metadata on the web page is blank. My environment is Xcode 16.1 macOS 15.1

I have a macOS application built via command line (xcodebuild) using Xcode 16.1. Developed on ARM but end user is on Intel (same macOS 15.1). App crashed and they sent me a .IPS dump. From what MacGPT tells me: Reading an IPS (Incident Processing System) file from a macOS crash report in Xcode isn’t as straightforward as with iOS device logs. I can open the dump using Console. I see the IPS dump is partially symbolicated. Line in the dump says: Meteorologist 0x103e0348f 0x103d88000 + 504975 Referencing this article: Adding identifiable symbol names to a crash report | Apple Developer Documentation I run this command and see the same UUID for x86_64 as in the dump. dwarfdump --uuid /Users/ed/meteorologist/trunk/Build/Meteorologist.xcarchive/dSYMs/Meteorologist.app.dSYM/Contents/Resources/DWARF/Meteorologist I run this command: atos -arch x86_64 -o /Users/ed/meteorologist/trunk/Build/Meteorologist.xcarchive/dSYMs/Meteorologist.app.dSYM/Contents/Resources/DWARF/Meteorologist -l 0x103d88000 0x103e0348f And it says: fg: no current job Suggestions for what I’m missing?

I have developed and distributed a Mac app on App Store. From the Organizer in Xcode, I noticed that it has a lot of crashes. And 90% of these crashes is the same crash as following: Thread 0 Crashed: 0 libsystem_kernel.dylib 0x00007ff81ce27112 __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007ff81ce5d233 pthread_kill + 263 2 libsystem_c.dylib 0x00007ff81cda9d10 abort + 123 3 libc++abi.dylib 0x00007ff81ce1a0b2 abort_message + 241 4 libc++abi.dylib 0x00007ff81ce0b1fd demangling_terminate_handler() + 266 5 libobjc.A.dylib 0x00007ff81cd08509 _objc_terminate() + 96 6 libc++abi.dylib 0x00007ff81ce194d7 std::__terminate(void (*)()) + 8 7 libc++abi.dylib 0x00007ff81ce19488 std::terminate() + 56 8 libdispatch.dylib 0x00007ff81cca6cdd _dispatch_client_callout + 28 9 libdispatch.dylib 0x00007ff81cca9746 _dispatch_continuation_pop + 460 10 libdispatch.dylib 0x00007ff81ccbaa5a _dispatch_source_invoke + 2150 11 libdispatch.dylib 0x00007ff81ccb3518 _dispatch_main_queue_callback_4CF + 759 12 CoreFoundation 0x00007ff81cf625d9 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 9 13 CoreFoundation 0x00007ff81cf236ae __CFRunLoopRun + 2752 14 CoreFoundation 0x00007ff81cf2252d CFRunLoopRunSpecific + 563 15 HIToolbox 0x00007ff825b403e1 RunCurrentEventLoopInMode + 292 16 HIToolbox 0x00007ff825b40137 ReceiveNextEventCommon + 587 17 HIToolbox 0x00007ff825b3fed5 _BlockUntilNextEventMatchingListInModeWithFilter + 70 18 AppKit 0x00007ff81f94d8f0 _DPSNextEvent + 886 19 AppKit 0x00007ff81f94bf5c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1411 20 AppKit 0x00007ff81f93e359 -[NSApplication run] + 586 21 AppKit 0x00007ff81f9121f8 NSApplicationMain + 816 How to fix this issue?