RTL work: https://github.com/wikimedia/wikipedia-ios/pull/4372

Dynamic type support is working well for me, and VoiceOver work will be done as a part of T318611.

@Tsevener I'm really sorry but I can't see dynamic type represented in 7.0 (1993) . Am I looking in the wrong place?

@cmadeo That should be a working build - this is an all-native screen so it will be based on the font size set up in the iOS accessibility settings. Let me know if it's still not working how you expected, thanks!

@Tsevener ah! yes, dynamic type is working if set on a device level, but I was expecting that if I had a large type size set in my reading preferences within the app that I would be able to see the talk page in the same type size, this isn't currently the case. Would it be possible for internal to the app settings to proliferate to this view?

@cmadeo Well, this would be the first time a native view has reacted to that app font size setting, so I wouldn't want to scramble together a change that big in our widespread font-producing classes. Currently only the article and section editor web views react. That's actually why we pushed back on having the reading preferences popover in the Talk Page bottom toolbar. I'm worried about changing something that affects all native views in the app, and I'm also worried about spinning off a separate experience / ability just for one feature.

I think as a team we need to hash out exactly when a native view should respond to that setting before going down this path, because (in my opinion) there are several areas where the line between chrome and content feels blurry. For example, Explore, Revision History, Diffs, Old Talk Pages, and Notifications Center do not react to the app font size - those are all native views. Apologies if this is veering too far away from engineering, but this is one area where I'd like to better understand where that line is before putting in the work. I'm happy to discuss more of your thoughts here!

But, once we have a good rule in place, I think it might not be too difficult to check their app font size setting, map it to an Apple dynamic type size setting, and use that instead what the system is telling us when producing a font for native views. We've generally tried to keep all of our font creation spots in one class so my hope is that will help us implement a bigger change like this. Thanks! 🙏

@Tsevener, I'm sorry I totally forgot that we don't proliferate the sizing outside of article view! As you suggested, this is a larger conversation and change that it'd be great to talk about as a team.

Working for me natively for VoiceOver and RTL and device settings for dynamic text on 7.0.0 (2003)