Sunday, October 2, 2016

RadioKit with iOS 10 / XCode 8 support

The current version of RadioKit (version 2.15.4) is compatible with iOS 10 and XCode 8.  If you already have an existing license, the current lib file can be retrieved here:
http://www.stormyprods.com/Libs/RadioKitLib-XCode7.zip

The demos have been updated to XCode 8 and are available here:

Also, the Swift demo project has been updated to XCode 8 and Swift 3.0.  It is available here:
https://github.com/MostTornBrain/Swift-Radio-Pro/tree/RadioKit

If you notice any issues with iOS 10, please let me know.

Saturday, September 17, 2016

Tunemark Radio - now free for the foreseeable future

Tunemark Radio is now available for free on iTunes.   Due to time constraints with other work, I do not see myself having the time to make a significant update release for this app, so I've decided to make it available for free.

It is still fully functional on iOS 10, however it hasn't been updated since the release of iOS 7.

If you've never used the app before, I still think it is a great option for accessing the SHOUTcast database of stations.   And, it has NO banner ads.

You can get it here: 

Sunday, October 11, 2015

Bitcode error when trying to archive a project using Xcode 7.0.1

RadioKit has been updated to version 2.15.4.   This is a simple rebuild of the library to correct an error Xcode 7.0.1 introduced when trying to "archive" a project that is linked with RadioKit:

"libRadioKit.a(AudioStreamEngine.o) was built without full bitcode. All object files and libraries for bitcode must be generated from Xcode Archive or Install build for architecture armv7"

Latest version can be downloaded here:  http://www.stormyprods.com/Libs/RadioKitLib-XCode7.zip


Sorry for the inconvenience.

Saturday, October 10, 2015

RadioKit and Swift

Good news for those that are looking for an example of using RadioKit with Swift.   Matthew Fecher was kind enough to create a very nice Radio App using Swift 2.0 and he released it on GitHub.  He was also kind enough to give me permission to use it for demonstrating RadioKit usage with Swift.

Here is a link to the project: https://github.com/MostTornBrain/Swift-Radio-Pro/tree/RadioKit

This project demonstrates:
  • Playing stations from a JSON list 
  • Parsing the meta data of a live stream
  • Connecting to Live.FM to get album artwork for the currently playing song
  • Using the RadioKit rewind and fast forward features
  • Using the RadioKit buffer view to visualize where in the live stream playback is currently occurring
The sample project is a very good starting point for creating a professional radio app using Swift and RadioKit.



RadioKit linker warnings related to precompiled headers

If you are seeing a lot of warnings with Xcode 7 related to linking with RadioKit, please downloaded an updated version of RadioKit (2.15.3).   It corrects the issue.   Xcode 7 apparently handles precompiled headers differently now in libraries and the way I was building the library was causing these warnings.

Sorry for the confusion.

Latest version of the RadioKit SDK can be found here:

http://www.stormyprods.com/Libs/RadioKitLib-XCode7.zip

Monday, September 21, 2015

RadioKit and Apple TV

For anyone interested in making radio apps for the new Apple TV, I've created a beta version of RadioKit that is compatible with the current Apple TV beta (tvOS 9.0).    Apple TV uses different library images than iOS, so I needed to create a separate RadioKit library specifically for Apple TV.  You can't just use the existing iOS version of RadioKit - it is not binary compatible with Apple TV.

If you want to try it out, the library is here:

http://www.stormyprods.com/Libs/RadioKitAppleTv.zip

It uses the same API methods and names as the version of RadioKit for iOS.

I am currently working on putting together a sample Xcode project for Apple TV which demonstrates using the SDK.  I'll followup once I have it complete.

Wednesday, September 16, 2015

RadioKit and Xcode 7 and iOS 9

Good news!  The latest version of RadioKit (2.15.2) is compatible with Xcode 7 and iOS 9.   Previously built apps that use an older version of RadioKit do NOT need to be updated (they should continue to work just fine), however if you are building a new app,or creating an update to an existing app, it is recommended that you download the latest version of RadioKit:

http://www.stormyprods.com/Libs/RadioKitLib-XCode7.zip

This version of the SDK is compiled with ENABLE_BITCODE support for iOS 9 app trimming.

Also, as of iOS 9, any new app or app update compiled for iOS 9 that makes an HTTP or HTTPS connection needs to explicitly allow the destination address via settings in the app's info.plist.  If you do not edit your info.plist with the necessary information, your app will not be able to play any remote audio streams.

