Hi everyone, my name is Donovan, I am sharing here the official response I received from Apple following my appeal with App Review Board (image attached). For context, I am an independent developer and a student, working alone. This application was originally created as a student project, with a very simple goal: to improve my skills in mobile application development and to understand the entire creation cycle, from the initial idea to a genuinely usable application. What was meant to be an exercise gradually became a real product. Over time, many people tested the project, used it, provided positive feedback, and encouraged me to take it all the way. That is why I decided to continue it, structure it properly, and finalize it with the level of seriousness expected from a public-facing application. Today, the application is a dating and social connection app, entirely free, with no blocking paid features, funded only by light and optional advertising. It follows the rules, works correctly, and offers features that Apple itself acknowledged as useful and informative. And yet, after review, the message is clear: it is not the quality that is being questioned, but the category. Because it is a dating app, a category considered saturated, two years of independent, self-funded work, carried out seriously and in compliance with the rules, can simply be dismissed. What is being judged here is not the work itself. It is the right to enter. The “unique and very high-quality experience” being required appears to be a threshold reserved for those who are already established, visible, or funded. For a serious student project carried by a single developer, the door remains closed, cleanly, politely, definitively. For those who still wish to see what the application looks like, I have attached a few images illustrating the interface and the main features. Unfortunately, this will likely be the only way to discover it on iOS. Under these conditions, the conclusion is pragmatic. Rather than continuing to defend the very existence of an honest and free project, it becomes more coherent to invest my energy where it is genuinely accepted. On its side, Android validated the project without difficulty. It still allows an independent developer to propose an idea, let it evolve, and bring it to completion without requiring prior success just to earn the right to try. It is therefore very likely that these two years of development will never make it to the App Store. Not out of frustration. Out of clarity. I am publishing this message not to provoke, but to inform other independent developers: Apple is a remarkable platform, provided you are already established on it. And this is a reality worth knowing before turning a student project into a life project. Screenshots:

We are planning to migrate our application from an iOS In‑App Purchase (IAP) subscription flow to an external web purchase flow. The intended user journey is: The user taps a “Subscribe” button in the app. The user is redirected to a web-based checkout to complete the purchase. The user returns to the app, and subscription access is unlocked based on entitlement verification from our backend. Our app is currently listed in the Education category. Before we begin this refactor, we would like confirmation on the following: Entitlements / permissions Do we need to request any specific Apple entitlements or approvals to implement this external purchase flow (e.g., external link or alternative payment related permissions)? Compliance / review requirements Are there any specific App Review compliance checks, disclosures, or review process requirements we must satisfy when moving from IAP to an external purchase flow? If relevant, are there constraints based on app category (Education) or product type (subscription)?

If an app is rated 4+, does it have any additional obligation due to the SB2420 beyond this rating on the AppStore ?

Hi everyone, I’m hoping someone here can help or share insight. I submitted my enrollment for the Apple Developer Program a little over a week ago. After submitting my documents, I was told by Apple that I should receive a response within two business days, but I haven’t received any update, approval, or follow-up yet. I’ve double-checked that all required documents were successfully submitted Everything appears to be in order, but the status hasn’t changed and I haven’t been contacted. This is becoming urgent, as my app is ready for submission and I’m blocked from moving forward until the developer account is approved. I want to make sure I didn’t miss a step or that there isn’t something additional Apple needs from me. Is there a recommended way to escalate or follow up? Should I expect additional verification beyond the initial submission? Any guidance would be greatly appreciated. Thanks in advance for your help.

Hello, I am new application developer that has been developing several applications in the productivity and finance sections concurrently for about 1 year. One of my applications is nearly ready to be submitted to the App Store. I have received a lot of discouragement from people who have submitted apps in regards to putting submitting as a paid app, however due to all of the upfront and ongoing investment I've made, I do not wish to release my application for free initially. (I am learning how to best integrate storekit and in-app purchases and subscriptions, but I'm not ready to implement that yet) QUESTION: When releasing an app as a paid app and then converting to a FREE app with subscription later on, is there anything I need to be aware of technically or in regards to guidelines so I don't shoot myself in the foot when changing pricing? Any advice is greatly appreciated. Thank you.

Hello, I am trying to find out the best way to move my app from Base 44 to the App Store. I know its a process but I want to do it the best way possible to avoid any issues with the migration.

