Introduction

Digital platforms have recently become a common phenomenon in the context of connected digital devices. Devices such as Smartphones, Tablets, Smart TVs and Connected Cars are equipped with access to the producer’s digital platforms and are part of their ecosystems. Digital platforms allow external contributors to extend the functionality beyond the platform’s core functionality provided by the platform owner (Tiwana et al. 2010). Thereby, digital platforms are able to provide users with a more diverse range of functionality than a single entity can realize alone (Eisenmann et al. 2011).

Typically, extended functionality is provided through capsuled code fragments, often referred to as applications or add-ons. These applications are distributed by means of the marketplace maintained by the platform owner. Platform customers utilize the marketplace to search and gather applications for their devices. In order to be distributed through the marketplace, third-party applications need to comply with platform design rules (Ghazawneh and Henfridsson 2015). Applications are deployed using specialized boundary resources provided by the platform owner. Platform-specific Software Development Kits (SDKs) allow third parties to effectively realize their application on the individual platform. Application Programming Interfaces (APIs), as part of the boundary resources, allow applications to access platform resources and thereby establish integration with the platform.

Integration is of utmost importance considering the highly modularized software architecture of digital platforms as well as the distributed development with various actors participating on a platform (Tiwana 2015a). Integration in this study needs to be seen as distinct from its simplest version, that is, participation. While participation of third-party developers refers to providing applications for the platform regardless of their interaction with the platform (Ceccagnoli et al. 2012), integration means the effective usage of platform boundary resources in order to interact with the platform core and exchange information, as well as to use the features provided. Integration can be considered a more intense form of participation. Whereas participation is present for every third-party application on the platform, the degree of integration varies widely between applications. While the use of some boundary resources is mandatory in order to realize applications (participation), developers are free to choose most of the boundary resources to be used in application development (integration) (Ghazawneh and Henfridsson 2013). For the platform owner, integration might be desirable as it increases control over platform activities and allows for providing a uniform user experience (Boudreau 2010; Eaton et al. 2015). For contributors, integration can be an effective way to realize applications and utilize advanced platform features; however, it requires an additional platform-specific integration effort and simultaneously increases dependencies (Hsieh and Hsieh 2013; Kim et al. 2016). Developers are therefore interested in whether the integration effort involved will pay off.

While positive effects have been found for platform participation, there is a lack of research on integration which is addressed in this study. In contrast to participation, understanding the role and implications of integration requires a more detailed view of platform architecture, especially concerning different types and levels of integration for applications on digital platforms. Since neither a systematic consideration of integration aspects nor a related model is available, we review related platform concepts to better understand integration possibilities prior to exploring the research question: How does application integration on digital platforms impact application success and customer satisfaction? By conceptualizing an application integration model based on established platform concepts, this study addresses a literature gap and provides a basis for subsequent analysis. The model distinguishes aspects of integration and provides means to measure platform integration. Subsequently, the model is operationalized and applied to the Apple iOS platform using linear regression to assess the impact of integration for over 82,000 applications. Application success and customer satisfaction are used since these are most prevalent among developer targets and for characterizing application performance (Lee and Raghu 2014; Siegfried et al. 2015). The analysis provides valuable insights for developers and platform owners. Related implications are discussed.

Related Literature

We refer to a software platform following Tiwana et al. (2010) as an “extensible codebase of a software-based system that provides core functionality shared by the modules that interoperate with it and the interfaces through which they interoperate”. A module, in the mobile domain referred to as application, is a “[···] software subsystem that connects to the platform to add functionality to the platform” (Tiwana et al. 2010). Following Ghazawneh and Henfridsson (2015) we consider an application marketplace to be “a platform component that offers a venue for exchanging applications between developers and end-users [···]”.

Participation on Digital Platforms

Considering the effects of participation as a predecessor of integration helps to assess similarities and differences to integration. For the platform owner and contributors, positive economic effects related to participation on platforms were found. For the platform owner, adopting a business model incorporating a digital platform could result in multiplied market value compared to work as a stand-alone company. It has been found that the ecosystem was the main reason for this (Antero and Bjørn-Andersen 2013). In a similar vein, financial effects for contributors include positive effects on sales and an increased likelihood of an initial public offering (Ceccagnoli et al. 2012). Regarding the contributions themselves, higher prices were found for commodities traded through a digital platform (Banker et al. 2011).

Platform Openness

Platform openness constitutes a prerequisite for integration and is a major design element of digital platforms. Gawer and Cusumano (2014) distinguish internal and external industry-wide platforms. Open platforms allow third parties to participate without restrictions, whereby each side can be considered individually (Eisenmann et al. 2009). While openness is less important for end-users (Nikou et al. 2014), it is highly important for contributors. Koch and Kerschbaum (2014) consider openness to be important for developers in terms of innovation and resource expenditure. Hilkert et al. (2011) identified openness as a satisfaction factor for developers. Exemplarily, Google’s Android platform is considered more open than the competing Apple platform (Ghazawneh and Henfridsson 2015; Parker et al. 2017).

Since third parties’ abilities to integrate as well as related boundary resources are controlled by the platform owner, openness is considered a requirement for integration (Tilson et al. 2012) and has been given much attention (Thomas et al. 2014). Since platform resources change over time (Eaton et al. 2015; Baldwin and Woodard 2009), managing openness is an important task (Eisenmann et al. 2009) which induces effects concerning innovation dynamics and profits (Parker and Van Alstyne 2008). Opening a platform increases the innovation rate (Boudreau 2010) and more open platforms with more developers lead to higher profits (Parker et al. 2017). The elements, effects and measurement approaches of platform openness provide a framework to capture application integration (Ondrus et al. 2015; Benlian et al. 2015).

Boundary Resources as Integration Mechanism

