It's hard to believe, but when using the run argument "-com.apple.CoreData.ConcurrencyDebug 1", the app would crash consistently just because its name (PRODUCT_NAME variable in Xcode build settings) starts with "Music" or "Musik". Simply changing the target name prevents the crash. This issue started appearing only on iOS 14.0 To reproduce: Use Xcode 12.01 to create a new project -> iOS -> App. Use Core Data and Objective-c in the wizard settings. Enter an app name which is starting with "Music" or "Musik". For example "MusicTest". Place "-com.apple.CoreData.ConcurrencyDebug 1" in the scheme run arguments. Add a new entity to the data model named "TestEnt" Add the following code to the end of the AppDelegate.m file. (void)test {   //   // Set run argument in the scheme as follow:   // -com.apple.CoreData.ConcurrencyDebug 1   //   NSLog(@"TEST");   dispatch_async(dispatch_get_global_queue(QOS_CLASS_USER_INITIATED, 0), ^{     NSManagedObjectContext *managedObjectContext = [self managedObjectContext];     [managedObjectContext performBlockAndWait:^{       NSError *error = nil;       NSFetchRequest *request = [NSFetchRequest fetchRequestWithEntityName:@"TestEnt"];       NSArray *result = [managedObjectContext executeFetchRequest:request error:&error];       NSLog(@"result=%@", result);     }];   }); } (NSManagedObjectContext *)managedObjectContext {       // The old-fashion way to create a managed object conttext       NSString *documentsDir = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) lastObject];   NSString *storeFilePath = [[documentsDir stringByAppendingPathComponent:@"MusicTest"] stringByAppendingPathExtension:@"sqlite"];   NSURL *storeURL = [NSURL fileURLWithPath:storeFilePath];           NSURL *objectModelURL = [[NSBundle mainBundle] URLForResource:@"MusicTest"                           withExtension:@"momd"];   NSManagedObjectModel *objectModel = [[NSManagedObjectModel alloc] initWithContentsOfURL:objectModelURL];       NSPersistentStoreCoordinator *coordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:objectModel];       NSDictionary *options = @{NSMigratePersistentStoresAutomaticallyOption: @YES,                NSInferMappingModelAutomaticallyOption: @YES};   NSError *error = nil;   [coordinator addPersistentStoreWithType:NSSQLiteStoreType                configuration:nil                     URL:storeURL                   options:options                    error:&error];       NSManagedObjectContext *managedObjectContext = nil;   if (coordinator != nil) {     managedObjectContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];     managedObjectContext.persistentStoreCoordinator = coordinator;     managedObjectContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy;   }       return managedObjectContext; } Modify code on ViewController.m as follow: (void)viewDidLoad {   [super viewDidLoad];       [(AppDelegate *)UIApplication.sharedApplication.delegate test]; } Run project and view crash coming. Multithreading_Violation_AllThatIsLeftToUsIsHonor Select MusicTest project on the project navigator. Rename "MusicTest" appearing under "TARGETS" on the main window to "MyMusicTest" Run project again No crash this time. Did Anyone encounter this issue? Can someone from Apple kindly reply?

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

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?

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?

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?

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 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?

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)

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 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;

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.

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?

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