Hello, I have an app with a few essential asset packs currently totaling to ~8GB. I've noticed that when trying to install the app fresh from TestFlight, there is a significant delay between tapping install and the app appearing on the device in the loading state. The delay is long enough where it's hard to tell what's happening, or if the installation has failed. This also appears to be an issue in App Review, as I've had my app rejected twice due to the app not loading on the reviewers device. The reason they gave is UIRequiredDeviceCapabilities is blocking the installation, but UIRequiredDeviceCapabilities is empty. Note: I'm not looking for App Store review help, simply sharing the extent of the issue. Thank you

Hi everyone, I subscribed to the Apple Developer Program on Tuesday evening, Dec 7th, 2025. The payment has already been charged to my bank account, but my account still shows the status “Pending” with the message “Subscribe your membership”. It’s now been several days, and I haven’t received any confirmation email or any request for additional information. I already contacted Apple Support by email, but I’d like to know if other developers have experienced the same situation and how long it took before their account was activated. Thanks in advance for your help and feedback!

According to this news, we don't need anymore (at least temporarily): https://www.macrumors.com/2025/12/23/texas-app-store-law-blocked/ A Texas federal judge today blocked an App Store age verification law that was set to go into effect on January 1, 2026, which means Apple may not have to support the changes after all. Hope we shall get very rapidly more information from Apple.

I've spent the last few days researching the upcoming laws in Texas and other US states, and how these laws will impact on developers around the world. I want to share what I've learned so far with the community and get feedback on my current understanding. This post is not so much focused on a single API, but more of the bigger picture. Background The law essentially mandates that: (1) app store platforms implement age categorization and verification mechanisms, and (2) developers implement logic to listen to age categorization signals provided by the platform and respond accordingly. You can read the law itself here: https://capitol.texas.gov/tlodocs/89R/billtext/html/SB02420S.HTM Most people seem to be interpreting the law as follows: All developers who distribute apps in the USA are effectively required to implement the new APIs (required by Texas, not by Apple). The penalties are heavy, but it's unclear whether developers would actually be pursued and by whom (e.g. would someone seriously pursue an alarm clock app because it could be accessed by a minor?). Putting aside the ethical, privacy, and legal issues (and the damaging precedents this law sets), most people seem to agree that, from a technical perspective, this is a very silly way to implement age blocking (app store collects the info and passes it to dev, dev is responsible for blocking access). It would make way more sense for the platform to block the app directly for affected users (with optional API support for developers who wish to use it). However, I believe the law has specifically mandated that this is how they expect the system to work, so Apple's hands have been tied. Apple has basically complied with their obligations by providing the relevant APIs to developers. Because the law is vague and open-ended, there are a lot of legal and technical uncertainties about what developers actually need to do to be compliant. Understandably, Apple seems reticent to provide any guidance to developers that could be interpreted as legal advice. Apple's docs simply describe what the APIs do with no guidance on what the overall flow is meant to look like or how and when the APIs should actually be used in practice. Americans familiar with the political situation seem to think there's the possibility of an injunction before this law goes into effect, but that looks increasingly unlikely given that it's two weeks away. Developer solutions Many devs seem to be exploring two main workarounds, at least as temporary solutions: (1) Raise your app's rating to 18+. Putting aside the fact that Texas law would effectively be forcing developers to raise their global age rating (resulting in lost revenue that extends far beyond Texas), it remains unclear whether this solution is actually legally compliant, since the law specifically mandates that apps must implement logic to respond to signals from the platform. (2) Geo-block Texas. Again, it remains unclear if this is compliant because geo-blocking is not 100% accurate and it doesn't actually do what the law says you have to do. It also creates issues if you already have users in Texas, and it means performing additional privacy-hostile checks (i.e., detecting the user's location, even users who are not subject to the law). The DeclaredAgeRange API is actually pretty straight-forward to use – although there is still a lack of documentation on certain edge cases and it's difficult to test. In addition, the new APIs are only available in iOS 26.2, so it's unclear what you need to do if you're still supporting < iOS 26.2. Some people are of the opinion that developers can only reasonably respond to the signals that are available, thus pushing responsibility back to the platforms in regards to earlier OS versions. The API provides a bool (AgeRangeService.shared.isEligibleForAgeFeatures), which allows you to determine if the user is someone to whom age checks need to be applied. https://developer.apple.com/documentation/declaredagerange/agerangeservice/iseligibleforagefeatures I'm not 100% sure, but perhaps the simplest action you can take is to check this bool on launch and block access if it's true. In any case, it looks like this API will be very useful because it means we can avoid applying the checks in other jurisdictions and for grandfathered-in users without needing to implement custom geo-tracking code (albeit only in iOS 26.2+). To implement the API, my current thinking is that, on every launch, I should first check the above bool and, if it's true, do the following: (1) get the App Store age rating with let appStoreAgeRating = await AppStore.ageRatingCode ?? 18, (2) request the user's age with let ageRangeResponse = try await AgeRangeService.shared.requestAgeRange(ageGates: appStoreAgeRating), (3) check that the user has agreed to share their age, (4) check that lowerBound >= appStoreAgeRating, and (5) check that the verification method is not one of the self-declared methods. If this procedure fails, I should block access to the app and provide a link to Apple's support page: https://support.apple.com/en-us/122770 I stress, however, that this is just my current idea and there are some edge cases I'm unsure about. Other issues It is possible to do some basic testing of the API, but only using a sandbox App Store account on a physical device. From the Developer section in iOS Settings, you can select from a few different scenarios, like "Texas user aged 14 without parental consent", etc. There's also a whole separate aspect to this law relating to "significant updates". Everyone seems kinda confused about this, but it seems like the general idea is that, if your app's age classification changes in the future, the app should be responsive to that change. My current interpretation is that if I use the AppStore.ageRatingCode as the age gate (as described above) then that should allow me to comply, but I haven't really looked into this aspect of the law yet. There's also another aspect to this law requiring developers to revoke access to the app when requested by the parent. I have not looked into this yet, but as noted above, it doesn't make sense to me why this is the developer's responsibility given that the platforms already provide solid parental controls. Do I need to something else in addition to what I've sketched out above? It goes without saying, of course, that everything above is not legal advice, and I still have some gaps in my understanding. I would really appreciate any feedback on the above, perhaps with recommendations about better ways to approach this.