For boundary resources as the primary element for technical integration, literature is in agreement regarding their importance (Eaton et al. 2015). Ghazawneh and Henfridsson (2013) define boundary resources as “the software tools and regulations that serve as the interface for the arm’s-length relationship between the platform owner and the application developer”. Platform owners use boundary resources as control mechanism. In the area of conflict between stimulating external contributions and maintaining control over the platform, precise decisions are required regarding the design of boundary resources and related governance mechanisms (Eaton et al. 2015; Ghazawneh and Henfridsson 2013). Ghazawneh and Henfridsson (2013) specify that boundary resources typically consist of a software development kit (SDK), e.g., iOS SDK, and a multitude of related APIs. For the developer, both quality and functionality of boundary resources are relevant selection criteria (Hsieh and Hsieh 2013). Designing boundary resources according to developers’ needs is important (Kim et al. 2016), since efficiency in application realization is a main driver for them to participate in digital platforms (Hyrynsalmi et al. 2014).

Platform integration is distinct from bilateral integration efforts in the IT systems context. As platform resources are highly standardized, owners offer possibilities for integration through boundary resources. However, conducting integration is subject to the developer during application development. Therefore, third-party developers choose the degree of platform integration themselves, which we define as the extent to which boundary resources are employed to utilize platform resources. Platform integration is understood as the use of boundary resources during application development.

Hypotheses Development

We focus on the level of systems integration for digital platforms (Stavridou 1999). Thereby, integration is not considered to be a system property, but a relationship of system elements, which seems appropriate since applications are contributed by a diverse developer community (Boudreau 2012; Thomas and Nejmeh 1992).

The employment of platform resources to realize application functionality is considered as platform integration. Developers use interfaces as an integration mechanism to access platform functionality. The platform core subsumes basic functionality useful for applications realization regardless of their domain. The incremental evolution ensures them to be well-tested and demonstrate a good performance while being easy to use and robust with regard to changes (Ghazawneh and Henfridsson 2013; Eaton et al. 2015).

Employing platform core functionality is assumed to enhance effectiveness, since the developer is able to focus on core competencies, which is application realization to provide new functions. Developers typically contribute specialized functionalities that are not provided by the platform itself (Haile and Altmann 2016; Bosch and Bosch-Sijtsema 2010). Compared to developers who do not employ the provided resources, less effort is required of the first to realize a similar functionality (Harter et al. 2000; Bosch and Bosch-Sijtsema 2010). Conversely, assuming limited development time and budget, more time can be used to develop specialized functionality. Devoting more time is assumed to result in better functionality, which leads to superior success. Software development studies have proved that the devotion of additional time results in better software quality (Harter et al. 2000). Focusing on the contribution of specialized functionality is not a one-time aspect. Instead, this becomes increasingly relevant with the many updates typical for digital platforms, that impact functionality and competition between developers (Kapoor and Agarwal 2017). Since platform resources are maintained by the owner, developers can rely on their availability and focus on providing specialized functions. Developers thereby enhance effectiveness throughout the application lifecycle. Correspondingly, studies on product platforms have found integration to be associated with performance enhancements (Droge et al. 2004).

Concerning efficiency, employing platform resources allows developers to realize specialized functionality with less input required (Bosch and Bosch-Sijtsema 2010). Here two aspects are relevant. First, realizing necessary elements while requiring fewer resources makes it possible to devote resources to developing specialized functionality, which results in better functionality and therefore differentiates from competitors (Bosch and Bosch-Sijtsema 2010). Second, faster realization results in reduced time to market (Droge et al. 2004), which is especially relevant in hypercompetitive markets such as application marketplaces (Sangaralingam et al. 2012). Releasing applications faster allows for a better starting position compared to competitors, which allows to gain a substantial market share, especially if competition lags behind. In light of the dynamics associated with two-sided markets such as network effects (Eisenmann 2008), this creates a competitive advantage which is accelerated by the dynamics themselves and hard to catch up for others.

As platform integration allows for a more effective and efficient realization of applications, it makes it possible to gain competitive advantage. Consequently, more integrated applications are assumed to be more successful, which leads to the hypothesis:

Hypothesis A

More integrated applications on digital platforms are more successful than less integrated ones.

In information system literature, integration is an antecedent of system quality which impacts user satisfaction (Wixom and Todd 2005). Even though typically considered on the system level, integration is likely to be relevant for system components as well and consequently impact customer satisfaction.

Integrated applications and functions have better availability and are therefore easier to access. Since platforms offer various access options for third-party functionality, greater accessibility is assumed to be favored by users. As accessibility influences the ease of use, which is relevant for customers’ attitude towards system usage (Wixom and Todd 2005), a positive impact on satisfaction is assumed. Integration from a user-interface (UI) and design perspective is another important criterion. Platforms implement typical UI elements that are used across different platform contexts (Wasserman 2010). Through continued use, users become familiar with these platform-specific characteristics and are more likely to use them, as these design concepts are familiar to them (Andre and Wickens 1995; Morris et al. 2010). For users, integration thus reduces learning effort, which allows them to be productive faster which is assumed to be perceived positively (Nikou et al. 2014). Similarly, integration can reduce the setup effort, since integrated applications can access central settings, data and accounts, which is likely to be perceived positively (Park and Koo 2016). Considering central settings in individual applications allows to adapt solutions to the individual user’s needs, without the necessity to specify them individually. Haile and Altmann (2016) found system usability (the extent to which a system can be used effectively and efficiently) positively affects users’ perceived value on a platform level, which is similarly assumed for the application level. Many of the aforementioned aspects are associated with factors known to be important for the acceptance of and satisfaction with software solutions, as they influence customers’ perception and intention to use a technology. All in all, integration affects several aspects which are directly visible for users and is therefore assumed to impact their perception, which leads to the hypothesis:

