App 2

Vol. 28, No. 10, October 2019, pp. 2594–2608 DOI 10.1111/poms.
13072
ISSN 1059-1478|EISSN 1937-5956|19|2810|2594 © 2019 Production and Operations Management Society
Habitat Traps in Mobile Platform Ecosystems

Nargis Pervin
Department of Management Studies, Indian Institute of Technology Madras, Sardar Patel Road, Chennai 600036, India,
nargisp@iitm.ac.in
Narayan Ramasubbu
Joseph M. Katz Graduate School of Business, University of Pittsburgh, 3950 Roberto Clemente Dr., Pittsburgh, Pennsylvania 15260, USA,
narayanr@pitt.edu
Kaushik Dutta*
Muma College of Business, University of South Florida, 4202 E Fowler Ave, Tampa, Florida 33620, USA, duttak@usf.edu
ven with the rapid proliferation of applications (“apps”) running on smart handheld devices, achieving success in
E mobile platform ecosystems is challenging for developers because of the heavily crowded marketplaces and easy sub-
stitutability of apps. In this study, we draw inspiration from biological ecosystems research and from the operations man-
agement literatures on software production, product management, and digital platforms to empirically examine the
sustainability of newly launched apps in the Apple and Google mobile platform ecosystems. In the ecology literature, a
“habitat trap” refers to the instinctive but detrimental behavioral response which can potentially lead to the extinction of
organisms facing dynamic changes in their habitats. Applying the habitat traps concept to mobile platform ecosystems,
we investigate whether seemingly beneficial actions of app developers can indeed become detrimental to the sustainability
of their apps. Using lifecycle data of 57,117 newly launched paid apps, we examine the impact of five developer actions
(updating the apps, offering price promotions, and diversifying into functional variants, similar apps, and other plat-
forms) on the sustainability of the apps. The results of our analysis show that while frequent app updates are beneficial,
engaging in price promotions and diversification-oriented activities indeed have the risks of turning into traps for devel-
opers. We utilize the empirical results to draw attention to the heterogeneity of traps in mobile platform ecosystems, shed
light on the need to develop strategies for overcoming the traps, and discuss the implications of the presence of platform
traps for emerging theories on digital ecosystems.
Key words: digital ecosystems; mobile platforms; platform traps; survival

History: Received: April 2017; Accepted: June 2019 by Subodha Kumar, after 3 revisions.
mobile apps, only a few are successful in gaining con-

