I submitted the app for review. They reviewed it the first time, provided feedback, I fixed the issues, and resubmitted it. Three weeks have passed, and they didn’t even accept the app with the fixes for a second review. This isn’t normal But at the same time, they charged me 99 euros for developer status in just 3 minutes It’s unclear what to expect and how long it will take

Hi! I have a few questions about the lifecycle and capabilities of the Crash Reporter Extension. Besides using the corpsePort to inspect the crashed process through Mach APIs, is it safe/supported/recommended for the extension to access files in a shared App Group container? Are there any caveats or exceptions we should be aware of, for example around memory-mapped files, file coordination, or filesystem access after the host app has crashed? Shall we use some particular APIs for this kind of shared resource or not? While debugging the extension, I noticed that when I trigger a crash in the app I am debugging, LLDB does not stop inside the extension (it also ends up stopping the debugging session). However, I can observe that the extension does run, because it writes data into a shared App Group directory related to the crash. Is this expected behavior? Is there a recommended way to debug the Crash Reporter Extension reliably (with lldb, or other way)? More generally, I would like to better understand the extension lifecycle: When exactly does the extension start running? How long can it live after the app crashes? Is there a time limit for operating on the corpse process? Is the extension subject to resource limits similar to other app extensions, such as memory, disk, CPU, watchdog, or jetsam constraints? If the Crash Reporter Extension itself crashes, how can we detect that? Would those crashes appear in Xcode Organizer, or is there another recommended way to observe them? Any clarification around the supported lifecycle, debugging model, and resource limits would be very useful.

