A new study from the US Government’s National Institutes of Health helps explain one aspect of the benefits that exercise provides to the brain. The study reported that skeletal muscle cells secrete a protein, Cathepsin B, in higher quantities for people who exercised regularly on a treadmill.

Researchers reported that an increase in blood Cathepsin B levels corresponded to an improved performance in visual memory tests for humans and that it also resulted in improved performance for mice in spatial memory and maze navigational skills.

Exercise resulted in increased muscle production of Cathepsin B and increased secretion of this protein into the bloodstream and researchers also used mice to verifiy that this protein was able to cross the blood-brain barrier and thereby influence the brain. In other studies, elevated levels of Cathepsin B have been observed in some ailing people (e.g. cancel patients), however, it is unclear whether the elevated levels were due to the body’s attempt to combat the ailment or whether it was due to other reasons.

The recent studies demonstrate that exercise leads to increased levels of Cathepsin B and that this is directly linked to improved brain performance for healthy people. It isn’t easy to figure out every detail about the brain, but this study on exercise, Cathepsin B and the brain helps improve our understanding on how the brain benefits from exercise.

However, a new study looked at a related topic – preventing weight gain. This study compared three groups of obesity-prone rats. The control group was sedentary. The second group of rats exercised regularly in running wheels. The third group of rats was sedentary and on a calorie-restricted diet. All three groups ate the same kibbles though daily servings for the calorie-restricted group were 20% less than that for the group of runners.

Unsurprisingly, the control group turned out to be obese at the end of the study. The other two groups staved off obesity. However, the runners were metabolically healthier in terms of insulin sensitivity, cholesterol, burning more fat and they also seemed to have more metabolic activity within their brown fat. Interestingly, gut microbes in the runners were different from gut microbes in the calorie-restricted group, so exercise had a probiotic effect even though all groups had been fed the same kibbles.

This study suggests that exercise alone can deliver results that are far superior to dieting alone – at least for rats trying to avoid obesity. It seems reasonable to assume that this would be true for humans too, though it is obviously important to focus on both exercise and calorie intake while eating healthy food.

Interestingly, the study doesn’t limit benefits to dark chocolate and that suggests that eating regular chocolate  (e.g. milk chocolate which accounts for around 85% chocolate sales in the US) might also help the brain. However, I’ve headlined this post with “dark” chocolate because it seems more likely (from a lot of other research) that cocoa flavanols found in dark chocolate are responsible for improved brain function.

The left side of the brain stays alert when sleeping in an unfamiliar place for the first night. Researchers found that playing irregular beeping sounds into the right ear (thereby stimulating the left hemisphere) is much more likely to wake up a person than playing the same sounds into the left ear (and stimulating the right hemisphere).

This has been described as a first-night-only phenomenon because it only happens when a person is sleeping in a new place for the first time. Presumably, this behavior of the brain is an evolutionary adaptation that happened in an ancient time when humans sleeping in a new place were at risk of being attacked by predators and needed to be on alert.

Walking is tied to a number of  health benefits and should (almost) always be encouraged. That is why we created a pedometer app to track steps. However, anecdotally, many of us would agree that walking in a natural environment is generally a more pleasant experience than other walking. From my own experience in walking in cities and towns across four continents and natural environments across five continents, I can relate to Henry David Thoreau who said “I think that I cannot preserve my health and spirits, unless I spend four hours a day at least – and it is commonly more than that – sauntering through the woods and over the hills and fields,  absolutely free from all worldly engagements.” even though I myself don’t walk four hours a day in any environment, let alone walk in nature for four hours.

Given anecdotal experience with walking in nature, it is interesting to see that medical science can now use data to explain the neurological mechanisms of how walking in nature helps the brain. A Stanford study establishes that cerebral blood flow and neural activity in the subgenual prefrontal cortex (sgPFC) is decreased for nature walkers and not for urban walkers. Self-reporting from the walkers also showed that nature walkers ruminated less. I first heard about this study from a column that explains the Stanford study for a wider audience

