Overview

Apps should all be free then cost money after you play them like fortnite is free but is really popular and make a lot of money so other apps should be like that and have in game purchases to

Hello, according to reports from our users these two ManagedSettingsStore options seem to be stuck in the enabled state even after turning them off or removing screen time permissions and uninstalling the app that configured them. Is this possible? Has anyone seen it? The denyAppRemoval (https://aninterestingwebsite.com/documentation/managedsettings/applicationsettings/denyappremoval-swift.property) prevents the user from uninstalling any apps from their device when active. The denyAppInstallation (https://aninterestingwebsite.com/documentation/managedsettings/applicationsettings/denyappinstallation-swift.property) "hides" App Store, making it impossible to install any new apps. We haven't been able to replicate it yet. Does anyone know about workarounds when this happens? So far it seems like the only way is to reset the affected device.

We are evaluating the new behavior mentioned in the Nearby Interaction documentation for iOS 18.4+, which states: “In iOS 18.4 and later, your app can continue ranging in the background with any supported device if the app starts a Live Activity as it goes to the background." Could you clarify what situations are considered “can continue ranging” versus cases where it will not continue? Specifically, if my app: starts a NISession in the foreground starts a Live Activity with that data then the app goes to background should the NI session still deliver ranging updates so the app can update the Live Activity? also, my app already enable Background Modes capability

Given that we can't use isEligibleForAgeFeatures property on macOS, the documentation states that In macOS, isEligibleForAgeFeatures returns false because the system doesn’t require Age Assurance for the person or device. However, you can still call requestAgeRange in macOS to get the declared age range. But in unsuitable region the requestAgeRange request always returns DeclaredAgeRange.AgeRangeService.Error.notAvailable which is vague, as it might stand for API being unavailable just as well as "You receive this error when the system prompts a person and they decide not to share their age range with your app. ", as per documentation. Unfortunately, this error fires immediately instead of showing any kind of prompt for user, so the description is definitely wrong (or incomplete) in here. Possible solutions: expand Error cases to separate not available API and not available response expand isEligibleForAgeFeatures to properly support macOS Moreover, unlike iOS, there is still no usable tool or algorithm to test given feature for macOS (mock region, mock age, mock source of approval, revoke declared range, etc). Now I get a review with rejection, stating that I don't have age verification mechanisms present in my app. Also I found out that after filling the App Information regarding Age Ratings it spreads to all fresh releases, so even though my newest macOS release doesn't contain age verification mechanisms yet, it should, as iOS release has got this functionality up and running already and I had to check this when filling Age Ratings questionnaire. Now I'm stuck between removing this capability from App Information, so the macOS release can pass and stalling macOS releases until there is a proper usable API to implement Declared Age Range verification properly (at least the same way as on iOS). How should I properly develop and test this feature for macOS before releasing it publicly?

Hi App Review Team, I would like to raise a concern regarding the review process for our app update (Version 2.0.0), which has now been pending for over two weeks. We completely understand the importance of the review process, but the extended delay is starting to impact our business. This update is not a major change—the app already exists on the App Store, and Version 2.0.0 mainly includes UI improvements. The core functionality remains the same as the currently approved version. Additionally, the app has been rejected multiple times with the status “Information Needed.” We have been promptly providing all the requested information each time, but the repeated cycle is significantly extending the overall review timeline. We kindly request guidance on how to move forward more efficiently, or if there is anything specific we can provide upfront to avoid further delays. If possible, we would also appreciate support in expediting the review. Any help or clarification would be greatly appreciated, as this delay is leading to business loss. Thank you.

My app was submitted on February 14, 2026, and the Apple ID is 6758344632. It has now been over a month, but the app is still in Waiting for Review status. Could you please let me know when the review is expected to be processed?

I have a watchOS WidgetKit complication that needs the user's location to show the nearest transit station, but the widget never gets location permission and CLLocationManager times out. Setup: NSWidgetWantsLocation = YES in Widget Extension's Info.plist NSLocationWhenInUseUsageDescription and NSLocationAlwaysAndWhenInUseUsageDescription in Widget Extension's Info.plist Watch App successfully has location authorization Problem: The system never presents a location permission prompt for my widget. Apple's own World Clock widget does get one on watchOS (see screenshot) — I can't figure out what triggers it. When the widget tries to get location via CLLocationManager, the request times out and never returns a location. Questions: What triggers the system location prompt for a watchOS widget? Is NSWidgetWantsLocation sufficient or is something else required? Why would CLLocationManager time out and never return a location inside a widget extension? Is there a specific pattern required for requesting location in a WidgetKit timeline provider? Screenshots Sorry for swedish, but it says "Do you allow widgets from World Clock to use your location services?"

Hello, I have a question regarding how prorated refunds are reflected when a user upgrades a subscription. From my understanding, when a user upgrades to a higher-tier subscription, the remaining value of the current subscription is refunded as a prorated amount, typically represented as REFUND_PRORATED or PRORATED_CREDIT. However, when reviewing the available transaction history and refund-related data (including the App Store Server API and transaction history endpoints), I cannot find any field or record that clearly indicates: the actual prorated refund amount, or the credit applied when upgrading to another subscription In other words, while the concept of REFUND_PRORATED seems to exist conceptually, I cannot identify where the actual prorated value or credit applied to the upgrade is exposed in the transaction or refund history. My questions are: Is there any way to retrieve the actual prorated refund or credit amount when a user upgrades a subscription? Is this information available through the App Store Server API (e.g., Get Transaction History) or any other API endpoint? If not, is there any recommended method to determine how much of the previous subscription was credited toward the upgraded subscription? Any clarification would be greatly appreciated. Thank you for your help.

Stage Feed - Test Flight Link Tracking your favorite Artists, does NOT need to be so cumbersome! Please try our app, we would really love to have you! Any and all feedback would greatly be appreciated!

显示为——构建描述签名错误: 签名证书无效。签名证书；不可用于代码签名。它可能已被吊销或过期。、 目前是在Apple Developer 重新创建证书、生成描述文件了（显示的是有效）；但是下来出来放进打包里就显示证书失效是什么原因？

Is it possible to retrieve the position and orientation of a window that is opened in an immersive space? The following code: struct MyWindow: View { var body: some View { VStack { Text("Hello") } .onGeometryChange3D(for: Point3D.self) { proxy in try! proxy .coordinateSpace3D() .convert(value: Point3D.zero, to: .worldReference) } action : { point in print(point) } } } seems to work for the position, but I also need the orientation.

描述：低等级会员在 7 天免费期内订阅了高级会员 预期：低级会员的 7 天免费试用结束，高级会员直接扣费生效，苹果的升级通知如下： { "extra_info": { "quantity": 1, "expiresDate": 1754627893000, "purchaseDate": 1754623693000, "transactionId": "2000000979349440", "offerDiscountType": null, "originalTransactionId": "2000000979347229", // 升级前后没有变化 "subscriptionGroupIdentifier": "21729756" }, "decodedPayload": {}, "orgin_sku_name": "unlimited.minutes.per.year.v3", "payment_platform": "app_store", "decodedPayload_Renew": { "productId": "unlimited.minutes.per.year.v3", "autoRenewStatus": 1, "originalTransactionId": "2000000979347229" }, "decodedPayload_Trans": { "type": "Auto-Renewable Subscription", "price": 228000, "bundleId": "ai.plaud.ios.plaudzh", "currency": "CNY", "quantity": 1, "productId": "unlimited.minutes.per.year.v3", "signedDate": 1754623696459, "storefront": "CHN", "environment": "Sandbox", "expiresDate": 1754627293000, "purchaseDate": 1754623693000, "storefrontId": "143465", "transactionId": "2000000979349440", "appTransactionId": "704742096472000913", "transactionReason": "PURCHASE", "inAppOwnershipType": "PURCHASED", "webOrderLineItemId": "2000000107917134", "originalPurchaseDate": 1754623472000, "originalTransactionId": "2000000979347229", "subscriptionGroupIdentifier": "21729756" } } 异常 case：苹果通知升级到高级会员且继续剩余试用时间，例如：低等级会员7 天免费试用期剩余 4 天，升级到 4 天的高等级会员的免费试用，收到的通知消息如下： "extra_info": { "quantity": 1, "expiresDate": 1773109207000, "purchaseDate": 1772708455000, "transactionId": "550002836609836", "offerDiscountType": "FREE_TRIAL", "originalTransactionId": "550002832625469", //升级前后没有变化 "subscriptionGroupIdentifier": "21729756" }, "purchase_type": "upgrade", "decodedPayload": { "signedTransactionInfo": {}, "orgin_sku_name": "unlimited.minutes.per.year.v3", "payment_platform": "app_store", "decodedPayload_Renew": { "productId": "unlimited.minutes.per.year.v3", "autoRenewStatus": 1, "originalTransactionId": "550002832625469" }, "decodedPayload_Trans": { "type": "Auto-Renewable Subscription", "price": 0, "bundleId": "ai.plaud.ios.plaudzh", "currency": "CNY", "quantity": 1, "offerType": 1, "productId": "unlimited.minutes.per.year.v3", "signedDate": 1772708460325, "storefront": "CHN", "environment": "Production", "expiresDate": 1773108607000, "offerPeriod": "P7D", "purchaseDate": 1772708455000, "storefrontId": "143465", "transactionId": "550002836609836", "appTransactionId": "705330723507531368", "offerDiscountType": "FREE_TRIAL", "transactionReason": "PURCHASE", "inAppOwnershipType": "PURCHASED", "webOrderLineItemId": "550001244481732", "originalPurchaseDate": 1772507407000, "originalTransactionId": "550002832625469", "subscriptionGroupIdentifier": "21729756" } } 请问是苹果的会员试用的策略发生了变化吗

I am currently running iOS 26.4 Beta and have encountered a critical issue with the in-app purchase system. Due to a system malfunction in this beta version, I was charged multiple times for the same purchase. I have already submitted a formal refund request through the official channels; however, the request was rejected/not processed. Has anyone else experienced similar billing issues on this specific beta build? Any advice on how to escalate this, given that the standard refund process has failed?

We are trying to upload the first Apple-hosted Managed Background Assets pack for our macOS app, but Transporter rejects the asset pack ID during upload. App details: App name: DistillApp Apple ID: 6760288806 Bundle ID: cn.rkbkosp.DistillApp Asset pack ID: distill.pipeline.zh-baseline Platform: macOS Transporter: 1.4 Xcode: 26.2 macOS: 26.3.1 What we see in Transporter: Apple ID: 6760288806 App Name: DistillApp App Bundle ID: cn.rkbkosp.DistillApp No background assets found. And when we try to upload the first asset pack, Transporter fails with: 获取 Apple ID “6760288806”的资源包列表失败。 (-19243) There is an error with a URL parameter (400) Found invalid values: distill.pipeline.zh-baseline What we have already confirmed locally: The app resolves correctly in Transporter, so the Apple ID and bundle ID appear to be correct. The app Info.plist includes: BAHasManagedAssetPacks = YES BAUsesAppleHosting = YES BAAppGroupID = 8U6DAJ62JT.group.cn.rkbkosp.DistillApp.assets The asset pack manifest uses: assetPackID = distill.pipeline.zh-baseline This is intended to be the first Apple-hosted background asset pack for the app. Our understanding is that No background assets found is expected before the first successful upload, so the actual problem seems to be that Transporter/App Store Connect refuses to accept the initial asset pack ID. Questions: Has anyone seen Transporter reject the first Apple-hosted background asset pack for an app with -19243 and 400 invalid values? Does the first Managed Background Assets upload require any additional App Store Connect state beyond having BAHasManagedAssetPacks and BAUsesAppleHosting in the app? Does the app need a newly processed build in App Store Connect after enabling those plist keys before the first asset pack upload will work? Is there any known issue in Transporter 1.4 or App Store Connect for first-time Apple-hosted MBA uploads on macOS apps? If useful, I can also share the exact asset pack manifest and a redacted upload log.

I am trying to create keys for my personal project with MusicKit and other resources, but MusicKit specifically for now. I want to gather my recent music history and log the time in my system to measure with my other life data to do analysis on. I have created an Identifier with an appropriate Description and Bundle ID and have MusicKit checked in AppServices. I have saved and reset cash and waited all day and the keys have still not update and show "There are no identifiers available that can be associated with the key" in this field. Please help!

While WhatToTest..txt was being used in xcode cloud. I wish this feature should just being adopted to functioned from XCode archive and upload to set initial release note from the build pipeline directly from xcode in machine

Can you Make an GLOBAL IN REAL LIFE SIMULATOR ROLEPLAY.. Try to get 8 Different Developers to Help do it.. (Similar to Sims Play others Kind of that as well.. Gta Greenfiel rp in Roblox Minigame others as well..) Family Life Simulator Make it Realistic as can be.. The Server Could Add Billionaires or More then That on the Server & Add Multiple ppl on there in Online & Offline.. They Could Play it on ALL KINDS OF DEVICES & Android IPad Google Play IOS other Stuff too) Pls Pls Pls Pls.. I will Make a Image of it then I will Show it to you Guys to See what I want to be in the Game thnxs.. they could Have Wifi/Internet Hotspots & Offline..

Hi, I’m seeing a strange TestFlight issue. My builds process successfully in App Store Connect, appear in TestFlight, and are assigned to internal testers, but installation fails immediately with: “The requested app is not available or doesn’t exist.” What I’ve verified: • builds are processed/completed • apps are visible in TestFlight • internal tester groups are configured • agreements/banking/tax are active This affects multiple apps in the same developer account. The issue started after adding a widget extension and moving to a new Swift-based workflow, so I’m trying to isolate whether this is: • signing/provisioning/entitlements • widget extension misconfiguration • or a backend issue on Apple’s side I’ve already contacted Apple Developer Support and submitted Feedback Assistant reports. Has anyone seen this exact behavior before?

Hi, I’m seeing a strange TestFlight issue. My builds process successfully in App Store Connect, appear in TestFlight, and are assigned to internal testers, but installation fails immediately with: “The requested app is not available or doesn’t exist.” What I’ve verified: • builds are processed/completed • apps are visible in TestFlight • internal tester groups are configured • agreements/banking/tax are active This affects multiple apps in the same developer account. The issue started after adding a widget extension and moving to a new Swift-based workflow, so I’m trying to isolate whether this is: • signing/provisioning/entitlements • widget extension misconfiguration • or a backend issue on Apple’s side I’ve already contacted Apple Developer Support and submitted Feedback Assistant reports. Has anyone seen this exact behavior before?

**To offer apps or other in-app purchases, you must update your legal entity information prior to signing the Paid Apps Agreement. Edit Legal entity ** Hello everyone, i have for days and weeks tried to change this so i can update my address, but i cannot change it by my own. And all i see is message above Does anyone know exactly how long it takes to be updated by apple support? what other alternatives there to sign up for business agreements so i can not loose much time ? Thanks