My company has a server that supports ticket-based TLS session resumption (per RFC 5077). We have done Wireshark captures that show that our iOS client app, which uses URLSession for REST and WebSocket connections to the server, is not sending the TLS "session_ticket" extension in the Client Hello package that necessary to enable ticket-based resumption with the server. Is it expected that URLSession does not support ticket-based TLS session resumption? If "yes", is there any way to tell URLSession to enable ticket-based session resumption? the lower-level API set_protocol_options_set_tls_tickets_enabled() hints that the overall TLS / HTTP stack on IOS does support ticket-based resumption, but I can't see how to use that low-level API with URLSession. I can provide (lots) more technical details if necessary, but hopefully this is enough context to determine whether ticket-based TLS resumption is supported with URLSession. Any tips / clarifications would be greatly appreciated.

We have developed apps for the App Store for more than 7 years. One day, out of the blue we noticed all our apps have been removed and our account was pending termination. We really didn't know what was going on since we behaved correctly and honestly during all those years of development. After we asked for more info on why our account was in pending termination state we received this reply: Hello [redacted], We received your complaint filed on 2 October 2024 pursuant to the Regulation (EU) 2019/1150 of the European Parliament and of the Council of 20 June 2019 on promoting fairness and transparency for business users of online intermediation services (“P2B Regulation”). This correspondence serves as a response to your complaint. We thoroughly evaluated the activity associated with your Apple Developer Program membership. Our investigations confirm that your Apple Developer Program membership has been repeatedly used for dishonest and fraudulent activity in violation of Section 3.2(f) of the Apple Developer Program License Agreement, which states: “You will not, directly or indirectly, commit any act intended to interfere with any of the Apple Software or Services, the intent of this Agreement, or Apple’s business practices including, but not limited to, taking actions that may hinder the performance or intended use of the App Store, Custom App Distribution, TestFlight, Xcode Cloud, Ad Hoc distribution, or the Program (e.g., submitting fraudulent reviews of Your own Application or any third party application, choosing a name for Your Application that is substantially similar to the name of a third party application in order to create consumer confusion, or squatting on application names to prevent legitimate third party use). Further, You will not engage, or encourage others to engage, in any unlawful, unfair, misleading, fraudulent, improper, or dishonest acts or business practices relating to Your Covered Products (e.g., engaging in bait-and-switch pricing, consumer misrepresentation, deceptive business practices, or unfair competition against other developers).” We found a pattern of manipulative or misleading behavior. As a result of this behavior, your Apple Developer Program membership has been flagged for termination. These behaviors can include, but are not limited to, inaccurate metadata describing your app or service, misleading app content, engaging in inauthentic ratings and reviews manipulation, providing misleading customer support responses, providing misleading responses in App Store Connect, engaging in misleading purchasing or bait and switch schemes, or other dishonest or fraudulent activity within or outside of the app. Our recent investigation and review of your developer account confirm violations of the App Review Guidelines. Specifically, we received a notice claiming that your [redacted app] allowed users to download media content without authorization from the relevant third-party sources. Our investigations confirmed this behavior which constitutes direct and egregious violations of App Review Guidelines 2.3.1 and 5.2.3. In addition, your binary submission from 1 October 2024 continued to include references to impermissible conduct under Guideline 5.2.3. Given the egregious nature of the violations, your app was removed and your Apple Developer Program account has been flagged for termination. For the sake of clarity, we have included relevant excerpts from the App Review Guidelines below for reference: 2.3.1 (a) Don’t include any hidden, dormant, or undocumented features in your app; your app’s functionality should be clear to end users and App Review. All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review. Similarly, marketing your app in a misleading way, such as by promoting content or services that it does not actually offer (e.g. iOS-based virus and malware scanners) or promoting a false price, whether within or outside of the App Store, is grounds for removal of your app from the App Store or a block from installing via alternative distribution and termination of your developer account. (b) Egregious or repeated behavior is grounds for removal from the Apple Developer Program. We work hard to make the App Store a trustworthy ecosystem and expect our app developers to follow suit; if you’re dishonest, we don’t want to do business with you. 5.2.3 Audio/Video Downloading: Apps should not facilitate illegal file sharing or include the ability to save, convert, or download media from third-party sources (e.g. Apple Music, YouTube, SoundCloud, Vimeo, etc.) without explicit authorization from those sources. Streaming of audio/video content may also violate Terms of Use, so be sure to check before your app accesses those services. Authorization must be provided upon request. The guiding principle of the App Store is to provide a safe and enjoyable experience for users and a great opportunity for all developers to be successful. We work hard to make the App Store a trustworthy ecosystem and expect our app developers to be honest with users and with us. Manipulative or misleading behavior degrades user trust in the App Store and is grounds for removal from the Apple Developer Program. [...] Sincerely, Apple We immediately checked upon the issue and noticed that the feature that Apple has been mentioning was enabled by mistake due to a technical malfunction inside our app and explained this to Apple in detail. We have also immediately submitted a new update to completely remove the code that allow the download of media content from the third party website in order to avoid an issue like this would ever happen in the future and also explained the situation to Apple, being completely transparent. Apple is currently ignoring our explanation and also the fact that we immediately addressed the issue and nothing was done in bad faith. The update we submitted should have completely fixed permanently the issue and yet we got our account terminated. An account with an app downloaded 50M times that have users worldwide and a 4.5 star rating. We never engaged in dishonest or fraudulent behavior and tried to explain this. It’s really disappointing and unfair to be falsely accused of dishonest behavior, and having no way to resolve the issue. We have been at complete disposal and all the facts reported are true and we have always been honest with our users and with Apple. We heavily invested in the Apple ecosystem having our app implemented Siri support, CarPlay support, MacOS support, Widget support and recently working also on the Apple Watch support. I really hope someone of the Apple Review Team could look into this and gave us the opportunity to fix this issue.

