Smart cards, in their traditional deployment architecture referred to as the Issuer Centric Smart Card Ownership Model (ICOM), have a restricted application lifecycle. In this model, an application is installed onto a smart card by the relevant card issuer. In most cases, the card issuer is also the centralised controlling authority for different lifecycle stages of the application. The installed application might not be deleted for the whole duration of the smart card's operation. The interaction of the application is controlled and closely monitored by the card issuer. ICOM-based smart cards have only one application, in the majority of deployments. Therefore, the likelihood of Feature Interaction Problems (FIPs) is minimal. By contrast, in open and dynamic smart card models like the GlobalPlatform Consumer-Centric Model (GP-CCM), and the User Centric Smart Card Ownership Model (UCOM) the probability of FIPs is substantially higher. The nature of these models allows users to install and delete applications as they require. This change in the application landscape might create a situation in which features (functions) of an application do not execute properly due to their reliance on an application that might be removed by the user or updated/modified by the Service Provider (SP). In this paper, we will focus on the problems related to application deletion that can potentially cause an FIP on the smart card platform. The paper proposes a framework to minimise such problems so the users can gain maximum service from their device and "freedom of choice" without concerns about application interdependencies.