Not good for sharing across a medium-to-large organizations and among mixed user groups, some of whom may not have developer's licence to access apps directly. Even if an app is shared as a web-based version, users have little power to make changes and must always rely on developers on the smallest revisions.
As a developer, I find it to be quite unpredictable and erratic in the way it handles data. For example, Qlikview will always try to connect fields among different tables without being told that they are the same, because it treats all tables as flat files and does not handle relational data the way other tools work. I understand Qlikview is trying to be helpful here but that's not how it should work.
Another development issue I always run into with Qlikview is with the chart/object property box. It is not intuitive the way they've grouped the various functionalities in different tabs. This makes simple tasks confusing and frustrating. Things that should be found under "Axes", for example, are found in "Numbers" or "Presentation". It took me a year to learn where things are. I think Qlikview should learn from Excel on this.
Can be quite buggy if one tries to do a few things at the same times such as running SQL, reading from external data tables, running incremental loads, and creating variables in load script, not to mention using complex functions and set analyses for the front end. This means it doesn't help with business continuity when people leave their job and an app changes hands.