There are significant crash reports coming from iOS 18 users regarding AVKit framework that starts from this line [AVPlayerController _observeValueForKeyPath:oldValue:newValue:] which seems to be coming from iOS internal SDK. There are 2 kinds of crash we found: UI modification on background thread From the stack trace it seems like when AVPictureInPictureController is being deallocated and its view is being removed from superview somehow the code is being executed in background thread because there is this line there _AssertAutoLayoutOnAllowedThreadsOnly highlighted before the crash. But I’ve checked our code that plays around AVPictureInPictureController, in the locations where we would deallocate the object it will always be called on main thread which are insideviewDidLoad and deinit inside UIViewController class. From the log, it seems like the crash happened when user try to open another content when PIP player is active resulting in the current PIP instance will be replaced with a new one. My suspect is the observation logic inside AVPlayerController could be the hint to this issue, probably something broken over there since this issue happened across our app versions on iOS 18 users only. Unfortunately, I was unable to reproduce this issue yet but one of my colleagues reproduced it once but haven’t been able to do it again since. The reports keep raising each day up to 1.3k events in the last 30 days now. Over release object This one has lower reports than the first one but I decided to include it since it might have relevant information regarding the first crash since the starting stack trace is similar. The crash timing seems to be similar to the first one, where we deallocate existing AVPictureInPictureController and later replace it with a new one and also found only in iOS 18 users which also refers to [AVPlayerController _observeValueForKeyPath:oldValue:newValue:]. I also was unable to reproduce this issue so far. Oh, and both of the issues happened on both iPhone and iPad. We’d appreciate any advice on what we can do to avoid this in the future and probably any hint on why it could happened. I have reported this issue with bug number: FB15620734 I also attached one sample crash report for each of the crashes here. non ui thread access.crash over release.crash

I have recently been having trouble with my iOS 18.2 beta update. It has been 2 weeks since I have updated to iOS 18.2 beta and joined the Genmoji and image playground waitlist. I am wondering how much longer I have to wait till my request is approved.