For more details, refer to this Apple tech note:

https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/

If you are creating a generic radio player that will connect to arbitrary streams, you will need to set NSAllowsArbitraryLoads to YES in your NSAppTransportSecurity dictionary in your app's info.plist.
If you are connecting to just one stream, you can instead enable access to just that URL.

The RadioKit demos have been updated with this information as well.  For more information see:

http://www.stormyprods.com/products/radiokit.php

Friday, June 12, 2015

RadioKit and 64-bit support

As of February of 2015, Apple now requires all apps submitted for review (including updates to old apps) provide support for 64-bit.

If you are using an older version of RadioKit, you may receive the following error when building your app:

Undefined symbols for architecture x86_64:
  "_OBJC_CLASS_$_RadioKit", referenced from:
      objc-class-ref in AraRadioAppDelegate.o
ld: symbol(s) not found for architecture x86_64

If you are receiving this error, all you need to do if update your app project to use the latest version of the RadioKit library.  It can be found here free of charge:

http://www.stormyprods.com/Libs/RadioKitLib-XCode5.zip

Simply replace the RadioKitLib in your project with these new files and your project should build without any issues.

Friday, May 15, 2015

RadioKit and iOS 8

Just a quick update:  the existing version of RadioKit continues to work fine with iOS 8.   All the sample projects have been updated to work with the latest version of Xcode.

Wednesday, September 25, 2013

RadioKit and iOS 7 support

Good news for all existing RadioKit SDK license holders:   the current version of the RadioKit SDK works fine with iOS 7 as-is, so unless you want to make other iOS 7-related changes due to other features of your app, your existing apps should continue to work just fine.

For anyone just getting started with RadioKit, I have put together a simple iOS 7 / Xcode 5 demo project which can be found here:  An XCode 5 (iOS 7) utility app - http://www.stormyprods.com/Demos/ios7/RadioKitDemo.zip

If you just want to grab the most up-to-date RadioKit SDK (version 2.6.2), you can get it here:  http://www.stormyprods.com/Libs/RadioKitLib-XCode4.5.zip


Wednesday, November 21, 2012

Tunemark Radio with Improved Visualization

Thanks to a new feature of iOS 6, I will be adding significantly improved audio visualization features to Tunemark Radio. Specifically, I am referring to Audio Queue taps, which Apple mentions in their iOS 6 SDK release note, but provide no documentation at all, other than comments in the AudioQueue.h file. If you are looking for the technical details, search for AudioQueueProcessingTapCallback in the AudioQueue.h file. I’ll write up a more detailed description of how it can all be used, along with the hooks I added to RadioKit to support it, in a future post.

Anyhow, once you get over the hurdle of the lack of documentation, you can do some pretty nice things with an Audio Queue Tap. It provides a way to get the raw PCM audio right before it is played, perform adjustments to the audio (apply echo effects, etc.) or just monitor the audio for visualizations.

In my case, I’m interested in using it for adding better visualizations to Tunemark Radio. Since Tunemark Radio is playing Internet radio station streams, it is generally dealing with MP3 or AAC audio, which is in a compressed format and short of implementing your own MP3 or AAC decoder, there’s no easy non-CPU intensive method to get actual waveforms. Instead, in the past I had to resort to just querying the audio queue gain (i.e volume) information and do some rudimentary visualizations with that.

Now that I have real-time access to the raw audio waveforms thanks to the Audio Queue tap, I can do more more dynamic and responsive visualizations. The first one I’ll be adding (which will be available in the next upcoming Tunemark Radio update) is a waveform visualizer. It will look something like this, although it’s a lot more engaging when it’s actually moving:

ScreenShot2012-11-22at1.25.12AM-2012-11-22-00-18.png



Basically, the waveform will move in time to the music.

Future updates will include more dynamic visualizers that have various visual effects based on different frequency changes (such as part of an image changing based on bass notes and another part changing based on high frequency notes).

Saturday, September 15, 2012

RadioKit for iOS 6

A version of the RadioKit SDK is now available with support for XCode 4.5 and iOS 6. If you already have an app using RadioKit and are just looking for the library so you can target the new iPhone 5, the library can be found here:

http://stormyprods.com/Libs/RadioKitLib-XCode4.5.zip

