Overview

I have been waiting for completion of the migration from personal dev account to organisation. I had a few initial emails and then nothing for weeks. How long does this normally take and how do i get it unstuck?

How do I disable the "Ask Siri" button in the SwiftUl context menu in macOS?

I'm looking for a supported way to read intermediate tensors from a model executing on the Apple Neural Engine - specifically the output of an individual node in the compiled graph, rather than only the final output. What I'm trying to do: validate a from-weights reimplementation of a model against the real thing, layer by layer. Comparing only the final output tells me the reimplementation is wrong but not where; a per-layer comparison would localise it immediately. What I've established so far: A compiled ANE program can be executed unprivileged through the public graph API, and the final readout matches, so the execution path itself is reachable. Intermediate activations don't appear in host memory during normal operation, which is expected since the scheduler keeps them in accelerator-local storage. Requesting a per-node output appears to hit a kernel-side check that an ordinary process doesn't satisfy. Questions: Is there a supported API for retrieving per-node outputs from an ANE-scheduled graph - a debug or instrumentation mode, an Instruments template, or a Core ML compute-plan facility that surfaces them? Failing that, is there a supported way to make a specific node materialise its output to a host-visible buffer - for example by splitting the graph, marking an intermediate tensor as a model output, or compiling with that node as a terminal operation? I'm aware this may change scheduling and defeat the purpose, but I'd like to know whether it's the intended approach. If neither exists, is that a deliberate design boundary rather than a gap? A clear "no" is a useful answer and I'll stop looking. I'm not asking about any particular shipped model, and this isn't a request to bypass anything - the question is whether the platform exposes per-node observability for ANE execution at all, and if so what the supported entry point is. Thanks.

I would like to sell physical printed books via my app on Apple. Is it permitted to do this? Can I link out to my physical bookstore outside of the App? What details or documentation do I need to provide to Apple to get this approved on the App Store?

Hello, I am experiencing a serious issue with my Apple Developer Program enrollment, and after multiple contacts with Apple Developer Support, I still have no resolution. My enrollment process has been ongoing since August 5, 2026. Here is a summary of what has happened: August 5: I started the Apple Developer Program enrollment process. I initially could not enroll through the Apple Developer app because the Enroll Now button was disabled and I was directed to enroll through the website. During the web enrollment process, Apple requested additional identity verification. I submitted the requested identity documents and information. After the review, I was eventually allowed to continue with the enrollment and reached the payment stage. August 13: I paid 1,029 TRY for the Apple Developer Program through Apple's website. The amount was successfully charged. However, my Developer Program membership was never activated. I was subsequently directed to try enrollment through the Apple Developer app. On my iPhone, the identity verification process failed and the app displayed “ID Verification Rejected.” I also tried on a Mac. After entering my identity and address information, I received: “Contact us to continue. There may be an issue with your account that needs to be resolved before you can continue. Please contact support.” August 15: Apple issued and emailed me an official invoice confirming the 1,029 TRY Apple Developer Program payment. Despite the successful payment and invoice, I still have no active membership. Today, the situation changed again. A few hours ago, the Developer app was still displaying “ID Verification Rejected.” I then went to the Apple Developer website, where an Enroll button appeared. I selected it and chose to continue enrollment through the website. The website immediately displayed: “Your enrollment could not be completed. Your enrollment in the Apple Developer Program could not be completed at this time.” After this happened, I checked the Apple Developer app again. Interestingly, “ID Verification Rejected” had disappeared, but the Enroll Now button became disabled again. The app now says that enrollment through the Apple Developer app is not available for this Apple Account and directs me back to the website. So I am currently stuck in a loop: Developer app → tells me to use the website Website → says my enrollment cannot be completed At the same time, Apple has already charged me 1,029 TRY and issued an official invoice, but I still do not have the Apple Developer Program membership that I paid for. I have already contacted Apple Developer Support multiple times and have an existing support case. I have followed every instruction provided to me, submitted the requested identity information, tried enrollment on the web, iPhone, and Mac, and completed the payment. This has been ongoing since August 5, and it is now preventing me from continuing with my app development and distribution plans. Has anyone experienced a similar situation where Apple successfully charged and invoiced the Developer Program membership, but the enrollment remained blocked? If an Apple Developer Support representative sees this post, I would greatly appreciate it if my enrollment could be reviewed or escalated to the appropriate enrollment/review team. Case ID: 20000129008605 I can provide Apple Developer Support with the payment confirmation, official invoice, screenshots of both errors, and any additional identity documentation required. For privacy reasons, I have not included my Apple Account email address, invoice number, or personal identification information in this public post. Thank you.