Xcode’s “App Thinning Size Report” reports a size under 15MB, but very close to it like 14.9MB, and if I publish the clip it becomes unavailable for costumers (They get "App Clip Unavailable" after scanning the QR code. On the other hand, if the size on the report is 14.7MB, it works fine for everyone. Can you advice a more accurate way to determine if the size is valid for distribution? On the same topic: Are there any plans to increase the size limit beyond the 15MB?

The on-demand economy has transformed how businesses operate, and fuel delivery services are no exception. From mobile fueling for commercial fleets to doorstep fuel delivery for consumers, companies are investing heavily in advanced mobile applications to streamline operations, improve customer experiences, and optimize logistics. New York City is home to several leading app development firms that specialize in building innovative fuel delivery platforms. These companies offer expertise in mobile app development, route optimization, GPS tracking, payment integrations, fleet management, and real-time analytics. Choosing the right development partner can significantly impact the success of your fuel delivery business. This guide highlights the best fuel delivery app development companies in NYC, their strengths, key services, and reasons they stand out in the competitive app development market. 1. Suffescom Solutions Suffescom Solutions is a renowned mobile app development company offering custom on-demand fuel delivery solutions. Their team develops scalable applications equipped with real-time tracking, secure payments, and fleet management capabilities. Why They’re Selected Extensive experience in on-demand app development Expertise in fuel delivery and logistics platforms Strong portfolio across multiple industries Scalable and secure application architecture End-to-end development and maintenance support Key Services Fuel delivery app development Fleet management solutions GPS tracking integration Payment gateway integration UI/UX design App maintenance and support 2. BitsWits BitsWits specializes in creating innovative mobile applications for startups and enterprises. Their fuel delivery solutions emphasize user-friendly interfaces, automation, and advanced operational management features. Why They’re Selected Strong mobile-first development approach Custom-built applications tailored to business needs Agile development methodology Focus on performance and scalability Experienced development team Key Services Custom app development Fuel delivery application development Android and iOS app development Backend development API integrations Quality assurance testing 3. Fueled Fueled is a well-established digital product agency known for developing premium mobile applications. The company delivers high-performing fuel delivery platforms with intuitive customer experiences and advanced functionality. Why They’re Selected Strong reputation in mobile app development Expertise in enterprise-grade applications Innovative design capabilities Proven project delivery record Focus on user engagement Key Services Mobile app development Product strategy UX/UI design Backend engineering Cloud integration Digital transformation solutions 4. FuGenX Technologies FuGenX Technologies provides comprehensive app development services for businesses seeking digital transformation. Their fuel delivery solutions incorporate advanced technologies to improve operational efficiency and customer convenience. Why They’re Selected Global experience across industries Skilled development professionals Advanced technology adoption Cost-effective development solutions Strong support services Key Services Fuel delivery app development Enterprise mobility solutions Cross-platform app development AI-powered integrations Cloud solutions Maintenance and upgrades 5. Nectarbits Nectarbits delivers innovative mobile and web applications designed for on-demand service industries. Their expertise helps fuel delivery businesses streamline logistics and improve customer satisfaction. Why They’re Selected Specialized in on-demand applications Strong technical expertise Customized development approach Reliable project management Excellent customer support Key Services Mobile app development Fuel delivery platform development Fleet tracking systems Web application development API development Technical consulting 6. Apps Chopper Apps Chopper focuses on building custom mobile applications that help businesses achieve operational excellence. Their fuel delivery solutions support seamless fuel ordering and real-time service management. Why They’re Selected Extensive mobile development expertise User-focused design philosophy Strong development framework Transparent project execution Reliable post-launch support Key Services iOS app development Android app development Fuel delivery app solutions UI/UX design App testing App modernization services 7. Hyperlocal Cloud Hyperlocal Cloud is recognized for developing hyperlocal and on-demand delivery solutions. The company offers feature-rich fuel delivery applications that enable businesses to manage operations efficiently. Why They’re Selected Specialization in hyperlocal delivery models Advanced logistics management expertise Quick deployment capabilities Scalable application infrastructure Industry-focused development approach Key Services Hyperlocal app development Fuel delivery platform development Route optimization solutions Real-time tracking integration Dispatch management systems Cloud-based solutions 8. Konstant Infosolutions Konstant Infosolutions is a leading app development company serving startups and enterprises worldwide. Their fuel delivery solutions combine innovative technology with scalable business-focused functionality. Why They’re Selected Over a decade of development experience Strong international client base Comprehensive development services Flexible engagement models Proven success across industries Key Services Mobile application development Fuel Delivery App Development Company solutions Cross-platform development Cloud integration Enterprise software development Ongoing support and maintenance Conclusion The demand for on-demand fuel delivery services continues to rise as businesses and consumers seek greater convenience and efficiency. Partnering with an experienced app development company can help you build a reliable, scalable, and feature-rich platform that meets market expectations. The companies listed above have demonstrated expertise in developing advanced mobile applications and on-demand solutions. By carefully evaluating your business requirements and development goals, you can select the right technology partner to bring your fuel delivery app vision to life.

Hello, I am exploring an iPadOS product idea for Apple Pencil users and would like to understand the current public API boundary. The user need is a temporary, user-controlled Apple Pencil annotation layer while the user is working in another app or workspace. For example, a student may be reading in Books, Safari, a PDF app, or another educational app and want to write quick Pencil notes directly over the visible material without taking a screenshot or exporting the content first. I understand that PencilKit works inside an app's own UI, and I also understand that iPadOS sandboxing prevents third-party apps from inspecting or modifying other apps. I am not trying to bypass that model. What I am trying to determine is: Is there any current public API, extension point, or entitlement that allows a user-initiated Apple Pencil overlay session across the current iPadOS workspace? If not, is Feedback Assistant the right place to request a new PencilKit / iPadOS entitlement for this use case? Are there existing Apple-recommended patterns for this workflow beyond Quick Note, Screenshot Markup, Split View, Stage Manager, or importing content into the developer's own app? The privacy model I have in mind would be strict: The overlay is user initiated only. A visible system indicator is shown while active. The developer app receives Pencil stroke data only by default. The app cannot inspect the underlying app's view hierarchy, documents, text, or private data. Screen pixels are not captured unless the user grants separate explicit permission. The user can close or clear the overlay at any time. The closest mental model is a system-mediated Pencil annotation layer, not a background screen recorder or a way to control another app. If this is not possible today with public APIs, I would appreciate confirmation so I can file a clear enhancement request through Feedback Assistant. I also filed this as Feedback Assistant report FB23067750. Thank you.

WeatherService fails on every request with: WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" hourly forecast fetch failed: … Code=2 I've verified the entire setup and the error persists, which points to the App ID's WeatherKit token generation not being provisioned on Apple's backend: Team ID: 2LWCLD2636 Bundle ID: com.hoagiecorps.poppit WeatherKit capability and App Service both enabled on the App ID. com.apple.developer.weatherkit entitlement present in the signed binary and the embedded provisioning profile (verified via codesign -d --entitlements). A TestFlight build carrying the entitlement has been processed (VALID). Location authorized (When-In-Use); valid coordinates are obtained — the failure is purely the JWT auth step. Tried: device reboot, VPN off, iCloud Private Relay off, cycling the WeatherKit capability off/on plus regenerating the profile and clean rebuild, and waiting several days. Physical device, iOS 26. Could someone from the WeatherKit team please check the status for Team 2LWCLD2636, Bundle ID com.hoagiecorps.poppit, and enable WeatherKit token generation for this App ID? It looks like a backend entitlement sync is needed. Thanks!

Hi Apple Developer Support / WeatherKit team, I’m seeing WeatherKit fail on a physical iPhone with what appears to be a JWT / permission issue, even though the app appears to be correctly configured and signed with the WeatherKit entitlement. App / project context: App name: Signals Platform: iOS Framework: SwiftUI WeatherKit usage: Native WeatherKit framework, using WeatherService.shared.weather(for:) Purpose: Showing a small morning weather summary inside the app What I have already verified: Active Apple Developer Program membership WeatherKit capability enabled for the App ID in Apple Developer Portal WeatherKit capability enabled in the App Capabilities tab WeatherKit capability added in Xcode Signing & Capabilities Automatic signing enabled Built and tested on a physical iPhone device Location permission is requested and granted The app binary appears to include the WeatherKit entitlement The embedded provisioning profile appears to include the WeatherKit entitlement Issue: WeatherKit still fails at runtime with a JWT / permission-related error. Could you please help verify whether: The WeatherKit entitlement is correctly attached to my App ID and provisioning profile My Team ID / App ID has WeatherKit access fully enabled on Apple’s backend There are any backend propagation delays or stuck entitlement states WeatherDaemon has permission to generate JWTs for this app There is anything else I need to reset or regenerate, such as provisioning profiles, certificates, or App ID capabilities I can provide: Team ID Bundle ID provisioning profile UUID entitlement output from codesign device logs / WeatherKit error logs screenshots of App ID capability settings Thank you.

Hi, I wanted to reach out about an issue we're seeing in PTT Framework. We have been investigating reports from some users that our app would run without issue for a day or so and then they would suddenly be unable to transmit audio but playback continued to work normally. After doing some digging and internal testing I was able to reproduce this by triggering a media services reset while PTT Framework was active (we had joined a channel). When this occurs everything appears to work correctly, all normal callbacks are received and the audio session is activated, but the data from the tap on the input node of our audio engine returns only silence regardless of whether the app is in the foreground or background. I'm able to reproduce this with 100% reliability using the following steps: Activate PTT Framework by joining a channel. Navigate to Settings -> Developer, tap Reset Media Services, and select Reset All Media Services. Return to the app and attempt to transmit. I've validated this behavior both in our app as well as in a separate minimal test app we use internally to validate interactions with the framework. Once we end up in this state it persists through tearing down and recreating our audio engine, deactivating and re-activating the audio session, killing the app and restarting it, etc. The only way we have found to recover from this state is to either reboot the device or leave the framework's channel and join again (basically toggle PTT Framework off and back on). Based on what I was able to find I believe this is the known CallKit issue (r.157725305) referenced in this forum post and does extend to PTT Framework. As mentioned above, we currently haven't found a good way to deal with this. Our current solution to this is to programmatically "toggle" PTT framework. This partially solves the problem but it has a couple issues: It causes the PTT Framework activation and deactivation sounds in quick succession. This is expected but not ideal UX. Because attempting to join a channel when the app is not in the foreground results in a failure with PTChannelError.appNotForeground we can only recover when in the foreground. The second issue is the more serious of the two as our users commonly rely on external wired or BLE devices to trigger PTT calls while the device is locked or the app is in the background. In this scenario we can't automatically recover so they won't know something is wrong until they realize they are only transmitting silence. We can identify when this occurs via the internal media services reset notification but again we only receive this while the app is active. Additionally, if the app was suspended when the reset occurred but then becomes active it is received after a 2-4 second delay so if the app wakes up to start a call, we commonly don't receive it until the user is already in the middle of a call trying to transmit. Is there anything we can do here other than posting a notification telling the user that there is an issue and they need to on-screen the app to resolve it? I've tried to provide as much information as possible but if there's anything else that would be helpful let me know.

Incoming calls reported via reportNewIncomingCall on a CXProvider are correctly presented on the iPhone via CallKit, but are never relayed to the paired Apple Watch. Native cellular calls relay to the Watch correctly on the same devices. What does a VoIP app's CXProvider need to satisfy for callservicesd to consider it eligible for phone continuity relay to paired Apple Watch?

We are seeing a reproducible scenario on iOS 26 where incoming VoIP push notifications are never delivered when the device has been idle and screen-locked for 30+ minutes. The same failure was observed simultaneously on WhatsApp, and Microsoft Teams and our app as well, on the same device during one incident, confirming this is a platform-level issue and not specific to our implementation. We have captured full system logs across three separate incidents. Below are the exact log sequences. Incident — All VoIP apps fail simultaneously (Our app, WhatsApp, Teams) Device: iPhone 17 Pro · iOS: 18.x · Network: 5G NSA (kNRNSA) The device had been idle with the screen locked for approximately 31 minutes. An LTE cell handover caused apsd to begin an APNs reconnection. powerd entered policy 3 before apsd reached channel-flow viable, defuncting the app. 17:45:59.562 symptomsd New RRC 0 when previous 1 from pdp_ip0 ↑ Radio drops to RRC_Idle. Device has been idle since 17:14:56 (31 min). 17:46:01.206 CommCenter #I Mapping the registration state to kRegisteredHome ↑ LTE cell handover triggers RRC reconnect. 17:46:01.330 apsd [C138 IPv4#b71cac13:5223 ready parent-flow (satisfied (Path is satisfied), interface: pdp_ip0[lte], scoped, ipv4, ipv6, dns, expensive, uses cell, LQM: good)] event: path:satisfied_change @594.391s ↑ APNs path re-satisfied. Reconnection begins. channel-flow viable NOT yet reached — TLS handshake still in progress. 17:48:08.057 apsd Powerd has requested assertion activity update ↑ Warning: powerd about to change policy. ── 2 minutes 40 seconds after APNs reconnect started ── 17:48:41.248 powerd Sending com.apple.powerd.assertionpolicy 3 17:48:41.250 apsd Update assertion policy 3 17:48:41.250 powerd Activity changes from 0x1 to 0x0. UseActiveState:0 17:48:41.250 powerd hidActive:0 displayOff:1 assertionActivityValid:0 ↑ Screen off, device locked. OS enters restricted idle. apsd restricted. APNs reconnection abandoned. 17:48:42.669 kernel necp_process_defunct_list: necp_update_client abort nexus error (2) for pid 1518 Comera ↑ Kernel terminates Comera's network stack via NECP. No API available to prevent this. WhatsApp and Teams remain suspended — no DEFUNCT, but apsd in policy 3 means no push delivery for them either. ── Dead zone: VoIP pushes for all 3 apps undeliverable ── 17:50:04.028 powerd Process CommCenter.104 Created SystemIsActive "com.apple.ipTelephony.sipIncoming.cell" ↑ Incoming cellular PSTN call forces system wake. 17:50:04.494 powerd Sending com.apple.powerd.assertionpolicy 0 17:50:04.598 apsd Update assertion policy 0 ↑ Full wake. Queued VoIP pushes from Comera, WhatsApp, and Teams are delivered simultaneously. Gap between channel-flow viable needed and actual delivery: 4 minutes 3 seconds. Recovery trigger: external cellular call from carrier — not any app action. Working case (same test, different conditions) Device: iPhone 17 Pro · iOS: 26.5.1 · Screen unlocked, no hotspot 19:2x:xx apsd policy state {downgradeWhenLocked: NO, isSystemLocked: NO, isConnectedOnUltraConstrainedInterface: NO} ↑ Device unlocked. No policy 3. Comera NOT defuncted. Push delivered. Call rings normally. Our implementation PKPushRegistry is held strongly and re-registered on every applicationWillEnterForeground reportNewIncomingCall(with:update:completion:) is called synchronously within pushRegistry(_:didReceiveIncomingPushWith:) VoIP background mode entitlement is present App has com.apple.developer.pushkit.voip entitlement Questions Is there any entitlement or API to prevent NECP from defuncting a process holding an active PKPushRegistry? The VoIP push entitlement exists for exactly this background delivery scenario. Is pushDisallowed being applied to apps with VoIP push entitlements when InternetSharingActive == 1 intentional? Should VoIP entitlements exempt an app from the Internet Sharing Policy gate in dasd? Is there a documented way to know when apsd has fully completed APNs reconnection (i.e. channel-flow viable) so a server can time push retries more accurately within a call validity window? What is the recommended apns-expiration value for VoIP pushes to survive brief APNs reconnection windows without exceeding a 60-second call validity period? Full log stream captures available for all incidents.

I built an advanced app clip experience, associated it to a location, and its MATCHED. The status is marked (green) RECEIVED. However, I am unable to see the invocation on Maps. I don't see the buttons such as SUPPORT/ORDER shown for that place. The docs does not explain why. What is the exact requirement for us to surface buttons for POI? We are authorized by the businesses to add these for them. I'd love to hear in detail the exact process to add buttons for POI - how Uber Eats and Door Dash does it for restaurants and how their app clips get shown. Thank you.

I'm building a cross-device parental-control app: separate child and parent devices in the same Family Sharing group. I want to show the child's per-app (and per-category) Screen Time usage on the parent device. After extensive testing I can only get the child's total minutes across, and I'd like to confirm the supported architecture before building further on a path the framework may intentionally forbid. Authorization / setup Child device: AuthorizationCenter.shared.requestAuthorization(for: .child) — approved. Confirmed authorized: my app appears under Settings → Screen Time on the child, and the child's own DeviceActivityReport(users: .all) renders full per-app data. Parent device: separate device in the same family. Targets: main app + DeviceActivityReport extension + DeviceActivityMonitor extension, all with com.apple.developer.family-controls and a shared App Group. Physical devices, iOS 26.4.1. Xcode ⟦version⟧. What works: only the child's total minutes reach the parent — and only via my own relay: a DeviceActivityMonitor extension on the child writes aggregate totals to the App Group, the host app syncs them through CloudKit. No Screen Time API itself delivers the child's app/category breakdown to the parent. ⸻ Finding 1 — the report extension computes correct per-app data but cannot export it. On the child, makeConfiguration(representing:) iterates the results and produces correct per-app durations: LumicoActivityReport makeConfiguration done — 1 activityData, 1 segments, 5 apps, 17 min total Writing those aggregates to the shared App Group from inside the extension is then denied by the sandbox: Couldn't write values for keys ("screen_time_per_app_json") in CFPrefsPlistSource (Domain: group.servusjon.Lumico.shared …): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access (UserDefaults.set doesn't throw — the write silently no-ops; only this CFPrefs log reveals the denial.) Q1: Is there any supported way to surface aggregated, non-identifying per-app usage (app name + minutes + category) computed inside the DeviceActivityReport extension to the host app, given that App Group writes from the extension are denied? Or is the DeviceActivityMonitor extension (threshold events) the only supported way to get any usage signal out of the Screen Time sandbox? Finding 2 — on the parent, users: .children shows the parent's OWN data. On the parent I embed DeviceActivityReport(_:filter:) with DeviceActivityFilter(users: .children, …). The report renders, but shows the parent's own apps/categories — no child data. FamilyActivityPicker on the parent behaves the same (lists the parent's own apps). The identical code on the child (users: .all) returns the child's full data — so the pipeline works; only the cross-device delivery to the parent fails. Q2: What is required for DeviceActivityReport(users: .children) to deliver a child's activity to a third-party app on the parent device? Must the parent app hold a specific FamilyControls authorization (which FamilyControlsMember)? What conditions make FamilyActivityPicker surface a child's apps (not just categories) from the family on the parent device — authorization type, Family Sharing roles, child managed status, sync timing? ⸻ Already ruled out: physical devices (not Simulator); Screen Time data present on the child; extension correctly embedded (ExtensionKit com.apple.deviceactivityui.report-extension) and running makeConfiguration normally; family-controls + App Group present on app and both extensions; iCloud container named conventionally iCloud.. Core question: What is the supported architecture for showing a child's per-app usage on a parent's device in a third-party app? I want to build on the sanctioned path rather than a workaround. Thanks!

We have six Advanced App Clip Experiences configured for our production app, each mapped to a different path under a single domain, each with its own title and image. When a user without the full app installed receives one of these links in Messages, iOS always presents the default App Clip card -- never the matching advanced experience card. The same URLs resolve the correct advanced card in Safari. What we've already verified (so this isn't a basic setup problem): Opening the exact same URL in Safari shows the correct advanced card, including the expected per-path title. A Local Experience (Settings → Developer → App Clips Testing) for the same path + bundle ID validates and launches the correct flow. Associated Domains validation is green in Settings. The AASA at app-site-association.cdn-apple.com contains the appclips component with our App Clip bundle ID, and the applinks components include all six paths. In App Store Connect, all six Advanced App Clip Experiences show "Received" with successful domain validation, and the app + App Clip are live in the App Store. Reproduced on multiple devices on iOS [version], none with the full app installed. Messages does show a card — it's just always the default card. Our questions: Is per-path Advanced App Clip Experience card selection supported in the Messages link bubble at all -- or is Messages documented to always present the default experience metadata regardless of which advanced-experience URL is shared? Apple's App Store Connect help states the default metadata is used "in the app clip link bubble in Messages," which suggests this may be by design -- can someone confirm? If advanced cards in Messages are supported, what conditions cause Messages (but not Safari) to fall back to the default card for the same URL? Does "Received" status indicate an advanced experience is fully live, or is there a later state that confirms Messages rollout? If Messages is expected to always show the default card, we'll plan around that -- we just want a definitive answer rather than continuing to chase a configuration cause. Thanks!

