Sounds like an interesting app! I would say that using a UITableView would make the app horribly complicated. A UIScrollView would be a good base to drag and drop controls onto. Perhaps with an "add page" button, the user could tap this it required, and you could extend the contentSize of the UIScrollView to be the width of +1 pages, and then scroll it so the user can drag more controls onto that page.
To drag the controls around, you could use a UIPanGestureRecognizer attached to each control, and when triggered it changes the centre position of the control. You might need to turn off user interaction of some of these controls - e.g. for a UITextField the power user will want to drag it around but not want to enter a value into it.
For grouping controls, you could do something like this:
- a "group mode", whereby the user taps a button to enter this mode, then taps a number of controls (would need some visual indication on them to show they are selected) and then taps done.
- the selected controls are then be removed from the UIScrollView
- a new UIView is created and positioned at the centre point of the selected controls, and is big enough for the controls to fit in at the same distances apart. It is added as a subview of the scroll view
- the controls are all added as subviews of this view
- the gesture recognizer is added to this view, instead of the individual controls. Then when dragging around, this group of controls will all move as a group with fixed layout.
If you have groups of controls that you think might be commonly used, you could even create them in advance, each in their own nib, and then allow the user to drag them onto the scroll view as a pre-made group.
What you might find, especially if some of your controls are quite large (e.g. I'd expect an image view to be significantly bigger than a label or text field), the pan gesture recognizer gets a bit limiting because when trying to drag views around you'll inadvertently pick the wrong one if they are positioned close together or overlapping. In which case, you might need the extra precision of handling all the touch events yourself - so when a touch starts, you test against all the controls (or groups) to see which has the closest centre to your tap position, and then as you get the touch moved events you can update this centre position.
I've not made anything quite as complex as what you're describing, but I did make an app where the user could drag small images onto a large image to apply as "decorations". They could drag on any number of these decorations, and also scale them with a pinch gesture. In this case, I had a UIImageView as a background which held the main image. Then the decorations were on the edge of the image, and a pan gesture recognizer was used to detect them being dragged onto the image. On drag, I'd actually create a new instance of the decoration (UIImageView) so that there was always another one left in the toolbox. A pinch gesture recognizer was used for the user to scale the decorations. For the user to move around a decoration they had already placed, I had to use manual touch handling to detect the right decoration (since they could easily be overlapping, and ones that looked round to the user are actually square in terms of UIViews, so it was easy for the user to accidentally drag the corner of one when they intended to drag a different one). Mixing an matching gesture recognizers and manual touch handling seemed to work out just fine, which was good because it's much easier to use the gesture recognizers for the more complex behaviour like pinching.
Back to your app, once your power user has set up everything, then when the normal user loads the app, you can just turn off any touch handling code (and remove or don't create the gesture recognizers) and they will get static forms as laid out by the power user. Then make sure user interaction is enabled on all of the controls (e.g. UITextField) and they will be able to enter data into them.
Doing all of the above with controls onto a scroll view will be complex enough I think, and you may end up having to deal with lots of niggly behaviour in trying to get it working nicely for both normal and power users. I think this would be 100x harder if you were also dealing with UITableViews and UITableCells at the same time.
Please let me know if you'd like me to elaborate on any aspect of the app I outlined above, as it does seem to have a fair chunk of functionality in common with your app. Hope to see/hear more about your app in the future!
EDIT
One more thing occurred to me - if you are keen to use a UITableView in your solution, then I would suggest that your power user lays out one UITableViewCell at a time. In fact, they would be dragging UILabels and other controls onto just a basic UIView, which when they've finished you then use to record the positions of the controls. You then use these positions when presenting those controls in a cell - in cellForRowAtIndexPath you would create and init all of the chosen controls, and position all of them in a newly created cell at the positions and layout the power user had chosen. The power user could also have a control to change the height of the cell they are laying out, for more flexibility. They would create a series of cell layouts one after the other (I guess each of these would be a "group" of controls), and then those cells would be presented in order in the table view. You could then give the power user some final tweaking control by letting them put the table into edit mode so they can reorder the cells (or even remove some).
Depending on the application, perhaps the user could also have these cell layouts they've previously created always available, so after they've built up a few common control groups, they can just keep reusing them to very rapidly build up a form. And then occasionally they would create a new cell layout when none of the ones they have created so far are suitable, and again it would be saved as a template for them to use again in future forms.
