I want to create movie recommendation app with ability to instantly watch selected movie in Apple TV app. As it is possible to share link to content in Apple TV app I wonder can I use it in my own app? I mean legal issues at first.

I am using SwiftData to model my data. For that i created a model called OrganizationData that contains various relationships to other entities. My data set is quite large and i am having a big performance issue when fetching all OrganizationData entities. I started debugging and looking at the sql debug log i noticed that when fetching my entities i run into faults for all relationships even when not accessing them. Fetching my entities: let fetchDescriptor = FetchDescriptor<OrganizationData>() let context = MapperContext(dataManager: self) let organizations = (try modelContainer.mainContext.fetch(fetchDescriptor)) Doing this fetch, also fetches all relationships. Each in a single query, for every OrganizationData entity. CoreData: annotation: to-many relationship fault "relationship1" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 9 rows CoreData: annotation: to-many relationship fault "relationship2" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows CoreData: annotation: to-many relationship fault "relationship3" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows CoreData: annotation: to-many relationship fault "relationship4" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows CoreData: annotation: to-many relationship fault "relationship5" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows CoreData: annotation: to-many relationship fault "relationship6" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows CoreData: annotation: to-many relationship fault "relationship7" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 1 rows CoreData: annotation: to-many relationship fault "relationship8" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows CoreData: annotation: to-many relationship fault "relationship9" for objectID 0x8aa5249772916e00 <x-coredata://B891FCEB-DF16-4E11-98E6-0AFB5D171A81/OrganizationData/p3869> fulfilled from database. Got 0 rows The relationships are all defined the same @Relationship(deleteRule: .cascade, inverse: \EntityData1.organization) var relationship1: [EntityData1] = [] Am i missing something? As far as i understood relationships are lazy and should only be faulted when accessing the property. But doing the fetch as described above already causes a query to happen, making the fetch take very long when using a large data set.

