Hi We are building a VPN app (PacketTunnelProvider) and allowing users to install the app through test flight and app upgrade works seamlessly without VPN, but immediately after enabling the VPN, we are not able to get app upgraded with the progress bar in test flight stuck at 90 percent and now app is not usable after that but VPN is still working. We are not noticing the issue on ios 12.4.1 version but facing the issue on iOS 13 versions. On looking through console app during upgradation process we are noticing a below recurring log message. Error acquiring hold on plugins for <bundle_identifier>: Error Domain=PlugInKit Code=14 "plugins are busy" UserInfo={busyPlugInUUIDs=({         XPCExtensionBundleIdentifier = "<bundle_identifier>.tunnel";     } ), NSLocalizedDescription=plugins are busy} Could someone please help us in resolving the issue.

I'm currently experiencing the same problem that many have had with error 422 "Beta contract is missing." I read that I should contact Apple support, but when I try to access the support page and log in with my credentials, the page doesn't load and I can't generate a ticket to resolve this problem. I get the message "There was an error processing your request. Please try again later." And when I inspect with Safari it shows me this information: "errors" : [ { "id" : "9be0314c-3bd5-4143-a625-602322d7156e", "status" : "422", "code" : "ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING", "title" : "Beta contract is missing for the app.", "detail" : "Beta Contract is missing." } ] This is when I want to share the most recent build of my app with external groups through Testflight, but additionally, when my internal testers try to access it through Testflight app, it shows the error "The requested app is not available or doesn't exist." Could someone tell me what process I should follow or where I can correctly generate the ticket for my error? Since the Apple support page does not load. Thanks!

Hello everyone, We recently noticed a sudden and unexplained increase in our app's download and install sizes on App Store Connect. The jump happened literally overnight between April 2 and April 3. After auditing our commit history and running some isolation tests, it appears this increase is artificial and related to a change in App Store Connect's post-processing or size attribution logic, rather than our actual codebase. The initial observation: Build A (April 2): Download: 174 MB | Install: 380 MB Build B (April 3): Download: 179 MB | Install: 386 MB To figure out what caused the ~5 MB download and ~6 MB install jump, we looked at the diff between the two builds. We ran a local size analysis on the IPAs for both commits and the diff was just 18,287 bytes. Such a difference in the compiled binary absolutely does not account for a 5-6 MB jump in the final App Store Connect estimates. To completely rule out our code, we took the exact source tree from Build A (which originally processed at 174 MB / 380 MB) and pushed a fresh upload to App Store Connect. Re-uploaded Build A increased in size to 179 MB / 386 MB. Since re-uploading the exact same commit now results in the larger size estimates, it seems the discrepancy is not originating from our code. Has anyone else experienced a similar bump in their app sizes recently? Could an Apple engineer provide any insight into what might be causing this?

Beta testers outside the US, for our MacOS App, are being told their ID is not valid in the US Store and that they must switch to a store in their country. Yet the store switch fails Essentially beta testers outside the US cannot do testflight sandbox eCommerce for the Mac version of our app. Note that eCommerce on the Mac works for US based testers and eCommerce for the iOS/iPadOS works for testers in all territories. Many of these testers are in India, the UK and Canada. We believe that this is incorrect, that storeKit is not correctly detecting the AppStore Region for mac based testflight eCommerce. At this point we have 382 testers, most outside the US and we can only Beta Test our app with US users. Attached are images of the messages that are coming from storeKit: Here is a link to a video from a user in Canada who is demonstrating the problem (cut and paste into browser) https://youtu.be/kB818wfVld4 Here is another link to a video from a user in Canada who is demonstrating the problem (cut and paste into browser). https://youtu.be/7uAZKo8wpfU We see that there is another post with a similar problem. Similar eCommerce Problem Because eCommerce works in all territories on iOS/iPadOS but ONLY in the US for Mac we suspect that this is an error that either a DBA or a coder will need to fix. Any insights from anyone would be appreciated.