1. Introduction tinued usage by consumers. Even among the success-
Market research indicates that about 63% of the global ful applications, revenues are skewed in the sense
population already owns a mobile device and that the that <2% of the app developers net the vast majority
number of global mobile phone users is expected to of the revenues from the app stores (Perez 2014). Mar-
reach about five billion by 2020 (Statista 2018). With ket observers note that about half of iOS developers
the widespread proliferation of smart mobile devices, and 64% of Android developers operate with as little
the mobile application (“app”) marketplaces have revenue as $500 per app per month; 35% of iOS and
also seen enormous growth. In a recent estimate by 49% of Android developers perform even worse by
the market analysis firm App Annie, the mobile app making <$100 per app per month (Perez 2014). Also,
economy was valued at about 81 billion USD in 2017, revenue yields vary tremendously across and within
and consumer spending in the app stores is expected app categories. For example, in the entertainment cat-
to grow to more than 150 billion USD by 2022 (Che- egory, the #1 app makes 4.8 times as much revenue as
ney and Thompson 2018). The ease of development of the #10 app; in the social networking category, the
mobile apps with innovative, cross-platform software ratio is 6:1, and in the lifestyle category it is about
kits (e.g., PhoneGap and Appcelerator) has helped the 8.7:1. This indicates a tendency for the app market to
number of mobile apps to reach more than 2 million veer toward a-few-superstars-take-the-most scenario
in both the Google Play store and the Apple App store (Zhong and Michahelles 2013). Therefore, publishers
marketplaces in 2018. However, among so many are constantly looking for ways to keep their apps in
2594
19375956, 2019, 10, Downloaded from https://onlinelibrary.wiley.com/doi/10.1111/poms.13072 by Zhejiang University, Wiley Online Library on [11/03/2024]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
Pervin, Ramasubbu, and Dutta: Mobile Platform Habitat Traps
Production and Operations Management 28(10), pp. 2594–2608, © 2019 Production and Operations Management Society 2595
the top ranking, highly visible zone of the platform production process (Dawande et al. 2008, Staats
marketplace listings. et al. 2011). To this operations management literature
The rankings of the apps listed in the mobile plat- on software production process, this study makes
form marketplaces reveal dynamic patterns. For contributions by examining the DevOps process in
example, it is common for an app that is shown in the the context of mobile apps production. We investi-
top 250 list of a store to drop entirely out of the rank- gate the antecedents and consequences of developer
ing bounds within the next 30 days. In fact, our data actions taken in response to signals received from
indicate that 90% of newly launched apps that man- end users and competitors in the mobile platform
age to get within the visible, ranked zone (e.g., top ecosystems.
500) are not featured within the ranked zone after In the DevOps app production and publishing set-
30 days. Given this dynamic, publishers are often ting, developers tend to rely on market-analytics
keen to be agile and improvise their strategies in products such as App Annie platform intelligence,
order to keep their apps within the visible ranking which provides real-time data about reviews and rat-
ranges of marketplaces. Often in the mobile app ings of apps along with their market positions rela-
release management process, publishers adopt the tive to competitors (App Annie 2018). Informed by
practice of “DevOps” (development operations) such market intelligence data, app publishers often
where the IT production environment is managed by react to competitors’ actions by strategizing changes
collaboration and communication of both app devel- to their own apps. For example, app publishers
opers and business professionals. An integrated could alter their app’s price, change its category,
development and operations approach is often imple- and/or release a new version. With DevOps tools,
mented through automating the process of software introducing these changes has become fast and oper-
delivery and infrastructure changes. For example, ationally easy.
DevOps practices include automatic build scripts To study market- and user-centric influences on
that produce new versions of apps, deployment software products, researchers have utilized a variety
scripts that manage the release of the new app ver- of operations management techniques such as queu-
sions, and infrastructure scaling scripts that manage ing theory models that relate allocation of product
the operational infrastructure of the apps. In a maintenance effort to user requests (e.g., Kulkarni
DevOps setting, the onus of the software product et al. 2009). Bala and Carr (2009) address pricing
delivery (mobile app release in this case) is on both issues related to software upgrades by considering
the software developers and the business managers, the intertwined roles of quality improvement and
who operate in a “fused” operational environment to user costs. Similarly, other studies have recom-
achieve optimal coordination. The integrated mended policies for software product management
DevOps teams make key strategic and operational by balancing the influence of system-level characteris-
decisions including the market timing of the initial tics such as complexity and lifecycle stage with user-
release and subsequent upgrades of apps, changes in level aspects such as learning effort and anecdotal
pricing of apps, positioning of apps in various plat- reasoning that are often based on word-of-mouth in
form ecosystem categories, and responding to com- digital platforms (Ji et al. 2011, Mehra and Saha 2018,
petitor actions such as the release of functional Ren et al. 2018, Wang et al. 2019). These studies about
variants of apps. In this study, we discuss the strat- software product management and digital platforms
egy and operational decisions in the DevOps of in the operations management literature highlight a
mobile app development. variety of challenges related to optimal sequencing
Operations management techniques have been and pricing of application features and responding to
applied in the software development lifecycle to customer voice in digital platforms. In the context of
derive optimal policies for coordinating multiple DevOps operations and mobile app production, exist-
activities (e.g., Koushik and Mookerjee 1995, Mook- ing research does not make it clear if quick and fre-
erjee and Chiang 2002, Xia et al. 2016). Similarly, quent responses to user feedback and competitor
sequencing development of software components actions by app publishers would always have positive
such that they can be reused across complex soft- impacts on the marketplace performance of the apps.
ware projects has been discussed by Liu et al. (2007). Hence, there is a need to systematically examine the
Studies have also considered how such coordination antecedents and consequences of operational deci-
and sequencing of software development activities sions executed by app publishers participating in
may be impacted by operational strategies that mobile platform ecosystems. To address this need, we
embrace co-production between clients and vendors build on prior research on product life-cycle manage-
(e.g., Rahmani et al. 2017). Finally, research on soft- ment and on product portfolio strategies (e.g., Chen
ware production has also shed light on the benefits et al. 2008, Mehra et al. 2014, Ramdas 2003) and
of adopting a lean, agile, and integrated software examine how DevOps strategies impact the
2596 Production and Operations Management 28(10), pp. 2594–2608, © 2019 Production and Operations Management Society
survivability of apps in mobile platform ecosystems. the launches and subsequent lifecycles of 57,117 paid
Thus, as shown in Figure 1, our study brings together apps from the Apple and Google marketplaces
three distinct literature streams on software produc- (30,842 from the Apple App Store and 26,275 from the
tion and operations, product lifecycle and portfolio Google Play Store). Following Lee and Raghu (2014),
management, and digital platform ecosystems for we model the survival of those apps and consider the
examining issues related to the competition among antecedents and impacts of five operational decisions
and the survival of mobile apps. by their publishers such as offering price promotions,
We first empirically demonstrate that mobile app introduction of functional variants, release of app
publishers react to market signals such as changes in updates, and diversification into other similar apps
user ratings and competitors’ releases of app and platforms. Our results show that app developers
updates, for example, by offering price promotions, do indeed react to signals from the marketplace and
adding functionality, and/or releasing functional that such reactions may detrimentally affect the sur-
variants. Industry observers tend to prescribe such vival of their apps. Utilizing those empirical results,
reactive responses of app developers as best prac- we discuss the implications of the presence of habitat
tices (e.g., Haselmayr 2015, Katemats 2012). How- traps in mobile platform ecosystems for research on
ever, contrary to the common assumption that such digital ecosystems and for managing the product life-
market-driven reactions by app publishers would cycles of mobile apps.
always improve the acceptance or popularity of an
app in the marketplace, these reactive actions could
become potential traps. This counterintuitive notion
2. Theoretical Background
about app survival in mobile platform ecosystems is We draw inspiration from biological ecosystems, soft-
motivated by the concept of “habitat traps” found in ware operations, and digital platforms literatures to
biological ecosystems (Schlaepfer et al. 2002). In develop our hypotheses on the sustainability of apps
habitat traps, sometimes members of a species are in mobile platform ecosystems. We first present the
misled by environmental cues and make instinctual background literature on ecological habitat traps and
decisions that are actually detrimental to the survival then map the phenomenon to the context of mobile
of the species. Though in the short term such deci- platform ecosystems. We then consider the impact of
sions may appear rational and based on survival five specific operational actions enacted by develop-
instincts, in the long run those instinctive decisions ers on the survival of their apps in the platform mar-
may lead to a significant reduction in population ketplaces: (i) offering app updates, (ii) launching
growth and even eventual extinction of the species price promotions, (iii) releasing paid functional vari-
(Kokko and Sutherland 2001). In this study, we sys- ants, (iv) releasing other similar apps, and (v) launch-
tematically explore this possibility and show that ing the app in other mobile platforms.
some market-induced reactive actions of app devel-
opers could have significant negative impacts on the 2.1. Ecological Habitat Traps
survivability of apps. In a biological ecosystem, organisms inhabiting the
Applying the idea of habitat traps to the mobile ecosystem act according to the signals they perceive
platform ecosystems, we examine data collected on from their habitat and their evolutionary survival
instincts. For example, certain species of birds and
animals migrate to more resourceful patches upon
Figure 1 Positioning of Research Study
sensing a shortage of food or other periodic seasonal
changes. However, if the habitat changes suddenly or
in dynamically different patterns, an organism’s typi-
Software cal evolutionary (instinctual) response may differ
production and from what is optimal for the organism’s welfare.
operations When instinctive behavior becomes dissociated from
choices that are optimal for its welfare and survival,
the situation is termed an ecological habitat trap
(Robertson and Hutto 2006, Schlaepfer et al. 2002).
Product
Digital Organisms caught in a habitat trap make errors in
lifecycle and
platform assessing the suitability of a habitat as a result of mis-
portfolio
ecosystems matches between the environmental cues that they
management
instinctively use and the actual quality of the habitat
that is undergoing changes (Battin 2004). A well-
documented example of an ecological habitat trap
Study’s contribution
(Mannan et al. 2008), is the case of hawks preferring
to nest in urban areas rather than in more suitable often by the flick of a finger adds to the challenge of
exurban areas. Although nestling mortality for the high substitutability of apps for developers. Thus, the
hawks is higher in the urban areas (>50%) compared mobile app marketplace is a challenging and competi-
to the exurban areas (<5%), the hawks seem to be tive environment to operate in. In this context, we
drawn into the urban areas because of the higher den- consider the possibility of five specific developer
sities of their prey such as pigeons and doves found actions that can potentially trigger habitat traps: (i)
there. However, the urban pigeons and doves often offering app updates, (ii) launching price promotions,
carry a disease, trichomoniasis, the chief cause of nest- (iii) releasing paid functional variants, (iv) releasing
ling mortality of the urban hawks. Thus, the hawks other similar apps, and (v) launching the app in other
are said to be caught in an ecological habitat trap, mobile platforms. We hypothesize the effects of each
being misled by their perception of the availability of of these actions and present them for empirical verifi-
abundant prey in urban areas. The population of a cation. Since the marketplace dynamics and business
species caught in an ecological habitat trap decreases strategies related to free and paid apps in platform
over time and might tend towards extinction because ecosystems differ distinctively (e.g., Lee and Raghu
of competition for resources and the decrease in the 2014, Liu et al. 2014), we limit this study to the cate-
breeding output of the species at dwindling popula- gory of paid apps.1
tion sizes, an effect termed the “Allee effect” (Kokko
and Sutherland 2001). We next apply the ecological 2.2.1. App Updates. Mobile platforms make it
habitat trap concept to the mobile platform ecosys- easy for developers to update their apps so that new
tems context. features can be rolled out and the quality of the apps
can be continuously improved through bug-fixing
2.2. Traps in Mobile Platform Ecosystems activities. Although the platforms facilitate easy and
We draw inspiration from the habitat trap concept in automatic updates of apps for users without the has-
the ecology literature and conceptualize the presence sle of manual intervention, app developers and end
of similar traps in the mobile platform marketplaces users still share the burden of ensuring backward
such as those hosted by Apple and Google. In doing compatibility and interoperability with other apps.
so, we follow the tradition of analogy-based theoriza- Furthermore, the presence of different generations of
tion in the management literature (Cornelissen 2005, devices and operating systems even within the same
Ketokivi et al. 2017) and build on the precedence of platform ecosystem not only makes it difficult for
invoking analogies between biological ecosystems developers to ensure backward compatibility and
and business-related platform ecosystems. For exam- interoperability but also creates demand variability
ple, Levin and Iansiti (2004) discuss how ecology when they make changes to their apps (Dogan et al.
could inform strategic decisions of firms sponsoring 2011, Ji et al. 2011, Tilson et al. 2012). Hence, develop-
business platforms. We propose that similar to the ers pursuing an aggressive update schedule do risk
organisms that are propelled by their evolutionary, creating potential conflicts with underlying platforms
survival instincts to react to signals emanating from or other dependent apps. Often such dependencies
their habitats, developers also react to observable are user-specific and app publishers do not have full
changes in the platform marketplaces for economic visibility of a user’s complete set of actual application
benefits. And similar to the organisms caught in an usages. Thus, the risks of breaking compatibility with
ecological habitat trap, developers of mobile applications other apps that a user has installed are often difficult
might likewise make sub-optimal choices that hinder to quantify by an app publisher or a third-party mar-
the survivability of their apps in the platform market- ket analytics firm. Given this information asymmetry,
places. Thus, the analogy of organisms caught in an an aggressive update schedule tends to increase the
ecological trap can be applied to the mobile apps, chance of an app becoming unusable in the diverse
which are driven by the agency of their developers. use contexts of the app’s installed base. Furthermore,
The two mobile platform ecosystems hosted by an aggressive update schedule might also suggest
Apple and Google each carry more than 2 million that an app is unstable; frequent updates may be per-
apps, and competition between apps to acquire users ceived as a signal of poor quality, causing users to
is intense. Imitation of apps among competing devel- prefer more stable substitutes. For example, Foerderer
opers is also widely prevalent in the mobile platform and Heinzl (2017) note that existing consumers of an
ecosystems (Xue et al. 2019). Apart from the large app provided lower ratings for an app after receiving
number of apps that the app stores carry, the lack of updates, indicating that app updates do have the risk
uniform naming standards and ambiguous catego- of alienating the existing installed base of the app.
rization of apps often make their discovery and Hence, frequent updates of apps could become poten-
assessment difficult for users. The ease with which tial traps for developers. We hypothesize that possi-
consumers can delete apps in their mobile devices, bility as following:
HYPOTHESIS 1. The higher the frequency of updates of a base. However, if the new apps and app variants are
paid app, the higher the probability of the app encounter- perceived as substitutes for the original app, users
ing a habitat trap. may decrease their continued usage or downloads of
the original app and thereby trigger a habitat trap
2.2.2. Price Promotions. Similar to other desktop scenario. The heterogeneity of consumer preferences
and server software products, offering price promo- as well as of various devices found in the mobile
tions in the mobile app marketplaces is a well-known platform ecosystems further complicates any market-
strategy to target and acquire new users (Bala and driven forecasts about the complementing or substi-
Carr 2009, Lee and Raghu 2014, Liu et al. 2014). Often, tuting effects of diversification moves. In the presence
developers promoting newly launched apps are of such forecasting uncertainties, the diversification
tempted to react to competitors’ promotional actions moves of app publishers often follow a trial and error
by providing rebates on their paid apps for new users. approach. Market observers report that successful
However, such price promotions may also trigger a diversification expansions are an exception rather
price war, which has the potential to trap developers than the norm (e.g., Perez 2014).
in a vicious cycle. For example, in the presence of From a consumer’s point of view, alternatives to
abundant substitutes, potential new users could wait paid apps, whether functional variants or other similar
for a better promotional price rather than making an apps, tend to decrease potential users’ willingness to
immediate purchase. Furthermore, promotions trig- pay for the focal app (Hsu and Lin 2015), and those
gered by competitors’ actions could become a source competing apps have a negative impact on downloads
of buyers’ remorse for users who have already pur- of the app and its ranking in the marketplace. Thus,
chased the app at a higher price. Buyers with such the risks of diversification into functional variants and
remorse could leave negative review comments on similar apps are high for newly launched apps in the
digital platforms (Kumar et al. 2018, Wang et al. absence of precise data on demand uncertainties and
2019), which may further discourage potential new market segmentation. Similarly, a switch to multi-
users from adopting the app. Such negative user com- homing injects a host of uncertain scenarios for both
ments on app pricing may serve as anecdotal reasons users and developers including divergent experiences
that induce uncertain estimates about app quality and on devices belonging to different platforms, cross-plat-
reputation in the eyes of boundedly rational and form compatibility issues, and potentially distinct
price-sensitive customers (Ren et al. 2018), and requirements from the different platform markets.
thereby contribute to a weakened position for the app Overall, we posit that there are tangible risks asso-
among other competitors. Thus, unstable prices and/ ciated with diversification moves attempted by develo-
or price competitions would negatively affect the sur- pers; in the absence of precise market segmentation
vivability of an app in mobile platform ecosystems. data, there is a non-zero probability that the trial-and-
We hypothesize that prediction as the following: error actions taken to diversify the footprint of an app
could turn into traps for the publishers. We hypothe-
HYPOTHESIS 2. The greater the magnitude of price pro- size that prediction as the following:
motion of a paid app, the higher the probability of the app
encountering a habitat trap. HYPOTHESIS 3. The launch of a functional variant of a
paid app increases the probability of the app encountering
a habitat trap.
2.2.3. Diversification Moves. Developers of suc-
cessful apps might be tempted to expand and/or tap HYPOTHESIS 4. When a publisher releases any additional
further into their installed base by promoting func- apps that are similar to a focal paid app, the probability
tional variants or other new apps. Multi-homing of the focal app encountering a habitat trap increases.
(operating in multiple mobile platform ecosystems
with the same app) is another strategy to expand the HYPOTHESIS 5. When a paid app switches from single-
overall installed base of an app (Hyrynsalmi et al. homing to multi-homing, the probability of the app
2016). However, such diversification moves through encountering a habitat trap increases.
the launch of similar apps, functional variants, and
multi-homing create product variety and may have
either a complementing or a substituting effect on the
focal apps (Dogan et al. 2011, Ramdas 2003). If the
3. Data and Empirical Approach
new apps and app variants complement the original 3.1. Data Source
app, the app publisher might effectively segment the We collected lifecycle data on newly launched paid
market and serve each of the segments, thereby applications in the Apple and Google app stores
increasing the footprint among the overall installed through an independent app-analytics firm, Mobilewalla
(Datta et al. 2011, 2013, Mobilewalla 2018). Our data Figure 2 Data Collection Process
collection efforts began in May 2011 and continued
until November 2017. There are two types of data App stores and
Mobilewalla
available in the platform marketplaces (Apple App
and Google Play stores): (i) static data, such as app
Data Acquisition System
name, app description, developer name, etc., which
do not change much over time, and (ii) dynamic Input: Text stream containing
• Static information (e.g.,
data, such as user rating, rank, reviews, version, price,
app name, release date,
etc., that change regularly. Using tools provided developer) Data Filtering System
by Mobilewalla we gathered the dynamically chan- • Dynamic information (e.g.,
ging attributes of an app on a daily basis, which reviews, rating, version,
were stored in a proprietary database. We aggregated rank)
the dynamically changing data into weekly observa- Natural Language
tions (by averaging) and used it for our empirical Processing & Sentiment
Input: Text Analysis
analysis.
Tools: Text mining and
sentiment analysis
3.2. Data Aggregation and Preprocessing
Figure 2 depicts the information sources and the pro- Database
cessing steps involved in our data collection. All the Input: Derived variables
data fetched from Mobilewalla was in a normalized Method: Statistical analysis
relational schema form, and the details of the entity
relationships in the Mobilewalla database can be
found in published studies (Datta et al. 2011). We
integrated all of the separate database tables from subjective reviews represent signals of the perceived
Mobilewalla into a master database table for our ana- quality of apps and also indicate the extent to which
lysis. We started by integrating the static information users are engaged with the apps (O’Brien et al. 2008).
on newly launched apps with the dynamic data such We derived sentiments for the subjective reviews sub-
as the app rank and reviews. We aggregated review mitted by users using a sentiment analysis algorithm
and rank information of the apps on a weekly basis, called SentiStrength (Thelwall et al. 2010). Typically,
and we augmented this information with the other sentiment analysis applications predict only a positive
variables required for our empirical models. For or negative sentiment for a given customer-reported
example, we extracted review comments along with feedback and do not simultaneously identify emo-
the user-provided review scores and performed senti- tions with both positive and negative components or
ment analysis on the review comments. We used the discrete emotions such as happiness and surprise.
SentiStrength API (Application Programming Inter- Another challenge is that the end users frequently
face) for deriving sentiment scores of apps (Thelwall ignore the normal rules of grammar and spelling
et al. 2010). All data aggregation and pre-processing while interacting through electronic communication
were done through custom-written Java programs. media. Users also tend to use truncated sentences,
After preprocessing, we exported the integrated data abbreviations, and emoticons for online reviews
as a csv file and converted it into a Stataâ 15 readable (Grinter and Eldridge 2003, Thurlow and Brown
data format for further statistical analysis. To mini- 2003). Emoticons such as :-), :-)), D:, >:), and abbrevia-
mize censoring of an app’s lifecycle, we omitted apps tions like gr8 (great) and u (you) (Thurlow and Brown
for which we could not collect at least six months of 2003) are reasonably effective in conveying users’ sen-
lifecycle data. Overall, we gathered full lifecycle data timent in online review platforms. However, most of
for 30,842 paid Apple apps and 26,275 paid Android the sentiment analysis applications do not take into
apps for the observation period ending November account these types of emoticons and word abbrevia-
2017.2 tions, because typical linguistic sentiment analysis
programs start with part-of-speech tagging (e.g., Brill
3.3. Variable Descriptions 1992), which is contingent upon standard spelling
The variables in our dataset are described in Table 1, and grammar; for that reason, spelling and grammar
with an additional explanatory note on deriving senti- should be corrected before examining the corpus to
ment scores below. Summary statistics of the vari- derive sentiment scores.
ables are shown in Table 2. Addressing these issues with generic sentiment
Sentiment Scores: The app stores display user-gen- analysis applications, Thelwall et al. (2010) proposed
erated content including star ratings of apps and text a machine learning-based algorithm to detect the sen-
comments from app users. These user ratings and timent term weighting for non-standard spelling (e.g.,
Table 1 Variable Descriptions
Variables Description
App Age it At week t, the total number of weeks appi has been in the app store since its launch
Developer Experience it The total number of apps launched by the developer in the platform marketplace until week t
Installed Base it For appi, the total number of unique users who have provided reviews for the app since the launch of the app until
week t
The change in the installed base is then measured on a weekly basis as the difference in the number of unique
users who have provided reviews until week t and week (t 1)
Review Score it For appi, the average user rating scores registered in the platform marketplace at week t
Changes in review scores were tracked at weekly intervals (rating score at week t rating score at week (t 1))
App Price it At week t, the price of appi listed in the official platform marketplace
Competitor Apps Competitor apps are apps with similar functionality to a focal app but published by developers other than that of the
Similar Apps focal app. The similarity between two apps is determined by the Apache Lucene tool (Lucene 2005), which leverages
app names and app descriptions for deriving similarity scores. We used a predefined similarity threshold of >0.7 for
two apps to be considered as similar
If those two apps considered similar are developed by different developers, they are coded as competitor apps. If two
apps are developed by the same developers, they are coded as similar apps
Competitor Count it Total number of competitor apps for appi at week t
Competitor Installed Base it For appi, average installed base for all competitor apps in week t.
Changes in the installed base numbers were tracked on a weekly basis (count at week t count at week (t 1))
Competitor Review Score it For appi, the average user rating scores of all the identified competitor apps at week t
Changes in the scores were tracked on a weekly basis (average score at week t average score at week (t 1))
Competitor Price it For appi, the average price of competitor apps at week t
Changes in prices were tracked on a weekly basis (average price in week t average price at week (t 1))
App Updates it For appi, the total number of versions released until week t
Functional Variant it A dummy variable set to 1 if appi has device- or functionality-specific versions of the app at week t, 0 otherwise
Example: “Cut the Rope” and “Cut the Rope HD” are device-specific variants developed by the same developer
“ZEPTOLAB” for different Android devices with different screen resolutions
Competitor Functional Variant it Dummy variable set to 1 if any of the competitor apps for app i released a functional variant, and set to 0 otherwise
Price Promotion it At week t, the price discount offered for appi in the official platform marketplace
Customer Price Promotion it At week t, the average price discount offered for the identified competitor apps of the focal appi in the official platform
marketplace
Multi-homing Switch it Dummy variable, =1 if the focal appi has moved from operating in one platform (Apple or Google) to both the
platforms in week t, and set to 0 otherwise
luv, xox, lol, haha, muah) with emoticons and word propensity of developers to react to signals emanating
abbreviations. This algorithm is a hybrid approach from the platform ecosystems. We investigate the role
which considers both emotions and text when of installed-base changes, user reviews and visible
deriving sentiments. Further, it uses a dictionary of competitor actions acting as signals that prompt
sentiment words with associated measures and developers into action. To analyze the impact of these
exploits a range of recognized non-standard spel- signals, we use them to predict the probability of
lings and other common textual methods of developers enacting any of the five hypothesized
expressing sentiment. SentiStrength uses English actions: (i) offering app updates, (ii) launching price
text and an initial set of 2600 human-classified MyS- promotions, (iii) releasing paid functional variants,
pace comments to develop a machine learning algo- (iv) releasing other similar apps, and (v) launching
rithm for identifying specific sentiments embedded the app in other mobile platforms. This involved esti-
in user feedback. To process the user reviews of the mating a fixed-effects, longitudinal logistic regression
mobile apps in our dataset, we utilized the SentiS- model as shown in Equation (1).
trength algorithm, which helped us to classify the For a given time period t, yit is set to one when a
reviews into positive, negative, and neutral ones. developer of the focal app (i) engages in any of the
We used the average sentiment score in week t for above five actions, and zero otherwise. The vector of
an app as an alternative measure of capturing user coefficients estimated from the regression is for the
feedback in the empirical models. set of explanatory variables (xit) that we posit as the
observable signals in the mobile platform ecosystems.
3.4. Empirical Approach They are (i) change in the installed base, (ii) change in
We adopt a two-step analysis approach to examine a focal app’s user review score, (iii) change in the
the presence of habitat traps in mobile platform competitor count, (iv) change in the competitors’
ecosystems. In the first step, we examine the installed bases, (v) change in the competitors’ app
Table 2 Variables Summary not featured in the visible ranking zone of a platform
Variable Mean SD Min. Max.
store have very low download rates and usage. Since
our observation period was limited, the app data is
Google Platform
Installed Base 6.985 93.921 0.000 9823.000
right censored, and we use survival analysis for the
Review Score 2.113 2.192 0.000 5.000 second stage examination. In the app survival model,
Price 2.220 3.286 0.010 49.990 for appi, the hazard rate function hi(t) is given by the
Competitor App Count 3.036 3.746 0.000 10.000 following:
Average Installed Base of 0.504 1.102 0.000 30.000
Competitor Apps
hi ðtjXÞ ¼ h0 ðtÞexi b ; ð2Þ
Average Review Score of 0.519 1.028 0.000 5.000
Competitor Apps
Average Price of 0.281 2.222 0.000 49.99
where, hi(t|X) represents the hazard of mortality for
Competitor Apps the ith app, h0 ðtÞ is the baseline hazard function,
App Age 13.014 8.686 0.000 80.000 and xi is a vector of measured explanatory variables
Developer Experience 9.996 13.237 1.000 59.000 for appi, which include the five hypothesized devel-
App Updates 1.839 1.978 1.000 59.000 oper actions that can potentially turn into habitat
Similar Apps 0.415 1.522 0.000 44.000
traps for apps. b is the vector of coefficients to be
Price Reduction Offered 2.719 0.875 0.000 100.000
estimated using data that will be used to test the
Apple Platform five hypotheses presented in section 2. We treat app
Installed Base 17.168 174.758 0.000 9935.000
Review Score 1.021 1.792 0.000 5.000
mortality as a repetitive event in this study. All of
Price 3.033 4.920 0.120 49.990 the variables we consider are described in section 4.
Competitor App Count 4.307 4.227 0.000 10.000
Average Installed Base of 46.620 132.212 0.000 876.000
Competitor Apps 4. Analysis and Results
Average Review Score of 0.115 0.472 0.000 5.000
Competitor Apps 4.1. Ecosystem Signals
Average Price of Competitor Apps 0.177 1.653 0.000 49.99 The specification of the propensity-to-change model
App Age 12.393 9.631 0.000 80.000
Developer Experience 7.642 13.366 1.000 56.000
mentioned in Equation (1) is:
App Updates 1.523 1.151 1.000 20.000
Similar Apps 0.186 0.700 0.000 21.000 logitðpÞ ¼ ai þ b1 Installed Base Changeit
Price Reduction Offered 2.887 0.571 0.000 75.000 þ b2 Review Score Changeit
þ b3 Competitor Count Changeit
þ b4 Competitor Installed Base Changeit
review scores, (vi) change in prices of competitors’ þ b5 Competitor Review Score Changeit
apps, and (vii) competitors’ diversification moves. þ b6 Competitor Price Changeit
exit bþai þ b7 Competitor Functional Variant Introductionit
Pr yit 6¼ 0 ¼
1 þ exit bþai þ b8 App Ageit
for apps i ¼ 1; . . .; m and time periods t ¼ 1; . . .; n: þ b9 Developer Experienceit
ð1Þ ð1aÞ
In the second step, to identify the survival and visi- For each of the Apple and Google groups of
bility of an app in platform marketplaces, we leverage applications, we estimated Equation (1a) using the
a unique property of how mobile platforms rank apps Stataâ xtlogit function with fixed effects. Results of
in their stores. At the time of our data collection, the the estimations of Equation (1a) are presented in
Apple app store featured only 240 apps in each cate- Table 3 and Table 4 for the Google and Apple app
gory and ranked them in an ascending order (visible groups respectively. From Table 3, we see that in
range). Similarly, the Google app store featured only the Google platform ecosystem, an app publisher’s
the top 500 apps in each category. To rank their apps, probability of reacting increases with the changes
both stores deploy proprietary ranking algorithms in its app’s installed base, review scores, and com-
that include the cumulative downloads garnered by petitor count. Utilizing the reported odds ratio for
an app; the rank of an app is widely utilized as a easier interpretation, we see that odds of a devel-
proxy for downloads. An app’s success in the market- oper making a change to an app increase by about
place is sustainable only if it continues to stay in the 1.4% with the addition of a user to the installed
visible ranking zone (Garg and Telang 2013). We refer base of an app in the Google marketplace. Simi-
to any falling off from the visible ranking zone of a larly, when the review score of an app changes
marketplace as app mortality because apps that are (gains or losses rating stars), the odds of the app
publisher making a change to the app increase by log hi ðtÞ ¼a þ b1 App Ageit þ b2 Developer Experienceit
about 29%, and with every additional competitor þ b3 Competitor Countit þ b4 Review Scoreit
app, the chance of an app developer making a
þ b5 Installed Baseit þ b6 Application Priceit
change increases by about 39%. In addition, from
Table 3 we see that more experienced developers þ b7 App Updatesit þ b8 Price Promotionit
tend to have a higher propensity to react to ecosys- þ b9 Lauch of Functional Variantit
tem signals and that the propensity to enact a þ b10 Release of Similar Appit
change decreases with the application age.
þ b11 Multi-homing Switchit
The results are qualitatively similar for the Apple
apps although application age is not a significant pre- ð2aÞ
dictor of the propensity to enact a change in the Apple
Ecosystem. Table 4 shows that for the Apple apps, We considered three techniques for handling multi-
competitor count has the most influence in triggering ple failure (or repeated) events survival analysis: the
a change to an app, followed by review score changes. Andersen and Gill (1982) method, the Wei et al.
Each additional competitor app increases the chance (1989) method (WLW), and the Prentice et al. (1981)
of a change to an Apple app by about 32% and a method (PWP). The Anderson–Gill model assumes
change in the app’s star-rating (review score) that the ordered failures are of identical types; the
increases the odds of seeing an app change by about WLW model treats each failure event occurrence as
18%. an independent stratum and ignores the order of an
Overall, we find evidence for our proposition that event’s failures, and the PWP model is a conditional
the app publishers tend to observe the platform risk model, where the analysis is stratified by failure
ecosystem signals pertaining to their apps and enact order. Results were qualitatively similar irrespective
changes in response to those signals. Next, we con- of the choice of the modeling approach to handle
sider the impact of such reactions on the survival of repetitive events in the individual samples. We pre-
the apps. sent the estimations of the Anderson–Gill model in
the following sections and use it for testing our
4.2. Evidence for Platform Traps hypotheses.
In the second step of our analysis, we examined We took necessary precautions to ensure the
whether the following five reactions of developers in robustness of our estimations. Studies with extremely
response to the platform ecosystem signals constitute large sample sizes need to be cautious with the statis-
a habitat trap: (i) offering app updates, (ii) launching tical inference because the p-values associated with
price promotions, (iii) releasing paid functional vari- coefficient estimates become very small as the number
ants, (iv) releasing other similar apps, and (v) switch- of observations increases. We follow the recommen-
ing the app to multi-home in another mobile platform dations provided by prior research for taking ade-
ecosystem. We estimated Equation (2) by taking into quate precautions when dealing with large datasets
account repeated failures, accounting for the possibil- (Lin et al. 2013). We have reported robust standard
ity that an app may drop out of the visible ranking errors along with the confidence intervals for our esti-
zone, only to reemerge in the rankings later. The spec- mates, interpreted the economic significance of the
ification of the model outlined in Equation (2) is as results, and verified the robustness of the coefficient
follows: estimates by studying the variance in estimates
Table 3 Propensity to React to Ecosystem Signals—Google Apps
Standard error 95% confidence interval of

