I am loving this discussion post! I think apps are such an underutilized portion of the Alteryx toolkit. I agree with a lot of the sentiment from @patrick_digan. Here are my full thoughts below:
A - Ensuring action tools are applying to the correct part of the tool it's connected too can be quite a struggle and then in some instances doesn't work quite as intended. For example if I connect a text box to a formula tool to replace the value of a string that is hardcoded in the formula tool ("Replace Me") and I connect an action tool to replace that it also replaces the " marks in the tool as a default.
B - Debugging is quite the challenge and making sure the functionality is working as intended is very tough. I don't mind that a debug opens a new workflow, but it would be nice to be able to push any changes (that allows you to fix any problems) back to the original app. Without this aspect altering your app in a debug scenario becomes very cumbersome and requires you to make continuous notes of changes so you can make them back in the original app.
C - It is a challenge to have to use a secondary app to feed front end values to a list box or any other interface tool. Chaining apps is not always the easiest to debug or have it be successful and it would be much easier to allow on open any part of a workflow that feeds the UI components.
D - The differences in the way UI components look and the way things operate in Designer versus on Server is definitely a challenge. At times I feel I can't develop something locally as it could present problems on server, so I am constantly saving versions to server and this can slow down development time and also create a more complex development cycle.
E - A specific mention on a tool would be around drop downs. It is helpful to be able to use the first letter to go to the values starting with that letter in a drop down, but what would be even better is a drop down that is searchable. An end user could have so much more functionality in this type of drop down and would simplify use. You can find this idea here
F - Chaining apps secondary issue. In my apps I use a lot of the temporary files location (%TEMP% or [Engine.TempFilePath]) and when you chain apps, this variable does not cross over chained apps even though they are operating as one app. Trying to create files and ensure files aren't overwritten (if multiple runs of an app occur simultaneously) can be quite challenging when chaining apps.
A - Requirements gathering on the front end is so helpful in the development process. Ensuring you understand the process of what the app needs to do and what a front end should entail allows you to mock up the UI and get feedback to avoid as much rework as possible. This can entail using a drop down versus a list box or tree file as a requirement may need to allow for multiple selections and not just one.
B - Multiple interface tools can update a single tool and you can also have multiple interface tools flow to an error message. This has been tremendously helpful for me and something I wish I knew from the beginning.
A - Automating Process
B - Standardizing metric data pulls
C - Simplifying analytics for end users (we incorporate data science algorithms with simple front ends to allow end users to custom build models based on selections)