Hypothesis B

Users perceive more integrated applications on digital platforms more positively than less integrated ones.

Model Development

Given the situation of a missing model for platform integration and for the use as measurement instrument, an integration model has to be conceptualized first. While aspects of integration have been discussed individually, an integrated model incorporating the different aspects in the platform context is missing. The platform context with its highly modular architecture, high level of standardization and uniqueness of boundary resources is different from typical system integration aspects which is why existing integration models lack the complexity of platform integration. Following a three-step process, a platform integration model is developed (see Table 1). First, concepts related to the integration on digital platforms are identified by reviewing existing literature (first column). Literature on digital platforms with a focus on, but not restricted to, integration, openness and boundary resources was considered. Second, relevant aspects and findings were used to identify additional related aspects relevant for integration. Third, identified concepts were grouped according to the integration aspect they refer to, which is subsumed in the model category (fourth column). Table 1 presents the identified concepts, a brief description and relevant findings as well as the associated model category. While options for integration are platform-specific, similarities exist concerning the platform architecture and related integration possibilities. The derived platform integration model constitutes a general version for digital software platforms.

Table 1 Concepts related to platform integration

Aspects of Platform Integration

Device Ecosystem Integration (DEI)

On mobile device platforms, integration can be established on the software and hardware level (Saarikko 2016). Platform access for mobile devices is bound to specific devices or at least operating systems. While Google opened up the Android platform for other device manufacturers, access to the iOS platform is restricted to Apple devices (Kenney and Pon 2011). From a developer’s perspective, iOS is considered to have a lower platform complexity regarding device-specific adaptations than Android (Kapoor and Agarwal 2017). Developers need to face platform complexity by implementing adoptions, which is considered an integration. While mobile devices platforms supported only smartphones in the early days, they have been opened for devices such as tablets, watches and the like (Tilson et al. 2013). As a result, device-related platforms typically inhibit sub-ecosystems for which applications are released individually (Idu et al. 2011). Providing applications for multiple sub-ecosystems requires adoptions which are considered as integration, since this allows additional users to access the application’s functionality.

Operating System Integration (OSI)

For device-bound platforms, the operating system (OS) is a key component within the ecosystem infrastructure. The operating system provides basic functionalities and access to specialized third-party functionality. Since the OS mediates the interaction with the user, operating system integration is a viable element for enhanced interaction (e.g., speech assistants). Platforms offer multiple ways to access third-party complements, which is why integration can ease access (Wasserman 2010). Aside from direct interaction, the OS and related boundary resources typically offer frameworks with context functionality for developers (Eaton et al. 2015). This includes functions such as authentication (e.g., fingerprint verification) which developers can use for their applications. Developers are free to choose the extent to which they integrate applications with the operating system (Ghazawneh and Henfridsson 2013). Platforms progress over time and are usually released in cycles. Through updates, developers are regularly offered additional options for integration (Ghazawneh and Henfridsson 2013).

Data Integration (DI)

Data integration is of great importance on digital platforms (Schreieck et al. 2016). With its central position within the ecosystem, the platform is ideally suited for data integration (Gawer 2014). While integration of various data sources is one aspect, the integration of applications via shared data is another. A platform can act as central abstraction layer for data integration. Typically, platforms provide storage, retrieval and synchronizing features for data. For storing specialized information, platforms offer domain-related frameworks (e.g., health applications). Regarding data provision, platforms offer data access (e.g., sensor information) through interfaces. Data synchronization allows for data access across devices within the platform. Through the reuse of data and settings, data integration makes it possible to customize solutions to a user’s needs.

Marketplace Integration (MPI)

Marketplaces are an important instrument for matching the two sides of the platform, i.e., developers who contribute applications and users who seek applications. Application marketplaces as primary distribution mechanisms play three central roles: they provide a catalogue of applications to match the supply and demand, they facilitate transactions, and offer institutional infrastructure for regulatory and legal aspects (Ghazawneh and Mansour 2015). Marketplaces’ exclusiveness varies across platforms. While Apple strictly controls functionality distributed on iOS through the exclusive AppStore, Google is less restrictive and allows for additional marketplaces (Ghazawneh and Henfridsson 2015; Koch and Kerschbaum 2014).

For users, marketplaces facilitate gathering additional functionality. In the search phase, users seek an application that fits their needs (Müller et al. 2011). To support this, marketplaces allow for application presentation, e.g., by categorizing applications, providing a description, or screenshots. Typically, marketplaces also allow users to rate and review applications (Siegfried et al. 2015). Marketplace integration facilitates search process efficiency. A greater integration, i.e., using the features provided, reduces users’ search cost (Müller et al. 2011). This is especially relevant if many alternatives are available, as for applications on mobile devices (Qiu et al. 2017; Avinadav et al. 2015). While developers can make choices regarding application presentation, transactions and regulatory aspects are standardized. Marketplace integration allows to reduce uncertainty and to stand out from competition.

Platform Application Integration (PAI)

Integration with other third-party applications on the platform can be established via the platform or through direct connections. Integration via the platform can be achieved using frameworks or data integration. Through direct application integration, also referred to as product integration, new services are created by combining existing ones (Kim et al. 2012). Integration with other applications allows access to resources other applications provide (Tiwana et al. 2010). For instance, social networks offer recommendation functions which are useful for enhancing awareness (Lis and Neßler 2014). Since PAI targets the platform ecosystem rather than the platform directly, it is categorized as ecosystem integration. Application integration allows for enhanced functionality.

Timeliness