Coefficient Odds ratio of coefficient coefficient
Installed Base Change 0.014*** 1.014 0.003 0.008 0.020
Review Score Change† 0.258*** 1.294 0.035 0.189 0.327
Competitor Count Change 0.327*** 1.387 0.087 0.156 0.498
Competitor Installed Base Change 0.010 1.010 0.027 0.042 0.063
Competitor Review Score Change† 0.072 1.075 0.090 0.104 0.249
Competitor Price Change 0.034 1.034 0.048 0.061 0.129
Competitor Introduction of 0.161 1.174 0.200 0.230 0.552
Functional Variant
App Age 0.824*** 0.438 0.032 0.888 0.761
Developer Experience 1.091*** 2.977 0.319 0.465 1.716
Number of Apps = 26,275; Log Likelihood = 6558.966; LR Chi-Squared = 999.94***
Notes: ***p < 0.01; **p < 0.05; *p < 0.1; †Use of sentiment scores of reviews in lieu of the review scores yields similar results.
Table 4 Propensity to React to Ecosystem Signals—Apple Apps
95% confidence interval of

Coefficient Odds ratio Standard error of coefficient coefficient
Installed Base Change 0.365 9 103** 1.0004 0.156 9 103 0.594 9 103 0.671 9 103
†
Review Score Change 0.164*** 1.179 0.024 0.117 0.212
Competitor Count Change 0.278** 1.320 0.132 0.0189 0.537
Competitor Installed Base Change 0.576 9 103 0.999 0.877 9 103 0.002 0.001
Competitor Review Score Change† 0.140 1.150 0.165 0.183 0.463
Competitor Price Change 0.320 0.726 0.204 0.720 0.080
Competitor Introduction of Functional Variant 0.284 1.328 0.275 0.257 0.824
App Age 0.054 1.056 0.033 0.011 0.119
Developer Experience 1.248* 3.485 0.752 0.226 2.723
Number of Apps = 30,842; Log Likelihood = 5015.295; LR Chi-Squared = 68.80***
through Coefficient/P-value/Sample-size (CPS) interoperability between apps and losing backward