The sgPFC (or Brodmann Area 25, BA25) plays a major role in depression and decreased neural activity in this area can help prevent depression and combat stress. Since walking in nature helps the brain (specifically the BA25 region) and decreased rumination/brooding helps reduce stress, the results of the Stanford study strongly suggest that walking in nature can change the brain in ways that help mental health, improve mood and reduce the chances of depression.

Clearly, walking in nature is not a viable option for all people in all circumstances. Health conditions, weather conditions or concerns about some wild animals, criminal humans etc. may dissuade some people from walking in nature. However, for those who enjoy walking in nature and for those who’d like to consider it, studies seem to establish that walking in nature can impact the subgenual prefrontal cortex in ways that are good for the brain.

With that in mind, let us consider two of the five WatchKit performance tips recommended by Apple. The last part of Knuth’s quote is also relevant to both of these tips, but I’ll defer that discussion to the end of this post.

Update only what has changed: Apple’s first performance tip stipulates that “A well-performing WatchKit app requires minimal traffic between iPhone and Apple Watch.” Apple continues with a second tip that says “Update only what has changed”. This essentially means that values on user interface objects (such as the text shown on an Apple Watch app screen through a WKInterfaceLabel object) must only be updated if the value changes. For example, if a hypothetical DadBod watch app set the text of a label called LabelCaloriesConsumed to “Calories: 2100/2400”, the app shouldn’t attempt to set the label value again until the user consumed more calories and increased their consumption count to something more than 2100.

Dangers of worrying about performance: For many programmers, “Update only what has changed” might seem like common-sense and Apple’s stipulation is likely to nudge more developers to implement the “update only what has changed” guideline. This will minimize traffic between the iPhone and Apple Watch. However, many developers reading Apple’s performance tips may not be aware of other WatchKit technical facts and that can make Apple’s performance tip a risky proposition. To quote Spock, “Insufficient facts always invite danger”

Naïve Programmer-X ignores performance tip: One archetypal naïve developer might ignore this performance tip and repeatedly set the label value to “Calories: 2100/2400” repeatedly. This would result in a slightly adverse performance impact, but on the plus side, the app will function correctly from a user perspective.

Well-intentioned Naïve Programmer-Y implements performance tip: An archetypal well-intentioned, but naïve developer might implement the “Update only what has changed” performance tip without caution. One popular blog post suggests a “View Model” approach and replacing traditional calls like label.setText(“newValue”) with calls to label.updateFrom(“oldValue”, “newValue”). They also provided an implementation of the updateFrom method with the code shown below. However, their code may not work correctly on all occasions and so I’ve listed it in strikethrough style.

extension WKInterfaceLabel : Updatable { func updateFrom(oldValue : String?, to newValue : String?) {   if newValue != oldValue {self.setText(newValue) }}  }

The risks of minimizing traffic: Well-intentioned programmer-Y might see some performance gains, but they run the risk of having the app function incorrectly. Apple’s documentation says that “attempts to set values for interface objects are ignored” after the didDeactivate method is called. In other words, setting WKInterfaceLabel text will be useless if the controller is inactive. In walking through code, I’ve verified that setText code in controller methods may not always set the text value of labels. If the Apple Watch screen times out (as it does very often for almost every watch user), the app might execute setText code, but the setText call is ignored by the watch.

This means that the developer’s controller class might think that the WKInterfaceLabel’s value was updated to the latest value, but the watch might have ignored the new value. If the user pressed the crown to activate the screen again, Programmer-Y’s app will show the old value (e.g. Calories: 2100/2400) but refuse to update the label text value because it thinks that it showing the new value (e.g. Calories: 2500/2400).