App initiates a App group based UserDefaults within the willFinishLaunchingWithOptions method and the same reference are used throughout the app life cycle + (NSUserDefaults *)appGroupUserDefaults { if (_appGroupUserDefaults == nil) { NSString *appGroupIdentifier = [NSString stringWithFormat:@"group.%@",[[NSBundle mainBundle] bundleIdentifier]]; NSUserDefaults *groupDefaults = [[NSUserDefaults standardUserDefaults] initWithSuiteName:appGroupIdentifier]; if(groupDefaults != nil) { NSLog(@"[DB_ENCRYPTION] appGroupUserDefaults initialised"); _appGroupUserDefaults = groupDefaults; } else { NSLog(@"<ALA_ERROR>: [CCF-OS] [DB_ENCRYPTION] %s Unable to create NSUSerDefaults with groupIdentifier", __func__); _appGroupUserDefaults = [NSUserDefaults standardUserDefaults]; } } return _appGroupUserDefaults; } Doesn't have any issues on accessing the values but seen the below console error: Couldn't read values in CFPrefsPlistSource<0x103eedb00> (Domain: group.com.kodiak.InstaPoC, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd Does it require any action here ?

Hi, Upon reviewing our app, we got feedback that our app icon within the Wallet app is not behaving as expected when the home screen is set to "light mode" only. In that case, on the home screen, the app icon remains its default color (e.g., red), regardless of the device's appearance settings (light or dark), which is expected. However, in the apple Wallet, e.g., under the From Apps from your device, app icons change their color (e.g., red in light mode, black in dark mode) when iOS appearance is changed - which is reported as an app issue. I've noticed that all apps in that section are changing the color, not just ours, so it seems to me like a bug in iOS or a behavior that was not clearly defined in the app store guidelines. If there is an API we must use to cover that case, which one would that be? Is this a bug that Apple should resolve, or is this the intended behaviour?

Hi everyone We have brought the iOS development in-house from a consulting firm and have developed a new app that will replace the old one. To minimize disruption for users of the old app during this upgrade, we would like to release the new app as an update to the old one, using the Bundle ID from the old app. It is important to note that the old app has already been released through the App Store. The two apps share no code and are almost incompatible on any points. Is it possible to change the Bundle ID and delete UserDefaults from the old app during the transition to the new app? We look forward to your input!

I have an app which uses ubiquitous containers and files in them to share data between devices. It's a bit unusual in that it indexes files in directories the user grants access to, which may or may not exist on a second device - those files are identified by SHA-1 hash. So a second device scanning before iCloud data has fully sync'd can create duplicate references which lead to an unpleasant user experience. To solve this, I store a small binary index in the root of the ubiquitous file container of the shared data, containing all of the known hashes, and as the user proceeds through the onboarding process, a background thread is attempting to "prime" the ubiquitous container by calling FileManager.default.startDownloadingUbiquitousItemAt() for each expected folder and file in a sane order. This likely creates a situation not anticipated by the iOS/iCloud integration's design, as it means my app has a sort of precognition of files it should not yet know about. In the common case, it works, but there is a corner case where iCloud sync has just begun, and very, very little metadata is available (the common case, however, in an emulator), in which two issues come up: I/O may hang indefinitely, trying to read a file as it is arriving. This one I can work around by running the I/O in a thread created with the POSIX pthread_create and using pthread_cancel to kill it after a timeout. Attempts to call FileManager.default.startDownloadingUbiquitousItemAt() fails with an error Error Domain=NSCocoaErrorDomain Code=257 "The file couldn’t be opened because you don’t have permission to view it.". The permissions aspect of it is nonsense, but I can believe there's no applicable "sort of exists, sort of doesn't" error code to use and someone punted. The problem is that this same error will be thrown on any attempt to access that file for the life of the application - a restart is required to make it usable. Clearly, the error or the hallucinated permission failure is cached somewhere in the bowels of iOS's FileManager. I was hoping startAccessingSecurityScopedResource() would allow me to bypass such a cache, as it does with URL.resourceValues() returning stale file sizes and last modified times. But it does not. Is there some way to clear this state without popping up a UI with an Exit button (not exactly the desired iOS user experience)?

when in portrait, the UINavigationBar shows normal: when in landscape: The top is white and blank.

In this WWDC talk about liquid glass https://developer.apple.com/videos/play/wwdc2025/219/ they mention that there are two variants of liquid glass, regular and clear. I don't see any way to try the clear variant using the .glassEffect() APIs, they only expose regular, is there some other way to try the clear variant?

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: &lt;key&gt;com.apple.security.files.downloads.read-only&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.files.user-selected.read-only&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.app-sandbox&lt;/key&gt; &lt;true/&gt; 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).

