Labels are completely broken when subviews of a glass effect view on iOS 26

[LeoNatan]

Hi @cbpowell ,

This is a new issue, only occurring if a MarqueeLabel is added as a subview to a UIVisualEffectView's content view, and the effect is a UIGlassView. Here is a screenshot of the issue:

The sublabel draws its content with an odd offset and animations are pretty much broken.

If change the effect to a UIBlurEffect, everything is back to normal:

This also happens if set a MarqueeLabel as a UITabBarController.bottomAccessory:

I've forked to https://github.com/LeoNatan/MarqueeLabel and pushed a commit to master that demonstrates the issues outlined above.

Thanks

[KaiOelfke]

We had the same issue integrating it in a miniplayer via SwiftUI as representable. This took a while to debug, but basically the anchor point that gets set in setup() gets overridden somehow in these cases.

The workaround in the updateUIVIew of the representable is this:

So to fix this in UIKit it would probably need to add some checks during the UIView lifecycle methods to keep the anchor point valid or find some other way to prevent this. I think the anchor point is reset by iOS / the system.

// Workaround for some weird tab bar accessory issue.
            // MarqueeLabel sets sublabel.layer.anchorPoint = CGPoint.zero in setup()
            // Due to mysterious reasons beyond me this gets reset to the default UIKit anchor point 0.5 0.5 (center),
            // but only when integrated via UIKit as tabBarAccessory.
            // This does not happen, when directly integrating it into SwiftUI via TabView.
            // And it does not happen, when just adding it as a child UIHostingController into the view hierarchy (not as accessory).

            for subview in uiView.subviews.filter(is: UILabel.self) {
                if subview.layer.anchorPoint != .zero {
                    subview.layer.anchorPoint = .zero
                }
            }

[LeoNatan]

Hi @KaiOelfke

Have you tried setting a breakpoint in setAnchorPoint: to see what in UIKit decides to override the anchor point?

I think there are more issues than just the anchor point, as if I stop and the later restart the animation, it doesn't seem to start.

What an odd behavior. Apple really screwed UIKit in iOS 26; it's a broken mess. And the fact they filled it with Swift this release makes it very difficult to debug and workaround.

[KaiOelfke]

Have you tried setting a breakpoint in setAnchorPoint: to see what in UIKit decides to override the anchor point?

No, I didn't further investigate, but sounds like a good idea. This fix worked for our specific usage of MarqueeLabel.

[LeoNatan]

I'll try to debug this later today and see if I can work around the issue.

[LeoNatan]

Seems like the culprit is -[UIView mt_setContentEffects:], intended to add automatic vibrancy to labels. It takes the label's layer and wraps it in the wretched _UIMultiLayer that is plaguing all of iOS 26.

If I subclass UILabel and put an empty implementation of that method (I don't need vibrancy effects for my use), my old ObjC MarqueeLabel functions as expected. I can easily hide the private API impl. I think this is a good enough solution for me.

For the framework, I think you should not rely on anchorPoint being (0,0), and instead do the math yourself and calculate the position values so that the anchor point can remain at (0.5,0.5).

[LeoNatan]

If you are interested in a PR with a hidden override of that private method, let me know.

[cbpowell]

Awesome, thanks for looking into it. I agree on the anchor point, I actually did remove the anchor point setting in some recent testing, but was running into a strange offset issue on iOS26 still - it’s doubling the leading buffer. That may be the UIMultiLayer that you discovered, if that’s somehow interacting with the CAReplicationLayer.

I’d certainly be interested in a PR if you don’t mind!

[LeoNatan]

Sure, I will create one in a few mins.

[LeoNatan]

One more approach that could work is not using a UILabel sublabel and instead create either a UIView or CALAyer-based helper that will draw an attributed string directly. But then you are in the weeds with regard to TextKit1 vs TextKit2, etc.

[cbpowell]

Well seems like the fix wasn't too bad in the end, assuming I haven't missed something. Latest pushes seem to fix all issues that I can identify on the example case you posted, @LeoNatan. Key change was returning to the nominal anchor point, and then handling the offset for scrolling correctly. If you wouldn't mind checking to verify, I'd definitely appreciate it (@KaiOelfke as well!)

I also added some additional debug features that I was using to verify things were aligning correctly.

[LeoNatan]

Cheers, I'll take a look later.

I've been also playing around with private UILabel APIs to enable marquee scroll:

https://github.com/LeoNatan/LNSystemMarqueeLabel

This is what Apple uses on tvOS for scrolling labels under the hood, but it's available for iOS too, as private API. They use a UIImageView instead of a second label, and animate the position of that.

You can play around with the above lib if you are interested in debugging Apple's own impl for ideas.