The WatchKit API doesn’t provide any way for the app to know what exactly the watch is displaying. Apple’s documentation says “Communication between an interface object and the corresponding view on Apple Watch is one way, with information flowing from your WatchKit extension to Apple Watch. In other words, you set values on an interface object but you cannot get the current values of its attributes.” The end-result is that Programmer-Y might “Minimize Traffic” and get some performance gains with a naïve implementation of the “Update only what has changed” performance tip. However, the user of this app might see stale and incorrect data/text in the app and the app would have no way of knowing what was being shown to the user. This would be a worse user experience than the one provided by naïve programmer-X’s app and is a good illustration of Donald Knuth’s point that a focus on efficiency could potentially have a “strong negative impact”.

The critical 3%: Knuth’s essay says that “We should forget about small efficiencies, say about 97% of the time” and then starts his next paragraph by saying “Yet we should not pass up our opportunities in that critical 3%.”. The two statements complement each other just like Spock’s admonition complements Apple’s performance tip. The iPhone communicates with the Apple Watch using Bluetooth or WiFi and traffic between the two devices can be slow and also result in greater battery usage. So I would assert that minimizing traffic would generally fall in the “critical 3%” and that programmers should neither follow the Programmer-X model nor the Programmer-Y model.

Optimize with caution: One starting point to minimize traffic between the iPhone and Apple Watch is to maintain information about interface objects (e.g. calorie values pertinent to a label on the watch screen) in the WatchKit extension of the watch app and only set watch interface objects to new values if the new value is different from the old value known by the watchKit extension. In addition, WatchKit extension code should only update interface object state if it believes that the interface controller is active at the time.

The WatchKit extension code could do this by maintaining an isActive flag that is turned on in the WKInterfaceController’s willActivate method and turned off in its didDeactivate method. This will help in making sure that the extension code doesn’t hold on a new value even though the watch is actually showing an old value. This eliminates almost all risks, but it is possible that some version of the Watch OS might ignore setText calls after the screen times-out and before the didDeactivate method is called.

A conservative approach to this potential problem might be to turn off the optimization when the interface controller is re-activated, but keep optimization turned on during the rest of the session.

The Bottom-line: Minimize traffic between the iPhone and Apple Watch, but understand your WatchKit extension code and make sure that you’re not sacrificing correctness for efficiency. Users appreciate performance gain even more if the app works correctly and if it doesn’t display stale, wrong data.

An ill-fated project: This was a long time ago (1994/1995). I was a recent campus hire at Microsoft and Satya was an (individual contributor) Product Manager at the time (At Microsoft, product managers are people who work on marketing the product. They are typically not in the product development team organization).

We were both among hundreds of people working on the ill-fated “Interactive Television” (ITV) project. Satya had described the video-on-demand app that I developed (in C++) as the “flagship” of our pre-alpha ADK release.

Thoughts on Satya: I didn’t know Satya very well and haven’t met him in recent years. However, I remember him well from the ITV project in 94/95. At that time, he struck me as a good fair-minded person. He also came across as someone who looked out for others.

Thoughts on Microsoft: Microsoft was most successful when it had a programmer at the helm. That programmer – Bill Gates – will now spend one-third of his time at Microsoft. Satya has been very successful in leading the cloud and enterprise group at Microsoft. I wish them both the best in their new roles.

Satya’s letter and Oscar Wilde:  On his first day as CEO , Satya wrote an email to employees and it had a good mix of humility and inspiration. Interestingly, he paraphrased a quote from Oscar Wilde “we need to believe in the impossible and remove the improbable”. That quote is paraphrased from ‘The Decay of Lying‘ and is spoken by a character named Vivian who says “Man can believe the impossible, but man can never believe the improbable”.

What the Oscar Wilde quote meant: Vivian deplores a “degrading concession” to realism and says that ” The growth of common sense in the English Church is a thing very much to be regretted.”. He goes on to say that they must “revive this old art of lying”. In context, Vivian was clearly asserting that the church must lie to its members because the absence of lies may lead to the church losing its credibility.

Satya altered the quote a bit, but it is intriguing that Satya chose this particular Oscar Wilde ( Vivian) quote. Presumably, he wasn’t suggesting that Microsoft should act as per Vivian’s exhortation. I’m guessing he included the quote because it sounded interesting and inspirational. It also seems like he correctly guessed that the tech media and most Microsoft employees would miss the essence of Vivian’s quote.