We noticed that in older OS versions the accessory picker would consistently display a peripheral's advertised friendly name on top of displaying information from the matching display item. While in newer OS versions we would mostly only see the name from the display item. Is there a way to configure this?

The documentation specifies that when Contacts framework returns unified contacts that each fetched unified contact object (CNContact) has its own unique identifier that’s different from any individual contact’s identifier in the set of linked contacts and that when refetching a unified contact, that this identifier should be used. There is also an analogous identifier within the list of contactRelations, but each of these don't seem to corespondent to the unified contacts. For example, is a new contact (Sheryl Zakroff) is created in the simulator Contacts and their spouse is set to Hank Zakroff. However, the GUID created for the contactRelations identifier does not correlate to the original Hank Zakroff GUID and cannot be searched. Is this a bug or what is the indent of the contactRelations identifier? Here's a debug output of walking the unifiedContacts: Name: Hank Zakroff 2E73EE73-C03F-4D5F-B1E8-44E85A70F170 - Other : (555) 766-4823 - Other : (707) 555-1854 Name: David Taylor E94CD15C-7964-4A9B-8AC4-10D7CFB791FD - Other : 555-610-6679 Name: Sheryl Zakroff DE783BC8-7917-4138-93F6-3AF0FD4CE083 - Other : (707) 555-1854 - Spouse: <CNContactRelation: 0x60000000dd60: name=Hank M. Zakroff> - 534B467D-CA00-46D3-897C-16EEA782C9CF - Looking for ["534B467D-CA00-46D3-897C-16EEA782C9CF"] []

