Summary I am seeking clarification regarding an App Store rejection under Guideline 4.2 – Design – Minimum Functionality, specifically around expectations for booking and payment flows in apps that rely on third-party, industry-standard reservation platforms. This app is a production application for a licensed transportation (black car / limo) service. It includes multiple native iOS features implemented via Capacitor and custom Swift plugins. However, the booking and payment flow depends on a third-party transportation platform (RideBits) that does not currently support deep linking with prefilled parameters or programmatic booking APIs. Before committing to a significant architectural change, I am hoping to understand whether Apple’s expectation under Guideline 4.2 is that all transactional booking and payment flows must be fully native and controlled by the app developer, even when third-party systems are operationally required. ⸻ App Context The app is designed for a real transportation business and is not a content, marketing, or browsing application. It is purpose-built for trip booking, pickup coordination, and customer interaction. The third-party platform (RideBits) handles: • Dispatch and driver assignment • Vehicle inventory and pricing rules • Payment processing • Trip lifecycle management This platform is central to business operations and is commonly used in this industry. ⸻ Native Functionality Implemented The app includes meaningful native iOS functionality beyond web content, including: • Native Core Location access (with permission handling) • Native reverse geocoding using CLGeocoder via a custom Swift Capacitor plugin • Native clipboard integration • Native iOS share sheet integration • Apple Maps deep linking • Custom CAPBridgeViewController with explicit plugin registration All native plugins were verified at runtime and tested on physical devices and simulators. ⸻ Booking Flow Constraint The third-party platform does not currently support: • Deep links with prefilled booking parameters • Passing pickup/dropoff data via URL • Native SDK embedding • APIs for programmatic booking creation As a result, even when pickup data is collected natively, users must re-enter details within the booking flow. ⸻ App Review Outcome Despite adding additional native functionality, the app was rejected again under Guideline 4.2, with feedback stating the experience is not sufficiently differentiated from web browsing and that features such as Core Location or sharing alone are not robust enough. ⸻ Clarification Requested I am hoping to better understand Apple’s expectations in this scenario: 1. Is Apple’s expectation that core booking and payment flows must be fully native to satisfy Guideline 4.2, regardless of industry-standard third-party dependencies? 2. Would an app be considered acceptable if the booking UI is native, but final transaction submission occurs through a third-party system? 3. Are there known precedents for service or transportation apps using third-party booking platforms that have successfully passed review? 4. Is the issue primarily technical (missing native features), or conceptual (core value relies on an external flow)? ⸻ Purpose of This Post Before undertaking a major rebuild of pricing, payments, and booking logic in-house, I want to ensure there is no App Store–acceptable architecture that allows: • Meaningful native functionality, and • Continued use of a third-party operational booking platform. Any guidance or shared experience would be greatly appreciated.

Hello Apple Developer Community, We have an enterprise app that was originally developed using Xcode 10 and Objective-C. The app has been running smoothly on previous iOS versions, but with the upcoming release of iOS 26, we are concerned about potential compatibility issues due to the age of our development environment and possible deprecations in the iOS SDK. Our Situation: App Type: Internal enterprise app (distributed via Apple Developer Enterprise Program) Development Environment: Xcode 10, Objective-C Current Status: App works on iOS 18; not yet tested on iOS 26 Distribution: Not on App Store; internal use only Questions: Are there known compatibility issues for apps built with Xcode 10 and Objective-C when running on iOS 26? Are there specific deprecated APIs or changes in iOS 26 that we should be aware of? What are the recommended steps to test and validate enterprise apps on the latest iOS beta? Is it mandatory to rebuild the app using a newer version of Xcode for iOS 26 compatibility, or can we continue using our existing build if it passes testing? Any advice on best practices for enterprise app migration or update planning? Additional Info: We plan to test the app on iOS 26 beta devices soon and will share any specific issues encountered. If there are official Apple resources or documentation addressing these concerns, please point us in the right direction. Thank you in advance for your guidance!

I am working to update a live blog in Apple News. As far as I know there is an update endpoint to update a content in Apple News. Is there any feature in Apple News to trigger an event when the original content updated and pull the updated content?

Hi there, Can anyone tell me how to possibly get approved as an Apple News Publisher in 2025? We attempted in 2024, but received this message from Apple support: "Thank you for your interest in Apple News. At this time, we're not accepting new applications." When I inquired further, I got this second response: "Apple News is no longer accepting unsolicited applications. To learn more about Apple News requirements, visit the Apple News support page. If you have any feedback, please use this form to send us your comments. Keep in mind that while we read all feedback, we are unable to respond to each submission individually." My questions are: Is this still the case? (Especially when you are a legit local news outlet) Is there a link to apply as a news publisher? I don't seem to have that option at all. Thanks for any feedback.

Apologies if this isn't tagged right but dev tools and services seemed the most appropriate since this is related to the workbench Ad Tester tool. I'm seeing a behavior where the preview link is not being generated. Specifically, I am seeing a POST request to the following URL consistently fail: https://iadworkbench.apple.com/adtester/api/v1/ads/previewLink?orgId=1127861 Variations/scenarios I have tried so far: All possible ad format choices on all possible devices All options for the placement type Both third party and uploaded creative sources Uploaded creative sources appear to be failing to upload as well A simple div with a "hello world" content fails as a third party creative source Multiple apple accounts I created a new account specifically to test if my primary apple ID was experiencing issues with this Multiple browsers I have tried multiple versions of Chrome/Firefox/Safari I tested with and without browser extensions to determine whether an extension was interfering or not Clearing session/local storage along with cookies I also created new profiles in browsers to verify that I was getting a fresh browser environment In all of these cases, the API request to generate a preview link is consistently failing with a 500 error code. It's worth noting that the web preview option works, but this isn't a truly accurate test environment and can't be solely relied on when testing ad content. I don't know exactly when this started happening as I have not used it in the last couple of weeks but I have used the workbench ad tester extensively in the past the same way I have been trying with my current test without issue. That coupled with the fact that the request for the preview link consistently fails in all of the test scenarios I've outlined above leads me to believe there is a problem with the API that is responsible for generating the preview links.

Hello, I’m reaching out to gather information regarding the upcoming changes to APNs certificates that are set to be implemented in the beta at the end of January 2025. Specifically, I would like to understand the following: What will be the practical impact of these changes on apes apis ? What actually needed to be done at trust store for this changes, and how will it affect our current setup? What steps do we need to take to update the certificates on our servers? it’s crucial for us to address these changes in advance and keep our customers informed. Thank you for your help!

I work at a well-established university with a business journal that is over 25 years old. We have been waiting now for almost four months to have our Apple News account reviewed. In what world is this OK? No ability to communicate with anyone or have any updates except to log in once a month to see the 'under review' message still there. Seriously?