Hi I uploaded the zenweb mac app for review in TestFlight and it was rejected - after that I uploaded a new version - which was reviewed and approved. Since then all version I upload (TestFlight or App Store) are displayed in TestFlight but the Distribution - App Review is displaying only the link to the first app that was rejected. I have no way of submitting to app to review before publishing. Opened a cse with apple - 102876729124 - received a response from SB - to which I answered on 30 April 2026 since then - nothing - we re keen to deploy, Safari is lagging after Chrome and Edge solution now.

Hello Apple Developer Support, We are experiencing an issue with TestFlight Internal Testing. Our internal testers can see the app and the assigned build in the TestFlight app, but when they try to install it, the installation fails with the following error: "Could not install [App Name]. The requested app is not available or doesn't exist." This issue happens with Internal Testing, so Beta App Review should not be involved. We have already checked the following: The build was uploaded successfully through Xcode using App Store Connect distribution. The build processing is completed. The build is assigned to the correct Internal Testing group. The testers are added as App Store Connect users and have access to the app. The app appears in TestFlight for the testers. Agreements, Tax, and Banking do not show any pending actions. Export Compliance / Missing Compliance does not show any pending actions. The issue happens on multiple devices. We have tried removing and reinstalling TestFlight, and uploading a new build number, but the issue still occurs. App details: App Name: WearNow AR Try-On Bundle ID: com.yakovchuk.wearnow Apple Developer Team ID: 6G4QX44Y4A Could you please check whether there is an account-level, app-level, or TestFlight backend issue that prevents this build from being installed by internal testers? This looks similar to multiple recent Apple Developer Forums reports where the app is visible in TestFlight, but installation fails with "The requested app is not available or doesn't exist." Thank you.

"Could not install . The requested app is not available or doesn't exist." when installing app from TestFlight" I've tried uninstalling and reinstalling the app, and even removed older versions. I emailed support, but I still haven't found a solution. Does anyone know the solution to this problem?

Hi Our team is not able to install the app from testflight after April 30. Install stops with the following error The requested app is not available or doesn't exist." This is a blocker for us. Please help resolve this.

Hello, I’m experiencing two issues which I believe may be related to a single root cause: TestFlight Installation Error When I try to install my app via TestFlight for testing purposes, I receive the following error message: “Could not install app. The requested app is not available or doesn’t exist.” Unable to Add Build to External Testers When I attempt to add a build to an external testers group, I see the following error in the network tab after submission: { "errors" : [ { "id" : "95d240bd-94bd-4653-8d60-8dc691d6e3dc", "status" : "422", "code" : "ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING", "title" : "Beta contract is missing for the app.", "detail" : "Beta Contract is missing." } ] } I have reviewed and completed all required forms under Business → Agreements, and there are currently no pending alerts or agreements requiring action. At this point, I’m unable to proceed with testing my application and would greatly appreciate any guidance or suggestions. Additionally, I have an open support case that has not yet received a response: Case ID: 102855791526 Area: Distribution / TestFlight Thank you in advance for your help.

Hi everyone, We are investigating a possible iOS permission state issue after a device previously installed our app through TestFlight and later installed the production version from the App Store using the same Bundle ID. Environment: Device: iPhone 15 iOS version: 26.2.1 App distribution history: The app was previously installed through TestFlight and later installed from the App Store Permissions involved: Camera / Photos Issue: When the user opens the App Store version of the app and tries to access a feature that requires Camera or Photos permission, the iOS permission prompt does not appear as expected. Also, the app does not appear under: Settings > Privacy & Security > Camera or: Settings > Privacy & Security > Photos Because of this, the user cannot manually enable the permission. Another user on iOS was able to grant the permissions normally, so the issue appears to be isolated to the device that previously used the TestFlight build. Expected behavior: When the App Store version requests Camera or Photos permission, iOS should display the permission prompt, or the app should appear under Settings > Privacy & Security > Camera/Photos so the user can manage the permission manually. Actual behavior: The permission prompt does not appear, and the app does not appear in the corresponding privacy permission list. Possible cause: It seems like the device may be preserving or reusing a stale privacy permission state from the previous TestFlight installation, since both the TestFlight build and the App Store build use the same Bundle ID. Steps to reproduce: Install the app through TestFlight. Open the app and trigger a Camera/Photos permission request. Grant or deny the permission. Stop testing or remove the TestFlight version. Install the production version from the App Store using the same Bundle ID. Open the App Store version. Trigger the same Camera/Photos permission request flow. Go to Settings > Privacy & Security > Camera/Photos. The app does not appear, or the permission prompt does not behave as expected. Workarounds attempted or suggested: Close and reopen the app. Restart the iPhone. Delete and reinstall the app from the App Store. Stop testing the app from TestFlight. Reset Location & Privacy settings. Question: Has anyone experienced a similar issue where iOS does not show the permission prompt or does not list the app under Privacy & Security after switching from a TestFlight build to the App Store version with the same Bundle ID? Is there a recommended way to fully clear the previous TestFlight permission state, or should this be reported as a possible iOS/TestFlight permission state bug?