Hi! Sms reporting is no longer available in iOS beta 26 builds. I can set my app as the SMS/Call Reporting Extensions but the report button is missing for sms messages in the messages app. Xcode 26 beta 7 build the app without errors. This is a breaking change. Same extension was previously broken for calls but has been fixed in beta 7 build, as reported here. It is however still missing for sms messages in the messages app (beta 9 build).

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 don't see upload option for the App Store connect, can only export .ipa. Also having issues with Transporter, pasting error message here. Could not create a temporary .itmsp package for the app "Redacted.ipa". Unable to determine app platform for 'Undefined' software type. Is anyone else facing the same issue? I am using Xcode 15.

I have a question regarding parental control features within a region with age assurance regulations. The DeclaredAgeRange docs here suggests that age range can be "set" by the user or their parent or guardian: Check the ageRangeDeclaration to understand how the person or their parent or guardian set their age range. The declaration method indicates whether the age was self-declared, guardian-declared, or verified using a payment method, government ID, or another method. Based on this, I'm assuming the parent has the ability to override the user's real age (ex: 13 year old set to 18+?). Is that a correct assumption? Or do users that belong into a regulated region always return their true age for the purposes of Texas SB2420?

Hello! Our app includes a calling feature for some users, and we would like to promote to those users that they can set our app as their default calling app. If there is no way to check this state, then the risk is that we may repeatedly prompt users to enable something they have already enabled. There also doesn't appear to be a way to set the default calling app programmatically, and that the best we can do may be to direct the user to the default app section in Settings. For our app, the calling capability is only applicable to some users. For users who are not eligible to place calls, we would prefer that they not be able to set our app as the default calling app at all. Otherwise, iOS may route calling actions to our app. So my questions are: Is there any supported API or other mechanism to determine whether the user has set our app as their default calling app? Is there any supported way to enable, disable, or hide default calling app eligibility programmatically? My current understanding is that neither of these is possible, but I would appreciate confirmation or any recommended workaround. Thanks.