What the components handle, what they do not, and THE NUMERAL SYSTEM TRAP — a quantity in the wrong digits BESIDE ONE IN THE RIGHT ONES.
Half of this estate's users read Arabic, so this is not an internationalisation afterthought — it is half the application, and it fails in ways an English-reading developer cannot see.
WHAT THE COMPONENTS HANDLE IS THE LAYOUT MIRRORING. Set the direction and the page reverses: alignment, order, controls, scrollbars. That part works, and it is the part people worry about.
WHAT THEY DO NOT HANDLE IS ANYTHING YOU BUILT WITH A DIRECTION ASSUMED. A margin on the left, an icon meaning "next" that points one way, a fixed pixel position. Use logical properties — start and end — so the page mirrors rather than needing a second version of itself.
AND THE NUMERAL TRAP IS THE ONE THIS PLATFORM HAS RECORDED HITTING REPEATEDLY, SO IT IS WORTH THE DETAIL. Arabic can be written with Western or Arabic-Indic digits, and the choice is made by the LOCALE you format with. A bare Arabic locale often resolves to Western digits; a region-qualified one gives Arabic-Indic.
SO THE FAILURE IS TWO NUMBERS ON ONE SCREEN IN TWO DIFFERENT NUMBERING SYSTEMS. A total formatted through a helper, in Arabic-Indic, beside a count interpolated raw into a sentence, in Western digits — a few pixels apart, on the same line. Both are readable and the pair is obviously wrong to a reader and invisible to everybody else.
THE CAUSE IS ALWAYS THE SAME: A NUMBER THAT REACHED THE SCREEN WITHOUT PASSING THROUGH A FORMATTER. Interpolated into a message, concatenated into a label, or rendered straight from a variable. So the rule is that no number reaches the page unformatted, and a message takes a formatted STRING rather than a number.
AND THE ONLY WAY TO FIND THESE IS TO LOOK AT THE ARABIC PAGE. No test can see it, the English page is perfect, and every one of these defects lives exclusively in the locale the developer does not open.