If you would like a full XCode 4.5, iOS 6 demo project, it can be found here:

http://stormyprods.com/Demos/RadioKitARC-4.5-Demo.zip

Full details about the RadioKit SDK can be found here:

http://www.stormyprods.com/products/radiokit.php

Please note: with XCode 4.5, Apple has removed support for armv6 and will only allow builds targeting iOS 4.3 and higher. So, if you still have projects targeting armv6, or want to use XCode 4.4 or lower, you will want to use the older RadioKit library.

Also note that existing apps already using an earlier version of RadioKit will work just fine under iOS 6 as-is. You only need to get this new update if you specifically want to build an app using RadioKit and XCode 4.5.

Friday, July 27, 2012

RadioKit SDK, now with Recording!

I'm happy to announce the RadioKit™ SDK for iOS now includes an API for recording the audio from a stream.
Here's a simple example demonstrating the API’s syntax:

NSString *filename = [NSHomeDirectory() stringByAppendingPathComponent:@"tmp/test.audio"];
[radioKit startRecording:filename appendToFile:NO];
[radioKit setStreamUrl:@“http://enteryourstreamhere.pls” isFile:NO];

And when you want to stop recording:

[radioKit stopRecording];

Then, you can simply play back the saved file at a later time via the RadioKit local-file playback support:

[radioKit playLocalFile:filename];

It’s that simple.

To read more about all the features of the RadioKit SDK and how it greatly simplifies the process of creating a full-featured iOS radio app, check out http://www.stormyprods.com/products/radiokit.php

Monday, March 12, 2012

The 2.2.1 Artificial Life update for iPhone/iPod Touch that was recently released contains a bug which causes the screen to flicker terribly when you have a protozoa selected and you are using a non-retina display device, such as iPhone 3GS or older. I've located the cause of the problem and it is now pending review with Apple. Hopefully it will be available for download about a week from today. NOTE: this problem does not occur on the Artificial Life HD (i.e. iPad) version. Sorry for the inconvenience.

Sunday, March 13, 2011

Japan Disaster Relief


All proceeds from the sales of the Tunemark Radio app between March 12th and March 20th will be donated to the Red Cross and Salvation Army for the disaster relief efforts in Japan.

If you prefer to make a direct donation to the relief efforts, Apple has set up a way for you to do it via iTunes here.

3/21/2011 UPDATE: Thanks for all the support! Over $620 was donated to the Japanese Red Cross Society and The Salvation Army from Tunemark Radio app sales.

Tuesday, March 8, 2011

Tunemark Radio 2.1 - the iPad update

Much to my disappointment, I accidentally introduced a bug into the 2.0 version of Tunemark Radio, causing the app to crash on launch on devices running iOS 3.x. Thankfully, Apple let me put through a rush update to fix the problem, so the new 2.0.1 version now available on iTunes fixes the problem for those people with an iPhone or iPod Touch running iOS 3.x.

Unfortunately, I hadn't realized the same bug also existed on any iPad that is still running iOS 3.x. and the 2.0.1 update does not fix that bug.

I had been in the process of creating an improved version of Tunemark for the iPad, and had it nearly complete this weekend when I started receiving reports of the iPad 3.x problem, so I decided to roll the new iPad look for the app into this bug fix update.

So, yet another update is now pending review with Apple, this time addressing the problem for those with an iPad running iOS 3.x., but also with the bonus of (in my opinion) a much better UI for iPad. Here's a screenshot showing how it will look on iPad:



Hopefully you will agree this is a much better look than what is currently Tunemark Radio on the iPad.

And in case anyone was curious what country-western music looks like in Japanese, here's another screenshot:



You can tap on either image for an iPad-sized version of the screenshot.

Tuesday, March 1, 2011

Tunemark Radio 2.0 now available!


Tunemark Radio 2.0 is now available on iTunes for 99 cents. This latest updated adds a few new features:

1) Album artwork and artist information is now available via last.fm. If last.fm has any information about the current playing song, a “last.fm” button will appear allowing you to view the content provided by last.fm. Also the album artwork (if available) will automatically be displayed on the “Now Playing” screen.


IMG_0621-2011-03-1-22-26.PNG

If you prefer to only have your own custom background image displayed, don’t worry. There is an option in the settings to disable album artwork.