While building an SMB 2/3 client as an FSKit file system module (FSUnaryFileSystem + FSVolume, the macOS 27 Handler protocols), I ran into a number of framework-level issues. I have filed each one with a title starting "FSKit:" so they are easy to find, and every report has a minimal reproduction attached: a small in-memory FSKit module (no network, no disk, no cache of its own), so none of them depend on SMB. All were measured on macOS 27.0 (26A5406e and 26A5416b) with Xcode 27.0 beta 5. Summaries below in case anyone else is hitting these. FB24419773: renameatx_np with RENAME_SWAP returns success but destroys the destination file. On any FSKit volume a RENAME_SWAP is performed as an ordinary clobbering rename: rc=0, but the destination's contents are silently lost instead of exchanged. The module cannot refuse it because renameItem receives no flags; a swap and a plain overwriting rename look identical. (RENAME_EXCL works correctly.) FB24419825: a negative lookup is cached permanently. Once anything gets ENOENT for a name on an FSKit volume, the kernel serves that ENOENT for the life of the vnode. If the file is created later (for example by another machine on a network volume), it stays unopenable by that name indefinitely, while ls of the same directory lists it. There is no API through which a module can report that a name now exists. FB24419858: a data-cache grant from openItem can be applied after the module has already invalidated. The grant in FSOpenItemResult is applied asynchronously after the module's reply, and an invalidation issued in that window succeeds (setCacheState returns no error) and is then overwritten by the stale grant. The result is a kernel cache no future event will invalidate; readers see stale data. FB24419870: synchronize(flags:) is never called on a URL-backed volume. fsync(2), fcntl(F_FULLFSYNC), fcntl(F_BARRIERFSYNC) and sync(8) all return success with zero calls reaching the module, so durability is reported and never established. A packet capture of the same SMB share shows five SMB2 FLUSH requests through Apple's smbfs and zero through an FSKit module. FB24419894: FSItemSetAttributesRequest.consumedAttributes is never observed, and wasAttributeConsumed(.changeTime) answers about the wrong attribute. Consuming everything and consuming nothing are indistinguishable to the caller (chmod returns 0 either way), even though the setAttributes documentation says the upper layers will detect unsupported attributes. Separately, wasAttributeConsumed answers YES for changeTime when only accessTime was consumed, and never answers correctly about changeTime itself; this part reproduces by constructing the request directly, no file system needed. FB24419911: restrictsOwnershipChanges = true does not reject non-superuser chown. The property is documented as "the volume rejects a chown(2) from anyone other than the superuser", but on an -o owners mount a non-root chgrp is delivered to the module's setAttributes anyway, so every module has to enforce the policy itself. FB24419932: a failed activate wedges the resource URL. After a module's activate throws once, every later mount of the same URL string fails with "Resource busy" (fskitd logs "Can't start new task, resource state is 5"), while the same volume under a different URL spelling mounts fine. For a network module the ordinary trigger is one wrong password. Recovery requires killing both fskitd and the extension process. FB24419964: enumeration cannot report extended-attribute presence. FSItem.Attributes has no per-item "has xattrs" field, so one cold ls -l of a 500-entry directory costs about 2,000 FSKit boundary crossings: an xattr call per entry plus a "._name" AppleDouble sidecar lookup per entry, and each of those ENOENTs is then pinned by FB24419825. Suggestion: a per-entry hasExtendedAttributes flag so getattrlistbulk can be satisfied from the enumeration. FB24419974: no byte-range lock operations. flock(2) and fcntl(2) locks on an FSKit mount stay kernel-local and never reach the module, so advisory locks cannot coordinate between clients of a network file system. Suggestion: an optional lock-operations handler. FB24419979: no ACL or security descriptor operations. ls -le, chmod +a, acl_get_file(3) and cp -p with ACLs cannot work on any FSKit volume; a network server's real ACLs are invisible behind synthesized mode bits. The nearest surface, FSVolumeAccessCheckHandler, can only be asked yes/no questions about a descriptor the module has no way to provide. Suggestion: an optional ACL-operations protocol. If any of these are biting you too, duplicate feedbacks referencing the FB numbers above genuinely help with prioritization.