Hello, I have an app in AppStore "Counter Widget". https://apps.apple.com/app/id1522170621 It allows you to add a widget to your homescreen/lockscreen to count anything. Everything works fine except for one scenario. iOS 18+ I create 2 or more widgets for one counter. For example, medium and small widgets. I click on the widget button to increase or decrease the value. The button in the widget uses Button(intent: AppIntent) to update the value and calls WidgetCenter.shared.reloadAllTimelines() to update the second widget for the same counter. For iOS 18 in this particular scenario, you don't even have to call the WidgetCenter.shared.reloadAllTimelines(). iOS already knows that there is a widget with the same INIntent settings and will update it itself. Both widgets are updated and show the new value. Everything is correct. Now on the homescreen I open the widget configuration for one of the widgets to change the INIntent for the widget. For example, i change the background to wallpaper. This is just a skin for the widget, and the widget is associated with the same counter value as before. As in (2), I click the widget button to increase or decrease the value. But now only one widget is updated. iOS ignores my call to WidgetCenter.shared.reloadAllTimelines() and does not update the second widget connected to the same counter. As I found, iOS, when I call WidgetCenter.shared.reloadAllTimelines() from the widget itself, updates other widgets only if INIntent is absolutely equal for them. Overriding isEqual for them did not help. That is, I cannot specify which fields from my INIntent can be ignored during such an update and consider that widgets are equal and need to be updated. Obviously iOS make this compare outside my code. The main problem is that when the user adds a widget to the lock screen and increases and decreases the value there. After that, he opens the home screen and the widget there is not synchronized with the value from the widget on the lock screen. How to solve this problem?

We're seeing sporadic crashes on devices running iOS 18.1 - both beta and release builds (22B83). The stack trace is always identical, a snippet of it below. As you can tell from the trace, it's happening in places we embed SwiftUI into UIKit via UIHostingController. Anyone else seeing this? 4 libobjc.A.dylib 0xbe2c _objc_fatalv(unsigned long long, unsigned long long, char const*, char*) + 30 5 libobjc.A.dylib 0xb040 weak_register_no_lock + 396 6 libobjc.A.dylib 0xac50 objc_storeWeak + 472 7 libswiftCore.dylib 0x43ac34 swift_unknownObjectWeakAssign + 24 8 SwiftUI 0xeb74c8 _UIHostingView.base.getter + 160 9 SwiftUI 0x92124 _UIHostingView.layoutSubviews() + 112 10 SwiftUI 0x47860 @objc _UIHostingView.layoutSubviews() + 36

I add the following info in the build settings of my app. Then I also add the icon to my asset. I build the app, it works normally, but I notice that when I changed the icon to 'AppIcon-Defaults', The icon change alert didn't appear. but it succeeds . I uploaded the archive to App Store I got: ITMS-90895: Missing Icon - The Info.plist key CFBundleIcons.CFBundleAlternateIcons contains an entry “AppIcon-Defaults” that references asset “AppIcon-Defaults.” No such asset is present in the asset catalog. Then I use xcrun --sdk iphoneos assetutil --info Assets.car to check the assets inside the archieved app, It have the asset.

In Xcode's (version 16.1) "Devices and Simulators" window pressing the device's context menu item "Show Provisioning Profiles..." does nothing: no new window, no message, nothing. How can I fix this?

In order to create a Message Filter Extension it is necessary to set up Shared Web Credentials. I'd like to form an understanding of what role SWC plays when the OS is making request to the associated network service (when the extension has called deferQueryRequestToNetwork()) and how this differs from when an app directly uses Shared Web Credentials itself. When an app is making direct use of SWC, it makes a request to obtain the user's credentials from the web site. However in the case of a Message Filter Extension, there aren't any individual user credentials, so what is happening behind the scenes when the OS makes a server request on behalf of a Message Filtering Extension? A more general question - the documentation for Shared Web Credentials says "Associated domains establish a secure association between domains and your app.". Thank you