Hi,i am trying to provide my newest build to my testers.I have to provide some information in the invitation mail, since many of them are new to the process.But after inviting my self as a test, Testflight keeps sending the outdated app description in the invitation mail.For the specific build, i changed the "What to Test" content and i also changed the "Beta App Description" in the "Test Information" Tab.But Testflight still sends the old text, which is nowhere to be found anymore.Am i doing something wrong? How can i fix this?

Has anyone seen Managed Background Assets get stuck before any download progress is reported on iPadOS 26.3 / TestFlight? We are using Apple-hosted managed asset packs for a large on-demand model download. The app can resolve the asset pack metadata: we can show the asset pack’s download size in the UI, so AssetPackManager.assetPack(withID:) appears to work. But when we call ensureLocalAvailability(of:), the UI stays at 0% indefinitely. We also do not receive any useful terminal state from statusUpdates(forAssetPackWithID:): no .began, .downloading, .failed, or .finished. The app remains responsive. The issue also appears persistent on the affected device/account. Reinstalling the app does not help, reinstalling TestFlight does not help, logging out and back in does not help, and restarting the device does not help. After each attempt, the app can still resolve the asset pack metadata/download size, but the actual download remains stuck before any progress or failure status is delivered. The suspicious part of the device log is that the managed helper starts normally, fetches/installs the manifest from TestFlight, but repeatedly fails to create its helper directory inside the app container: OurApp Initializing the asset-pack manager… OurApp Creating a proxy object for the helper service… OurApp activating connection ... name=com.apple.backgroundassets.managed.helper.service kernel Sandbox: no system container path found for ID "com.apple.backgroundassets.managed.helper.service" Managed Background Assets Helper Service Starting the Managed Background Assets Helper Service… Managed Background Assets Helper Service Configuring the directory suffix… Managed Background Assets Helper Service The directory suffix was successfully configured. Managed Background Assets Helper Service The extension token "<...>" was consumed. kernel Sandbox: Managed Background Assets Helper(...) deny(1) file-write-create /private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service Managed Background Assets Helper Service mkdir: path=/private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service/ mode= -rwx------: [1: Operation not permitted] After that, manifest fetching still seems to work: OurApp The asset-pack manager has been initialized. OurApp The system download-manager delegate has been assigned to the download manager. OurApp The app was installed for internal beta testing; checking for updates automatically… OurApp Refreshing the manifest… Managed Background Assets Helper Service The app with the bundle ID "..." is configured to use Apple hosting. Managed Background Assets Helper Service Asking the TestFlight extension via the App Store Daemon for the URL request... Managed Background Assets Helper Service Fetching the download manifest ... from TestFlight… Managed Background Assets Helper Service Installing a manifest at ".../Library/Application Support/.../Manifest.json"... But during/after manifest install, the same mkdir failure appears again: Managed Background Assets Helper Service Installing a manifest at ".../Manifest.json"... Managed Background Assets Helper Service mkdir: path=/private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service/ mode= -rwx------: [1: Operation not permitted] kernel duplicate reports for Sandbox: Managed Background Assets Helper(...) deny(1) file-write-create /private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service So the behavior seems to be: TestFlight/internal beta install Apple-hosted managed asset pack Manifest fetch succeeds Asset pack metadata resolves, including download size Actual local availability request never starts reporting progress No visible Background Assets failure reaches the app Logs show repeated sandbox file-write-create denial for the Managed Background Assets Helper trying to create /tmp/com.apple.backgroundassets.managed.helper.service inside the app container Reinstalling the app/TestFlight, logging out and back in, and restarting the device do not clear the stuck state On devices with 26.4, the issue doesn’t seem to exist Has anyone else seen this on iOS/iPadOS/macOS versions before 26.4? Is this a known issue in the Managed Background Assets helper/runtime? I noticed 26.4 added more local status APIs for asset packs, so I’m wondering whether this area changed in 26.4. Any hints on whether the sandbox denial is expected/noisy, or whether it could explain ensureLocalAvailability(of:) never progressing, would be appreciated.