Cannot save a shortcut I created in the Shortcuts App to the dock. Get the following message. The file “CompRmLights.app” couldn’t be saved in the folder “Applications”. Have disabled csrutil with no luck. Anyone have any answers.

I've been building an SMB client and hoping to ship it as an FSKit module, but because of some blocking issues I decided to serve it over NFS instead. Unfortunately, I've run into another blocker, which I'll share in case others are seeing the same behavior. While testing against an NFSv4.1 server (stock Linux nfsd), I ran into a situation where processes on the Mac end up permanently blocked inside the NFS client, and I wanted to share it in case others hit the same thing. Filed as FB24538163. The trigger is several processes concurrently opening, unlinking and recreating the same filenames in one directory. Something like ten shell loops each doing cat, rm, and echo > over the same five names will do it. When it happens: The stuck processes ignore SIGKILL and sit in state U indefinitely (I have had them survive more than eight hours). umount -f on the mount blocks the same way, so the mount cannot be cleared either. Only a reboot recovers. The rest of the system stays responsive. Two details that may help narrow it down: It really is the name collision, not the load. The same loops using distinct filenames per process, at the same traffic volume and latency, ran clean for twenty minutes, while the same-name version wedged every time. Adding 8 ms of reply latency made it roughly ten times more frequent. It happens on a soft mount (timeo=100,retrycnt=3), where I would have expected EIO after the retry budget instead of an indefinite wait. Spindumps show the blocked threads inside nfs_vnop_open / nfs4_vnop_create, down through nfs4_open_rpc_internal into nfs_node_set_busy_helper, with one thread typically waiting on a write RPC reply (nfs_wait_reply) inside that same open path. A self-contained repro script is attached to the Feedback. The script only needs any NFSv4.1 server to point at, and its header has a one-line Docker command that produces one. This looks related to what the FUSE-T project has reported (macos-fuse-t/fuse-t issues 112 and 45), since FUSE-T rides the same client. If anyone knows a mount option or usage pattern that avoids the wait, or can confirm seeing this elsewhere, I would love to hear it.

We have a published, approved App Clip that works correctly via QR code and the Safari Smart App Banner, but URL-based invocation does not trigger the App Clip card in any context. Most notably, Apple's own default App Clip URL does not work either: https://appclip.apple.com/id?p=hazel-torus.Clip **Tapping this link in Messages or Notes does nothing. ** Long-pressing it shows a generic website link preview rather than the App Clip card, even though appclip.apple.com is Apple's domain and requires no configuration on our end. Setup details: App Clip bundle ID: hazel-torus.Clip Team ID: 2UNR2APH47 App Clip experience URL: https://passportreader.app/open AASA includes a correctly formatted appclips key with 2UNR2APH47.hazel-torus.Clip (confirmed via https://app-site-association.cdn-apple.com/a/v1/passportreader.app that AASA is correctly cached) Associated Domains entitlements (appclips:passportreader.app) are present on the App Clip target App and App Clip experience are both Approved / Ready for Sale Tested on two physical devices, neither with the full app installed Since QR and Safari banner invocation work, the App Clip itself and its entitlements appear correctly configured. The fact that even Apple's own appclip.apple.com URL fails, and is treated as an arbitrary website link, suggests this may be a backend indexing issue specific to this App Clip rather than a client-side configuration problem. Has anyone else encountered this, or know what could cause appclip.apple.com to not be recognized as an App Clip URL?