2) The switching of stations should be noticeably faster. I discovered I had a minor inefficiency in the transition which caused a noticeable lag when starting playback of a new station.

3) If you are a Japanese user of the app and were disappointed that you lost all the “cool” English text when I recently added Japanese language support, I listened to your complaints. Via the settings, you now have an option to force the app to use English only. Please note, this will require that you either force-quit the app or reboot your device after choosing this setting.

IMG_0628-2011-03-1-22-26.PNG

Wednesday, January 12, 2011

Apple's New Policy on Single-Station iPhone Radio Apps

Back in November there was a a bit of stir in the radio community regarding one developer's claim that Apple was no longer allowing single-station radio apps. The article found here gives a decent summary of the story. The final conclusion was Apple hadn't changed their policy, but instead it was just this one developer's approach to making "template-based apps" that was the problem. Apple was even quoted as saying: "There are many unique radio apps on the App Store and we look forward to approving many more. One developer has attempted to spam the app store with hundreds of variations of essentially the same radio app and that is against our guidelines."

So, at the time of the article, the general thought was if you develop custom radio apps, and don't have them with little content other than playing an audio stream, then you should be OK. It turns out, this answer is true, but with one important caveat: Apple is now requiring any new single-station radio apps be hosted under the radio station's own developer account.

I ran into this new policy two days ago when I received a rejection for a new single-station app. The text of the rejection was a bit alarming to me when I first read it:

"We've completed the review of your apps[sic], however, we are unable to post them[sic] to the App Store because they provide the same feature set as your existing radios apps and simply vary the content. Apps that replicate functionality with different content create clutter in the App Store, hindering users' ability to find apps. They are therefore not appropriate for the App Store, as noted in the App Store Review Guidelines :

2.20 Developers 'spamming' the App Store with many versions of similar apps will be removed from the iOS Developer Program"


First, I only submitted one app, but the text implied I had submitted several. Also, the claim I was "spamming" the app store seemed extreme - every radio station app I've developed is commissioned (i.e. paid for) by the radio station and is completely customized per the radio station instructions. Granted, some of the apps are similar to others, but this is because it is common for one radio station to say something along the lines of, "I want an app just like the one you did for station X." From the radio station's point of view, it's all about getting their brand onto the iPhone - they want their listeners to be able to have easy access to their station, and having an app in the iTunes App Store is one way to do that.

Based on the text of Apple's rejection email, it seemed a bit doom and gloom for the single-station radio app. I quickly sent off an email to Apple requesting some clarification about the rejection, outlining the reasons why I thought single-station radio apps are not "spam" and asking Apple for some clarification.

Today I spoke with someone from Apple on the phone and got the needed clarification. Apple is no longer allowing developers to host large numbers of single-station radio apps under their own account. Instead, they are requiring the station to apply for their own developer account and host the app themselves under their account.

I can see why this makes sense for Apple. Most single-station radio apps are free. Apple makes zero money on them. Best case, they get a bit of free advertising for the iPhone platform from the radio stations when the station says, "Download our free iPhone app" on-air. Now, Apple will instead be making $100/year on each new single-station radio app.

Financially, from Apple's point of view, this change of policy makes sense. For us developers, it's not too big a deal - we'll just have to do a bit more hand-holding with the stations to help them set up their developer account and upload their apps. For a radio station, there's now going to be an increased cost for an app ($100/year), but really that's a not a huge amount of money.

The only part that doesn't make sense to me, is this goes directly against Apple's original explanation for why the app was rejected in the first place. They said single station apps "create clutter in the App Store, hindering users' ability to find apps", but this change in policy is not going to reduce the number of single-station apps. They're just going to be hosted under different developer names. But, since Apple reserves the right to reject an app for any reason, I suppose it's a moot point. Their reasoning doesn't have to make sense - we developers just have to do what they say.

The good news for radio stations is they will still be allowed to have their own custom apps.

Tuesday, December 14, 2010

Switching an iPhone app from Free to Paid - postmortum

A little more than a year ago, I created a free iPhone app called Tunemark Radio. After more than a year of being a free download (with no banner ads), I decided to see how the app would fare if I switched it to a 99 cent app. It has now spent 2 months as a paid app and I detail the results in this post.

Background