We're seeing a sharp uptick in BaseBoard/FrontBoardServices crashes since we migrated from UIApplicationDelegate to UIWindowSceneDelegate. Having exhausted everything on my end short of reverse engineering BaseBoard or making changes without being able to know if they work, I need help. I think all I need to get unstuck is an answer to these questions, if possible: What does -[BSSettings initWithSettings:] enumerate over? If I know what's being enumerated, I'll know what to look for in our app. What triggers FrontBoardServices to do this update? If I can reproduce the crash--or at least better understand when it may happen--I will be better able to fix it Here's two similar stack traces: App_(iOS)-crashreport-07-30-2025_1040-0600-redacted.crash App_(iOS)-crashreport-07-30-2025_1045-0600-redacted.crash Since these are private trameworks, there is no documentation or information on their behavior that I can find. There are other forum posts regarding this crash, on here and on other sites. However, I did not find any that shed any insight on the cause or conditions of the crash. Additionally, this is on iPhone, not macOS, and not iPad. This post is different, because I'm asking specific questions that can be answered by someone with familiarity on how these internal frameworks work. I'm not asking for help debugging my application, though I'd gladly take any suggestions/tips! Here's the long version, in case anyone finds it useful: In our application, we have seen a sharp rise in crashes in BaseBoard and FrontBoardServices, which are internal iOS frameworks, since we migrated our app to use UIWindowSceneDelegate. We were using exclusively UIApplicationDelegate before. The stack traces haven't proven very useful yet, because we haven't been able to reproduce the crashes ourselves. Upon searching online, we have learned that Baseboard/Frontsoardservices are probably copying scene settings upon something in the scene changing. Based on our crash reports, we know that most of our users are on an iPhone, not an iPad or macOS, so we can rule out split screen or window resizing. Our app is locked to portrait as well, so we can also rule out orientation changes. And considering the stack trace is in the middle of an objc_retain_x2 call, which is itself inside of a collection enumeration, we are assuming that whatever is being enumerated probably was changed or deallocated during enumeration. Sometimes it's objc_retain_x2, and sometimes it's a release call. And sometimes it's a completely different stack trace, but still within BaseBoard/FrontBoardServices. I suspect these all share the same cause. Because it's thread 0 that crashed, we know that BaseBoard/FrontBoardServices were running on the main thread, which means that for this crash to occur, something might be changing on a background thread. This is what leads me to suspect a race condition. There are many places in our app where we accidentally update the UI from a background thread. We've fixed many of them, but I'm sure there are more. Our app is large. Because of this, I think background UI are the most likely cause. However, since I can't reproduce the crash, and because none of our stack traces clearly show UI updates happening on another thread at the same time, I am not certain. And here's the stack trace inline, in case the attachments expire or search engines can't read them: Thread 0 name: Thread 0 Crashed: objc_retain_x2 (libobjc.A.dylib) BSIntegerMapEnumerateWithBlock (BaseBoard) -[BSSettings initWithSettings:] (BaseBoard) -[BSKeyedSettings initWithSettings:] (BaseBoard) -[FBSSettings _settings:] (FrontBoardServices) -[FBSSettings _settings] (FrontBoardServices) -[FBSSettingsDiff applyToMutableSettings:] (FrontBoardServices) -[FBSSettingsDiff settingsByApplyingToMutableCopyOfSettings:] (FrontBoardServices) -[FBSSceneSettingsDiff settingsByApplyingToMutableCopyOfSettings:] (FrontBoardServices) -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 (FrontBoardServices) -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke.cold.1 (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke (FrontBoardServices) _dispatch_client_callout (libdispatch.dylib) _dispatch_block_invoke_direct (libdispatch.dylib) __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ (FrontBoardServices) -[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] (FrontBoardServices) -[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] (FrontBoardServices) __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (CoreFoundation) __CFRunLoopDoSource0 (CoreFoundation) __CFRunLoopDoSources0 (CoreFoundation) __CFRunLoopRun (CoreFoundation) CFRunLoopRunSpecific (CoreFoundation) GSEventRunModal (GraphicsServices) -[UIApplication _run] (UIKitCore) UIApplicationMain (UIKitCore) (null) (UIKitCore) main (AppDelegate.swift:0) 0x1ab8cbf08 + 0

I am trying to add a pinned(always visible and not moving) toolbar to the bottom of UISheetPresentationController or presentationDetent. This is achievable when the user is dragging to change the size of the sheet. But when changing the detent by code, it does not work. For example, when changing from medium to large, the ViewController's size is changed to large then moved up to the position. From the user's POV, anything at the bottom to disappear for a few frames then reappears. From my testing, when using UISheetPresentationController, ViewController only knows the medium and large state's frame and bounds, so manually setting it up won't work. Is there a way to keep views at the bottom always visible in this case? The sample code below is in SwiftUI for easy recreation, and the responses can be in UIKit. Sample Code: struct ContentView: View { @State var showSheet: Bool = true @State var detent: PresentationDetent = .medium var body: some View { EmptyView() .sheet(isPresented: $showSheet) { ScrollView { } .safeAreaInset(edge: .bottom) { Button { detent = (detent == .medium) ? .large : .medium } label: { Text("Change Size") } .buttonStyle(.borderedProminent) .presentationDetents([.medium, .large], selection: $detent) .presentationBackgroundInteraction(.enabled) } } } }