I built this very simple example to demonstrate the issue im facing on iOS 26 when trying to use custom ToolbarItem element for .largeTitle. Code: struct ContentView: View { var body: some View { NavigationStack { Screen() .navigationTitle("First") .toolbar { ToolbarItem(placement: .largeTitle) { Text("First") .font(.largeTitle) .border(Color.black) } } .navigationDestination(for: Int.self) { integer in DestinationScreen(integer: integer) } } } } struct Screen: View { var body: some View { List { ForEach(1..<50) { index in NavigationLink(value: index) { Text(index.description) .font(.largeTitle) } } } } } struct DestinationScreen: View { let integer: Int var body: some View { HStack { Text(integer.description) .font(.largeTitle) Spacer() } .padding() .navigationTitle(integer.description) .toolbar { ToolbarItem(placement: .largeTitle) { Text(integer.description) .font(.largeTitle) .border(Color.black) } } } } As shown on the gif, when navigating between pages, titles are going to overlap for a short while. Other questions: Why is it required for .navigationTitle() to exist (empty string wouldn't work!) so that the ToolbarItem .largeTitle can render at all? If none is added, this ToolbarItem simply won't appear Why isn't the large title naturally aligning to the leading side? Apple doc. doesn't mention any of this behaviour as far as I know but in general these placement should replicate known established behaviours, and .largeTitle should be leading aligned. Another issue is shown on the image below. When using both .largeTitle and .title (to simulate the same behaviour of transition between large and inline title when scrolling), both will appear at the same time. The large title will disappear as you scroll down which is fine.

I am working on a DriverKit driver and we are subclassing IOUserSCSIParallelInterfaceController. I have implemented UserLogicalUnitResetRequest end-to-end and it sends a real Task management IU to the controller and returns the correct kSCSIServiceResponse_*. When I call the hook from within the dext manually it works but I am not able to invoke this UserLogicalUnitResetRequest from macOS. My question is, under what conditions does macOS itself invoke this hook (or the other five TMF hooks - abort/set, TargetReset, ClearACA/TaskSet)? I tried to insert a gate at the top of UserProcessParallelTask, which for one chosen target, swallows the incoming task without submitting it to the controller and without completing the OSAction. I then ran normal APFS filesystem IO against the target and observed following: Every stalled command arrives with SCSIUserParallelTask.fTimeoutInMilliSec = 0. The command hang indefinitely. None of the TMF hooks are ever invoked by the framework. I am not sure if I am doing something wrong here. Is fTimeoutInMilliSec = 0 on filesystem IO expected? Is there a way for the dext to surface a shorter deadline that the framework will watchdog? What actually invokes the TMF hooks- filesystem-IO timeout escalation, storage recovery, or is there an expectation that the dext runs its own per-command watchdog and invokes its reset code internally? Any help would be really appreciated! Thank you for your time!

We are facing an issue with push notifications on our iOS production application and would appreciate guidance. Issue Summary Push notifications were working correctly previously but stopped working around two weeks ago. We use Firebase Cloud Messaging (FCM) for push notifications, which delivers notifications to our iOS application through APNs. The issue appears to be related to existing FCM tokens. Existing FCM Token We have an FCM token already stored in our production backend database. When we try to send a notification using this token: Our backend sometimes receives the following response: { "error": { "code": 404, "message": "NotRegistered", "status": "NOT_FOUND", "details": [ { "@type": "type.googleapis.com/google.firebase.fcm.v1.FcmError", "errorCode": "UNREGISTERED" } ] } } In some cases, the API request appears successful, but the notification is still not received on the iPhone. We also copied the exact same existing token and tested it directly using Firebase Console → Send test message. The notification was not received on the device. Newly Generated / Retrieved FCM Token We then generated/retrieved the FCM token again from the same application and tested it directly from Firebase Console. Using the newly retrieved token: The notification was successfully received on the same iPhone. This means the following behaviour is observed: Existing FCM Token ↓ Backend may return 404 UNREGISTERED OR Firebase may accept the send request ↓ Notification not received But after retrieving the token again: FCM Token Retrieved Again ↓ Firebase Console Test ↓ Notification received successfully Client-Side Configuration We have confirmed the following: APNs device token is successfully generated. FCM registration token is successfully generated. Notification permission is granted. The application is connected to the correct Firebase project. FirebaseAppDelegateProxyEnabled is set to NO. Since Firebase method swizzling is disabled, we manually assign the APNs token to Firebase Messaging. Our APNs registration code is: func application( _ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data ) { print("*** APNS Device Token: ", deviceToken) Messaging.messaging().apnsToken = deviceToken Messaging.messaging().subscribe(toTopic: "testing_new_events") { error in if let error = error { print("*** Failed to subscribe: \(error.localizedDescription)") } else { print("*** Subscribed to topic successfully") } } } Main Question About the 404 UNREGISTERED Response One part of this behaviour is particularly confusing to us. If Firebase returns: 404 UNREGISTERED NotRegistered for a particular FCM token, we would expect that token to be invalid and that the application should receive or generate a completely new FCM registration token. However, when we retrieve the FCM token again from the application, Firebase may return the same token value again. Our question is: If Firebase considers an FCM token unregistered and returns 404 UNREGISTERED when sending a notification, why can Messaging.messaging().token() or the token callback still return the same token again instead of generating a new token? For example: Token A stored in backend ↓ Backend sends notification ↓ FCM returns 404 UNREGISTERED ↓ App retrieves FCM token again ↓ Firebase returns Token A again We would like to understand whether this is expected behaviour. Specifically: Does UNREGISTERED always mean that the locally cached FCM token should immediately be replaced with a new token? If not, why can the same FCM token still be returned to the application after Firebase returns UNREGISTERED for it? Is there a delay between Firebase invalidating a registration for sending and the client generating a replacement token? Is there a recommended way to force Firebase Messaging to refresh or re-register an FCM token after receiving UNREGISTERED? Could the token be cached locally even though its server-side registration is no longer valid? Additional Questions We would also appreciate guidance on the following: Is it possible for an existing FCM token to become stale or no longer usable for notification delivery without immediately returning an UNREGISTERED error for every send attempt? Can Firebase accept a message for an existing token and return a successful response, while the notification is never delivered to the device? On iOS, could the relationship between an existing FCM token and its APNs token become invalid or stale, while the application still returns the same FCM token? Is there any APNs-side reason why an old FCM token would stop receiving notifications while a newly generated/retrieved token on the same device receives notifications successfully? What is the recommended client-side and backend-side handling after receiving a 404 UNREGISTERED response? Should we immediately remove the token from our database and wait for the application to register a new token? Our main concern is understanding why an FCM token can receive a 404 UNREGISTERED response during sending, but the application can still return the same token when we attempt to retrieve it again. Any guidance on whether this behaviour is expected, particularly regarding the interaction between FCM token registration and APNs on iOS, would be greatly appreciated.

I am seeing a reproducible Apple Pay card provisioning failure on iOS 27 Beta 6 (24A5418b). The card eligibility check succeeds and the Apple Pay provisioning response contains a valid termsID, but provisioning subsequently enters the Secure Element storage-management stage and fails with: SEStorageManagementSheet Code 4 SES.presentationTimedOut The Terms & Conditions screen therefore never appears and provisioning cannot continue. I reproduced the same system-level failure through multiple independent provisioning paths: First-party Apple Wallet provisioning with manual card entry Wallet-initiated provisioning that redirects to the issuer app Issuer-app initiated in-app provisioning The issue affects multiple issuers, including East West Bank and Mercury. The same iPhone successfully provisioned Chase UK and HSBC Hong Kong cards on an earlier iOS 27 beta build, and Apple Pay provisioning worked normally on iOS 26. I have already tested different network conditions, reset network settings, and removed two existing Apple Pay cards before reproduction. The behavior remains unchanged. Two separate sysdiagnoses show the same failure path. During the latest reproduction, SESUIServiceApp was successfully launched, but provisioning ultimately failed during SEStorageManagementSheet presentation with SES.presentationTimedOut. The captured RunningBoard state also showed SESUIServiceApp in a background/suspended state rather than maintaining a successful remote presentation. I have submitted the complete diagnostics and sysdiagnose files through Feedback Assistant: FB24403156 Could an Apple Wallet / Apple Pay engineer please review this Feedback and investigate the SESUIServiceApp / SEStorageManagementSheet remote presentation path on iOS 27? For privacy reasons, I am not attaching the full sysdiagnose publicly here; the diagnostic files are attached to FB24403156

Hello, Could App Review please confirm the submission is still progressing? App: GrapeMap: Winelands Guide Apple ID: 6802603098 Submission ID: 43018af6-1ff8-43c7-9831-d10f95837a1f 18 Aug - Submitted (v1.0, new app); received Guideline 2.1 Information Needed same day 19 Aug - Replied with all seven requested items, including a screen recording from a physical device; demo credentials are in App Review Information 26 Aug - Sent a follow-up; no response or status change since 19 Aug Free travel guide app, no purchases or regulated activity. Thank you, Riaan Theron

We develop an endpoint security agent that customer IT deploys and manages via MDM on supervised, ADE-enrolled Macs. The agent requires Accessibility permissions to perform core security functions. Historically, IT provisioned this via the PPPC payload which granted Accessibility as a managed control without end-user interaction. In macOS 27 this path for Accessibility has been removed. The documented replacement — the Privacy key in com.apple.configuration.app.settings — is consent-based: on a supervised device it presents the user a consolidated prompt with "Allow" preselected, which the user may decline. We are seeking guidance on the supported approach for macOS 27 GA: On a supervised macOS 27 device, is there a supported mechanism for an MDM-managed, code-signature-verified application to be provisioned with Accessibility as a managed security control, without depending on individual end-user consent? (i.e. an equivalent to what PPPC provided for enterprise-managed endpoints.) If the consent-based com.apple.configuration.app.settings Privacy declaration is the only path, what is Apple's recommended approach for enterprise-mandated security agents that must have Accessibility to function — including handling the case where a user declines or dismisses the prompt? We have also filed this as an enhancement request via Feedback Assistant (FB23531820). Environment for context: macOS 27 supervised via Automated Device Enrollment, managed by Jamf Pro.

Submission ID: 4f64fd8d-529d-4829-9f29-07bbc53b3afb · Review date: August 26, 2026 · Version 1.0 (47) I never wanted to build a dating app. I wanted to build the thing I couldn't find: a place where you say what you're actually looking for, a partner, a friend, someone to travel with, people for a Tuesday-night board game, and see the people who are looking for the same thing. Not a deck of strangers dealt to me by an algorithm that profits from dealing slowly. My name is Gleb and for the past 13 months, in Barcelona, with my partner, who did the art direction, I built Tekero. No investors. No revenue. Nothing to monetize. I haven't built a paywall, because the first thing I'd have to sell is the thing every other app sells: your loneliness, rationed back to you. Here's what's different, and why it's different: Every mechanic in Tekero is aimed at a specific thing that hurts people. Ghosting: if you're sitting on a pile of likes you haven't answered, you drop out of the feed. Why should you be shown to more people when you're not responding to the ones you have? Inbox overload: your active chats are capped. Want a new conversation? Finish an old one, or keep it deliberately by adding that person as a friend. The app only unlocks that once you've built up friendship progress, a separate feature that measures how much two people (or more, in a group chat) have actually said to each other. Pay-to-reveal-likes: gone. Every like arrives openly, immediately, free. No slot machine. Both sides filter each other, the person who posted the announcement and the person browsing. So anything you see in the feed is someone who was also looking for you. Couples and friends can browse together and post together, because meeting people doesn't stop being useful once you've met someone. There's a trust score that costs you points for treating people badly: ignoring them, being toxic, attempting screenshots of private data (chat messages or private photos). It gives you points for treating people well, for communicating, for making friends. Screenshotting a private photo isn't a clever move here: it saves a black frame, sends a notification to the person you betrayed, and raises a ticket on the reports desk, which can lead to a block if the trust score is already low. The blank first message: most apps hand you a stranger and a cursor. Tekero gives you openers, including one called Game, where you both answer three psychological questions and start from something real instead of "hey". The first exchange is designed to be worth having, not to be survived. The dropdown that doesn't fit you: most apps give you two options and call it a profile. Tekero gives you 72 non-binary gender identities alongside the binary ones, the full range of orientations rather than the four everyone ships, and gender expression as a separate field: feminine, masculine or androgynous. How you present isn't the same question as who you are. This isn't a diversity checkbox. The whole app runs on both sides filtering each other honestly, and filtering can only be as true as the vocabulary people are given to describe themselves. Precision here isn't decoration, it's what makes the matching real. In Tekero, we want everyone to be themselves. I gave it to testers. It's hard to recruit them while the app is TestFlight-only, people aren't keen on multi-step installs. Still, apart from minor improvement requests that I resolved as they came in, testers were genuinely excited about the mechanics. The two things I heard most often: Tekero reinvents dating and It's not just dating AppStore Connect Submission Last week Apple rejected it under Guideline 4.3(b): my app "primarily includes dating features that duplicate the content and functionality of similar apps that are already widely available," and "there are already enough of these apps on the App Store." The same letter also states that my app "may include features or characteristics that distinguish it." Taken together, those two statements suggest the distinguishing features weren't assessed against the standard, and that assessment is what I'm asking for. In June, Apple rewrote that guideline to name dating outright: no new submissions unless they offer a "meaningfully different or improved experience." That test has two limbs, and the second one is "improved". Tekero isn't a variant of what's already there. Every mechanic above exists because something in the current experience is failing the people using it. I'm not asking for an exemption from the rule. I'm asking for the half of it that says "improved." What's next The appeal is with the Review Board. Get familiar with Tekero here, if interested: tekero.io, there's a walkthrough video on the site (posting the address as plain text, since external links aren't permitted here). If you've gotten out from under 4.3(b) — I'd really like to know how.