Fragments to fix Fragmentation: I first downloaded the (preview/beta) Android SDK in 2007 and wrote a prototype location-based app at a time when there were no Android devices in the market. However, it wasn’t until last year that we decided to develop and release an app for the Google Play Store.

By this time, fragmentation had become a problem, but over the years, Google had done a fair amount of work (Fragment API, Android Support Library etc.) to alleviate fragmentation. Based on the research I did last year, it seemed like supporting multiple device sizes, screen densities, device capabilities, Android versions etc. was a manageable problem.

We decided that our Economy app (snapshot of the US economy) would use new UI paradigms from Android versions 4.x  (Ice Cream Sandwich and Jelly Bean) and yet support phones and tablets (of varying sizes) running any Android version with Gingerbread version 2.3.3 or higher. It is worth noting that the V1 version of our paid app was exclusive to Samsung devices (even though the latest versions – paid and free – can now run on thousands of devices from almost all manufacturers).

Implementing fragmentation fixes: Google’s documentation for solving fragmentation is reasonably good and in theory, you don’t need to have the navigational skills of a Medusan ambassador to track your course for solving fragmentation.

It took some work, but in practice, it was reasonably straightforward to overcome known problems related to fragmentation. For instance, we implemented Action Bar support for older devices running Android 2.3 (even though the action bar was introduced with Android 4.x and wasn’t natively supported in Android 2.3). The app uses hardware acceleration on newer Android versions, but doesn’t depend on any graphics processing unit for older devices.

Fragmentation and Unknown Unknowns: The biggest problem we encountered was related to fragmentation, but wasn’t fragmentation per-se. It was the numerous Android bugs that were specific to one or more specific versions of Android. This wasn’t something I anticipated. I don’t have a list of all the bugs I dealt with, but I’ll list some of the Android quality issues from comments I had written last year.

1. Android Section Indexer on 2.x: Our iOS app uses section indices for easy navigation through economic indicators (e.g. tapping “E” would take you to the ‘Employment’ section, ‘H’ to the Housing sector). I considered replicating the iOS section index for our Android app, but decided that it might be better to do section indexing the ‘Android way’. That involved using Android’s fast scroller. Unfortunately, Android’s fast scroller wasn’t ready for prime-time and it had huge display problems with getting refreshed in the 2.x versions of Android. Related problems are documented here and here. The bug didn’t reproduce with Android 4.x. However, for simplicity reasons, I chose to use the same (somewhat) inefficient workaround for the app on all Android versions.
2. Dashed lines on 4.x: Canvas.drawLine could draw perfect dashed lines on Android 2.x, but it didn’t work on Android 4.x with hardwareAccelerated turned on. A related problem is documented here. Luckily, the drawPath API worked correctly on all tested Android versions.
3. Fill Paint on 3.x: I’m assuming that the Android Honeycomb version family (3.x) set a record for being the least-ever used version of Android. I’d be surprised if it had ever exceeded a 1% share among Android versions, but we supported it because of our need to support older (2.x) and newer (4.x) versions of Android. One of the Honeycomb-only bugs we ran into related to fill-paint not rendering. I worked-around this problem by turning off hardware acceleration for Honeycomb.
4. Ellipsize and maxLines for Text: On some versions of Android, Android failed to ellipsize long text if the control had the ‘maxLines’ property set. I didn’t
   check to see if the bug was fixed in other versions.
5. Webviews and Transparent backgrounds: Transparent backgrounds don’t work with webViews on some versions of Android. One reference to the problem is available here.
6. HttpUrlConnection bugs: While writing the app, I tried to keep open the option of supporting Android version 1.6 (or perhaps 2.1). However, Google’s own documentation describes “frustrating bugs” with the usage of HttpUrlConnection in older versions of Android. I would think of these bugs as inexcusable on a 1.0 platform, so it is a bit disappointing to see that they continued on to 2.x versions of the platform.