Platform owners regularly release updates of their platforms which introduce new features (Dutta et al. 2017). Integration with digital platforms is understood as a continuous task instead of a one-time action (Tiwana et al. 2010). Complying with platform standards and utilizing new features is important in order to be competitive (Tiwana 2015a). Examples have shown that platform updates shift existing application performance and rankings (Kapoor and Agarwal 2017). To remain competitive, developers need to adjust their application and release new versions. Continuously providing application updates is therefore considered as integration. Application updates are also used to introduce new features. Similar to competition on platform level, the introduction of new features is important for developers on the application level (Ghazawneh and Henfridsson 2013). Updates are important to provide continuous innovation and compatibility.

Cross-Platform Availability (CPA)

While the former categories focus on a single platform, cross-platform availability considers platforms beyond the focal one. Previous studies have found that developer multi-homing, that is, contributing to more than one platform, is not a common phenomenon in the mobile domain, except for top-ranked applications (Hyrynsalmi et al. 2016; Ali et al. 2017). Literature suggests developers not to rely on a single platform from an innovation and risk standpoint (Selander et al. 2013). Platforms change governance over time (Eaton et al. 2015), which poses a risk to third-party developers. Multi-homing makes it possible to reduce platform dependency (Hyrynsalmi et al. 2016). While platforms are well suited to establish integration within their context, developers might aspire to create their own application-specific ecosystem across platform boundaries. A messaging application, for instance, has limited value if only available on a single platform, e.g., WhatsApp in contrast to iMessage allows for cross-platform messaging (Bender and Gronau 2017). The availability of a corresponding application on another platform is considered as integration, since the application works as a connector to the application ecosystem. Thereby, applications allow to bridge platform boundaries.

Figure 1 depicts the research model for platform integration in the mobile device sector.

Fig. 1
figure 1

Platform integration research model

Analysis

Together with Google’s Android, iOS is one of the largest platforms when it comes to contributed third-party applications. From a research perspective, the platform offers various interesting governance and dynamics aspects, which is why iOS was involved in many studies already (Dutta et al. 2017; Eaton et al. 2015; Ghazawneh and Henfridsson 2013). Apple iOS with its single marketplace, AppStore, allows for coherent and exhaustive measurement of success and satisfaction metrics, which is important for this analysis and the reason why iOS was chosen.

While the conceptualized integration model is suitable for different device-bound platforms, it is not yet sufficient to measure integration for a specific platform. Operationalization is necessary to appropriately cover the integration characteristics for the iOS platform and surrounding ecosystem accordingly in order to provide meaningful analysis results.

Model Operationalization

Model operationalization was conducted in a two-step procedure. First, the possibilities to measure platform integration were assessed. Preferably, application integration would be measured on the source code as ground truth. Since neither the proprietary platform nor the application code were available, approximations had to be used. Second, to measure integration of each application individually, a set of approximating indicators is needed. Indicators are identified based on the model categories of the generalized platform integration model. For each model category, based on the related concepts, appropriate measures were identified for the iOS case. Table 2 describes selected indicators for each model aspect.

Table 2 Integration model operationalization for the Apple iOS platform

Model Categories

Device Ecosystem Integration (DEI) consists of five indicators to describe the different sub-ecosystems which an application is available for. In addition to iOS-based devices (iPhone, iPad, iPod), compatibility with the Apple Watch (watchOS) and Car Play is considered. Platform complexity is covered through the number of devices an application supports for iOS-based devices.

Operating System Integration (OSI) encompasses nine indicators to describe operating system integration. The category covers aspects that indicate the use of platform frameworks/boundary resources for authentication (Touch ID, Face ID), interaction (Siri, Widgets, Notifications, Spotlight), communication (iMessage) and data transmission (AirPrint, AirDrop).

Data Integration (DI) subsumes five indicators to characterize data integration. The iCloud framework allows for the storage of data for backup purposes, as well as for the synchronization of data across devices. The other indicators are domain-related frameworks for specialized purposes. Apple Health allows users to store and retrieve fitness-related information. The Game Center similarly combines functionality for games. Apple Wallet makes it possible to centrally store tickets, cards, and vouchers. Apple Home allows for managing smart home equipment.

Marketplace Integration (MPI) covers six indicators to describe AppStore integration. Marketplace integration is mandatory on iOS for application distribution. To describe the extent of uncertainty reduction the elaborateness of application presentation is used. Description and release notes were considered in their length. Assuming a more extensive description allows for a better comparison of different applications and their functionality. Providing screenshots or a website assists user’s upfront assessment. Assigning applications to multiple categories facilitates their discovery. Market-specific adoptions, measured as the availability in country-specific application stores, also characterize marketplace integration.

Platform Application Integration (PAI) requires cross-module composability to realize product integration. Product integration is characterized by seven popular examples which were identified by analysing all available AppStore applications. Applications that were integrated with most often were chosen as examples to cover the aspect of composability as a requirement for integration. These include social networks (Facebook, Instagram), a blogging service (Twitter), a video sharing platform (YouTube), a messaging service (WhatsApp) and storage services (Dropbox, ownCloud).

Timeliness is measured by a single indicator which describes the provision of updates. Even though release number conventions exist, version numbers are not sufficiently standardized to be employed as a reliable indicator. Therefore, the number of updates throughout a half-year timeframe is considered.

To assess Cross-Platform Availability (CPA), a similar platform is needed. Given the market structure for mobile device platforms, the Google PlayStore is used. Since the two platforms (iOS and Android) combined account for a market share of more than 95%, other platforms cannot be considered comparable (Dutta et al. 2017). Furthermore, the two are often considered to be direct competitors for mobile devices platforms (Tilson et al. 2012). CPA measures the developer multi-homing as binary variable indicating whether a corresponding application is available on the PlayStore.

Control Variables