Hello Apple Developer Community, I am seeking clarification on the intended display behavior of HLS audio tracks within the iOS 26 (or current beta) native player, specifically concerning the NAME and LANGUAGE attributes of the EXT-X-MEDIA tag. In our HLS manifests, we define alternative audio tracks using EXT-X-MEDIA tags, like so: #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio",LANGUAGE="ja",NAME="AUDIO-1",DEFAULT=YES,AUTOSELECT=YES,URI="audio_ja.m3u8" #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio",LANGUAGE="ja",NAME="AUDIO-2",URI="audio_en.m3u8" Our observation is that when an audio track is selected and its name is displayed in the native iOS media controls (e.g., Control Center or within a full-screen video player's UI), the value specified in the NAME attribute ("AUDIO-1", "AUDIO-2") does not seem to be used. Instead, the display appears to derive from the LANGUAGE attribute ("ja", "en"), often showing the system's localized string for that language (e.g., "Japanese", "English"). We would like to understand the official or intended behavior regarding this. Is it the expected behavior for the iOS native player to prioritize the LANGUAGE attribute (or its localized equivalent) over the NAME attribute for displaying the selected audio track's label? If this is the intended design, what is the recommended best practice for developers who wish to present a custom, human-readable name for audio tracks (beyond the standard language name) in the native iOS UI? Are there any specific AVPlayer properties or AVMediaSelectionOption considerations that would allow more granular control over this display, or is this entirely managed by the system based on the LANGUAGE attribute? Any insights or official guidance on this behavior in iOS 26 (and potentially previous versions) would be greatly appreciated. Thank you for your time and assistance.

We are observing unexpected behavior in Apple Push Notification Service (APNS) delivery and would appreciate clarification and guidance. Below is a detailed breakdown of the scenario and related questions. Abbreviations: APNP – Apple Push Notification Provider APNS – Apple Push Notification Service Scenario: User1 is registered on iOS device1. Flight Mode is enabled on iOS device1. User2 initiates a call to User1 (Time t = 0 sec). User2 cancels the outgoing call after 5 seconds (Time t = 5 sec). Flight Mode is disabled on iOS device1 after 20 seconds (Time t = 25 sec). Observation: iOS device1 displays an incoming call notification (CallKit UI) after flight mode is turned off, despite the call being cancelled by User2. This notification disappears automatically after approximately 8–10 seconds. Logic Flow: At time t = 0, our APNP sends a VoIP push (priority) to APNS for the incoming call. Since device1 is in flight mode, APNS cannot deliver the push. At t = 25 sec, after flight mode is turned off, APNS delivers the cached VoIP push to device1. The app takes ~5 seconds to initialize (CSDK setup, SIP registration, etc.). It eventually receives a SIP NOTIFY with state="full" and empty dialog info (indicating no active call). Consequently, the CallKit incoming call is removed after ~8 seconds. Questions: → We set the apns-expiration header to 0, expecting that the VoIP push would not be delivered if the device was unreachable when the push was sent. However, APNS still delivers the push 20–30 seconds later, once the device is back online. Q. Why is the apns-expiration header not respected in this case? → Upon receiving the VoIP push, we require ~10–12 seconds to determine if a visible CallKit notification is still relevant (e.g., by completing SIP registration and checking for active dialogs). Q. Is it acceptable, per Apple guidelines, to intentionally delay showing the CallKit UI (incoming call) for 10–15 seconds after receiving the VoIP push? → Apple documentation states that the priority VoIP push channel should be used only for notifying incoming calls, while regular (non-VoIP) pushes should be used for other updates, including call cancellations. Q. What is the rationale behind discouraging the use of the priority VoIP push channel for call cancellation events? In some cases, immediate cancellation notification is as critical as the initial incoming call. Would Apple consider it acceptable to occasionally use the priority VoIP channel for rare call-cancellation scenarios without risking throttling or suspension? → In our implementation, we send an incoming call notification via the priority VoIP channel. Shortly after, we send a call cancellation notification on the regular push channel, marked with "content-available": 1. We expect this regular push to wake the app (triggering application:didReceiveRemoteNotification:fetchCompletionHandler:), but in practice the app never wakes, and our debug logs inside that delegate method never appear. Q. Under what exact conditions does a "content-available": 1 regular push fail to wake the app when it follows a VoIP push? Are there additional requirements (e.g., background modes, rate limits, power optimizations) that could prevent the delegate from being called? → According to Apple documentation: “APNs stores only one notification per bundle ID. When multiple notifications are sent to the same device for the same bundle ID, APNs keeps only the latest one.” However, in our tests: If a device is offline when APNs receives both: (a) a priority VoIP push for an incoming call, (b) a regular push for call cancellation (same bundle ID), Upon the device reconnecting, APNs still delivers the earlier VoIP push, instead of discarding it and delivering only the most recent (cancellation) notification. Q. Why doesn’t APNs replace the queued VoIP push with the newer regular push when both share the same bundle ID? Is this expected behavior due to channel type differences (VoIP vs. regular), or is there a way to ensure that the latest notification (even if regular) supersedes the earlier VoIP push? We’d appreciate your input or recommendations on handling such delayed pushes and any best practices for VoIP push expiration handling and call UI timing.