charts. Results reported in Table 5 are for the apps in compatibility with older generation devices. Although
the Google platform, and Table 6 presents results for we are not able to find evidence for the presence of
the apps collected from the Apple platform. those risks in the current sample of apps, we note
Hypothesis 1 posited that a higher frequency of that our sample primarily included newly launched,
app updates could trigger a habitat trap. From the paid apps. Given that other studies have reported
results presented in Table 5 for the Google platform, that consumers provide lower review scores for apps
we see that the coefficient estimate for AppUpdates is after receiving app updates (Foerderer and Heinzl
negative (0.043) and statistically significant with a 2017), future research must look specifically into
p-value of <0.01. The corresponding hazard ratio is long-lived applications that span multiple genera-
0.958, indicating that a unit increase in the fre- tions of devices. Those applications may pose more
quency of updates reduces the chance of the app’s complex needs for ensuring backward compatibility
mortality by about 4%. Referring to Table 6 for the and should be examined before generalizing our
Apple platform, we see similar results for finding that a higher frequency of app updates is
AppUpdates. A unit increase in the frequency of helpful for app survival.
updates of an Apple app reduces the chance of its In Hypothesis 2, we proposed that a greater magni-
mortality by about 5%. Thus, we find that a higher tude of price promotion offered on a paid app may
frequency of app updates is helpful for app survival trigger a habitat trap. Referring to the regression esti-
in both the Google and Apple platforms. Therefore, mates of Price Promotion in Table 5 for the Google
we could not find evidence supporting Hypothesis 1 platform, we see that the coefficient is not statistically
and conclude that increasing the frequency of app significant (p > 0.1) and the confidence interval of the
updates is not associated with triggering a habitat estimate includes a zero. However, for the Apple apps
trap. In positing Hypothesis 1, we had argued that a the estimates for Price Promotion are statistically sig-
higher frequency of updates risks breaking the nificant at the 5% level. The coefficient estimates
Table 5 Traps in the Google Platform
95% confidence interval of