I’m experiencing an issue with subscriptions that behave differently between Xcode builds and TestFlight. Subscriptions work correctly when running the app directly from Xcode in a sandbox environment, but they do not work as expected when testing the same build through TestFlight. Has anyone experienced a similar issue with subscriptions working in Xcode but failing in TestFlight? Any guidance on what to check or debug would be appreciated. Additional details: iOS version: [ IOS 26] StoreKit version: [ StoreKit 2] TestFlight: When attempting to load the subscription products, the app returns “Product not found”. In some cases, it also shows the error “The subscription is unavailable in the current storefront”. This happens consistently in TestFlight, even though the same products load and work correctly when running the app from Xcode in the sandbox environment. Thanks

Hello, I'm experiencing a critical issue with my Flutter iOS app on TestFlight where the app shows a completely black screen immediately after launch. The app does NOT crash (no .ips logs in iOS Settings → Analytics & Improvements), but Flutter Engine appears not to start at all. The same code runs perfectly on Android. PROJECT INFO: App Name: CNC AI Assistant Bundle ID: com.beratech.cncassistant Team ID: 958PPWZD27 Provisioning Profile UUID: 8122ca65-b15f-4daa-b0d2-1da5409c6859 Build CI: Codemagic Flutter Version: 3.41.5 iOS Deployment Target: 14.0 Test Device: iPad15,3 running iOS 26.x ISSUE BEHAVIOR: Build succeeds on Codemagic without errors IPA is signed with valid distribution certificate TestFlight processes and accepts the build Tester downloads/updates from TestFlight successfully App opens → completely BLACK SCREEN immediately LaunchScreen.storyboard does not appear App does not auto-close (must be manually killed) NO crash logs generated in iOS Settings Same exact codebase works on Android (Google Play Internal Testing) DEBUGGING ALREADY ATTEMPTED: Replaced main.dart with MINIMAL code (only Firebase init + single Scaffold with white background and Text widget) - still black screen Removed flutter_secure_storage package (had a known iOS 26 keychain init crash) - still black screen Updated IPHONEOS_DEPLOYMENT_TARGET from 13.0 to 14.0 in pbxproj to match Podfile platform - still black screen Tried both empty entitlements and entitlements matching the provisioning profile (com.apple.developer.applesignin + keychain-access-groups) - still black screen Verified GoogleService-Info.plist is registered in pbxproj Verified LaunchScreen.storyboard exists and is valid Verified Info.plist has UILaunchStoryboardName = LaunchScreen and ITSAppUsesNonExemptEncryption = false AppDelegate.swift contains only GeneratedPluginRegistrant.register PROVISIONING PROFILE ENTITLEMENTS: application-identifier: 958PPWZD27.com.beratech.cncassistant com.apple.developer.applesignin: Default keychain-access-groups: 958PPWZD27.*, com.apple.token com.apple.developer.team-identifier: 958PPWZD27 get-task-allow: false (production) INSTALLED PLUGINS (from GeneratedPluginRegistrant.m): firebase_auth, firebase_core, firebase_storage, cloud_firestore purchases_flutter, purchases_ui_flutter (RevenueCat) sign_in_with_apple, google_sign_in_ios shared_preferences_foundation, path_provider_foundation webview_flutter_wkwebview, video_player_avfoundation url_launcher_ios, image_picker_ios, file_picker permission_handler_apple, package_info_plus, device_info_plus app_links, open_filex QUESTIONS: What could cause a Flutter iOS app to silently fail to launch on iOS 26 with no crash logs? Is there a known incompatibility between iOS 26 and certain entitlement configurations? Could there be a mismatch issue between the provisioning profile entitlements and the app's actual entitlements that causes silent termination on iOS 26 specifically? How can I obtain detailed launch/crash logs from the test device when no .ips file is generated? (sysdiagnose only shows system services like BackgroundShortcutRunner, not my app) Are there any iOS 26-specific changes related to TestFlight builds or Flutter Engine initialization that I should be aware of? I have full access to: Complete pbxproj Info.plist, Runner.entitlements, Release.entitlements Codemagic build logs Generated IPA file Provisioning profile (.mobileprovision) Screenshots of black screen on test device Any guidance on diagnostic next steps or known iOS 26 issues would be greatly appreciated. Thank you in advance.