Apple sent a final reminder asking developers to complete the updated age rating questions in App Store Connect. Final reminder: Answer the updated age ratings questions. We’re reaching out because you have not provided responses to the updated age ratings questions in the App Information section of your app in App Store Connect. If you don’t answer these questions by January 31, 2026, you won’t be able to submit app updates in App Store Connect. The email says that if the age rating questions are not answered by 31 January 2026, you will not be able to submit app updates. What is not clear is what actually happens after that date. Many of us are in the middle of development and may not be ready to submit a new build before the deadline. The email does not explain whether this means: A) You can still submit updates after 31 January 2026, as long as you complete the age rating questionnaire before submitting, or B) The app becomes locked and cannot be updated at all once the deadline passes This is not stated explicitly in the email, which makes it confusing for me. It would be helpful if Apple could clearly confirm what developers should expect after 31 January 2026, especially for apps that are still undergoing active development. Anyone knows?

Hello Apple Developer Team I am an independent iOS developer creating highly specialized applications for a very small private audience of fewer than ten users These applications are tightly coupled with custom hardware that I design and manufacture myself for example automotive air suspension control systems Due to the extremely narrow scope and non commercial nature of these apps maintaining a full Apple Developer Program membership is economically impractical The applications are not distributed publicly are not monetized and are used only by a small group of people who share the same technical hobby All application code is written entirely by me There are no copyright violations no private API usage no hidden functionality no tracking and no malicious behavior The apps do not compromise iOS security do not harm users and do not discredit Apple or the iOS platform The software only functions when paired with proprietary hardware under my control At present the only viable way to install these apps is by using free developer certificates with a seven day expiration period This creates a significant usability burden Users must constantly re sign and reinstall the apps Non technical users frequently make mistakes during this process which leads to frustration and discourages experimentation learning and hardware innovation I would like to propose that Apple consider a limited and tightly controlled homebrew style distribution option where non App Store applications could be installed only after Apple review and approval similar in spirit to TestFlight or app notarization This could include strict limitations such as a very small number of allowed users no monetization no public discovery and clear labeling as private experimental or hardware coupled software Apple would retain full control over approval enforcement and revocation at all times Such a mechanism would preserve the security and trust model of iOS while supporting independent engineers hardware developers and advanced hobbyists It would reduce incentives for unofficial sideloading and encourage innovation at a grassroots level without weakening platform safety I deeply respect Apple’s focus on security quality and user trust This proposal is not about bypassing the App Store but about enabling a controlled reviewed and extremely limited path for legitimate non commercial hardware specific applications I hope this message can receive timely consideration and that if such an approach aligns with Apple’s platform goals it could be explored for inclusion in upcoming iOS versions where feasible Thank you for your time and for supporting the developer community Best regards Anzor Tekuev Independent iOS Developer