Tunemark Radio is, as the name implies, and Internet radio stream playing app. It includes support for browsing and playing all the stations in the SHOUTcast database (over 30,000 of them!) as well as the entry of custom URLs for any mp3 or AAC stream you might happen to have which isn’t in the SHOUTcast database. The “tunemark” part of the name was intended as a play-on-words for bookmark, but applied to music. The app supports the concept of “tunemarking” songs that are playing - you can save the artist/title info to a list for later reference, look for it to purchase on iTunes, send the song info via email, share it on Facebook, Twitter, or Last.fm.

When I originally released the app, it did not included all of the features it includes today. The initial release was pretty barebones. I figured I’d release the app for free, hoping it would be good publicity for my iPhone app development business. I had a focus on developing iPhone apps for radio stations and thought this app might be a decent demonstration vehicle for future clients. They could see whether they liked the performance of the audio streaming code I wrote, and even would be able to enter the URL for their own station to test how their audio stream would behave in their own custom app.

Over time, I added more and more features (a music visualizer, iPad support, the social sharing aspects for Facebook/Twitter, and Last.fm scrobbling support are some examples). Even though the app was free, I also vowed to never have any ad banners. As the app matured, I began to get occasional email messages and app reviews on iTunes where someone would say something like “I can’t believe this app is free!”. But still, since the app had evolved over time, I still thought of it not having enough features to justify a paid price.

Even though the app was free, the download numbers were fairly modest - for the first 3 months, the average download was about 150 copies per day. Then, after the Christmas bonanza of new iDevice owners, average downloads increased to about 250 copies per day for the next several months. Slowly, the app was gaining in downloads, perhaps as a result of the iPhone user base itself growing. After the first 6 months, average downloads had climbed to 500 per day and were still climbing.

Then, in late July 2010, Tunemark Radio was featured in a special Radio Apps category on iTunes. This initially caused daily download numbers to more than double. The Radio Apps category was on the iTunes desktop app, on the iPhone, as well as on the iPad. After about a month, Apple revised the iPhone Radio Apps category and cut the number of apps featured down from 30+ to 17, and unfortunately Tunemark was dropped from the iPhone special feature. It was, however, still featured in the shortlist of 11 Radio Apps for the iPad.

Tunemark continued to be available for free, and after a couple of months of the Radio Apps category hanging around in iTunes special features for iPad, the average downloads for Tunemark had appeared to be fairly steady at 700 copies per day. About a month later, as the special Radio Apps category migrated to the end of the list of special features, the downloads were slowly falling. By mid-October, the download average was closer to 500 copies per day and was still falling.

The Switch to a Paid App

It is at this point in time, after getting a few more “I can’t believe this app is free” messages, I decided to switch Tunemark to a paid 99 cent app. I was mainly curious what would happen. Daily downloads as a free app were falling anyhow. How much would daily sales drop as a paid app? Surprisingly, for an app which had been free already for a year, the numbers weren’t too bad, as can be seen by the following graph.


PastedGraphic-2010-12-14-22-47.tiff
Initially after the switch from free to paid, the daily downloads dropped from about 500 to 100. I found this number surprisingly good. The day after setting the 99 cent price, I had feared I’d be seeing a number more like 10 downloads on the following day. Seeing the numbers drop to 20% of the free numbers was OK with me. Sure, an 80% reduction in sales is significant, but 100 paid sales per day is still pretty good.

Granted, the app did still have an artificial boost of being featured in the Radio Apps feature which appeared on iTunes for the iPad. That feature was finally rotated out of iTunes by Apple in mid-November as can be seen by the drop in numbers in the graph. But still, the drop was not as dramatic as I had feared and for an app now with absolutely no advertising, averaging more than 60 downloads per day, after having been available for free for a year, they seem like good numbers to me.

The Paid Effect on Ranking

What I found especially interesting was as a paid app, Tunemark Radio ranked far higher in the Music category than it ever did as a free app. You can see this with the following graph from AppAnnie.com:
Safari1-2010-12-14-22-47.png

As a free app, it was ranked around 200 in the music category. When it switched to a paid app, there were a few days initially where the app had no rank, since you do not carry over your sales or ranking info when switching from free to paid. After 2 days of sales at 99 cents, it began to appear in the paid rankings and quickly climbed within the top 100 paid music apps.

Best I can tell, the free music app category is much more competitive than the paid app music category. Is this true for all app categories in iTunes? Unfortunately, I have no definitive answer. I suspect that would be the case, but it could be a unique situation with the music category. Perhaps someone else can shed some light on this.