I’m trying to transfer an app between two Apple Developer accounts, both registered in Ecuador. The transfer is blocked with the following message: “The recipient of this app must first sign the Alternative Terms Addendum for Apps in the EU.” However, we have already completed the following steps on both accounts: Accepted the latest Apple Developer Program License Agreement. Accepted the Alternative Terms Addendum for Apps Distributed in the European Union. Received the confirmation message: “You’ve agreed to the Alternative Terms Addendum for Apps Distributed in the European Union.” Completed the required business/revenue declaration. Accepted the StoreKit External Purchase Link Entitlement (EU) Addendum as well. Logged out and back into Apple Developer and App Store Connect. Waited for the agreements to synchronize. Cancelled the original transfer and created a completely new app transfer. Despite all of this, App Store Connect still shows exactly the same error and does not allow the recipient to accept the transfer. Both accounts are in good standing and all visible agreements are active. Has anyone experienced this issue recently? Is there another agreement or setting that needs to be enabled, or is this an App Store Connect synchronization/backend issue that requires Apple Developer Support to fix? Any help would be greatly appreciated.

I have a watchOS app on a cellular Apple Watch (Series 11, watchOS 26.6) that periodically uploads small HTTPS payloads to a backend. It needs to keep working when the paired iPhone is absent and the watch is on its own cellular connection. What I observe: Foreground, no phone, cellular: uploads work. Background, no phone, cellular-only (no Wi‑Fi): nothing uploads for hours. The instant the watch joins Wi‑Fi (app still in background): the whole backlog flushes at once via my background URLSession. My questions: Is a background URLSession transfer over cellular ever expected to run without Wi‑Fi (e.g. while charging), or is Wi‑Fi effectively required in practice? Any configuration that improves the odds? 2. During an active HKWorkoutSession (which keeps the app executing), will a high-level URLSession data task reliably complete over cellular with the phone absent? And is using a workout session to keep a non-fitness background uploader alive acceptable, or is there a sanctioned alternative? 3. Is there any other supported mechanism for periodic background cellular upload from a phoneless watch that I'm missing? Any help would be greatly appreciated. Thank you!

