I have an iOS app with the following configuration: My own ObjC static library project - MyStaticLib My own ObjC app target project - MyApp I have both projects in the same Xcode workspace so that MyStaticLib is linked successfully to MyApp Both projects have a mix of ObjC and Swift code successfully working. Currently: MyStaticLib: ObjC code can access Swift code and vice versa MyApp: ObjC code can access Swift code and vice versa ObjC code from MyApp can access ObjC code from MyStaticLib (This is achieved by adding Copy Files in Build Phases at MyStaticLib project settings with the ObjC header files) Objective: Swift code located in MyApp to access Swift code located in MyStaticLib Issues: If I'm trying to call a public Swift function located in MyStaticLib from MyApp, I get Cannot find 'YYY' in scope. If I'm adding import MyStaticLib, I get dozens of Duplicate interface definition for class 'ZZZ' Any idea how to resolve this?

Seems like a bug on the Xcode 15.0 beta. Steps to reproduce: Create a new empty Static Library project in Xcode (objective-C) Add a String Catalog file Add a dummy function which includes NSString *str = NSLocalizeString(@"test string", @"comment"); Build the project. Result: String Catalog is empty while it should be updated with "test string". I submitted FB12408229 Anyone encountered this? Anyone from Apple can kindly confirm?

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?

I recently added Swift to my existing objective-c static library project and encountering issues when debugging Swift code. While in a breakpoint and entering po command to print a variable value I get: error: expression failed to parse: error: Couldn't realize type of self Note the following: The project is an objective-c static library with recently added Swift files. The error appears only when breakpoint is in a Swift file. There is no issues while debugging objective-c file (*.m file). Xcode version is 14.1 Project is using CocoaPods. There are no issues with compilation and runtime. The only issue is with debugging Swift code. When running swift-healthcheck from breakpoint, there are plenty of errors as follow: LoadOneModule() -- Missing Swift module or Clang module found for "Infra", "imported" via SwiftDWARFImporterDelegate. Hint: Register Swift modules with the linker using -add_ast_path. While Infra is the name of my static library. (I couldn't find any helpful instructions explaining how to register swift modules, while I'm not even sure it points to the actual issue). Any suggestions will be highly appreciated.

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

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?

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.

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;

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?

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)

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).

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?

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?

Here is my use case: I need to export a large core data store into some format (e.g., CSV, JSON) which requires fetching all objects of the main entity, and then iterating each object and serializing it to the desired format. Here is my code: NSError *error = nil; NSFetchRequest *request = [NSFetchRequest fetchRequestWithEntityName:@"MyEntity"]; NSArray<NSManagedObject *> *allItems = [managedObjectContext executeFetchRequest:request error:&error]; for (NSManagedObject *item in allItems) { &#9;&#9;[self exportItem:item]; } Since the for-loop code is running synchronously and in a single thread, it might take a long time to complete. This is especially true when dealing with a large database containing thousands of records. I wonder if there is a way to iterate the array concurrently, in a way that will take full advantage of the multiple cores available on the iOS device (rather than using only a single core). This would probably boost the performance significantly. I was thinking in the direction of using the following code to replace the for-loop code above: [allItems enumerateObjectsWithOptions:NSEnumerationConcurrent usingBlock:^(NSManagedObject* item) { &#9;&#9;[self exportItem:item]; } However, this would obviously crash the app due to violating core data concurrency rules... Any ideas how to target this use case?