When I build and rum my iOS app with xocde 16.0 or higher version with my 16.0 iOS, 17.0 iOS, if fails to run with error. (Library not loaded: /System/Library/Frameworks/SwiftUICore.framework/SwiftUICore) I found this error after update my macOS and xcode (Ventura -> Sequoia, Xcode 15.2 -> 16.2). I try to setting '-weak_framework SwiftUI' for solve this error with this post (https://forums.developer.apple.com/forums/thread/126506). But when applied, an error occurred in modify on all swiftUI. If a project is built with a simulator over 18 versions, it runs smoothly. *issue project is with tac or tuist. There are two projects in question, and each configuration is (1.17.0 tca + 4.37.0) / (tuist 3.4.0). Does anyone have any pointers as where I even start to debug this issue and narrow down on what's going on with Xcode 16?

The Apple documentation for [UIViewController willMoveToParentViewController:] states, Called just before the view controller is added or removed from a container view controller. Hence, the view controller being popped should appear at the top of the navStack when willMoveToParentViewController: is called. In iPadOS 16 and 17 the view controller being popped appears at the top of the navStack when willMoveToParentViewController: is called. In iPadOS 18 the view controller being popped has already been (incorrectly) removed from the navStack. We confirmed this bug using iPadOS 18.2 as well as 18.0. Our app relies upon the contents of the navStack within willMoveToParentViewController: to track the user's location within a folder hierarchy. Our app works smoothly on iPadOS 16 and 17. Conversely, our customers running iPadOS 18 have lost client data and corrupted their data folders as a result of this bug! These customers are angry -- not surprisingly, some have asked for refunds and submitted negative app reviews. Why doesn't willMoveToParentViewController: provide the correct navStack in iPadOS 18.2?

Hi, I've had trouble for a while now with HealthKit giving me different values if I make the request on iOS and WatchOS. I am using the exact same method on both with the same parameters but I get vast differences in the results. The code I am using to call HealthKit on both devices is: let dateRange = HKQuery.predicateForSamples(withStart: Date().removeMonths(numberOfMonths: 1), end: Date().endOfDay()) let predicate: NSPredicate predicate = NSCompoundPredicate(type: .and, subpredicates: [dateRange]) let query = HKStatisticsQuery(quantityType: HKQuantityType(.stepCount), quantitySamplePredicate: predicate, options: .cumulativeSum) { _, result, error in if error != nil { //print("Error fetching step count, or there is no data: \(error.localizedDescription), \(startDate) -> \(endDate)") onComplete(0) return } if let result, let sum = result.sumQuantity() { let stepCount = sum.doubleValue(for: HKUnit.count()) DispatchQueue.main.async { onComplete(Int(stepCount)) } } } healthStore.execute(query) }

Here's the problem I'm trying to solve: Create an iOS app which can scan the Downloads folder (where airdropped audio files arrive), identify audio media files, and play them, retaining some of its own metadata about them (basically, create textual notes mapped to timestamps and store that information in the apps own storage). I am not able to access that folder. I am able to get a path from NSSearchPathForDirectoriesInDomains(FileManager.SearchPathDirectory.downloadsDirectory, FileManager.SearchPathDomainMask(arrayLiteral: FileManager.SearchPathDomainMask.userDomainMask), true) or a URL from NSSearchPathForDirectoriesInDomains(FileManager.SearchPathDirectory.downloadsDirectory, FileManager.SearchPathDomainMask(arrayLiteral: FileManager.SearchPathDomainMask.userDomainMask), true) but let fileUrls = try fileManager.contentsOfDirectory(at:downloads, includingPropertiesForKeys: []) fails with an error that the folder does not actually exist, with or without a call to downloadsUrl.startAccessingSecurityScopedResource(). Determining whether this is a permissions issue, or if I'm getting a URL to an application-container local folder that has nothing to do with the one I am looking for is compounded by the fact that if I set the build setting Enable App Sandbox, then deployment to my phone fails with Failed to verify code signature. I have spent hours trying every possible combination of certificates and deployment profiles, and ensured that every possibly relevant certificate is trusted on my phone. Disable app-sandbox and it deploys fine, either with automatic signing or an explicit cert and profile. I have an entitlements file with the following - though, without the ability to enable app sandbox and run it on a phone with actual contents in the downloads folder, it is probably not affecting anything: <key>com.apple.security.files.downloads.read-only</key> <true/> <key>com.apple.security.files.user-selected.read-only</key> <true/> <key>com.apple.security.app-sandbox</key> <true/> So, questions: Should the URL returned by the above call be the Downloads/ folder airdropped to in the first place? Or is it a URL to some app-local folder that does not exist? Does the entitlement com.apple.security.files.downloads.read-only even allow an app to list all files in the downloads directory (presumably asking the user's permission the first time), or does the permission only get requested when using a picker dialog? (the point here is to find any new audio files without making the user jump through hoops) If I could get it deployed with app-sandbox enabled, would the above code work? Backstory: I'm a software engineer, audio plugin author, Logic Pro user and musician. My workflow (and probably many other Logic user's) for work-in-progress music is to airdrop a mix to my phone, listen to it in a variety of places, make notes about what to change, edit - rinse and repeat. For years I used VLC for iOS to keep and play these in-progress mixes - you could airdrop and select VLC as the destination (yes, Logic can add to your Apple Music library, but trust me, you do not want 20 revisions of the same song cluttering your music library and sync'd to all your devices). Last year, the behavior of Airdrop changed so that the target app for audio is always Files, period, wrecking that workflow. While I eventually discovered that, with an elaborate and non-obvious dance of steps, it is possible to copy files into VLC's folders, and make them available that way, it is inconvenient, to say the least - and VLC is less than fabulous anyway - it would be nice to have an app that could associate to-do notes with specific timestamps in a tune, A/B compare sections between old and new versions and things like that. So, figuring sooner or later I was going to get into a car accident futzing with the Files app to listen to mixes while driving, perhaps I should write that app. But the ability to do that at all relies on the ability of an app to list and access the Downloads folder airdropped audio files land in (assuming the user has given permission to access it, but that should be needed once).

Please include the line below in follow-up emails for this request. Case-ID: 11089799 When using AVSpeechUtterance and setting it to play in Mandarin, if Siri is set to Cantonese on iOS 18, it will be played in Cantonese. There is no such issue on iOS 17 and 16. 1.let utterance = AVSpeechUtterance(string: textView.text) let voice = AVSpeechSynthesisVoice(language: "zh-CN") utterance.voice = voice 2.In the phone settings, Siri is set to Cantonese

Hi, I've encountered a strange behavior in the DNS Proxy Provider extension. Our app implements both DNS Proxy Provider and Content Filter Providers extensions, configured via MDM. When the app is uninstalled, the behavior of the providers differs: For Content Filter Providers (both Filter Control and Filter Data Providers), the providers stop as expected with the stop reason: /** @const NEProviderStopReasonProviderDisabled The provider was disabled. */ case providerDisabled = 5 However, for the DNS Proxy Provider, the provider remains in the "Running" state, even though there is no app available to match the provider's bundle ID in the uploaded configuration profile. When the app is reinstalled: The Content Filter Providers start as expected. The DNS Proxy Provider stops with the stop reason: /** @const NEProviderStopReasonAppUpdate The NEProvider is being updated */ @available(iOS 13.0, *) case appUpdate = 16 At this point, the DNS Proxy Provider remains in an 'Invalid' state. Reinstalling the app a second time seems to resolve the issue, with both the DNS Proxy Provider and Content Filter Providers starting as expected. This issue seems to occur only if some time has passed after the DNS Proxy Provider entered the 'Running' state. It appears as though the system retains a stale configuration for the DNS Proxy Provider, even after the app has been removed. Steps to reproduce: Install the app and configure both DNS Proxy Provider and Content Filter Providers using MDM. Uninstall the app. Content Filter Providers are stopped as expected (NEProviderStopReason.providerDisabled = 5). DNS Proxy Provider remains in the 'Running' state. Reinstall the app. Content Filter Providers start as expected. DNS Proxy Provider stops with NEProviderStopReason.appUpdate (16) and remains 'Invalid'. Reinstall the app again. DNS Proxy Provider now starts as expected. This behavior raises concerns about how the system manages the lifecycle of DNS Proxy Provider, because DNS Proxy Provider is matched with provider bundle id in .mobileconfig file. Has anyone else experienced this issue? Any suggestions on how to address or debug this behavior would be highly appreciated. Thank you!

I want to understand which component types are intended to have an associated hint text, haptic feedback, or earcon associated with it for VoiceOver screen reader users. Is there a list somewhere or a HIG guideline for which transition types should have a sound? Some transitions in Apple apps generally include different beep sounds, such as opening a new screen screen dimming when a VoiceOver user swipes from the header / navbar to the body a scraping sound when swiping up or down a page. the beginning or end of the body section in Calculator when swiping from one row to the next. opening a pop up menu I would also appreciate any direction on what code strings are associated with these sounds and how custom components can capture these sounds or haptics or hints where it is expected? On the other hand, I don't want to get that info and then dictate that every component needs a specific beep type since these sounds appear to be used for specific purposes.

Hello everyone, I'm experiencing an issue with my app, and I would greatly appreciate any guidance. Here's the situation: My app works flawlessly on the simulator for all iPhone models (16, 16 Pro, 16 Pro Max, SE, etc.). It runs without issues on physical iPhone 11 devices (both mine and a friend's). However, when my friend installs the app from the App Store on their iPhone 15 Pro or iPhone 16, it crashes immediately upon opening. Steps I’ve taken so far: Verified that the app works on the simulator for the same models where it crashes in real life. Updated the app's minimum deployment target to iOS 18, but this did not resolve the issue. The app still crashes on the physical iPhone 15 Pro and 16 models while continuing to run fine on previous physical devices and all simulated ones. Additionally, I had another friend beta test the app through TestFlight on their iPhone 15 Pro, and they received an alert message indicating that the app had crashed when they tried to open it. This confirms the issue still exists after my attempted fixes. I'm unsure what could be causing this discrepancy between the simulated and physical devices, or what the alert message in TestFlight might signify. Has anyone encountered a similar issue, or does anyone have suggestions on what I should do to fix this? Thanks in advance for your help!

I've been seeing a high number of BGTaskScheduler related crashes, all of them coming from iOS 18.4. I've encountered this myself once on launch upon installing my app, but haven't been able to reproduce it since, even after doing multiple relaunches and reinstalls. Crash report attached at the bottom of this post. I am not even able to symbolicate the reports despite having the archive on my MacBook: Does anyone know if this is an iOS 18.4 bug or am I doing something wrong when scheduling the task? Below is my code for scheduling the background task on the view that appears when my app launches: .onChange(of: scenePhase) { newPhase in if newPhase == .active { #if !os(macOS) let request = BGAppRefreshTaskRequest(identifier: "notifications") request.earliestBeginDate = Calendar.current.date(byAdding: .hour, value: 3, to: Date()) do { try BGTaskScheduler.shared.submit(request) Logger.notifications.log("Background task scheduled. Earliest begin date: \(request.earliestBeginDate?.description ?? "nil", privacy: .public)") } catch let error { // print("Scheduling Error \(error.localizedDescription)") Logger.notifications.error("Error scheduling background task: \(error.localizedDescription, privacy: .public)") } #endif ... } 2025-02-23_19-53-50.2294_+0000-876d2b8ec083447af883961da90398f00562f781.crash

I'm working on the control widget which should display the SF image on the UI, but I have found that it cannot be displayed stably. I have three ExampleControlWidget which is about the type egA egB and egC, it should all be showed but now they only show the text and placeholder. I'm aware of the images should be SF image and I can see them to show perfectly sometimes, but in other time it is just failed. This's really confused me, can anyone help me out? public enum ControlWidgetType: Sendable { case egA case egB case egC public var imageName: String { switch self { case .egA: return "egA" case .egB: return "egB" case .egC: return "egC" } } } struct ExampleControlWidget: ControlWidget { var body: some ControlWidgetConfiguration { AppIntentControlConfiguration( kind: kind, provider: Provider() ) { example in ControlWidgetToggle( example.name, isOn: example.state.isOn, action: ExampleControlWidgetIntent(id: example.id), valueLabel: { isOn in ExampleControlWidgetView( statusText: isOn ? Localization.on.text : Localization.off.text, bundle: bundle, widgetType: .egA //or .egB .egC ) .symbolEffect(.pulse) } ) .disabled(example.state.isDisabled) } .promptsForUserConfiguration() } } public struct ExampleControlWidgetView: View { private let statusText: String private let bundle: Bundle private var widgetType: ControlWidgetType = .egA public init(statusText: String, bundle: Bundle, widgetType: ControlWidgetType) { self.statusText = statusText self.bundle = bundle self.widgetType = widgetType } public var body: some View { Label( statusText, image: .init( name: widgetType.imageName, // the SF Symbol image id bundled in the Widget extension bundle: bundle ) ) } } This is the normal display: These are the display that do not show properly: The results has no rules at all, I have tried to completely uninstall the APP and reinstall but the result is same.

Our company is developing an MFi headset with a button that we would like to use for initiating PTT. We can detect the button press and initiate PTT successfully, even when the app is not in the foreground, using the ExternalAccessory framework. But I wonder if this is a coincidence, or a scenario that should reliably work with Push to Talk?