We have a Live Caller ID Lookup deployment that has been blocked for weeks, and the core difficulty is not technical. It is that we cannot find out anything about the state of our onboarding submission. Here is where we stand. We submitted the onboarding form and our configuration was approved on 8 August. That approval email is the only communication we have ever received about this feature. Our service is deployed and verified: the OHTTP gateway negotiates HTTP/2, serves a valid key configuration, the issuer directory returns 200 and Apple polls it continuously, the DNS TXT record is in place, and the validation identity is in our corpus. Development builds work end to end and display caller names correctly on incoming calls. App Store builds do not. Every authenticated request fails on the device in roughly 47 ms, before anything leaves the phone: ciphermld(CipherML) requestData(byKeywords:shardIds:clientConfig:) threw NSURLErrorDomain Code=-1009 _NSURLErrorPrivacyProxyFailureKey = true nw_endpoint_proxy_handler_should_use_proxy: "Proxies not present, but required to fail closed" The network path is healthy in the same moment, and other processes on the device do receive proxy configuration. Only our extension's bundle identifier never does. We reproduced this on Wi-Fi and on cellular, and after a device restart. We have since learned, from a maintainer replying to an issue we opened on the pir-service-example repository, that "approved" in the CloudKit console is not the same thing as "successfully onboarded", and that we are still in the first state. That explains the behavior completely. What we cannot explain is how a provider is supposed to discover this. There is no status field in the console, no notification when the state changes, and nothing in the onboarding documentation that mentions a second stage exists. We wrote to Apple several times over these weeks. We were told more than once that an internal team would look into it, and we never received a reply. Apple Support told other providers in the same situation that this is a technical matter beyond their scope. Looking through the pir-service-example issues, this pattern is common. One provider reported waiting three months without a response. Another reported that form to production took almost four months. Another only discovered the feature had been enabled by noticing traffic arriving at their own server. My questions: Is there any supported way to check the onboarding state of a submitted configuration, or to ask about one that appears stuck? If not, is anything planned? Is the transition from "approved" to "successfully onboarded" expected to be automatic, and roughly how long should it take? For anyone who has been through this: did you eventually get a notification, or did you find out by watching your own server logs? We are not asking for our submission to be prioritized. We would simply like to know whether we are waiting on something or whether something needs to be resubmitted, and right now there is no way to tell the difference. Our paying subscribers cannot use the feature, and we have not been able to give them an accurate answer either. Thank you.