I'm experiencing a persistent issue where my app uploads successfully to TestFlight and appears in App Store Connect, but internal testers (including myself) receive the following error when attempting to install: "Could not install xxxxxxxxx. The requested app is not available or doesn't exist." What works: The build archives and exports successfully via Xcode (local build, Release configuration) The IPA uploads to App Store Connect without errors via eas submit The build appears in TestFlight and passes processing I can add the build to my Internal Testing group Testers receive the TestFlight notification and can see the app What fails: When any tester taps "Install" or "Update," the download begins briefly, then fails with the "not available or doesn't exist" error This affects all internal testers on the account, not just one device Troubleshooting already completed: Verified code signing is correct: Release configuration uses CODE_SIGN_STYLE = Manual, CODE_SIGN_IDENTITY = "iPhone Distribution", with a valid App Store distribution provisioning profile (UUID: 39bc4c63-bc64-403a-a2a6-6737b3d33115) 2. Distribution certificate is valid: Serial 4838CD7571DE5361B98A5FB2F769F74D, not expired (expires 2027-04-16) 3. Regenerated provisioning profile via EAS credentials, removed stale profiles, and rebuilt — same result 4. Incremented build numbers correctly across multiple submissions (3004 → 3005 → 3006) 5. Previously resolved a signing misconfiguration (build 3005 was incorrectly signed with "Apple Development" instead of "iPhone Distribution" due to expo prebuild reverting settings) — this was corrected for build 3006, but the install error persists 6. Confirmed the build is not stuck in processing — it shows as ready for testing in App Store Connect 7. Tested on multiple devices running current iOS versions 8. Cleared TestFlight app cache and reinstalled TestFlight on test devices Why I believe this is a server-side issue: Multiple developers in the Apple Developer Forums have reported the identical symptom — valid builds that upload and process correctly but fail to install with this exact error message. In those cases, Apple Support resolved the issue on their end within 48 hours with no action required from the developer. The signing, provisioning, and build configuration were not the cause. This one is very specific to what I am dealing with https://developer.apple.com/forums/thread/778597 One developer stated you fixed it on your side, without any real reasoning which also leads me to believe this is not something I can fix on my end https://developer.apple.com/forums/thread/778597?answerId=884241022#884241022 I've exhausted all client-side troubleshooting and believe this may require intervention on Apple's side. Has anyone been able to fix this on their end and not only when App Development called? I went through tons of the feedback and tried it all and it doesn't seem to be fixed. It's been a month or so like this. I can't get any info on who to call. I sent in a report to feedback assistant and through app developer support

Hi there, In the last few days ALL TF builds i has been flagged as Expired. Uploading new builds to TF seems to be successful but we get a 404 on the download link. It doesn't exist! Client side we have seemingly exhausted all our lines of enquiry. All certification seems to be correct and intact, and we can publish to the store. We cannot distribute builds through TF - which is highly problematic and inconvenient. These issues seems to be happening to many developers but I've not seen Apple comment on this yet. https://developer.apple.com/forums/thread/823347 https://developer.apple.com/forums/thread/778597 https://developer.apple.com/forums/thread/778597?answerId=885232022#885232022 I offer this as a sidenote. We transferred an app from this store, successfully to another store. The timing at first seemed linked, but now having seen other reports, it may just have been coincidence. Thankyou for your attention.