Different control variables are considered to account for alternative explanations in the variation of the success and satisfaction measures. The application category is considered since the importance of integration aspects varies across domains. While the Game Center is highly relevant within the game’s category, the overall influence for success is rarely significant. The applications belong to 23 different categories. Application categories have already been considered in prior studies (Sangaralingam et al. 2012). The primary device category controls for the device type (phone or tablet) an application was originally designed for. Studies found variations in dynamics between free and paid applications, e.g., the time for which an application remains successful (Lee and Raghu 2014; Koch and Guceri-Ucar 2017). Other studies found the combination of free and paid applications to be a strategic element (Baird et al. 2016; Voigt and Hinz 2016). The price variable accounts for this. Similar to earlier studies, we control for the age of an application, in days from the initial release, as applications need time to achieve a reasonable spread, reputation and position within the platform and marketplace (Comino et al. 2019; Zhou et al. 2018).

Application Success Measurement

Assessing success of applications on digital platforms is complex. Various factors could be considered, e.g., installed base, revenue, or time of usage. While revenue might be a useful measure for paid applications, it is not suited for the large proportion of free applications. The optimal measurement depends on the goals the individual developer aims to attain. For this study, a coherent measure is required to ensure comparability.

Application marketplaces often provide application rankings. Ranks are assigned for each ‘top’ (at least well-performing) application individually. The application rank is acknowledged to be important in application ecosystems and furthermore an established measure of success (Lee and Raghu 2014; Kapoor and Agarwal 2017). Marketplaces actively promote the top-performing applications, which is an advantage for those in the hypercompetitive environment (Sangaralingam et al. 2012).

Depending on the application marketplace, rakings are provided as either category-specific or overall. Category-specific ranks, as provided by the AppStore, are highly appreciated, since the impact of integration factors is assumed to vary across application domains. Furthermore category-specific rankings are well-suited for comparisons within each segment and are simultaneously comparable on the overall level. While the AppStore allows for assigning an application to multiple categories, we focus on the ranking within the primary application category, since the position is assumed to best characterize the application success relative to competition.

While the exact calculation of AppStore ranks is not public (Lee and Raghu 2014; Garg and Telang 2013), studies have identified factors that impact the ranking, e.g., the number of downloads (Bergvall-Kåreborn and Howcroft 2011). The importance of application rankings is further supported by their impact on customer decisions (Ursu 2018).

For this study, the primary application rank is employed to measure application success. Within each category, applications are ranked from 1 to 1000.

Customer Satisfaction Measurement

Various aspects influence customer perception. For this study, a coherent measure is required to ensure comparability across applications. Typically, marketplaces encompass a review and rating functionality for customers to state their application experience (Ghazawneh and Henfridsson 2015). Application ratings in the PlayStore and AppStore are realized through a five-point star schema. Additionally, users can review applications by giving textual feedback. While reviews are useful for addressing specific points, they are not as an overall measurement. Sentiment analysis can be employed to gain insights but does not provide a coherent metric measurement as required (Qiu et al. 2017). Additionally, more ratings are given than reviews are written, which makes the former more reliable to reflect user opinions. Previous studies supported the ratings’ relevance by highlighting their impact on buying decisions in e-commerce (Lin 2014; Bao and Chang 2014) and mobile device platforms (Siegfried et al. 2015).

To express customer satisfaction, the aggregated application rating is used. Through the combination of positive and negative ratings, a well-balanced average assessment is achieved. The star-based ratings from 1 to 5 are rounded to half-point values, resulting in nine different ratings. Two different ratings are provided on the AppStore: the rating of the current application version and the average of all ratings. Since both, applications and their integration, develop over time, we consider the current version’s rating as an appropriate time-dependent measurement for satisfaction (Bergvall-Kåreborn and Howcroft 2011).

Results

Descriptive Analytics

Data was collected for applications from the Apple AppStore for iOS devices. Since the Apple US Store had the most applications, we chose this for our analysis. Data from the Apple iTunes Store was obtained for a six-month period from October 2017 to March 2018 using iTunes Affiliate Resources.

While integration information was available for all applications, data regarding their success and satisfaction were limited. We gathered ratings for the same applications that were ranked to ensure comparability.

For the analysis, data from 82,876 applications were used. Each application is assigned to a primary category out of the 23 categories. Separate rankings are maintained for free and paid applications, as well as for smartphones and tablets. Ranks are attributed from 1 to 1000, adding up to a theoretical maximum of 92,000 (23 categories × 2 price categories × 2 device categories × 1000 ranks) ranked applications. Since not all ranks in each category are assigned, the number of actual observations is lower. With the exception of the newspaper & magazine category, the categories contain between 2910 and 3938 observations (separately for price and device category), with a mean of 3063 per category, which is why the data is considered to be relatively equally distributed among categories.

The application ranks are almost equally distributed among the 1000 possible ranks. A very slight tendency towards a decreasing number is found for higher ranks. This is attributed to the aspect discussed before, namely that later ranks are not assigned in all categories. With a mean of 492, an equal distribution can be assumed.

Since a minimum number of ratings is required before the average rating for the current version is calculated, not all applications are assigned a rating. For 61,788 observations in the dataset, average ratings could be retrieved. The distribution of the ratings is right-modal with an average of 3.68 and a median of 4 stars. Most applications are assigned a 4.5-star rating, followed by a five-star ranking.

Rankings are listed separately for free and paid applications. The dataset contains 43,514 free (53%) and 39,362 (47%) paid applications. Overall, more free than paid applications are available, which represents the distribution. With regard to the primary device category, the phone category with 41,978 (51%) contains slightly more applications than the 40,898 (49%) tablet category.

Regression Metrics

Although being explanatory models, the regression models are not intended for prediction but only for testing the hypothesized relationship. To test hypothesis A, application success measured by the category-specific application rank is used as dependent variable. For hypothesis B, application satisfaction measured by the average rating of the application’s current version is used. Indicators of the operationalized integration model are used as independent variables. Linear regression (OLS) was used to test the influence of integration.