Coefficient Hazard ratio Robust standard error of coefficient coefficient
Application Age 1.578*** 0.206 0.018 1.614 1.543
Competitor Count 0.0229*** 1.023 0.003 0.017 0.029
Review Score† 0.353*** 0.703 0.048 0.445 0.260
Installed Base 0.001*** 0.999 0.432 9 103 0.002 0.349 9 103
Application Price 0.007*** 1.007 0.945 9 103 0.005 0.009
App Updates 0.043*** 0.958 0.010 0.062 0.023
Price Promotion 0.955 9 103 1.001 0.001 0.002 0.004
Launch of Functional Variant 0.118** 1.125 0.049 0.022 0.213
Release of Similar Application 0.012** 1.012 0.005 0.003 0.021
Multi-homing Switch 0.432*** 1.540 0.133 0.171 0.693
Number of Apps = 26,275; Number of Observations = 398,919; Log Likelihood = 117,787.75; Wald Chi-Squared = 10,310.38***
Table 6 Traps in the Apple Platform
Robust standard error 95% confidence interval of

Coefficient Hazard ratio of coefficient coefficient
Application Age 0.391*** 0.676 0.001 0.394 0.388
Competitor Count 0.004*** 1.004 0.042 9 103 0.004 0.004
Review Score† 0.112*** 0.894 0.006 0.124 0.100
Installed Base 0.001*** 0.999 0.061 9 103 0.001 0.001
Application Price 0.001*** 1.001 0.081 9 103 0.390 9 103 0.001
App Updates 0.053*** 0.948 0.002 0.057 0.049
Price Promotion 0.002** 1.002 0.972 9 103 0.337 9 103 0.004
Launch of Functional Variant 0.081*** 0.922 0.015 0.112 0.051
Release of Similar Application 0.031*** 1.032 0.002 0.028 0.035
Multi-homing Switch 0.202*** 1.224 0.068 0.069 0.335
Number of Apps = 30,842; Number of Observations = 687,824; Log Likelihood = 5,182,723.90; Wald Chi-Squared = 96,017.76***
indicate that for every 10% discount offered on paid focuses on “architectural control” (Schultz et al. 2011,
Apple apps, the chance of app mortality increases by Tilson et al. 2012). Due to the lower barriers to entry
2%. Despite that small, negative impact, the result in the Android platform, the number of functional
shows the possible risk of price promotions offered variants and substitutes for an app are much larger
on paid apps in the Apple platform, which developers than in the Apple platform. In such a scenario, if an
need to weigh against purported benefits of price app is not doing well in the Android platform, releas-
promotions. ing additional functional variants would be a subopti-
Hypothesis 3 presented the possibility that the mal choice. In contrast, in the Apple platform device-
launch of a functional variant of a paid app would specific functional variants that have been subjected
trigger a habitat trap for the app. Results presented in to a rigorous review process may be seen as satisfying
Table 5 and Table 6 show contrasting findings for the niche requirements of users. Thus, as our results indi-
Google and Apple ecosystems. In the Google plat- cate, functional variants have a substitutive effect on
form, we find strong evidence for Hypothesis 3. When paid apps in the Android platform whereas they play
a developer launches a functional variant of an app in a complementing role to the paid apps in the Apple
the Google platform, the chance of mortality of the platform. This contrasting effect across the Google
focal app increases by 12.5% (hazard ratio = 1.125 and Apple platforms further reveals the challenges
with p < 0.05 for Launch of Functional Variant in faced by developers who aim to implement a multi-
Table 5). In contrast, in the Apple platform, the homing strategy, which we discuss later.
launch of a functional variant of an app reduces the Hypothesis 4 predicted that the launch of similar
chances of mortality of the focal app. Referring to apps would turn out to be a habitat trap. The results
Table 6, the coefficient estimate for Launch of Func- confirm this prediction and show that the launch of a
tional Variant is negative and statistically significant at similar app increases the probability of app mortality
<1%. The corresponding hazard ratio is 0.922, which by about 3% in the Apple platform and by about 1%
indicates that there is a decrease in the probability of in the Google platform. Although the direct risk of
the focal app’s mortality by about 8%. Thus, we see app mortality associated with the launch of similar
that the launch of a functional variant poses the risk apps seems small in magnitude, developers should
of a habitat trap in the Google platform, but it could carefully assess that risk against any potential bene-
potentially be helpful for app sustainability in the fits. Furthermore, there might be other indirect repu-
Apple platform. tational effects on the developer’s brand if customers
This contrasting effect of launching functional vari- perceive the strategy of launching similar apps as a
ants across the platforms could be attributed to ploy to fragment incremental functionality into differ-
idiosyncratic differences in app review processes and ent paid apps. We note that the empirical models in
customer preferences between the Apple and Google this study do not capture such indirect detrimental
platforms (Butler 2011, Reinfelder et al. 2014). While effects.
the Apple platform largely enforces control on devel- Finally, Hypothesis 5 posited that a switch from
opers through a “gated garden” approach that is operating in one platform to multiple platforms could
focused on stringent review processes and propri- potentially be a trap for developers. Results presented
etary standards, the Android platform has embraced in Tables 5 and 6 show strong support for Hypothesis
open standards and a flexible review process that 5. The coefficient estimates for Multihoming Switch in
both the Google and Apple sample are positive and literature and complement recent studies on under-
statistically significant at less than 1%. For the Google standing the antecedents and consequences of devel-
apps, we see that the switch to multi-homing oper strategies in platform ecosystems (e.g., Lee and
increases the chance of app mortality by 54%. Simi- Raghu 2014, Liu et al. 2014). The study highlights that
larly, for the Apple apps the chance of app mortality the presence of habitat traps in the operating environ-
due to a multi-homing switch increases by 22%. The ments of real-word digital platforms makes it chal-
detrimental effect of a multi-homing switch on app lenging for developers to derive and adhere to
survival in the focal platform is shown in Figure 3 optimal policies regarding feature enhancements,
using the Google apps data and holding all other pre- product variants, and pricing. A key implication that
dictors at their mean level. This shows that the risk of stems from the presence of habitat traps in platform
a habitat trap for an app is high in the focal platform ecosystems is that the long-term payoff from devel-
when a developer switches from a focused operation oper strategies, such as price promotions and diversi-
in the platform to a multi-homing approach. fication, may not necessarily be positive. Although
prior research has mostly focused on the beneficial
impacts of agile developer strategies, the findings of
5. Discussion this study highlight the risks and trade-offs of mar-
In this study, drawing inspiration from the ecology, ket-driven developer reactions that negatively impact
software production and operations, and digital plat- the long-run sustainability of apps in mobile platform
forms literatures, we hypothesized that some market- ecosystems. Given the beneficial effects of price pro-
induced developer actions in mobile platform ecosys- motions and developer diversification moves docu-
tems can turn into habitat traps for their apps. We col- mented in prior research and the risks highlighted in
lected and analyzed a large sample of data related to this study, a natural next step is to unearth the specific
newly launched paid apps in the Apple and Google conditions under which the benefits may outweigh
platforms and examined the presence of habitat traps the risks. We speculate that such an examination of
in those platforms. Results indicate that the risk of the dynamics of the trade-offs impacting app success
habitat traps does exist in mobile platform ecosys- in platform ecosystems would involve gathering life-
tems, and developers must carefully assess the risks cycle data that spans longer horizons as well as
associated with offering price promotions, launching expanding the analysis to the consideration of a port-
functional variants, and switching to multi-homing folio of apps offered by a developer.
operations. In this section, we build on the results to Expanding the analysis to a portfolio of apps
develop recommendations for developer operations owned by a publishing house would help developers
and discuss the implications of the presence of plat- and publishers understand potential higher-order
form traps for theories on digital ecosystems. effects of branding and other promotional activities.
Such publishing house- and portfolio-level events
5.1. Implications for Research could warrant further investigation into the competi-
Through this study, we introduce the idea of habitat tive dynamics in mobile platform ecosystems. Also, in
traps to the software production and operations this study, we did not capture cross linkages between
apps beyond identifying functional similarity and
variations among them. Apps could exist as a “fam-
Figure 3 Multi-Homing Switch as a Potential Habitat Trap [Color fig- ily,” where a collective functionality from an end user
ure can be viewed at wileyonlinelibrary.com] perspective emerges from more than one app. Similar
to product families, such app families might depict
different sustainability patterns, the study of which
requires different metrics and modeling approaches
(Krishnan et al. 1999, Meyer et al. 1997). Moreover, in
this study we did not consider sustainability of multi-
homing apps jointly across the platforms due to data
limitations. Modeling the cross- or joint-habitat
survivability of apps across the platforms in which
they operate would help assess the success of devel-
opers’ app portfolios across all the platforms that
they engage with. We believe that addressing these
limitations of this study and exploring the dynam-
ics of app sustainability by adopting a product
portfolio perspective are fruitful avenues for future
investigations.
5.2. Implications for Practice account for the substitutive effects of their own simi-
To succeed in the mobile platform ecosystems, app lar applications and functional variants and better
developers need to be agile and responsive to the mar- plan for obsolescence of the focal apps, especially
ketplace. The increasingly easy availability of business when the installed base does not have a strong prefer-
analytics tools to gather and examine marketplace data ence for durability of the apps.
has aided app developers in swiftly launching their
Notes
responses to user feedback and competitor actions. In
1
this context, market-induced developer actions such as Although our focal apps are in the paid category, we do
offering price promotions, launching functional vari- consider all free apps in deriving the sets of competitor
ants, and diversifying into alternate platform ecosys- and similar apps for each of the focal paid apps.
2
tems seemingly appear to be rational and beneficial The Apple iTunes app store was redesigned in June 2017.
actions. Yet our results indicate that there are real risks However, this change does not affect our sample because
we study apps that have at least six months of lifecycle
associated with those market-induced actions. We find
data prior to June 2017. None of the Apple platform apps
that the biggest risk for app survival is associated with that we study encountered mortality-related events after
a switch to a multi-homing operation, wherein a devel- June 2017 and before the end of the observation period.
oper must tackle the idiosyncratic requirements of mul-
tiple platform ecosystems. There seems to be a trade- References
off between garnering a bigger installed base across Andersen, P. K., R. D. Gill. 1982. Cox’s regression model for
multiple platforms and ensuring that the app survives counting processes: A large sample study. Ann. Stat. 10(4):
the competition in those platforms. Also, there is 1100–1120.
heterogeneity in the factors that help app survival App Annie. 2018. Confidently navigate the entire app lifecycle
among the Google and Apple platforms that we stud- with App Annie Intelligence. Available at https://www.appa
nnie.com/en/platform/intelligence/ (accessed date June 28,
ied. For example, while the launch of functional vari- 2018).
ants is beneficial in the Apple platform, it is Bala, R., S. Carr. 2009. Pricing software upgrades: The role of pro-
detrimental to app survival in the Google platform. duct improvement and user costs. Prod. Oper. Manag. 18(5):
Such differences between the platforms add to the com- 560–580.
plexity of the trade-offs faced by developers aiming for Battin, J. 2004. When good animals love bad habitats: Ecological
traps and the conservation of animal populations. Conserv.
a multi-homing strategy.
Biol. 18(6): 1482–1491.
We recommend three approaches to tackle the
Brill, E. 1992. A simple rule-based part of speech tagger. M. Bates,
potential habitat traps in the mobile platform ecosys- O. Stock, eds. Proceedings of the third conference on Applied
tems. First, developers need to recognize the forecast- Natural Language Processing. Association for Computational
ing uncertainties and margin of errors involved in Linguistics, Stroudsburg, PA, 152–155.
aggregate marketplace data. Rather than relying on Butler, M. 2011. Android: Changing the mobile landscape. IEEE
Pervasive Comput. 10(1): 4–7.
such aggregate, platform-level data for planning their
Chen, Y., A. J. Vakharia, A. Alptekinoglu. 2008. Product portfolio
actions, we recommend that app developers invest in strategies: The case of multifunction products. Prod. Oper.
incorporating design elements that gather direct user Manag. 17(6): 587–598.
feedback through the apps. Such fine-grained user Cheney, S., E. Thompson. 2018. The 2017–2022 App economy
feedback can be used to better understand the market forecast: 6 billion devices, $157 billion in spend & more.
segments specific to the apps and the idiosyncratic Available at https://www.appannie.com/en/insights/marke
t-data/app-annie-2017-2022-forecast/ (accessed date June 20,
requirements of the installed base. It could be benefi- 2018).
cial to the entire ecosystem if platform sponsors, such Cornelissen, J. P. 2005. Beyond compare: Metaphor in organiza-
as Google and Apple, provide additional APIs and tional theory. Acad. Manag. Rev. 30(4): 751–764.
analytical tools to facilitate such finer-grained data Datta, A., K. Dutta, S. Kajanan, N. Pervin. 2011. Mobilewalla: A
collection for app publishers. Since such analytical mobile application search engine. J. Y. Zhang, J. Wilkiewicz,
tools may mitigate unnecessary churn in the apps, the A. Nahapetian, eds. International Conference on Mobile Comput-
ing, Applications, and Services. Springer, Berlin, Heidelberg,
stability of the entire ecosystems might improve as a 172–187.
result. Second, the risks associated with multi-homing Datta, A., S. Kajanan, N. Pervin. 2013. A mobile app search
can be potentially mitigated if developers take steps engine. Mobile Netw. Appl. 18(1): 42–59.
towards achieving sufficient lock-in and/or cross- Dawande, M., S. Kumar, V. S. Mookerjee, C. Sriskandarajah. 2008.
platform awareness among users before switching Maximum commonality problems: Applications and analysis.
their operations. Moreover, developers could mini- Management Sci. 54(1): 194–207.
mize the burden of addressing diverse user requests Dogan, K., Y. Ji, V. S. Mookerjee, S. Radhakrishnan. 2011. Manag-
ing the versions of a software product under variable and
and expectations by designing for a uniform user endogenous demand. Inf. Syst. Res. 22(1): 5–21.
experience across the different platforms in which the Foerderer, J., A. Heinzl. 2017. Product updates: Attracting new
app operates. Finally, developers need to specifically consumers versus alienating existing consumers. Proceedings
of 2017 International Conference on Information Systems, AIS Mehra, A., R. L. Saha. 2018. Utilizing public betas and free
Electronic Library, available at https://aisel.aisnet.org/icis2017/ trials to launch a software product. Prod. Oper. Manag. 27(11):
EBusiness/Presentations/2/ (accessed date December 10, 2018). 2025–2037.
Garg, R., R. Telang. 2013. Inferring app demand from publicly Mehra, A., A. Seidmann, P. Mojumder. 2014. Product life-cycle man-
available data. MIS Q. 37(4): 1253–1264. agement of packaged software. Prod. Oper. Manag. 23(3): 366–378.
Grinter, R., M. Eldridge. 2003. Wan2tlk?: Everyday text messag- Meyer, M. H., P. Tertzakian, J. M. Utterback. 1997. Metrics for
ing. G. Cockton, P. Korhonen, eds. Proceedings of the SIGCHI managing research and development in the context of the
Conference on Human Factors in Computing Systems. ACM, New product family. Management Sci. 43(1): 88–111.
York, NY, 441–448. Mobilewalla. 2018. Why consumer intelligence needs to be a part
Haselmayr, M. 2015. 65 simple ways to promote your mobile app. of every marketing strategy. https://www.mobilewalla.com/
Forbes Magazine. Available at https://www.forbes.com/sites/ (accessed date June 20, 2019).
allbusiness/2015/11/07/65-simple-ways-to-promote-your-mobile- Mookerjee, V. S., I. R. Chiang. 2002. A dynamic coordination pol-
app/#137932c248c4 (accessed date June 29, 2018). icy for software system construction. IEEE Trans. Software
Hsu, C.-L., J. C. Lin. 2015. What drives purchase intention for Eng. 28(7): 684–694.
paid mobile apps? An expectation confirmation model with O’Brien, H. L., E. G. Toms, E. K. Kelloway, E. Kelley. 2008. Devel-
perceived value. Electron. Commer. Res. Appl. 14(1): 46–57. oping and evaluating a reliable measure of user engagement.
Hyrynsalmi, S., A. Suominen, M. Mantymaki. 2016. The influence Proc. Am. Soc. Inf. Sci. Technol. 45(1): 1–10.
of developer multi-homing on competition between software Perez, S. 2014. The majority of today’s app businesses are not
ecosystems. J. Syst. Softw. 111(1): 119–127. sustainable. Available at https://techcrunch.com/2014/07/
Ji, Y., S. Kumar, V. S. Mookerjee, S. P. Sethi, D. Yeh. 2011. Opti- 21/the-majority-of-todays-app-businesses-are-not-sustainable/
mal enhancement and lifetime of software systems: A control (accessed date June 20, 2019).
theoretic analysis. Prod. Oper. Manag. 20(6): 889–904. Prentice, R. L., B. J. Williams, A. V. Peterson. 1981. On the regres-
Katemats. 2012. 20 things every iOS and mobile dev should con- sion analysis of multivariate failure time data. Biometrika 68
sider in their app promotion strategy. Available at http://ka (2): 373–379.
temats.com/20-things-every-ios-and-mobile-dev-should-con Rahmani, M., G. Roles, U. S. Karmarkar. 2017. Collaborative work
sider-in-their-app-promotion-strategy/ (accessed date June 29, dynamics in projects with co-production. Prod. Oper. Manag.
2018). 26(4): 686–703.
Ketokivi, M., S. Mantere, J. Cornelissen. 2017. Reasoning by analogy Ramdas, K. 2003. Managing product variety: An integrative review
and the progress of theory. Acad. Manag. Rev. 42(4): 637–658. and research directions. Prod. Oper. Manag. 12(1): 79–101.
Kokko, H., W. J. Sutherland. 2001. Ecological traps in changing Reinfelder, L., Z. Benenson, F. Gassmann. 2014. Differences
environments: Ecological and evolutionary consequences of a between Android and iPhone users in their security and pri-
behaviourally mediated Allee effect. Evol. Ecol. Res. 3(5): vacy awareness. C. Eckert, S. K. Katsikas, G. Pernul, eds.
603–610. Trust, Privacy, and Security in Digital Business. Lecture Notes
Koushik, M. V., V. S. Mookerjee. 1995. Modeling coordination in in Computer Science (8647). Springer, Cham, 156–167.
software construction: An analytical approach. Inf. Syst. Res. 6 Ren, H., T. Huang, K. Arifoglu. 2018. Managing service systems
(3): 220–254. with unknown quality and consumer anecdotal reasoning.
Krishnan, V., R. Singh, D. Tirupati. 1999. A model-based Prod. Oper. Manag. 27(6): 1038–1051.
approach for planning and developing a family of technol- Robertson, B. A., R. L. Hutto. 2006. A framework for understand-
ogy-based products. Manuf. Serv. Oper. Manag. 1(2): 132–156. ing ecological traps and an evaluation of existing evidence.
Kulkarni, V. G., S. Kumar, V. S. Mookerjee, S. P. Sethi. 2009. Opti- Ecology 87(5): 1075–1085.
mal allocation of effort to software maintenance: A queuing Schlaepfer, M. A., M. C. Runge, P. W. Sherman. 2002. Ecological
theory approach. Prod. Oper. Manag. 18(5): 506–515. and evolutionary traps. Trends Ecol. Evol. 17(10): 474–480.
Kumar, N., L. Qiu, S. Kumar. 2018. Exit, voice, and response on Schultz, N., J. Wulf, R. Zarnekow, Q. T. Nguyen. 2011. The new
digital platforms: An empirical investigation of online man- role of developers in the mobile ecosystem: An Apple and
agement response strategies. Inf. Syst. Res. 29(4): 849–870. Google case study. R. Minerva, ed. Proceedings of the 15th
Lee, G., T. S. Raghu. 2014. Determinants of mobile apps’ success: International Conference on Intelligence in Next Generation
Evidence from the App Store market. J. Manage. Inf. Syst. 31 Networks. IEEE, New York, NY, 103–108.
(2): 133–170. Staats, B. R., D. J. Brunner, D. M. Upton. 2011. Lean principles,
Levin, R., M. Iansiti. 2004. The Keystone Advantage: What the New learning, and knowledge work: Evidence from a software
Dynamics of Business Ecosystems Mean for Strategy, Innovation, services provider. J. Oper. Manag. 29(5): 376–390.
and Sustainability. Harvard Business Review Press, Boston. Statista. 2018. Number of mobile phone users worldwide from
Lin, M., H. C. Lucas, G. Shmueli. 2013. Too big to fail: Large sam- 2015 to 2020 (in billions). Available at https://www.statista.
ples and the p-value problem. Inf. Syst. Res. 24(4): S906–917. com/statistics/274774/forecast-of-mobile-phone-users-world
Liu, D., M. Dawande, V. S. Mookerjee. 2007. Value-driven creation wide/ (accessed date June 20, 2019).
of functionality in software projects: Optimal sequencing and Thelwall, M., K. Buckley, G. Paltoglou, D. Cai, A. Kappas. 2010.
reuse. Prod. Oper. Manag. 16(3): 381–399. Sentiment strength detection in short informal text. J. Am. Soc.
Liu, C. Z., Y. A. Au, H. S. Choi. 2014. Effects of freemium strategy Inform. Sci. Technol. 61(12): 2544–2558.
in the mobile app market: An empirical study of Google Play. Thurlow, C., A. Brown. 2003. Generation txt? The sociolinguistics
J. Manage. Inf. Syst. 31(3): 326–354. of young people’s text-messaging. Discourse Anal. Online 1(1):
Lucene, A. 2005. A high-performance, full-featured text search 1–27.
engine library. Available at http://lucene.apache.org (ac- Tilson, D., C. Sorensen, K. Lyytinen. 2012. Change and control
cessed date June 20, 2019). paradoxes in mobile infrastructure innovation: The Android
Mannan, R. W., R. J. Steidl, C. W. Boal. 2008. Identifying habitat and iOS mobile operating systems cases. R. H. Sprague Jr.,
sinks: A case study of Copper’s hawks in an urban environ- ed. Proceedings of the 45th Hawaii International Conference on
ment. Urban Ecosyst. 11(2): 141–148. System Sciences. IEEE, New York, NY, 1324–1333.
Wang, Y., P. Goes, Z. Wei, D. Zeng. 2019. Production of online Xue, L., P. Song, A. Rai, C. Zhang, X. Zhao. 2019. Implications
word-of-mouth: Peer effects and the moderation of user char- of application programming interfaces for third-party new
acteristics. Prod. Oper. Manag 28(7): 1621–1640. app development and copycatting. Prod. Oper. Manag. Early
Wei, L. J., D. Y. Lin, L. Weissfeld. 1989. Regression analysis of view. https://doi.org/10.1111/poms.13021
multivariate incomplete failure time data by modeling mar- Zhong, N., F. Michahelles. 2013. Google Play is not a long tail
ginal distributions. J. Am. Stat. Assoc. 84(408): 1065–1073. market: An empirical analysis of app adoption on the
Xia, H., M. Dawande, V. S. Mookerjee. 2016. Optimal coordination Google Play app market. D. Shin, ed. Proceedings of the
in distributed software development. Prod. Oper. Manag. 25(1): 28th Annual ACM Symposium on Applied Computing. ACM,
56–76. New York, NY, 499–504.

App 2

Uploaded by

Copyright:

Available Formats

App 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

App 2

Uploaded by

Copyright:

Available Formats

Vol. 28, No. 10, October 2019, pp. 2594–2608 DOI 10.1111/poms.

Habitat Traps in Mobile Platform Ecosystems

Key words: digital ecosystems; mobile platforms; platform traps; survival

mobile apps, only a few are successful in gaining con-

Table 1 Variable Descriptions

Table 3 Propensity to React to Ecosystem Signals—Google Apps

Standard error 95% confidence interval of

Table 4 Propensity to React to Ecosystem Signals—Apple Apps

95% confidence interval of

through Coefficient/P-value/Sample-size (CPS) interoperability between apps and losing backward

Table 5 Traps in the Google Platform

95% confidence interval of

Table 6 Traps in the Apple Platform

Robust standard error 95% confidence interval of

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.