Another interesting data point in the above graph is in late November, a day after I posted a new update of Tunemark on iTunes, the app was cracked and posted to various app pirate sites and there were several tweets made with a link to the cracked ipa. As far as sales go, app downloads dropped 36% that day. While sales recovered the following day, the app had the most dramatic ranking drop ever. I can’t really tell for sure if this is a direct cause of the app piracy, but it is suspicious. It was also the day before Thanksgiving here in the US, but this graph is showing app ranking, not sales, so if app downloads in general on iTunes were reduced around Thanksgiving, I would have suspected all apps would maintain their relative rankings.

The Paid Effect on App Ratings

One other benefit of switching from free to paid is the quality of app reviews. For the prior year, as was the case with most free apps, Tunemark Radio had an average rating of 3 stars. The vast majority of written reviews were 4 or 5 stars, however there were plenty of ratings that were 1 star, mainly due to the pre-iOS 4 feature of “rate-on-delete”. After switching to a paid app, the app’s average rating is now 4.5 stars with its most recent update from a few weeks ago. It has 17 five star reviews, 2 four star reviews, and only 1 one star review.

Conclusion

Overall, I can’t really think of any negative from switching from a free to paid app. When the app was free and was bringing in no income (other than a few iTunes referral commissions), it was not practical to be spending money on the development of the app. I was happy to spend some of my own free time, but I couldn’t justify the cost of paying “real” money to make other improvements to an app that was essentially a hobby.

Now that the app is earning decent daily income it will help justify spending more time on future feature enhancements. There are a lot of new features I have on the wish list and these features will require some significant code writing in the coming months. I also hope to at some point hire a graphic artist to improve the look of the app. I am not a designer, and the user interface for the app could be greatly improved. And finally, even though the app is only available in English, it has been surprisingly popular Japan. I hope to pay someone to assist with a Japanese language localization of the app, and perhaps some other languages.

I’ll be sure to follow up this post with more analysis of how the app does in the coming year.

Monday, August 23, 2010

iPhone App Piracy - a direct noticeable affect on niche market app sales

I've had a niche market app, called Artificial Life, for sale in the iTunes app store for over a year now. As the name implies, it's a simulation of artificial life. Given the subject matter of the app, I never expected to make a lot of money from it. There's a limited audience of the type of people who find the topic interesting (mainly tech people), and a smaller number who own iPhones and would enjoy watching such a sim on their phone.

But, there was a small niche market, and those who used the app tended to use it on average for about 45 minutes per day! The app had been slowly gaining sales over the past year increasing from single digit daily sales to over 20 sales per day. Then, back on April 18th, the app was cracked by pirates and was posted on a web site for jailbreak users to download for free.

I discovered this piracy when a saw a huge spike in app usage (via Google Analytics stats). The stats showed an increase in app usage by about 13 times the normal usage in just one day (over 3200 daily users vs. the previous days average of about 250).

At first, I assumed this would have a negligible effect on my daily apps sales - I was only selling 20+ copies a day and general wisdom say says the piracy numbers are people who would never buy your app in the first place anyhow. Well, sad to say, several months later I can say this general wisdom appears to be wrong, at least for my market.

Here's the graph of daily sales for the past year (you can click on the image for a larger view):



The red line denotes when the app was first cracked and posted on a pirate website. As can be seen, app sales had been steadily climbing, however shortly after the app was cracked app sales began to decline and now are back to single digits for daily sales. It could be coincidence, but it does seem fairly compelling that a couple weeks after the app was pirated, the sales for the app were more than cut in half.

One other interesting point that can be observed from the graph: Up until early April, the app included anti-piracy code to try to make the app a bit more difficult to crack. When I published an app update in early April, I discovered I had introduced a critical bug which was causing a false positive for the piracy detection on some devices. I immediately pulled the app from the store to prevent any existing customers from getting the new update and I was able to get Apple to push through an emergency bug fix the next day. This can be seen in the graph when there was one day in early April with zero sales. Because I wanted to get the bug fix out as quickly as possible, I simply disabled the piracy detection.

Much to my dismay, it only took a week for someone to then pirate this new app update since it no longer included any anti-piracy measures. And then a few more weeks and daily sales were cut in half. And the rest is history.

All content copyright © 2009  Brian Stormont, unless otherwise noted.   All rights reserved.