Is there a way to get all instances of ManagedSettingsStore that my app has previously configured? I managed to get into a situation, where I removed the identifier in my database, but forgot to clear the store and now the app is shielding couple of apps and I am unable to stop it. What is the proper workflow for this?

Hello, with new App Store Connect API I wanted to prototype a couple of ideas, but when I wanted to get a API key, this dialog made me question the validity: So this sounds like we are not supposed to create apps or web apps that would help other developers with App Store Connect tasks? For example if I wanted to create a web app that lets people manage their TestFlight, that is against the rules? Because it would presumably involve them getting an API key which my web app would use to talk to ASC API? On the other hand there are services like RevenueCat, Bitrise and similar, that presumably "access ASC on behalf of their users"? I would really appreciate if someone can explain this to me.

Hello, I am not quite sure, how the shielding of entire categories of apps is supposed to work. The FamilyActivitySelection contains tokens for apps, websites and categories. But the shield property of ManagedSettingsStore has only attributes applications and webDomains where I can configure the tokens from the family activity selection. shield.applications = selection.applicationTokens shield.webDomains = selection.webDomainTokens I would expect there to be the property categories that expects Set<ActivityCategoryToken> and based on this shields apps in that category.

Hello, with iOS 16 (multiple betas), I noticed that our VPN configuration created with NEPacketTunnelProvider appears twice in Settings -> General -> VPN & Device Management. I thought that this shouldn't be possible (even if I wanted to) because on iOS apps can provide just one configuration? All the basic configuration for your VPN is static. providerBundleIdentifier & serverAddress are contants in the source code. The only thing that gets changed is onDemandRules. When I inspected the configurations details in Settings, they were identical.

Hello, I have added new non-consumable in-app to my existing app. Initially I messed up and sent it to review by itself (since in-apps and regular submissions seem to be handled by different teams). It got rejected and the review notes said that the review couldn't be done, because they couldn't test it in the app. Makes sense. So I submitted new build to app review and then submitted the in-app again. Same rejection reason. The build got approved, the in-app got rejected. After my newest build was approved. I added note in the review notes that the in-app is available in approved build. But after almost 48 hours "In Review" I got another rejection: We have returned your in-app purchase products to you as the required binary was not submitted. When you are ready to submit the binary, please resubmit the in-app purchase products with the binary. I have no idea how to submit "in-app purchase products with the binary". When preparing new version for review, there isn't any option to add the in-app as a single submission. Please help :/

Hello, is this just me or does it seem lately that apps spend quite long time in "In Review" state? One of my work app has been "In Review" since April 20th, which is already 9 days. I have recently submitted minor update for my hobby app and it has been "In Review" for over 24 hours - while in the past it took just a couple of hours or even less to be approved. I understand that "Waiting for Review" can take time if there is long queue of apps but "In Review" this long? Surely the reviewer is not testing my app for 24 hours straight? Did they forget? Are they waiting for someone else to take a look? It just seems quite strange.

Hello, I am building contact form that allows to attach screenshots and screen recordings. The PhotosPicker part is relatively straightforward but I am not sure how to properly import the selected items. The binding is of type [PhotosPickerItem] which requires (at least for my current implementation) to first know if the item is image or video. I have this not so pretty code to detect if the item is video: let isVideo = item.supportedContentTypes.first(where: { $0.conforms(to: .video) }) != nil || item.supportedContentTypes.contains(.mpeg4Movie) Which for screen recordings seems to work only because I ask about .mpeg4Movie and then I have this struct: struct ScreenRecording: Transferable { let url: URL static var transferRepresentation: some TransferRepresentation { FileRepresentation(contentType: .mpeg4Movie) { video in SentTransferredFile(video.url) } importing: { received in let copy = URL.temporaryDirectory.appending(path: "\(UUID().uuidString).mp4") try FileManager.default.copyItem(at: received.file, to: copy) return Self.init(url: copy) } } } Notice here I have just the .mpeg4Movie content type, I couldn't get it to work with more generic ones like movie and I am afraid this implementation could soon break if the screen recordings change video format/codec. And finally my logic to load the item: if isVideo { if let movie = try? await item.loadTransferable(type: ScreenRecording.self) { viewModel.addVideoAttachment(movie) } } else { if let data = try? await item.loadTransferable(type: Data.self) { if let uiImage = UIImage(data: data) { viewModel.addScreenshotAttachment(uiImage) } } } I would like to make this more "future proof" and less error prone - particularly the screen recordings part. I don't even need the UIImage since I am saving the attachments as files, I just need to know if the attachment is screenshot or video and get its URL. Thanks!