Hi everyone, I’m currently implementing Tap to Pay on iPhone following Apple’s official documentation. I’ve completed all the required configurations (entitlements, capabilities, merchant setup, etc.) on the Apple Developer portal. However, when I archive the app and attempt to upload it to TestFlight, I receive the following error: "Profile doesn't support Tap to Pay on iPhone. Profile doesn't include the com.apple.developer.proximity-reader.payment.acceptance entitlement." From what I understand, this seems related to the provisioning profile not including the required entitlement, even though I believe everything has been configured correctly. I have already tried: Regenerating provisioning profiles Verifying App ID capabilities Ensuring the correct entitlements are added in the project But the issue still persists. Has anyone encountered this issue before? Is there any additional approval step required from Apple to enable the Tap to Pay entitlement? I’d really appreciate any advice or experience you can share. Thanks in advance!

Dear TestFlight Team! I am observing an increasing misuse of TestFlight public and private invites to distribute scam, spam, and potentially malicious builds: I had reported this already in December last year via Feedback assistant, but since the malicious behavior has not stopped, I hope that you can forward my bug reports to the right team: FB21379977, FB21845307 In multiple cases, these builds impersonate well-known apps (e.g. ChatGPT, OpenAI, Meta) by changing the app name and icon after an initial TestFlight approval, misleading users into installing software from unrelated developer accounts. I believe this represents a systemic weakness in the TestFlight review and update flow, enabling targeted phishing or malware distribution outside the App Store review process. My bug reports have attached: TestFlight invitation emails (.eml) Screenshots from TestFlight documenting impersonation behavior ⸻ Steps to reproduce Create a new Apple Developer account. Upload an initial, benign app (e.g. a calculator) as version 1.0.0 and obtain TestFlight approval. Upload a second build: without changing the version number increase build number Change the app name to a well-known product (e.g. “ChatGPT”) Change the app icon to match the impersonated product Invite targeted email addresses to the TestFlight group. Recipients receive an official TestFlight invite and are prompted to install the impersonating app. ⸻ Expected results TestFlight builds that significantly change app identity (name, icon, branding) should: Require additional review, or Be blocked from distribution without re-approval. Developer accounts should not be able to impersonate well-known companies (e.g. “OpenAI Platforms LLC”) without verification. Users should be protected from installing TestFlight builds that materially differ from what was originally reviewed. ⸻ Actual results App name and icon can be changed between TestFlight builds without triggering additional review. TestFlight invites can convincingly impersonate trusted brands. Targeted users may reasonably believe they are installing a legitimate beta. This creates a credible vector for: Phishing (credentials, payment details) Data exfiltration Social engineering attacks I did not install the builds to avoid personal risk, but the attached artifacts should allow Apple’s internal teams to reproduce and analyze the behavior safely. Some more examples:

Hi, We're experiencing inconsistent and unexpected values returned by Storefront.current?.countryCode when running our app via TestFlight. In our case: The device region and locale are set to Poland The App Store account (Media & Purchases) is also set to Poland However, when running a TestFlight build, Storefront.current?.countryCode sometimes returns a completely different value (e.g. "NO" for Norway), which does not match the current App Store account configuration. Here's the code we're using: if #available(iOS 15.0, *) { let code = await Storefront.current?.countryCode print("Storefront countryCode:", code ?? "nil") } What's particularly confusing: Across different devices logged into the same App Store account, we sometimes receive different countryCode values The returned value does not seem to reflect the current App Store region or device settings We understand that Storefront reflects the App Store storefront and not the device locale, but in this case the value appears stale or incorrect even with a properly configured App Store account. Questions: Is Storefront.current?.countryCode expected to behave differently in TestFlight vs. production builds? Are there known caching or propagation delays for storefront updates across devices? Can TestFlight builds return outdated or inconsistent storefront values? What is the recommended way to reliably determine the user's App Store region in this scenario? We rely on storefront to determine regional availability of features, so understanding this behavior is important for us. Thanks in advance for any clarification!

Hello, I'm experiencing an issue with accepting testflight invitations. The workflow: Developer invites me through Connect I am receiving the email and clicking Accept Invitation The link opens testflight, however I am immediately prompted with a "Couldn't Load App: This invitation has been revoked or is invalid. Request a new invitation from the developer." I hope this gets resolved quickly, I need to join the app testing. Thanks