【背景】 現在、各広告実績(コスト、クリック数など）とCV実績（Adjustローデータ）を紐付け、広告ダッシュボードを構築しております。 iOSアプリキャンペーンにおいて、AD名での紐付け(SQL上でのjoin)が必須となり、ご質問させていただきました。 【質問】 SKAN側の仕様について、計測時SKANからMMP側にデータを送信しているかと思います。 この送信データに、ADG名、AD名は付与されているのでしょうか。 Adjsut担当者様より、リファレンスは無いがポストバック値にはある、とご説明いただきました。 SKAN側でリファレンス等あればご教示いただけますと幸いです。 また、SKAN4.0からは source-identifier がポストバックデータに含まる認識ですが、 この4桁の数値からADやADGを特定することは可能なのでしょうか。 MMPや広告主側で各ADにsource-identifierに紐付けは不可で、媒体側で自動発行される認識をしており、発行粒度/規定も媒体ごとに異なっていると理解しております。 ご返答いただけますと大変ありがたいです。 ▼参考リファレンス https://developer.apple.com/documentation/storekit/verifying-an-install-validation-postback#3592477

Users that search for my exact app name need to scroll past 14 to 39 apps in the results, that don't match, before reaching the first and only exact match. My app is called 'cadance' specifically for the word 'dance' that is appropriate for my audience. But this assumed to be a spelling error for 'cadence' since there are a large number of assumed 'matching' apps presented before my exact match. I've had some luck with Apple Ads using an exact match on my product name but it seems unfortunate to be forced into a workaround for AppStore search issues.

Issue Description: Apps that support both iOS and tvOS can have different versions in App Store for each type(iOS and tvOS) but same Bundle Identifier and iTunesStoreID/trackID. For example, the iOS version of YouTube has the latest version in App Store as 17.30.3 the tvOS version of YouTube has the latest version in App Store as 2.07.01 This can be verified from two by two specific iTunes look Up API as shown below https://itunes.apple.com/lookup?id=544007664 https://itunes.apple.com/lookup?id=544007664&entity=tvSoftware Sample contentMetadataLookup URL: https://uclient-api.itunes.apple.com/WebObjects/MZStorePlatform.woa/wa/lookup?version=2&id=544007664&p=mdm-lockup&caller=MDM&platform=enterprisestore&cc=us&l=en Queries: What should we do to get the tvOS specific version of an app in contentMetadataLookup URL? The trackViewURL doesn't show tvOS specific version history of the app - https://apps.apple.com/us/app/youtube-watch-listen-stream/id544007664?platform=appleTV . How should we view this the apps' tvOS specific version history? Kindly help us with the queries.

Hi everyone, I am looking for guidance regarding a rejection under Guideline 3.1.1 – Payments / In-App Purchase. Our app is a **B2B SaaS platform for professional fitness coaches. Coaches subscribe through our website to access coaching management tools (client tracking, training programs, nutrition planning, messaging, etc.). The iOS app is only a companion app that lets existing coach accounts log in and access services they already purchased on the web. Important facts about our implementation: No subscriptions can be purchased in the app No pricing, plans, or commercial upsell screens in the app No sign-up in the app No external links to a website checkout or pricing The app is not usable at all without an existing paid account The content is professional B2B data, not consumer digital media Despite this, App Review keeps rejecting us for: “Your app accesses digital content purchased outside the app, and that content is not available through in-app purchase.” We tried referencing **3.1.3(b) Multiplatform Services, because our service is used on the web and mobile, and we only allow access with an existing account. We also provided examples of other coaching platforms in the App Store that appear to work the same way (Trainerize, Everfit for Coaches, Hubfit, etc.). But App Review still says the same thing, without pointing to a specific screen or UI element. I want to make sure we comply. To clarify: Do we need to completely block access to all content until login, even if the app already does this? Is it enough to display a disclaimer such as: “This app is for existing coach accounts only. No purchases, subscriptions, or account creation are available in the app.” For a B2B tool, does Apple still require In-App Purchase, even if users cannot sign up or buy anything inside the app? Is this considered a Reader-style app under Apple’s rules? Has anyone successfully passed review with a SaaS “login-only” model for professional software? We don’t want to violate any rule, we just need clear guidance on what is required to get approval. Any help or experience from other developers or Apple team members would be greatly appreciated. Thanks, Robin

For testing permission response we can use the sandbox account However, when testing permission requests using the AskCenter API, none of the ask API works for me in xcode 26.2 rc and iOS 26.2 rc. For SignificantAppUpdateTopic, I got errors like "The user is in a region that does not support this type of ask" in the console log, but I've already set my billing address to Texas. For CommunicationTopic, the console shows several XPC-related errors, and I’m not sure which of them are relevant. Both of them show an alert view of "Can't ask, An unknown error occurred" Can someone help to guide us how to test the request flow? Thanks

Hi everyone, I’ve completely removed my App Clip: Deleted all Advanced App Clip Experiences Removed the App Clip target from my build Removed App Clip references from my apple-app-site-association file Deleted the meta tag from my website: However: When scanning the QR code, the App Clip card still appears with: "This App Clip is not currently available in your country or region." This link still works for my App Clip, which is not what I expected: https://appclip.apple.com/id?p=com.example.appclip Does anyone know why the App Clip card is still showing and how to fully remove it? Thanks!

I'm making a wrapper library to abstract away some of the 'missing platform support' of DeclaredAgeRange until hopefully it expands to additional platforms. When I'm trying to fully enumerate all of the cases of AgeRangeDeclaration, which they all state available starting 26.0 (mysteriously added in Xcode 26.2 beta), the app crashes due to a missing symbol at launch time. This happens both for Xcode 26.1, 26.2 beta 2, and matching Xcode Cloud builds. So I've isolated it beyond "doesn't work on my machine". I just made a handful of crashes and attached a sysdiagnose to a fresh feedback. FB21121092 - DeclaredAgeRange: Eligibility property and new declaration cases unavailable on iOS 26.1 device contradicting documentation - causes runtime symbol not found crash If anyone is curious what these crashes look like I've attached the DiagnosticPayload.jsonRepresentation() generated from one of my favorite frameworks, MetricKit. Very clearly articulated in the diagnostic metadata you can see the symbol not found. "diagnosticMetaData" : { "platformArchitecture" : "arm64e", "terminationReason" : "Symbol not found: _$s16DeclaredAgeRange0bC7ServiceV0bC11DeclarationO14paymentCheckedyA2EmFWC\nReferenced from: <1894EDCB-3263-3604-8938-97D465FF3720> \/Volumes\/VOLUME\/*\/PerformanceOrganizer.app\/PerformanceOrganizer\nExpected in: <B8FD2C23-0CC9-3D94-902D-875900307A7A> \/System\/Library\/Frameworks\/DeclaredAgeRange.framework\/DeclaredAgeRange", "exceptionType" : 10, "appBuildVersion" : "745", "isTestFlightApp" : true, "osVersion" : "iPhone OS 26.1 (23B85)", "bundleIdentifier" : "dev.twincitiesapp.performanceorganizer", "deviceType" : "iPhone18,1", "exceptionCode" : 0, "signal" : 6, "regionFormat" : "US", "appVersion" : "2.0.0", "pid" : 22987, "lowPowerModeEnabled" : false } DiagnosticPayload.json This is the offending code in a type I control and make available on other platforms but leave unused. extension AgeRangeDeclaration { // A factory or initializer that takes the AgeRangeService.AgeRangeDeclaration and maps to the common AgeRangeDeclaration type public init?(platform value: AgeRangeService.AgeRangeDeclaration?) { guard let value else { return nil } switch value { // Xcode 26.1 visible cases case .selfDeclared: self = .selfDeclared case .guardianDeclared: self = .guardianDeclared // Xcode 26.2 visible cases // This is the first culprit, all of the following symbols would crash, this is just the first case .checkedByOtherMethod: self = .checkedByOtherMethod case .guardianCheckedByOtherMethod: self = .guardianCheckedByOtherMethod case .governmentIDChecked: self = .governmentIDChecked case .guardianGovernmentIDChecked: self = .guardianGovernmentIDChecked case .paymentChecked: self = .paymentChecked case .guardianPaymentChecked: self = .guardianPaymentChecked @unknown default: // Apple added new cases in Xcode 26.2 betas that were available in iOS 26.0, // so it is probable that this could happen again. If it does, assert to let developers // bring it to my attention. assertionFailure("Invalid or out of date knowledge of age range declaration \(value)") self = .unknown } } } For what it is worth, the same is also true for isEligibleForAgeFeatures which I suspect was also added to Xcode 26.2 somehow but not made available to real devices running [26.0 - 26.2). As a side note, thank you for this property, it will let me check what states I need to perform extra checks for in a clean way, I just will need it to now not crash my app on 26.0 and 26.1 runtime devices. :) Edit: DTS did confirm on a comment I had in another thread that this is a bug. Now just to wait for an Xcode beta update. https://developer.apple.com/forums/thread/807906?answerId=867205022#867205022 In any case, this is a great example of how MetricKit totally rocks capturing things other off the shelf crash tools might not have a chance to get. I did have to roll back my TestFlight to an earlier build, but MetricKit was there to send me the previous crashes as soon as the app could launch. Thanks MetricKit team!

I’m not sure what the issue is. I’ve filled in all the information on the Business Agreements page, but the status is still Pending User Info. Does anyone know what information might be missing?