I had a similar requirement: horizontal scrolling of tables in cells of a regular, vertically scrolling table.
My solution: I put the standard UIiew in the outer cell of the table. This view had a transformation property, which rotated 90 °, acting as a "hinge", turning its contents to the side.
In the form of a hinge was another UITableView . Since it is rotated, it is displayed horizontally on the screen. The cells of this inner table contained another kind of loop, turning their contents -90 °, back to a vertical orientation.
This may seem a bit confusing, but it gives you all the advantages of table views in horizontal orientation. This is less confusing if you do not take into account the appearance of the table with its cells, which are not needed in your case.
Edit: to reply to comment
Performance was definitely great. In fact, performance was the main reason for switching to this approach. Table views are especially good for displaying huge datasets, since they only create visible views (cells) and reuse them after scrolling. The look of the table itself is quite lightweight and very optimized for its purpose. My data sets, where the average size, I would say (about 100 elements in both dimensions) and scrolling, were completely smooth.
Another thing, besides the performance that I was worried about, was touch processing. It turned out that looking at tables (which are deduced from scrolling) always correctly recognize a gesture (scrolling scrolling in scrolling is not so simple). If you placed vertically, the look of the table would handle events, if you carried it horizontally, the inner table would receive all the events. I was very impressed with how well the system dealt with this non-standard situation.