Hello Richard, Finally, I found out which function is no longer working correctly with the system font in iOS 26.4. The issue is with CGContextGetTextPosition, which returns incorrect, almost random CGPoint values. With all fonts except the system font, the text position is updated automatically after calling drawAtPoint. The system font is now the only exception. This explains why the earlier workaround—using the Helvetica Neue font—worked well. A better workaround is to calculate the text position manually and then call CGContextSetTextPosition after drawAtPoint. This makes it possible to use the system font again. Best regards, Rolf

As a workaround, the mail composer is no longer presented fullscreen, allowing it to be dismissed by tapping outside the mail window. An updated version of the app has been submitted for review following user reports.

As a temporary workaround, I have replaced the system font with Helvetica Neue in the affected parts of my apps. This is not an ideal solution, but it allows users to continue using the apps without the rendering problems observed on iOS 26.4. I would still appreciate any information regarding the underlying issue with system font rendering, as I would prefer to return to the system font in the future if possible.

After additional testing, I found that the issue is specifically related to the system font: When using: UIFont* font = [UIFont systemFontOfSize:20]; or UIFont* font = [UIFont systemFontOfSize:20 weight:UIFontWeightRegular]; the text is rendered incorrectly (appearing right-aligned or partially clipped) on iOS 26.4. When switching to a named font such as: UIFont* font = [UIFont fontWithName:@"Arial" size:20]; the exact same drawing code produces correct results. I also tested multiple system font variants (including different weights and monospaced digit system fonts), and all system font variants exhibit the same incorrect behavior. This strongly suggests that the issue is related to system font rendering in combination with drawAtPoint:withAttributes: (and drawInRect:) on iOS 26.4. Important: switching to a different font is not a viable workaround for me. The affected drawing routine is a central part of multiple apps and is used in hundreds of places. Changing the font would significantly alter the appearance and require extensive regression testing across multiple iOS versions. Given that the same code worked correctly for years and still works on iOS 26.2, this appears to be a regression in iOS 26.4. Could you please confirm whether this is a known issue, or advise on a safe and compatible solution?

Good news! On iPad—in both landscape and portrait—there’s room for a status bar in my app. With it enabled, everything works perfectly on both the main screen and the settings screen: the window control is inserted into the status bar as shown in the video, and you don’t need to use the UILayoutGuide discussed there. As expected, the settings screen is positioned below the status bar, so the left-bar button is no longer obscured by the window controls. On iPhone in landscape, there isn’t room for a status bar, but you can handle this by implementing prefersStatusBarHidden. Since multitasking is only available on iPadOS 26, this is the simplest solution on iPhone.

That doesn’t solve my issue: The video only handles cases where a navigation bar is already at the top of the main screen. Please advise what can be done if this is not the case (as for my main screen). On my settings screen (a table view with a navigation bar on top), I implemented your sample code, but the left-bar button on the navigation controller’s bar still doesn’t move and remains covered by the window controls. I must be doing something wrong. Based on another user’s suggestion and also your video, I tried using UISceneWindowingControlStyleMinimal in my SceneDelegate.
Still about a third of the left-bar button is obscured by the window controls. Here’s my Objective-C code (based on your Swift code) in the navigation bar subclass: UIView *containerView = self.view; UIView *contentView = self.navigationBar; UILayoutGuide *contentGuide; UIViewLayoutRegion *marginsRegion = [UIViewLayoutRegion marginsLayoutRegionWithCornerAdaptation: UIViewLayoutRegionAdaptivityAxisHorizontal]; contentGuide = [containerView layoutGuideForLayoutRegion:marginsRegion]; // Pin all four edges of the content view to that guide [NSLayoutConstraint activateConstraints:@[ [contentView.topAnchor constraintEqualToAnchor:contentGuide.topAnchor], [contentView.leadingAnchor constraintEqualToAnchor:contentGuide.leadingAnchor], [contentView.bottomAnchor constraintEqualToAnchor:contentGuide.bottomAnchor], [contentView.trailingAnchor constraintEqualToAnchor:contentGuide.trailingAnchor], ]];

It certainly helps, but about 33% of the left-bar button is still obscured by the Windows control. I’ve only tested it in the simulator, so it may behave differently on a real device.

I tried implementing the code, but the leftBarItem button on the navigation controller’s bar isn’t moving and is now unfortunately covered by the window’s controls. Apparently I’m doing something wrong. Here’s my Objective-C code: UIView *containerView = self.view; UIView *contentView = self.navigationBar; UILayoutGuide contentGuide; UIViewLayoutRegion marginsRegion = [UIViewLayoutRegion marginsLayoutRegionWithCornerAdaptation:UIViewLayoutRegionAdaptivityAxisHorizontal]; contentGuide = [containerView layoutGuideForLayoutRegion:marginsRegion]; // Pin all four edges of the content view to that guide [NSLayoutConstraint activateConstraints:@[[contentView.topAnchor constraintEqualToAnchor:contentGuide.topAnchor], [contentView.leadingAnchor constraintEqualToAnchor:contentGuide.leadingAnchor], [contentView.bottomAnchor constraintEqualToAnchor:contentGuide.bottomAnchor], [contentView.trailingAnchor constraintEqualToAnchor:contentGuide.trailingAnchor], ]];

Hi Scott, Thank you very much for your input, it now works. Did not know this notation: UITraitUserInterfaceStyle.self It seems to be the same as UITraitUserInterfaceStyle.class which is perhaps a more intuitive notation? Anyway, both notations work, super! I'm mainly programming in C and always a bit afraid that memory is freed behind the scenes. But will give ARC a serious try. Thanks for the suggestion.

Tried the following in Objective C: UITraitUserInterfaceStyle* style = [[UITraitUserInterfaceStyle alloc] init]; NSArray* traits = [[NSArray alloc] initWithObjects: style, nil]; [self registerForTraitChanges:traits withTarget:self action:@selector(handleStyleChange)]; [traits release]; [style release]; Unfortunately, this crashes in registerForTraitChanges: UIKitCore`-[UIViewController registerForTraitChanges:withTarget:action:]: 0x1acce3f90 <+60>: bl 0x1acf55568 ; +[UITraitCollection _traitTokensIncludingPlaceholdersForTraits:] -> 0x1acce3f94 <+64>: bl 0x1afc953c0

Same here with the UIAlert generated by iOS / iPadOS asking for permission to use the microphone. Hope you can fix this.

Yes, it shows zero downloads for the last 24 hours. There was an update for the 22nd of March with nonzero downloads yesterday. Hopefully there will be an update for today. If so, it is "only" a problem with this "last 24 hours" option.

Also problems with Apple Music

Same here in the Netherlands, no sales since yesterday

Solved! Thank you Apple Developer Program Support team for acting so quickly!