Table 3 shows the regression model summary for the success measure on the left and the satisfaction measure on the right. Both models were computed using the lm-function from the stats package with R 3.6.1. To test for multi-collinearity, we employed the variance-inflation factor (VIF) for model indicators. The average VIF of the model variables is 1.3. Two indicators showed a value above three, with a maximum of 3.29. The aspect of multi-collinearity does not violate the commonly applied threshold of 10 for VIF values (O’brien 2007). The correlation matrix for model indicators is shown in the Appendix (available online via http://link.springer.com). During model analysis, no relation between fitted values and residuals was found. The model was evaluated for heteroscedasticity, which revealed a non-equal distribution of residuals, which is why robust standard errors according to White (1980) were used and reported in Table 3 (Long and Ervin 2000).

Table 3 Regression model A (application performance) and model B (customer satisfaction)

Integration Success Model

Regression model A contains 23 indicators that are significant at least at the 0.05-level. Highly significant variables are found in any category. In ranking logic, lower values are preferred over higher ones. Regarding coefficients, negative coefficients support hypothesis A.

The hypothesis can be split in overall significance and assumed hypothesis direction. The overall significance clearly shows that integration impacts application success. Concerning the positive impact, 20 out of the 23 significant model indicator have a negative coefficient. Since higher indicators values represent more integration, negative coefficients decrease the rank number, which in turn is positive in the logic of rankings. Therefore, 87% of the significant indicators support hypothesis A, which is therefore considered to be confirmed.

The regression model explains a variance of 8.6% (adjusted R2) for application rank. Thereby, the goal is not to explain a high variance of success, but rather to investigate the influence of applications’ integration on their success. Considering that integration is only one of many aspects that influence success, the explained variance can be considered good, especially since important aspects such as functionality are neglected (Nikou et al. 2014).

Integration Satisfaction Model

The regression model for satisfaction as well includes 23 indicators that are significant at least at the 5%-level. Each integration aspect contains significant variables. Contrary to the first model, higher values express higher satisfaction (stars logic). Therefore, positive coefficients support hypothesis B.

The overall model is highly significant and thereby confirms the impact of integration on satisfaction. From 23 significant integration indicators, 16 have a positive coefficient. Thereby, 70% support the direction of hypothesis B which is considered to be supported.

The model explains a variance of 11.2% for customer satisfaction. Similar to the previous model, the idea was not to build a model with explanatory power but rather to test for hypothesis B. We employ linear regression to test hypothesis B. Linear regression requires the dependent variable to be metric. When assessing the applicability for our setting, the calculation procedure of ratings has to be considered. When a customer rates an application in the AppStore, one can assign between one and five stars. The customer is thereby given an ordinal set of choices in the form of stars. Once a reasonable number of ratings are assigned, the marketplace calculates an average rating. The aggregated mean rating builds an almost metric measurement. The mean rating, even though not made publicly available, is afterwards rounded to the half-star values. The derived ranking ranges from 1.0 to 5.0 stars in half-point steps, resulting in nine different values which are shown in the marketplace. Given the assumption that ratings are rounded subject to mathematical conventions, the rating values represent the mid-points of the given interval of 0.5. Mid-point regression is a common procedure and similar results have been shown in previous applications (Boukezzoula et al. 2011). Therefore, using it in this case is considered appropriate. Furthermore, typical related issues do not apply since only the influence is tested.

In summary, regression analysis confirms integration to impact application success and customer satisfaction. Moreover, model analysis reveals that greater integration goes along with more success and higher satisfaction and thereby confirms hypotheses A and B.

Discussion

Results Discussion

The two regression models use different scales for their dependent variables. While the rank (success) ranges from 1 to 1000, the maximum for ratings (satisfaction) is five. The integration indicators as independent variables were measured consistently to allow for comparability. The satisfaction model explains a slightly higher variance than the success model. Both models are highly significant and support corresponding hypotheses.

The consideration of the aspects in more detail reveals the importance of integration aspects. For Device Ecosystem Integration, the same indicators are significant, and their direction matches each hypothesis which confirms further findings in that better availability is positive for applications (Sangaralingam et al. 2012). The iPod indicator is an exception for both models. One explanation is that iPods constitute a relatively small device proportion considering the total ecosystem and the constantly growing proportion of cellular smartphones (iPhones) compared to WiFi-only iPods. Given the intense competition, iPod-specialized applications might not be able to achieve an outstanding result, and thus show a reverse-directed influence. As rankings are maintained separately for iPhones and iPads but not for iPods, this intensifies the competition between iPhone and iPod-specialized apps. For OSI, both models have four significant indicators, albeit different ones. The overall positive impact of OSI integration supports findings of studies with a similar focus (Dibia and Wagner 2015). For Data Integration, all indicators were significant for satisfaction, while Game Center was not for success. Overall, data integration greatly impacts both measures. This highlights the importance of domain-related frameworks for integration, whereby only integration with mature and widespread solutions has positive impacts, a finding which Apple Home exemplifies by its low support. Regarding Marketplace Integration, all indicators are highly significant in both models. The many positive influencing factors highlight the importance of marketplaces as a distribution mechanism and confirm former studies concerning application presentation in marketplaces (Dibia and Wagner 2015; Siegfried et al. 2015). For Platform Application Integration, both models involve YouTube and Instagram as significant indicators. While both were positive for success, integration with YouTube negatively impacts satisfaction. While simply measured by common examples, the importance of integration with other applications is supported. Updates are highly significant and support the hypotheses for both models, which highlights their importance on platform markets. In line with earlier studies, we confirm the importance of updates for application success (Zhou et al. 2018; Comino et al. 2019). While Cross-Platform Availability positively impacts success, negative effects on satisfaction were found. While providing additional value, several issues are related to the provision across platforms. For instance, previous studies revealed functionality not always to be consistent across platforms (Ali et al. 2017), which might be perceived negatively. Since some platform owners – especially Apple – are known to create lock-in effects (Kenney and Pon 2011), customers might perceive it negatively if applications do not work seamlessly compared to what they are used to within the Apple ecosystem.

Considering significant indicators that point contrary to hypothesized direction reveals interesting results. With the exception of Apple Wallet, YouTube and application pendant, significant indicators with a reversed influence point in the same direction in both models. Overall, 19 of the 23 significant indicators overlap in both models. This proves the importance of similar integration aspects for both success and satisfaction. In conclusion, integration positively impacts application success (model A) as well as customer satisfaction (model B).

Theoretical Contributions

Regarding theoretical contributions, this study contributes to existing literature in various ways. An initial attempt to theoretically model and empirically test the concept of platform integration is made. The model includes different aspects of integration and provides a reasonable segmentation of integration possibilities in the context of digital platforms. The developed model may serve as a foundation to explore effects related to integration beyond the success metrics employed here.

Additionally, the study operationalizes the generic model for device-bound platforms for the prominent Apple iOS platform and thereby provides a measurement instrument for application integration. The study shows that platform integration is actively employed by application developer. Future studies might provide operationalized models for other platforms to explore related effects on similar platforms.

The study extends prior literature in that the notion of platform participation as a success factor is not comprehensive enough. With platform integration this study explores the relationship between platform and application in more detail and analyses the respective effect on success. While former studies highlighted the positive effects of platform participation (Ceccagnoli et al. 2012), this study extends prior results through the aspects of integration in specific that contribute to success.

The study confirms prior studies with regard to the importance of boundary resources (Karhu et al. 2018; Ghazawneh and Henfridsson 2013). The study extends existing literature by a more detailed model of boundary resources as integration mechanism for mobile device platforms and uncovers effects related to integration. The study reveals platform integration to positively affect application success and customer satisfaction. In doing so the study contributes to the understanding of platform dynamics and modeling application’s success. Developers use boundary resources for their applications, which contributes to their success that is especially important in hypercompetitive environments such as mobile device platforms. Simultaneously, using boundary resources creates dependencies. Developers rely on the boundary resources provided by the platform owner for their application to work. Boundary resources as a mechanism allow for control by the platform owner and are known to evolve and change (Eaton et al. 2015).

Therefore, risks are associated with integration. Enhanced integration results in a higher dependence on the platform or the owner respectively. Through the provision of specialized resources, digital platforms realize lock-in effects which is why developers are willing to tolerate changes regarding platform resources and governance mechanisms. Earlier studies proved termination costs to be important regarding the continued provision of applications on platforms (Kim et al. 2016), which is intensified with increased levels of integration. The developed integration model allows to explore aspects of lock-in effects in more detail which may provide strategical guidance for developer.

Application integration is also important in terms of multihoming. As applications rely on the platform-specific boundary resources of the focal platform, providing similar functionality on another platform requires more effort than if the functionality had been realized more autonomously with less boundary resources usage (less integration). Therefore, integration itself is part of the effort to switch to another platform (termination cost) (Kim et al. 2016). Closely related to that, integration runs contrary to platform multi-homing. Similar to switching a platform, multi-homing requires an application to run on multiple platforms. To achieve efficiency, developers are well-advised to realize functionality as independently from platform-specific resources as possible, to allow similar procedures to work on various platforms and thereby reduce the cost for multi-homing (Hyrynsalmi et al. 2016).

Additionally, enhanced usage of boundary resources for provision of functionality eases coring endeavors of the platform owner. As integrated applications already rely on platform resources to a great extent, they can be realized more easily by platform owners in a similar manner (Bender et al. 2019). Therefore, coring becomes more likely, which means the integration of third-party functionality into the platform core (Bender and Gronau 2017). Less integrated applications require more effort to be cored. Generally speaking, greater integration ties applications to the focal platform which makes them less competitive on their own. This can be seen critical in light of the power imbalance between contributors and owners.

Given the relative disadvantages of less integrated applications on digital platforms, it remains unclear whether an optimal degree of integration exists, which allows developers to balance advantages and downsides of integration.

The applicability of the implications to other platforms is of great interest. Similar results are expected for similar device-bound platforms (e.g., Google Android) as well as non-device related software platforms (e.g., WordPress). It remains questionable whether the results can be transferred to more specialized platforms such as data platforms. While data integration is only one aspect of platform integration, it is the key aspect for data platforms. Integration in the context of data platforms requires standardization. Once data is integrated and shared with the owner and other stakeholders, the risk to lose competitive advantage arises. Using the example of fitness and health data, we find specialized frameworks such as Apple health. For example, fitness trackers can contribute data to the health data framework. If they do so, users might tend to use the platform application for data analyses instead of their own, which results in fewer engagements with the fitness brand. In order not be reduced to a data provider, companies need to provide functionality of additional value. For instance, fitbit tried to establish an own ecosystem for fitness trackers across platforms (Schreieck et al. 2016) which offers additional value to customers who use devices of multiple platforms. The aspect of cross-platform integration is of great importance. While digital platforms are well-suited for integration within the platform context, they are not beyond the platform scope. Developers might aspire to create an own ecosystem independent of existing platforms. While the power of established platforms as well as the need to be present cannot be neglected by contributors, they aim to offer additional value. Therefore, the establishment of an own ecosystem across platforms can be a strategy to mitigate the risks of platform integration.

Practical Implications

Concerning practical implications, the results reveal that a higher level of integration positively impacts application success and customer satisfaction. First and foremost, this has implications for developers, who are free to choose the degree of integration for their applications. Integration allows them to achieve superior performance when they integrate their applications well with the platform. In doing so, the different integration aspects are important to reveal the full potential of integration.

Integration is relevant for all participants, i.e., platform owners, developers and customers. Each party should make careful decisions regarding platform integration. The owner, as the entity maintaining and governing the platform, is responsible for providing integration opportunities. Since integration enhances efficiency and effectiveness of application development, integration possibilities are relevant in platform competition and demanded by developers. Owners can use integration as a twofold strategic component. While attracting developers with good integration possibilities, they can also be employed to achieve lock-in effects. Prior research showed that developers with more integrated applications are less likely to leave the platform (Tiwana 2015b), and that termination costs keep developers from leaving a platform (Kim et al. 2016). Since integrated applications rely on platform-specific resources, providing a similar functionality on another platform requires extensive development effort. Developers, therefore, might tolerate more governance-related changes as a result of lock-in effects. Platform owners use integration and related boundary resources to govern third-party development (Ghazawneh and Henfridsson 2010) and to enforce their interests (Tilson et al. 2012).

Third-party developers can use integration as competitive advantage. The results have revealed a positive impact on success and satisfaction. However, required efforts are platform-specific (Hyrynsalmi et al. 2016). Developers should consider both effort and use of integration carefully. Furthermore, contributors should consider multiple platforms for innovation (Selander et al. 2013) and risk mitigation purposes (Hyrynsalmi et al. 2016). However, this results in integration effort for each platform. Platform-specific contributions that are not relevant for other platforms are an exception, therefore integration should be employed to gain related advantages. Developers should consider the strategy for and value of multi-homing before deciding on integration. Developers might not always consider success as most important but focus on other aspects such as customer engagement during development.

For customers, the results suggest that more integrated applications are preferred to less integrated ones. Customers probably consider integration when choosing applications. Depending on the use case, integration itself, as desired functionality, can provide value.

Finally, the study shows integration not to be limited to single platform boundaries. Providing corresponding applications on competing platforms plays a crucial role for applications’ functionality and success. Here, the system-of-systems idea applies within the broader mobile device ecosystem.

Limitations

Regarding the conceptualized integration model, the focus on mobile device platforms limits generalizability. While many aspects also apply to other platform types, some are specific for mobile device platforms. The conceptualized integration model does not claim to be exhaustive. During conceptualization, we focused on the most prominent examples of integration with other applications. However, an application’s popularity is not necessarily related to its integration importance. While the model itself provides a reasonable segmentation of integration, the usefulness regarding the comprehensive expression of integration is relatively limited. While not necessary for regression analysis, those aspects support further model refinement. Finally, the model focuses on technical integration of applications, while non-technical integration aspects are out of scope.

For the regression analysis model, constraints apply regarding the model operationalization and the data used. We employed the category-specific application rank as a success measure. Even though it has been acknowledged as a measure for success, the ranking is a self-reinforcing mechanism and the exact calculation procedure is not made transparent. Regarding generalizability, our focus on the top applications, since ranks are only assigned for them, has to be noted.

Some indicators in the operationalized model were derived from other measures or by means of text-analysis procedures. While these approximations seem reasonable for this study, future studies may preferably consider the applications source code as basis, which is not available in the case of iOS.

Even though the integration model provides an approximation and first measurement instrument for application integration in digital platforms, it is not yet suitable to guide development efforts.

Future Research

Future research to improve the conceptualized integration model can add new aspects and related indicators to describe platform integration. Additionally a more detailed notion of integration, guidance on comprehensively measuring integration and indices formulation is desirable. Regarding the analysis, alternative success measures could be employed to overcome current shortcomings.

Comparing results with competing platforms, e.g., Android, would provide input with respect to similarities and differences. Even though similar results are expected, the role of integration might have more impact in more restrictive ecosystems such as iOS compared to less restrictive ones. Incorporating other platform types makes it possible to evaluate and compare integration importance. Open-source platforms are favorable, since source code analysis allows for an in-depth analysis of integration and related implications. Comparing results for specific application domains may reveal more detailed insights which are useful for developers.

While this study only considers a single time-bound variable (number of updates), employing time-series analysis makes it possible to assess the impact of integration over time. Additionally, this allows to investigate the role of external events, such as major platform updates or the introduction of new integration opportunities.

Focusing on the platform owner’s perspective enables insights into providing integration opportunities, as well as strategic considerations regarding integration. Insights from the developer’s perspective provide valuable input regarding the design of integration opportunities. Assuming that integration is not a simple yes-or-no decision, a cost–benefit consideration could assist integration decisions.

While integration is here predominately found to be positive, studies could focus on the downsides of integration. In combination with this study, this would shed light on whether there is an optimal degree of integration.

Conclusion

Most of today’s mobile digital devices are equipped with access to the manufacturer’s digital platform by default. Platforms allow users to extend devices’ basic operating system functionality through associated marketplaces. Platform owners provide resources that allow for application development by third-parties. During development, platform integration is important to effectively realize application functionality on a platform. While aspects of participation on digital platforms have been studied, research on a comprehensive notion of integration is still missing. Integration refers to the effective employment of platform boundary resources for application realization. Understanding implications of integration is of great importance for developers in order to make deliberate decisions when designing or refining their products.

By proposing a platform integration model based on existing concepts, this study takes a first step towards a better understanding of integration on digital platforms. Concerning dynamics related to integration, hypotheses regarding the impact of integration were developed and tested using data from over 82,000 applications of the Apple AppStore. The results reveal that application success and customer satisfaction are positively influenced by platform integration. To achieve superior results, developers should address multiple aspects of integration, such as devices, data, the operating system, the marketplace, other applications, as well as provide updates and access to other platforms. Furthermore, the study highlights the importance of integration for all platform participants and their possibilities to employ integration as a strategic instrument.