There is nothing that an iApp can do that cannot be done using TMUI or TMSH. The iApp merely provides an alternative, customized configuration window into those resources that are relevant to a particular application. iApps are not a 1-shot wizard--they are meant to manage the application throughout its life cycle. There are 2 primary use cases: (1) Customers use F5-authored iApps to make easy work of well-known applications. For example, Microsoft Exchange optimization is configured with 95% fewer steps when using the F5 iApp. (2) Customers write an iApp to duplicate a custom configuration across many BIG-IP's. Many customers have quickly written simple iApps to stamp out a configuration that is specific to their business, which makes the process more efficient and less error-prone. Also, iApps are transactional, so if any part of the configuration fails for some reason, the iApp will return BIG-IP to its prior state.
iApps have a property called "strictness" which prevents resources that are created by the iApp from being modified outside the iApp. This helps to guarantee the integrity of the configuration throughout its life cycle. iApps accomplish this by tagging BIG-IP resources with the app-service property. If you experiment with an iApp, you will notice that resources created by the iApp will be in an app-specific folder and have the app-service property set.
Some iApp templates are shipped with BIG-IP, but the more up-to-date and sophisticated F5 iApps are posted on the iApp Codeshare, organized by application, at https://devcentral.f5.com/wiki/iApp.CodeShare.ashx You will also find community-shared iApps on the Codeshare. Note that iApps are currently used to configure LTM, APM, AFM, ASM, and AAM, but not GTM.
Nimbostratus