I'm running into a persistent problem with the iOS 18.5 simulator in Xcode 26 beta 2. I have built a very simple test app with a storyboard that includes only a toolbar added to the ViewController scene in the storyboard. The test app runs fine in iOS 26 simulators.When I try to run it in the iOS 18.5 simulator for iPhone Pro or iPad (16), it fails while unarchiving the storyboard (as far as I can tell) with this error message in the Xcode console: *** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView because no class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target)' terminating due to uncaught exception of type NSException CoreSimulator 1043 - Device: iPad (A16) (3E70E25F-8434-4541-960D-1B58EB4037F3) - Runtime: iOS 18.5 (22F77) - DeviceType: iPad (A16) I'd love a simple workaround for this.

Because .searchable does not allow for customizing buttons in the search bar, I've manually had to recreate the search bar as shown below. However, when removing one of the items in the search bar, the TextField does not resize correctly and effectively inserts padding on the leading edge. When the TextField is focused, it resizes and fills the entire space. If the "Compose" button was already hidden when the search bar is presented, it lays out correctly. How do I resize the TextField after removing the "Compose" button automatically? Thanks, jjp struct ContentView: View { @State var isSearchBarVisible = false @State var isComposingMessage = false @State var searchText = "" let items: [String] = ["hey", "there", "how", "are", "you"] var searchItems: [String] { items.filter { item in item.lowercased().contains(searchText.lowercased()) } } var body: some View { NavigationStack { VStack { List { if !searchText.isEmpty { ForEach(searchItems, id: \.self) { item in Text(item) } } else { ForEach(items, id: \.self) { item in Text(item) } } } } .toolbar { if isSearchBarVisible { ToolbarItem(placement: .principal) { TextField("Search", text: $searchText) .padding(8) .background(Color.gray.opacity(0.2)) } ToolbarItem(placement: .topBarTrailing) { Button(action: { isSearchBarVisible = false },[![enter image description here][1]][1] label: { Text("Cancel") }) } if !isComposingMessage { ToolbarItem(placement: .topBarTrailing) { Button(action: { isComposingMessage.toggle() }, label: { Text("Compose") }) } } } else { ToolbarItem(placement: .topBarLeading) { Button(action: { isSearchBarVisible = true }, label: { Text("Search") }) } ToolbarItem(placement: .principal) { Text("Title") } ToolbarItem(placement: .topBarTrailing) { Button(action: { isComposingMessage.toggle() }, label: { Text("Compose") }) } } } } } }

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 have an iPhone 13 Pro Max running iOS 26.0 (beta). After installing the update, I get a message stating that I need to update my Apple account settings. When I log in, it freezes and nothing can be done. I also can't access the login and security settings, as it also freezes and won't progress. Also, the option to install beta versions has disappeared. I don't know why? Could it be that since I have the latest beta, the option disappears until a new update? Please help!