Eclipse: I haven’t tried the new Android Studio, but no description of Android development problems can be complete without a mention of Eclipse (which is not from Google, but is the most commonly used Android IDE). Crashes and memory problems were annoying, but an even more annoying problem with Eclipse was its occasional sullen refusal to startup. Some of these problems could be worked-around with the –clean flag and luckily, I discovered a blog post with a workaround for the nastiest Eclipse startup problem.

Java: Another source of schedule unpredictability came from bugs introduced by obfuscation and optimization tools I used for Java code. I wish Google added more support for developing Android apps with C++. That would run the gamut from providing prebuilt HTTP libraries (like libCurl – which I built for Android after a lot of effort) to making it possible to create UI controls directly from C++ code (i.e. without being subjected to all the hassles of JNI). It is unlikely that C++ will ever be a fully supported language for Android and most Android-app-developers aren’t going to care about this topic, but I still hope that Google adds some incremental support for C++ developers.

Quality and Development Speed: Facebook is credited with the new-age “move fast and break things” philosophy. I haven’t worked with the Facebook development platform, but I think that Google has been going a bit overboard with the second part of the phrase. Apple and Microsoft seem to provide far more reliable platforms for development. While it may not be entirely reasonable to expect most developers to code with the speed and ease of a Horta tunneling through solid rock, Android’s quality issues make it unnecessarily difficult to write and test code quickly.

Fragmentation Statistics: At the time we launched the V1 version of our paid app, most Android devices were on Gingerbread (v2.3.3 to v2.3.7) even though it had been more than a year since the 4.x versions were launched. However, a very small fraction of Economy app users have been on Gingerbread and I think the percentage of Economy app users on Gingerbread never exceeded around 6%.

Today, Google’s dashboard says that around 24.1% of Android users are on Gingerbread (i.e. Android 2.3.x), but the Gingerbread percentage for our (paid) Economy app is less than 4%. Honeycomb registers at 0% for the Economy app now. So more than 96% of Economy app users are on the 4.x versions of Android. 12% of our users are on KitKat (Android 4.4) even though KitKat only has a 1.1% share of the overall Android market.

As per the latest stats, the free version of our app (Economy USA) has 92% on Android versions 4.x (including 7% on KitKat). 3% of “Economy USA” users are on Honeycomb (Android version 3.x) and 5% on Gingerbread (Android version 2.3.x).

Based on the data we had when development work started (and based on the fact that somewhere around 54% of Android devices were on Gingerbread when we first released the Economy app), I’d say we made the right decision to support Android devices from Gingerbread onwards. However, it was an interesting learning experience to find out that app usage/downloads were very disproportionately skewed towards the latest Android versions (i.e. new devices which ran Android 4.x)

Fragmentation – A strength and weakness: Android’s biggest strength is its ubiquity and the large market-share it has acquired due to the diverse range of devices it supports. So it isn’t unreasonable to have some problems relating to fragmentation. As mentioned earlier, Google has done a good job with providing frameworks to help developers navigate fragmentation issues. Developers interested in reaching large markets shouldn’t mind the overhead of dealing with fragmentation. We spent a lot of time and effort on ensuring that the Economy app (paid and free) were of a high quality on all supported versions of Android.

However, besides being one of the first developers to write Android code (with the preview/beta version of Android six years ago), I’m also an (admittedly infrequent) Android app user who purchased the first Android phone (G1) soon after it launched. So as a developer (who likes development speed/predictability) and as an app user (who is interested in seeing better apps in the play store), I hope that Google plays greater attention to quality issues with future versions of the Android SDK. That will help improve the quality of the average Android app in Google’s play store and it will also make it easier for good developers to ship good quality apps with slightly more predictable development schedules.

