Xcode 14 Beta 5 shows this exception: [<_UINavigationBarContentViewLayout valueForUndefinedKey:]: this class is not key value coding-compliant for the key inlineTitleView. I am getting this new exception in all my obj-c projects while using Xcode 14 Beta 5. A few notes: Exception appears on any simulator device (running iOS 16) Exception appears right on the start inside int main(int argc, char * argv[]) No exception on real device running iOS 15 Exception can be ignored (no crash). I wonder if anyone else encountered this.

Very strange issue. It seems that a specific project of mine causes Xcode to crash while idle due to resources issue. Not sure if related, but when viewing source code differences of this project, the entire window is flickering like crazy... crash file is attached (converted to txt file otherwise can't attach it) Any ideas? ExcResource_Xcode-2022-10-07-115919.diag.txt

My iOS app (paid app) is currently localized to ten different languages. However, some of the languages are not justifying the required ongoing efforts to support them. I therefore wish to remove a specific language, but I wonder if there are any basic rules or limitations about removing a language from an app. For example, am I required announcing the removal in some place (e.g. App Store or my website), for a predefined time period (e.g. one year ahead of removal) I can easily envision a case where a user who just purchased the app with support for her native language, have the app suddenly appear in English on the next update from the App Store. And that after paying nicely for the app and putting the efforts to build its database. That would obviously frustrate the user. Any thoughts about how to deal with this?

I mistakenly marked an answer as "solved" while it actually not solved yet. The question is at https://developer.apple.com/forums/thread/662602 I noticed that I can't remove the "solved" badge. Is there a forum administrator that can do that for me? I don't wish to resubmit the question just in order to get rid of the "solved" badge and loose all responses.

I have a UICollectionViewController while doing the following: Return a string array in collectionView:indexPathForIndexTitle:atIndex: Set cell.contentView.backgroundColor = [UIColor redColor] on collectionView:cellForItemAtIndexPath: Notice that changing the background color of the cell is just for demonstrating the issue. The important thing is to show index titles on the right. The result (as following displayed) is that the content view takes the entire collection view width and it doesn't being affected (as it should) by the appearance of the index titles. With UITableViewController I am doing similar steps: Return a string array in sectionIndexTitlesForTableView: Set cell.contentView.backgroundColor = [UIColor redColor] on tableView:cellForRowAtIndexPath: Here, in contrast to the collection view behavior, the content view is "shrinking" as expected as following appear: Can anyone tell if this is a bug or the expected behavior?

The scenario is: Configure UITableViewCell using custom content configuration. Call self.isAccessibilityElement = YES in the custom content view. On iOS 16.0, the accessibilityLabel won't be called by VoiceOver for the configured cell. Note the following: On iOS 15.x, accessibility works as expected with both UICollectionViewCell and UITableViewCell. Starting from iOS 16.0, accessibility is no longer working with UITableViewCell (while it keeps working with UICollectionViewCell). Anyone encountered similar issue?

I am currently testing IAP of auto-renewable subscription with Sandbox account. Purchase auto-renewable subscription Purchase the subscription again during the period of validity. SKPaymentTransactionStatePurchasing arrives Popup appears "You are currently subscribed" with "Manage" and "OK" buttons. So far this is common to iOS 13 and 14. However, when tapping the "OK" button, the flow continues with a different behavior as follow: iOS 13: Purchase fails as SKPaymentTransactionStateFailed arrives with SKErrorPaymentCancelled iOS 14: Purchase succeeds as SKPaymentTransactionStatePurchased arrives This new behavior affects the code that I am writing so I need to confirm that this behavior was actually changed by design on iOS 14 and it's the expected one. I found no documentation for such change, so any reference would be greatly appreciated. It also would be interesting to know if anyone else detected this behavior and whether this behavior appears in production environment or only in test environment.

I'm facing an issue where the header in a collection view is hiding part of the cell when an index title is selected. It's important to indicate that the headers on the collection view are sticky. For example, when "0" is selected, the following appears: While I expect the following: Notice that on the first screenshot the "0" section header is hiding the first line of the cell (which is "---- Cell Title ----"). I uploaded a sample app to Github that clearly demonstrates this issue. See https://github.com/yoasha/CollectionViewDemo To reproduce, run the project with any iPhone simulator, select the "Collection View" option on the main page, and then tap the "0" or "1" index title. For comparison with table view behavior, the sample app allows to select "Table View" on the main page. After that, selecting any index title will show a proper behavior of the table view in contrast to the collection view. Any suggestions on how to fix this? Following is the entire implementation of my collection view, which is also available on the above Github link. @implementation MyCollectionViewController static NSString * const reuseIdentifier = @"Cell"; - (void)viewDidLoad { [super viewDidLoad]; UICollectionLayoutListConfiguration *config = [[UICollectionLayoutListConfiguration alloc] initWithAppearance:UICollectionLayoutListAppearancePlain]; config.headerMode = UICollectionLayoutListHeaderModeSupplementary; self.collectionView.collectionViewLayout = [UICollectionViewCompositionalLayout layoutWithListConfiguration:config]; // Register cell classes [self.collectionView registerClass:[UICollectionViewListCell class] forCellWithReuseIdentifier:reuseIdentifier]; [self.collectionView registerClass:[MyCollectionReusableViewHeader class] forSupplementaryViewOfKind:UICollectionElementKindSectionHeader withReuseIdentifier:@"header"]; } #pragma mark <UICollectionViewDataSource> - (NSInteger)numberOfSectionsInCollectionView:(UICollectionView *)collectionView { return self.dataModel.count; } - (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section { return self.dataModel.count; } - (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath { UICollectionViewCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:reuseIdentifier forIndexPath:indexPath]; UIListContentConfiguration *config = [((UICollectionViewListCell *)cell) defaultContentConfiguration]; config.text = @"----- Cell Title -----\nsome info\nsome info\nsome info"; cell.contentConfiguration = config; return cell; } - (UICollectionReusableView *)collectionView:(UICollectionView *)collectionView viewForSupplementaryElementOfKind:(NSString *)kind atIndexPath:(NSIndexPath *)indexPath { if ([kind isEqualToString:UICollectionElementKindSectionHeader]) { MyCollectionReusableViewHeader *header = [self.collectionView dequeueReusableSupplementaryViewOfKind:UICollectionElementKindSectionHeader withReuseIdentifier:@"header" forIndexPath:indexPath]; header.text = self.dataModel[indexPath.section]; return header; } return nil; } - (NSArray<NSString *> *)indexTitlesForCollectionView:(UICollectionView *)collectionView { return self.dataModel; } - (NSIndexPath *)collectionView:(UICollectionView *)collectionView indexPathForIndexTitle:(NSString *)title atIndex:(NSInteger)index { return [NSIndexPath indexPathWithIndex:index]; } @end self.dataModel is NSArray<NSString *> * assigned with @[@"0", @"1", @"2", @"3", @"4"] I also found a report of this issue at UICollectionView: https://stackoverflow.com/questions/70385294/uicollectionview-how-can-you-make-the-index-fast-scroll-to-the-section-header-i

I have an auto renewable subscription where: subscription billed monthly subscription has free trial of 14 days What would be the subscription expiry date after it was first purchased? Would it be 14 days or a month?

Scrolling a collection view with a large number of supplementary header views is extremely slow. The more sections, the worst is the scrolling performance. (Tested with 5,000 sections). Best to give it a try and see for yourself. Code is available at https://github.com/yoasha/CollectionViewTest To reproduce, run the demo app with Xcode on either iPhone or iPad simulator (or a real device), select "Collection View" on the main page, and try to scroll. Any thoughts?

Starting on iPadOS 16.4 I noticed a new and unexpected behavior on iPad. Configuration: Tested on both iPad simulator and iPad real device with iPadOS 16.4 The app's window root view controller is set to UISplitViewController The UISplitViewController delegate is being used to detect when it collapses and expands. Scenario: Run the app Exit the app - applicationDidEnterBackground is fired splitViewController:collapseSecondaryViewController:ontoPrimaryViewController: is fired. Printing the traitsCollection of the main app's window shows that horizontalSizeClass is now Compact. (It was Regular before app was closed) Immediately after that, splitViewController:separateSecondaryViewControllerFromPrimaryViewController: is fired. Printing the traitsCollection of the main app's window shows that horizontalSizeClass is Regular. On both steps #3 and #4, the stack trace shows that a snapshot is being executed. Before iPadOS16.4, exiting the app didn't trigger the collapse/expand delegate methods. It worth indicating that the horizontalSizeClass is eventually restored to the original value (of Regular) after step #4, so in most cases, this behavior shouldn't cause any issues. However, this "dancing" behavior where the horizontalSizeClass changes from regular to compact and back to regular, has some side effects in my use case. I am not sure if this behavior is intended and by design, or its a bug. Does anyone familiar with this?

Hi all, Sharing a reproducible UIKit issue I’m seeing across multiple iPadOS 26 betas, with a tiny sample attached and a short video. Short video https://youtu.be/QekYNnHsfYk Tiny project https://github.com/yoasha/ListSwipeOvershootReproSwift Summary In a UISplitViewController (.doubleColumn), a UICollectionView using list layout shows a large leading-swipe overshoot when the split view is expanded (isCollapsed == false). The cell content translates roughly 3–4× the action width. Repros with appearance = .plain and .grouped Does not repro with .insetGrouped Independent of trailing provider (issue persists when trailing provider is nil) Collapsed split (compact width) behaves correctly Environment Devices: iPad Air (3rd gen), iPadOS 26.0 (23A5326a) → Repro Simulators: iPad Pro 11-inch (M4), iPadOS 26.0 beta 6 → Repro Also tested on device: iPadOS 26 beta 5, 6, 7, 8 Xcode: 26.0 beta 6 (17A5305f) Steps to reproduce Launch the sample; ensure the split is expanded (isCollapsed == false). In the secondary list, set Appearance = Plain (also repros with Grouped). Perform a leading swipe (LTR: swipe right) on any row. Actual: content shifts ~3–4× the action width (overshoot). Expected: content translates exactly the action width. Switch Appearance = InsetGrouped and repeat the leading (swipe right) gesture → correct (no overshoot). Feedback Assistant FB ID: FB19785883 (full report + attachments filed; this forum thread mirrors the repro for wider visibility) Minimal code (core of the sample) If anyone from Apple needs additional traces or a sysdiagnose, I can attach promptly. Thanks! // Secondary column VC (snippet) var cfg = UICollectionLayoutListConfiguration(appearance: .plain) // also .grouped / .insetGrouped cfg.showsSeparators = true cfg.headerMode = .none cfg.leadingSwipeActionsConfigurationProvider = { _ in let read = UIContextualAction(style: .normal, title: "Read") { _,_,done in done(true) } read.backgroundColor = .systemBlue let s = UISwipeActionsConfiguration(actions: [read]) s.performsFirstActionWithFullSwipe = false return s } // Trailing provider can be nil and the bug still repros for leading swipe: cfg.trailingSwipeActionsConfigurationProvider = nil let layout = UICollectionViewCompositionalLayout.list(using: cfg) let collectionView = UICollectionView(frame: view.bounds, collectionViewLayout: layout) // … standard data source with UICollectionViewListCell + UIListContentConfiguration // Split setup (snippet) let split = UISplitViewController(style: .doubleColumn) split.preferredDisplayMode = .oneBesideSecondary split.viewControllers = [ UINavigationController(rootViewController: PrimaryTableViewController()), UINavigationController(rootViewController: SecondaryListViewController()) ]

So here is my setup: UICollectionView configured with UICollectionLayoutListConfiguration appearance is UICollectionLayoutListAppearancePlain headerMode is UICollectionLayoutListHeaderModeSupplementary Using UICollectionViewListCell with content configuration Implementing collectionView:viewForSupplementaryElementOfKind:atIndexPath: to return custom section header Implementing indexTitlesForCollectionView: to return index titles representing the sections (e.g. "A", "B", "C") Implementing collectionView:indexPathForIndexTitle:atIndex: to return the index path of the first cell in given section. Now, when user taps on any index title, the collection view scrolls and positions the first cell of that section at the top. However, the header section (which is sticky) is now overlapping part of the cell. Any suggestion on how to fix this? I guess that a new delegate method, such as collectionView:supplementaryElementIndexPathForIndexTitle:atIndex: would probably target this use case (as the collection view would scroll to a section header rather than to a cell).

When there is a large number of supplementary views, scrolling is extremely slow. To reproduce: Download Apple's demo of "Implementing Modern Collection Views" from here Open project in Xcode and show PinnedSectionHeaderFooterViewController.swift Go to line 106 and replace it with let sections = Array(0..<3000) Run project, navigate to "Pinned Section Headers" page, and try scrolling. Scrolling is barely possible and extremely slow! While profiling with Time instrument, issue seems to rely in invalidating supplementary views. Screenshot attached below. How can I fix this? (I have many section headers in my view)

When scrolling a collection view, it looks like all supplementary views (even those that currently not appear) are invalidated. If there is a large number of supplementary views (section headers in my case) this significantly affects scrolling performance. Can I instruct the collection view to invalidate only the visible supplementary header views (rather than all of them) when user scrolls the view? Here is the code I use to create the collection view (tableview-like layout) in my custom UICollectionViewController class: // Create list layout configuration UICollectionLayoutListConfiguration *config = [[UICollectionLayoutListConfiguration alloc] initWithAppearance:UICollectionLayoutListAppearancePlain]; config.headerMode = UICollectionLayoutListHeaderModeSupplementary; // Create compositional layout based on configuration and assign to collection view UICollectionViewCompositionalLayout *layout = [UICollectionViewCompositionalLayout layoutWithListConfiguration:config]; self.collectionView.collectionViewLayout = layout;