Hello, I am curious if someone else also noticed this. We have started getting reports about our app not working correctly (mostly related to the Device Activity monitor that "runs" in the background, https://developer.apple.com/documentation/deviceactivity/deviceactivitymonitor). Upon checking the Xcode Organizer I can see somewhat significant amount of crashes that mostly appear to happen on iOS 16.6 - it is possible that our users don't wait with updating iOS but still looks suspicious. The crashes are related to ManagedSettings calls outside our own code. We haven't changes this code in a while so this coupled with the fact that these crashes happen "deep" in the ManagedSettings framework leads me to believe there is some other issue.

Please delete this, I made wrong conclussions. The issue wasn't with UISearchController as it is happening on other screens also where I dont even use the seach.

Hello, I have the following subclass of UICompositionalCollectionViewLayout to get the stretchy header effect as shown below. It works quite well, but I don't really have an experience with creating custom layouts so I thought I'd ask if maybe my implementation doesn't have some important flaws. I once ran into persistent layout loop crash with this and I am not sure what exactly I changed but it stopped happening. However since I am using this layout on important screen, I would like to make sure there isn't obvious potential for the layout loop crash happening in App Store version. I am particularly unsure about the shouldInvalidateLayout implementation. Originally I was returning true all the time, but decided to change it and only force invalidation for negative content offset which is when my header is supposed to stretch. Here is the full code: final class StretchyCompositionalLayout: UICollectionViewCompositionalLayout { override func layoutAttributesForElements(in rect: CGRect) -> [UICollectionViewLayoutAttributes]? { var attrs = super.layoutAttributesForElements(in: rect) ?? [] guard let collectionView = collectionView else { return attrs } let contentOffset = collectionView.contentOffset.y guard contentOffset < 0 else { return attrs } var newAttributes: UICollectionViewLayoutAttributes? attrs.forEach({ attribute in if attribute.indexPath.section == 0 && attribute.indexPath.item == 0 { let startFrame = attribute.frame newAttributes = attribute.copy() as? UICollectionViewLayoutAttributes let newFrame: CGRect = .init(x: 0, y: contentOffset, width: startFrame.width, height: startFrame.height - contentOffset) newAttributes?.frame = newFrame } }) if let new = newAttributes { attrs.removeAll { attr in return attr.indexPath.section == 0 && attr.indexPath.item == 0 } attrs.insert(new, at: 0) } return attrs } override func layoutAttributesForItem(at indexPath: IndexPath) -> UICollectionViewLayoutAttributes? { guard let attributes = super.layoutAttributesForItem(at: indexPath) else { return nil } let contentOffset = collectionView?.contentOffset.y ?? 1 guard contentOffset < 0 else { return attributes } if indexPath.section == 0 && indexPath.item == 0 { let attributes = attributes.copy() as? UICollectionViewLayoutAttributes ?? attributes let startFrame = attributes.frame let newFrame: CGRect = .init(x: 0, y: contentOffset, width: startFrame.width, height: startFrame.height - contentOffset) attributes.frame = newFrame return attributes } else { return super.layoutAttributesForItem(at: indexPath) } } override func shouldInvalidateLayout(forBoundsChange newBounds: CGRect) -> Bool { let contentOffset = collectionView?.contentOffset.y ?? 1 // There is visual glitch when 0 is used in this condition if contentOffset < 1 { return true } else { return super.shouldInvalidateLayout(forBoundsChange: newBounds) } } } Any feedback welcome!

Hello, my app sometimes has this super weird issue with scroll in a horizontal section (see the GIF below). The thing is, I have ever spotted it only in this third section and not the two sections above it. All have the same compositional collection view layout and are powered by the diffable data source. I reexamined the item definition and I don't think this could be a case of hash values being same and hence confusing the collection view. It also seems to happen only to these first items. It is not frequent but on my own device I have seen it many times so far. The problem always seems to manifest in similar manner. Anyone seen this? I am hoping that maybe someone will recognize the problem from the GIF.

Hello, I have collection view with context menu using contextMenuConfigurationForItemAt and I wanted to customize the preview, when user long presses and context menu is shown. Something maybe like in the Music app when you long press on an album it shows the album in bigger size... I found some snippets online for highlightPreviewForItemAt and dismissalPreviewForItemAt but it just doesn't work. As soon as a implemented these delegate methods, nothing happens when I long press, not even the standard preview with context menu. These two methods aren't being called at all. Do I need to do something else? Do I need the previewProvider when creating the context menu? It is my understanding that that is needed only when the item should also open further detail on tap - which is something I don't need and want. Below is my relevant implementation: private func shareMenuConfiguration(for itemAt: URL, indexPath: IndexPath) -> UIContextMenuConfiguration { let share = UIAction(title: "Share".localized(), image: UIImage(systemName: "square.and.arrow.up")) { [unowned self] _ in let shareVC = UIActivityViewController(activityItems: [itemAt], applicationActivities: nil) if let cell = collectionView.cellForItem(at: indexPath) { shareVC.popoverPresentationController?.sourceView = cell.contentView shareVC.popoverPresentationController?.sourceRect = cell.contentView.bounds } self.present(shareVC, animated: true) } return UIContextMenuConfiguration(identifier: nil, previewProvider: nil) { _ in UIMenu(title: "", children: [share]) } } func collectionView(_ collectionView: UICollectionView, contextMenuConfiguration configuration: UIContextMenuConfiguration, highlightPreviewForItemAt indexPath: IndexPath) -> UITargetedPreview? { guard let item = datasource.itemIdentifier(for: indexPath), let cell = collectionView.cellForItem(at: indexPath) as? GalleryImageCell else { return nil } let parameters = UIPreviewParameters() let visibleRect = cell.contentView.bounds.insetBy(dx: 1/3, dy: 1/3) let visiblePath = UIBezierPath(roundedRect: visibleRect, cornerRadius: 4) parameters.visiblePath = visiblePath return UITargetedPreview( view: cell.contentView, parameters: parameters, target: .init(container: collectionView, center: collectionView.convert(cell.contentView.center, from: cell.contentView)) ) } func collectionView(_ collectionView: UICollectionView, contextMenuConfiguration configuration: UIContextMenuConfiguration, dismissalPreviewForItemAt indexPath: IndexPath) -> UITargetedPreview? { guard let item = datasource.itemIdentifier(for: indexPath), let cell = collectionView.cellForItem(at: indexPath) as? GalleryImageCell else { return nil } let parameters = UIPreviewParameters() let visibleRect = cell.contentView.bounds.insetBy(dx: 1/3, dy: 1/3) let visiblePath = UIBezierPath(roundedRect: visibleRect, cornerRadius: 4) parameters.visiblePath = visiblePath return UITargetedPreview( view: cell.contentView, parameters: parameters, target: .init(container: collectionView, center: collectionView.convert(cell.contentView.center, from: cell.contentView)) ) } Thanks!

Hello, In a new app I am working on I noticed the FamilyActivityTitleView that displays "ApplicationToken" has wrong (black) color when phone is set to light mode but app is using dark mode via override. We display user's selected apps and the labels are rendered correctly at first, but then when user updates selection with FamilyActivityPicker, then those newly added apps are rendered with black titles. The problem goes away when I close the screen and open it again. It also doesn't happen when phone is set to dark theme. I am currently noticing the issue on iOS 18.4.1. I have tried various workarounds like forcing white text in the custom label style, forcing re-render with custom .id value but nothing helped. Is there any way how to fix this?