The first app: Around four years ago, Twitter announced that they would cut off Basic Auth for Twitter and that all apps needed to use Twitter OAuth. The iPhone Economy app was probably the first iPhone app to use Twitter OAuth for login and posting tweets. I wrote about it in 2009. In terms of development time, implementing Twitter OAuth login turned out to be much more expensive than I anticipated. Twitter didn’t create a mobile-friendly login page until much later and that was a big problem for most users. However, in spite of all these problems, the basic functionality worked and folks were able to post economic tweets with the Economy app (and #cEconomy hashtag)

Twitter breaks the access_token request: Earlier this month, I noticed that the Economy app could not post economic tweets anymore. New logins were also failing. It turned out that Twitter broke their OAuth 1.0 API. Debugging old code isn’t always easy and I had written this code in mid-2009, but fortunately, Twitter made trouble-shooting relatively easy by returning a helpful error message “Required oauth_verifier parameter not provided”. Fixing this problem meant two things (a) After the user types in their username and password, Twitter appends a query-string parameter (oauth_verifier) to the callback URL. This oauth-Verifier value needed to be retrieved from the URL. (b) The oauth_verifier needed to be included in the HTTP headers of the /oauth/access_token request.

Why Twitter broke access_token: Requiring the new oauth_verifier token clearly broke the previous definition of the access_token API and it broke Twitter functionality in third-party apps that relied on the official Twitter definition. Interestingly, Twitter documentation continues to describe oauth_verifier as an optional parameter. Twitter can make the case that their previous implementation and current documentation are both wrong and that incremental security gains weremore important than not-breaking their old API. However, it would have been nice if Twitter had publicly acknowledged their past mistake and given developers sufficient time to migrate to the new requirement. Of course, the best option would have been to require oauth_verifier in the original 2009 API implementation.

The broken request_token API: Current documentation of the request_token API states that the oauth_callback is required. Presumably, this documentation was updated recently. However, interestingly, our old code (without) the oauth_callback parameter continue to work fine. The oauth_callback parameter wasn’t necessary because the callback value is already pre-registered for our app on dev.twitter.com. Nevertheless, I spent the extra effort on adding the new parameter, modifying signature etc. and we now pass the oauth_callback parameter for request_token API calls. Apps don’t get broken regardless of whether the oauth_callback parameter is passed. However, I’d still consider the API as broken because it doesn’t conform to Twitter’s official definition of the API and it could potentially break apps in the future.

No more XML: Twitter seems to have joined the ‘XML is not cool’ bandwagon and they’ve announced that they’ll cut all support for XML response formats in the Twitter 1.1 API. The Twitter 1.0 API will stop working on May 7, 2013. The Twitter 1.1 API also removes endpoints such as /statuses/update.xml (and calls to these APIs will need to be replaced with calls to json endpoints such as /statuses/update.json). It seems unnecessary to cut off XML support and I don’t see this decision generating any real value for Twitter.

Hiding the tweet source: In 2009, Twitter promoted OAuth by announcing that the source (i.e. app) which created a tweet would only be shown if the app used OAuth. This helped users identify the source of a tweet (and perhaps download the app) and it also helped promote the app. Last year, in another flip-flop, Twitter decided that users didn’t need to know anything about the source of a tweet. So the source of tweets isn’t listed on Twitter’s official apps (or website) anymore and users won’t be able to identify apps that generated the tweets of people that they’re following.

Breaking Twitter Search (by source): The Economy app appends the #CEconomy hashtag to all its tweets and this helps create a collection of economic tweets that users can browse through. To eliminate spam, the app only shows #CEconomy tweets created with the Economy app. IOW the search results are filtered by the “source” (i.e. app that generated the tweet) . In 2009, this could be done with a simple HTTP request like http: //search.twitter.com/search?q=%23cEconomy+source%3AAppName. However, a few months ago, Twitter broke this query and the Economy app could not show the list of economic tweets it created. It turned out that Twitter broke this browser query and replaced it with http: //twitter.com/search?q=%23cEconomy%20source%3AAppName. This was an easy problem to fix and less serious than the broken Twitter APIs, but it did inconvenience a lot of users.

What next: The Twitter API has been unstable and besides wasting my time, this instability inconvenienced many users of the Economy app (though I should add that the percentage of users who post economic tweets with the app is fairly low).

I considered cutting the entire Twitter feature, but ultimately fixed the Twitter problems because (a) users who post (or want to post) economic tweets will appreciate keeping the Twitter integration feature (b) the fixes were’t too expensive, didn’t risk other parts of the app and hopefully the Twitter team wouldn’t break more things in the future (c) it is hard to make a totally objective/rational decision about cutting your losses (and killing Twitter functionality) when you remember how much time you had invested in implementing Twitter functionality. I’d like to think that the first two reasons played a bigger role in keeping Twitter integration in the app. In any case, last week, we tested the Twitter integration fixes I wrote and everything works fine.

Next month, we plan to release a major new update for ‘Economy for iPad’ and the Twitter fixes will be included in that release.

1. Pay for exposure: The WSJ report noted that Apple was concerned that “AppGratis was pushing a business model that appeared to favor developers with the financial means to pay for exposure.”

Does AppGratis make paid recommendations? The AppGratis response doesn’t respond to this charge. However, anecdotal evidence (as well as a Forbes interview with the CEO of AppGratis) suggests that AppGratis does have a pay-to-play model wherein they “recommend” apps to users if the app-developers pay them huge amounts of money

Honest, real recommendations provide great value to users. Our iPhone and Android apps have received a lot of great coverage in the media (for example, the iPhone Economy app was featured in the cover page of Wiley Publishing’s Book on Incredible iPhone apps, got great reviews in MacWorld, GeekWire etc). So in addition to the value that users get, I recognize the value that developers get from good reviews/recommendations.

However, paid recommendations are bad for the whole app ecosystem. They are bad for users and they also hurt good developers who rely on organic user-base growth and real/honest reviews and recommendations. Large companies with free apps and huge marketing budgets clearly benefit from pay-for-exposure. That is why they pay huge amounts of money to AppGratis and other companies like TapJoy which offer incentivized downloads. These tactics result in artificially inflated download-counts. They manipulate app-store rankings and artificially push promoted-apps to the top of Apple’s top-apps charts.

So it is easy to understand why Apple would want to eliminate apps based on the pay-for-exposure model.

Rule 3.10 in Apple’s app-store guidelines explicitly states that “Developers who attempt to manipulate or cheat the user reviews or chart ranking in the App Store with fake or paid reviews, or any other inappropriate methods will be removed from the iOS Developer Program”. One could make a weak argument that all advertisements (e.g. iAds or Google-ads) amount to something like pay-for-exposure, but I don’t think that regular banner ads are comparable with what Apple is trying to ban. I also think that full-disclosure is important and that AppGratis-users should be told that the recommendations were “paid for”. It is interesting to note that AppGratis’ response hasn’t attempted to address the charge that they’re based on a pay-for-exposure model.

2. Push Notifications for advertisements and promotions: Rule 5.6 in Apple’s guidelines explicitly states that “Apps cannot use Push Notifications to send advertising, promotions, or direct marketing of any kind”.

One could make a weak argument that Rule 5.6 is bad for the user and that all push-notification-advertisements/promotions must be allowed. That may be a debatable point. One could also make the claim that Rule 5.6 isn’t being applied consistently. Again, it is arguable whether Apple is correct to permit advertisements in one class of apps (e.g. an airline advertising a sale) and prohibit it for another class of apps (e.g. AppGratis).

The WSJ report suggests that AppGratis violated rule 5.6 and the AppGratis blog attempts to counter this by saying that they only send one notification per day and that users opt-in. However, all iOS push-notifications are opt-in anyway. Apple’s rule doesn’t make exceptions for apps that only send one notification per day. So the AppGratis response does nothing to counter the fact that their app violates Rule 5.6 (as it is written).

Prohibiting app store chart manipulation: I’ve myself dealt with an app-store-rejection (for using a private API) and I understand why developers may want to push some limits. However, when it comes to matters like incentivized downloads and pay-for-exposure, I think that Apple is right to prohibit the artificial manipulation of app store rankings.