We are currently developing an enterprise iOS application and are in the process of implementing Data Leakage Protection (DLP) features. As part of this effort, we need to control the available actions and target applications presented within the UIActivityViewController. Specifically, we would like to programmatically filter or restrict certain activities and destination apps shown in the share sheet based on user-specific permissions. These permissions will be dynamically evaluated and updated at runtime. This type of functionality is supported by the Microsoft Intune SDK. However, our objective is to implement this behavior natively within our application without relying on any third-party libraries. Could you please advise on the recommended approach or available APIs to achieve this level of control over the UIActivityViewController?

1.App build using xCode 26 beta 4 crashing on run time on iOS device with iOS < 26.0 but works fine on iOS 26 beta devices. 2. Works fine if build using xCode 16.2 Runtime Crash Dump 
dyld[67519]: Symbol not found: _NSUserActivityTypeBrowsingWeb Referenced from: /private/var/containers/Bundle/Application/2D4B24D6-CEA5-4682-B549-9CCB6A56BAB9/Foreground Camera.app/Foreground Camera.debug.dylib Expected in: <050203DD-7488-307D-A999-E587314B041A> /System/Library/Frameworks/CoreServices.framework/CoreServices Symbol not found: _NSUserActivityTypeBrowsingWeb Referenced from: /private/var/containers/Bundle/Application/2D4B24D6-CEA5-4682-B549-9CCB6A56BAB9/Foreground Camera.app/Foreground Camera.debug.dylib Expected in: <050203DD-7488-307D-A999-E587314B041A> /System/Library/Frameworks/CoreServices.framework/CoreServices dyld config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/usr/lib/libLogRedirect.dylib:/usr/lib/libBacktraceRecording.dylib:/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/usr/lib/libViewDebuggerSupport.dylib:/System/Library/PrivateFrameworks/GPUToolsCapture.framework/GPUToolsCapture Symbol not found: _NSUserActivityTypeBrowsingWeb Referenced from: /private/var/containers/Bundle/Application/2D4B24D6-CEA5-4682-B549-9CCB6A56BAB9/Foreground Camera.app/Foreground Camera.debug.dylib Expected in: <050203DD-7488-307D-A999-E587314B041A> /System/Library/Frameworks/CoreServices.framework/CoreServices dyld config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/usr/lib/libLogRedirect.dylib:/usr/lib/libBacktraceRecording.dylib:/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/usr/lib/libViewDebuggerSupport.dylib:/System/Library/PrivateFrameworks/GPUToolsCapture.framework/GPUToolsCapture

Hi all, I am hope someone could assist me with the below error if you ever ran into this during Tap-to-Pay functionality integration on iOS/iPadOS devices. Pre-condition: I have received required entitlements for the Tap-to-Pay integration and created Sandbox test account to validate my development work. Used updated development profile with the new capabilities required for the Integration. When i try to test my flow, i keep receiving this error, with multiple sandbox accounts in developer portal. Error (refreshContext): proxy error handler [ Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.merchantd.transaction was invalidated: failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.merchantd.transaction was invalidated: failed at lookup with error 159 - Sandbox restriction.} ] I greatly appreciate if anyone faced this issue or any knowledge on how to address this error. Thanks in advance. Best regards, Govardhan.