Hello, We ship a font provider app that installs fonts system-wide on iOS, delivering the font files through On-Demand Resources. Since iOS 27 shipped, customers have been reporting that their installed fonts vanish from the system font list after every restart. I would like to know whether the restore path for system-wide font registrations changed in iOS 27, and what a font provider app is expected to do after a device reboot. Environment iOS 27.0 and 27.0.0 only. We have no reports on iOS 26 or earlier. iPhone 18 Pro and iPhone 18 Pro Max Fonts delivered through On-Demand Resources and registered for system-wide installation using CoreText Steps to reproduce Activate a font in the app. It appears in Settings > General > Fonts. Reboot the device. Without launching the app, open Settings > General > Fonts. The font is gone. The app still shows the font as active, because it keeps its own activation state. Deactivate and reactivate the font in the app. It comes back. Reboot again. It disappears again. This happens on every reboot. It also happens with a single font activated, and it persists after updating or reinstalling the app. Because the font is missing from the system font list, it is also missing in other apps that use system fonts. What we have ruled out Not low storage. These are new devices with plenty of free space. The documented purge trigger for On-Demand Resources is low storage, which does not explain a result this consistent. Not a crash. Our crash data for the affected app version shows no elevated crash rate on iOS 27 compared to iOS 18. Not specific to one font or one app version. Questions Did the restore path for system-wide font registrations change in iOS 27? Are registrations that reference files inside On-Demand Resources still restored at boot? If a font provider app now has to re-register after a reboot, when and how should it do that? There is no natural launch point, since someone may use the font in another app without opening ours first. Is there a supported way for the app to detect that a font it installed is no longer present in the system font list, so it can repair the registration quietly? Context We deliver several thousand fonts this way, and Apple increased our On-Demand Resources limit for that reason (Case-ID 17273913, December 2025). On-Demand Resources is deprecated as of iOS 27. We have separately confirmed that fonts delivered through Background Assets cannot be registered system-wide: registration fails with CTFontManagerErrorDomain code 306, both from the Background Assets container and after copying the files into the app sandbox, because CoreText requires the file to sit inside the app bundle or On-Demand Resources. We have a separate question open about that migration path, so this post is only about the reboot behavior on iOS 27. Happy to provide a sysdiagnose from an affected device and a sample project. Thank you.

Hello, I am encountering the following error when uploading a build to App Store Connect: ITMS-90555: Thinned app size is too large – Your on-demand resources in the universal variant are 30 GB, which exceeds the maximum allowable size. After app thinning, the total size of your on-demand resource asset packs in any variant must be less than 30 GB. Our application includes a large amount of font resources delivered via ODR. Before making structural changes, I need clarification because the documentation does not fully explain how ODR size calculations work per variant. Environment Xcode: (latest stable) Distribution method: App Store submission ODR total size before thinning: approximately (28 GB) Build processing fails immediately with the ITMS-90555 error Questions How exactly does App Thinning compute the size of ODR asset packs per variant? Is ODR size evaluated: Per device-specific variant, Or is the “universal variant” treated as an additional variant that must independently stay under 30GB? The documentation mentions a 30GB limit per variant, but the universal variant error message is ambiguous. If device-specific variants are below 30GB but only the “universal variant” exceeds it, is the build still rejected? In our case: iPhone-only variants appear to be below the limit, But the universal variant exceeds 30GB due to aggregated resources. Is this expected behavior? Best practices for managing very large ODR sets (e.g., fonts) Fonts are small individually, but thousands of them produce very large ODR groups. Is there recommended guidance from Apple for: Structuring ODR bundles to avoid the universal variant exceeding the limit Segmenting ODR by device class / feature sets Any alternative packaging strategies Are there tools or logs that reveal how App Store Connect decides variant groupings and ODR size? At the moment, the failure only shows the ITMS-90555 error without further detail. Case-ID for DTS reference DTS advised submitting this question here. Case-ID: 17273913 Any clarification from Apple engineers or community members who have navigated ODR size limits would be greatly appreciated. Thank you very much!