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.
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:
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.
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.
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:
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.
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.
Saturday, July 24, 2010
Apple currently featuring "radio apps" and Stormy Productions has a strong presence on the list
I was pleasantly surprised this morning to discover Apple currently has a list of featured radio apps on the iTunes store, and Stormy Productions was involved in the creation of 10% of those apps.
There are two lists, one for iPhone apps and one for iPad apps.
The iPhone list contains 30 apps, and I've had a hand in the creation of 4 of those apps. Specifically, I wrote all the code for both the Tunemark Radio and JAZZ.FM apps. I also wrote all the radio streaming code and the "now playing" portion of the user interface code for the Public Radio App. And finally, I wrote the radio streaming code used by the PRI app. (A good friend of mine wrote the rest of the code for the PRI app - congrats Rob!).
For the iPad list of featured radio apps there are only 11 apps listed, and Tunemark Radio is one of them!
As an iPhone developer, one always hopes to some day have an app make Apple's "featured" lists on the front page of iTunes, so I am unbelievably happy today to have several make one of Apple's lists.
As for what effect this exposure has on app downloads, I only have access to the stats for the Tunemark Radio app (the rest of the apps are under other developer accounts), but I can say, for my Tunemark Radio app, after one day being on this featured radio app list, the number of downloads have more than doubled. The average daily download count jumped from 500 to over 1100.
There are two lists, one for iPhone apps and one for iPad apps.
The iPhone list contains 30 apps, and I've had a hand in the creation of 4 of those apps. Specifically, I wrote all the code for both the Tunemark Radio and JAZZ.FM apps. I also wrote all the radio streaming code and the "now playing" portion of the user interface code for the Public Radio App. And finally, I wrote the radio streaming code used by the PRI app. (A good friend of mine wrote the rest of the code for the PRI app - congrats Rob!).
For the iPad list of featured radio apps there are only 11 apps listed, and Tunemark Radio is one of them!
As an iPhone developer, one always hopes to some day have an app make Apple's "featured" lists on the front page of iTunes, so I am unbelievably happy today to have several make one of Apple's lists.
As for what effect this exposure has on app downloads, I only have access to the stats for the Tunemark Radio app (the rest of the apps are under other developer accounts), but I can say, for my Tunemark Radio app, after one day being on this featured radio app list, the number of downloads have more than doubled. The average daily download count jumped from 500 to over 1100.
Friday, July 2, 2010
Tunemark Radio iPhone app visualizer demo
I put together a video demo of what the Tunemark Radio app music visualizer looks like. I've gotten a few queries from people who didn't realize the app included a visualizer, so hopefully this will give a little more visibility to the feature:
I'd like to stress this this visualizer will work with any audio stream being played in Tunemark Radio. It looks best when the stereo channels have distinct volume levels.
Also, it should be pointed out that the visualization is not using the local microphone to pick up the audio signal, so will also work if you are using headphones or a dock connector. It's not a responsive as a full desktop-based music visualizer, but this is because the iPhone SDK does not provide access to the decoded data packets of MP3 or AAC audio as they are being played. So, instead, I have to only use the audio chaneel gain status words returned by the SDK.
You can download the app for free from iTunes.
Tunemark Radio visualizer demo from Brian Stormont on Vimeo.
Music in the demo is "Not Hip Hoppie" by Digitube (http://digitube.us)
I'd like to stress this this visualizer will work with any audio stream being played in Tunemark Radio. It looks best when the stereo channels have distinct volume levels.
Also, it should be pointed out that the visualization is not using the local microphone to pick up the audio signal, so will also work if you are using headphones or a dock connector. It's not a responsive as a full desktop-based music visualizer, but this is because the iPhone SDK does not provide access to the decoded data packets of MP3 or AAC audio as they are being played. So, instead, I have to only use the audio chaneel gain status words returned by the SDK.
You can download the app for free from iTunes.
Thursday, June 24, 2010
RadioKit SDK demo project now includes support for iOS 4 background audio play
I've update the RadioKit SDK demo XCode project so it now also demonstrates how to perform background audio play and audio control under iOS 4.
Source code for the sample project can be found here:
http://stormyprods.com/products/radiokit.php
The key point to adding support for background audio play under iOS 4 is to add a new entry to your app's info.plist file. You must add a new key called UIBackgroundModes and add the value audio.
If you want you app to also support remote control of the background audio (either via headphone controls or the audio controls on the background app taskbar) you must also add support for remoteControlReceivedWithEvent:. You can see how this was done in the sample MainViewController.m file in the RadioKitDemo XCode project.
Please note: background play is not supported under the simulator. This is a limitation with the simulator, not the sample XCode project.
If you are unfamiliar with the RadioKit SDK, you can read more about it here. It is a static library which greatly simplifies the process of handling streaming audio on the iPhone and iPad including support for pause, rewind and fast forward of the live audio stream. It is licensed on a per-project basis with single project licenses priced at $100 (US dollars). There are no royalty fees. Volume discount pricing is also available.
Source code for the sample project can be found here:
http://stormyprods.com/products/radiokit.php
The key point to adding support for background audio play under iOS 4 is to add a new entry to your app's info.plist file. You must add a new key called UIBackgroundModes and add the value audio.
If you want you app to also support remote control of the background audio (either via headphone controls or the audio controls on the background app taskbar) you must also add support for remoteControlReceivedWithEvent:. You can see how this was done in the sample MainViewController.m file in the RadioKitDemo XCode project.
Please note: background play is not supported under the simulator. This is a limitation with the simulator, not the sample XCode project.
If you are unfamiliar with the RadioKit SDK, you can read more about it here. It is a static library which greatly simplifies the process of handling streaming audio on the iPhone and iPad including support for pause, rewind and fast forward of the live audio stream. It is licensed on a per-project basis with single project licenses priced at $100 (US dollars). There are no royalty fees. Volume discount pricing is also available.
Wednesday, June 9, 2010
Steve Jobs opinion on Analytics on iPhone
I just watched an interview from D8 in which Steve Jobs answers a question regarding the use of analytics within iPhone apps. You can watch the video yourself here, but the short of it is Steve Jobs said Apple is banning some analytics companies because they are collecting user data without notifying the user first and this is in violation of the developer agreement.
I was very surprised to hear him say this, because I don't believe it to be true. Unless an iPhone developer posts their own EULA for their app, an app is distributed under Apple's default EULA, the terms of which (in the US store) can be read here:
http://www.apple.com/legal/itunes/us/terms.html#APPS
And a link to this text appears on the bottom of EVERY iPhone app page (in fine print) within the iTunes app store.
Now, take a close look at this agreement, specifically clause b.
This seems pretty clear to me that according to this default license agreement for every iPhone app, the potential an app is collecting user data is disclosed and is permitted.
Of course, I'm not a lawyer, and I'm sure Steve Jobs must have a reason for feeling this clause does not permit analytics within apps. But, at least to a layman such as myself, it seems pretty clear that the standard agreement for an app does in fact allow such capturing of user data and is disclosing to the user (via this license agreement) that such data collection may occur (which in turn meets the conditions of the developer license agreement).
I was very surprised to hear him say this, because I don't believe it to be true. Unless an iPhone developer posts their own EULA for their app, an app is distributed under Apple's default EULA, the terms of which (in the US store) can be read here:
http://www.apple.com/legal/itunes/us/terms.html#APPS
And a link to this text appears on the bottom of EVERY iPhone app page (in fine print) within the iTunes app store.
Now, take a close look at this agreement, specifically clause b.
b. Consent to Use of Data: You agree that Licensor may collect and use technical data and related information, including but not limited to technical information about your device, system and application software, and peripherals, that is gathered periodically to facilitate the provision of software updates, product support and other services to you (if any) related to the Licensed Application. Licensor may use this information, as long as it is in a form that does not personally identify you, to improve its products or to provide services or technologies to you.
This seems pretty clear to me that according to this default license agreement for every iPhone app, the potential an app is collecting user data is disclosed and is permitted.
Of course, I'm not a lawyer, and I'm sure Steve Jobs must have a reason for feeling this clause does not permit analytics within apps. But, at least to a layman such as myself, it seems pretty clear that the standard agreement for an app does in fact allow such capturing of user data and is disclosing to the user (via this license agreement) that such data collection may occur (which in turn meets the conditions of the developer license agreement).
Monday, May 3, 2010
Photo albums on the iPad
One the advertised aspects of the iPad is how easy it is to view your photo albums. On Apple’s web site, they say, “Your photo albums appear as tidy little stacks you can pinch to preview.”
While viewing photos on the iPad is a natural and fluid experience, one thing that wasn’t obvious to me is how to get my photo albums on the iPad. If you use two of Apple’s products, iPhoto or Aperture, then when you sync your iPad via iTunes you have the option to select specific photo albums to transfer.
But what if you don’t use those two products? In my case, I have over 13,000 photos and I manage them with a competing product from Adobe called Lightroom. I’m not going to switch to using Aperture just because it has a convenient method for putting selective photo albums on the iPad. Surely there must be an answer. And, there is.
In iTunes, when you choose to sync photos to iPad, you have a third option, which is to sync photos from a specific folder. Now this might not seem as useful as what you get from syncing from iPhoto or Aperture where you can pick and choose albums, but it does have one additional nicety. Any subfolders created within this folder appear on iPad as albums!
So, in my case, I have a folder set aside called “iPad” and when I want to sync over several albums from Lightroom, simply create a different subfolder for each album within this “iPad” folder. These albums are then available to be selected for the built-in Picture Frame feature of the iPad’s lock screen. (You can choose the albums to be displayed in the Picture Frame via the Settings app on iPad.)
One important note: if you don’t create a subfolder and instead simply put the photos in the main sync folder, they don’t end up appearing in any album on the iPad after you sync. They just appear in “Saved Photos” along with all your screenshots and other miscellaneous images.
While viewing photos on the iPad is a natural and fluid experience, one thing that wasn’t obvious to me is how to get my photo albums on the iPad. If you use two of Apple’s products, iPhoto or Aperture, then when you sync your iPad via iTunes you have the option to select specific photo albums to transfer.
But what if you don’t use those two products? In my case, I have over 13,000 photos and I manage them with a competing product from Adobe called Lightroom. I’m not going to switch to using Aperture just because it has a convenient method for putting selective photo albums on the iPad. Surely there must be an answer. And, there is.
In iTunes, when you choose to sync photos to iPad, you have a third option, which is to sync photos from a specific folder. Now this might not seem as useful as what you get from syncing from iPhoto or Aperture where you can pick and choose albums, but it does have one additional nicety. Any subfolders created within this folder appear on iPad as albums!
So, in my case, I have a folder set aside called “iPad” and when I want to sync over several albums from Lightroom, simply create a different subfolder for each album within this “iPad” folder. These albums are then available to be selected for the built-in Picture Frame feature of the iPad’s lock screen. (You can choose the albums to be displayed in the Picture Frame via the Settings app on iPad.)
One important note: if you don’t create a subfolder and instead simply put the photos in the main sync folder, they don’t end up appearing in any album on the iPad after you sync. They just appear in “Saved Photos” along with all your screenshots and other miscellaneous images.
Thursday, April 22, 2010
Tunemark Radio 1.8, now available
Tunemark Radio is now available for both iPhone and iPad on iTunes. There’s still just one app to download but it is now optimized for iPhone and also the larger iPad screen.
This app is designed to be a FREE alternative for playing Internet radio stations, without the annoying ad banners. If you have any suggestions for improvements to this app, please contact Stormy Productions and pass along your thoughts. You can read a full description of the app here.
This latest version significantly improves the “Buy on iTunes” feature. When you now choose that option, you will be presented with a list of matching songs currently available on iTunes. This way, you can verify the song you want to buy is going to be available before you launch iTunes and exit the app. There’s no sense stopping the music and launching iTunes only to be disappointed to find the song isn’t for sale there.
PLEASE NOTE: this most recent version of Tunemark Radio was required by Apple to remove the feature for playing 128K and higher bitrate streams over the 3G and Edge networks. This was not something we wanted to do, but Apple would not approve this update without the bandwidth limit for cellular usage. I’m sure many of you will be disappointed by this change, but please understand it was a requirement from Apple. We will continue to investigate whether Apple may allow this feature again some time in the future, and if the policy is changed, we will update the app accordingly.
Thanks for all the comments, suggestions, and even the complaints. All the feedback is helpful to continuously improve this app.
This app is designed to be a FREE alternative for playing Internet radio stations, without the annoying ad banners. If you have any suggestions for improvements to this app, please contact Stormy Productions and pass along your thoughts. You can read a full description of the app here.
This latest version significantly improves the “Buy on iTunes” feature. When you now choose that option, you will be presented with a list of matching songs currently available on iTunes. This way, you can verify the song you want to buy is going to be available before you launch iTunes and exit the app. There’s no sense stopping the music and launching iTunes only to be disappointed to find the song isn’t for sale there.
PLEASE NOTE: this most recent version of Tunemark Radio was required by Apple to remove the feature for playing 128K and higher bitrate streams over the 3G and Edge networks. This was not something we wanted to do, but Apple would not approve this update without the bandwidth limit for cellular usage. I’m sure many of you will be disappointed by this change, but please understand it was a requirement from Apple. We will continue to investigate whether Apple may allow this feature again some time in the future, and if the policy is changed, we will update the app accordingly.
Thanks for all the comments, suggestions, and even the complaints. All the feedback is helpful to continuously improve this app.
Tuesday, April 20, 2010
More Thoughts on iPad Development Decisions
I currently have two iPad apps available in iTunes. One, Artificial Life HD, is an iPad specific app which is a modified version of my Artificial Life iPhone app. I initially struggled with the decision of whether to release the iPad version of the app as a universal app, compatible with both iPhone and iPad, or as two separate apps. After doing some initial work in pursuing a universal app design, I decided it would be better to have an iPad-specific version.
There were mainly 3 reasons for this decision.
First, the iPhone app is currently slightly under 20 meg in size. 20 meg is an important number for iPhone apps. If an app is larger than 20 meg, Apple will not allow the app to downloaded via the cellular network. This has the potential for lost sales. Adding support for the iPad required adding higher resolution artwork and some iPad-specific code additions which made it very likely that the app would be larger than 20 meg.
Second, due to some early decisions I had made in the design of the the iPhone app, it was going to be very tedious to make the app run-time compatible with both iPad and iPhone. It was definitely possible, but a lot of time could be saved by making the iPad changes compile-time rather than run-time.
Third, while both the iPad and iPhone versions are nearly identical in functionality right now, I hope to be adding features to the iPad version which take better advantage of the larger screen area. Having the apps as two separate and distinct versions in the app store made the most sense.
My second iPad app is a universal app - Tunemark Radio. Tunemark Radio is a free streaming radio player which supports the full SHOUTcast directory as well as adding custom streams via pls, m3u or other custom URL formats. It supports both mp3 and AAC+ audio formats. It also has a few unique features such as support for custom wall-paper and a built-in fullscreen visualizer which reacts to the music. In the case of this app, a universal app made the most sense. The app binary is quite small (about 1 meg) and there will be little change in functionality between the two apps. The iPad version required a new layout, which meant new iPad specific view controllers, but the code differences were minor and were easy to handle during run-time.
In addition to becoming more familiar with the iPad vs. iPhone differences while adding iPad support for these apps, I learned a few important details during the app submission process.
1) When using a UIPopoverController, it is very important that you test that the popover continues to point to the correct section of the iPad screen as the screen is rotated to various orientations. This means testing rotating the screen while the popover is being displayed, not just testing the popover’s initial appearance in each orientation. I had the Artificial Life HD app rejected because one of my popovers did not redisplay itself with the arrow pointing to the proper button after the screen was rotated. I had never thought to test that behavior and has falsely assumed it would be handled automatically via the iPhone SDK internal logic. This is not the case.
In order to have your popover redisplayed properly when the screen is rotated, you must first save all the popover attributes to some state variables. This includes saving the sender which initiated the popover, the containing view, the popover arrow position, and a pointer to the popover itself. Here’s a snippet of code displaying a popover and saving some of the creation details:
Class classPopoverController = NSClassFromString(@"UIPopoverController");
id aPopover = [[classPopoverController alloc] initWithContentViewController:navController];
activePopover = aPopover;
activePopoverSender = sender;
activePopoverView = sidebarView;
activePopoverArrowDirection = UIPopoverArrowDirectionLeft;
[aPopover presentPopoverFromRect:[activePopoverSender frame] inView:activePopoverView permittedArrowDirections:activePopoverArrowDirection animated:YES];
I suggest saving the sender rather than the sender’s frame because when the screen orientation changes, the sender’s frame could change position and size, so you want to be able to get the current frame size and position, not the size and position when the popover was first displayed.
Then, you need to add some code in the view controller’s didRotateFromInterfaceOrientation to check for the presence of a popover, and if one is active, redisplay it. Here’s an example:
- (void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation
{
if (activePopover){
[activePopover presentPopoverFromRect:[activePopoverSender frame] inView:activePopoverView permittedArrowDirections:activePopoverArrowDirection animated:NO];
}
}
Even though the popover is already being displayed, it’s OK to call presentPopoverFromRect: again. Doing this has the effect of simply redisplaying the existing popover at the proper new orientation. If you don’t do this, sometimes the popover will rotate properly, but in most cases it will not and if Apple notices this, your app will be rejected.
2) On the iPad, Apple strongly suggests supporting all orientations. If you do support all orientations, then it is critical that all views display at the proper current orientation.
This seems like an obvious point, however if you are converting an app from an iPhone-specific project and you have lots of view controllers, it’s easy to overlook adjusting a view controller so it supports all the orientations. As a result, you need to make sure you test every single view at every single orientation while testing the app. It may not be immediately obvious if some buried menu item is only displaying at one orientation. It’s an easy enough fix if you do discover something comes out wrong - just find the view controller responsible and make sure shouldAutorotateToInterfaceOrientation returns the proper value for iPad.
If you are doing this in a universal app and the iPhone version only supports one orientation, here’s an easy way to handle it:
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
// Return YES for supported orientations
if (UI_USER_INTERFACE_IDIOM() != UIUserInterfaceIdiomPad){
return (interfaceOrientation == UIInterfaceOrientationPortrait);
}else{
return YES;
}
}
3) If using a UIPicker (such as date picker) on iPad, it must appear within a UIPopoverController. This is mentioned in the HIG, but it's just one sentence and is easy to overlook. If you don't display a picker within a popover, Apple will reject your iPad app. I'm not sure why this is a requirement, but rules are rules, as they say.
These are some fairly simple examples, but may be easy to overlook the first time you create an iPad app from an existing iPhone project. Hopefully they can help someone else avoid time lost in resubmitting an app.
There were mainly 3 reasons for this decision.
First, the iPhone app is currently slightly under 20 meg in size. 20 meg is an important number for iPhone apps. If an app is larger than 20 meg, Apple will not allow the app to downloaded via the cellular network. This has the potential for lost sales. Adding support for the iPad required adding higher resolution artwork and some iPad-specific code additions which made it very likely that the app would be larger than 20 meg.
Second, due to some early decisions I had made in the design of the the iPhone app, it was going to be very tedious to make the app run-time compatible with both iPad and iPhone. It was definitely possible, but a lot of time could be saved by making the iPad changes compile-time rather than run-time.
Third, while both the iPad and iPhone versions are nearly identical in functionality right now, I hope to be adding features to the iPad version which take better advantage of the larger screen area. Having the apps as two separate and distinct versions in the app store made the most sense.
My second iPad app is a universal app - Tunemark Radio. Tunemark Radio is a free streaming radio player which supports the full SHOUTcast directory as well as adding custom streams via pls, m3u or other custom URL formats. It supports both mp3 and AAC+ audio formats. It also has a few unique features such as support for custom wall-paper and a built-in fullscreen visualizer which reacts to the music. In the case of this app, a universal app made the most sense. The app binary is quite small (about 1 meg) and there will be little change in functionality between the two apps. The iPad version required a new layout, which meant new iPad specific view controllers, but the code differences were minor and were easy to handle during run-time.
In addition to becoming more familiar with the iPad vs. iPhone differences while adding iPad support for these apps, I learned a few important details during the app submission process.
1) When using a UIPopoverController, it is very important that you test that the popover continues to point to the correct section of the iPad screen as the screen is rotated to various orientations. This means testing rotating the screen while the popover is being displayed, not just testing the popover’s initial appearance in each orientation. I had the Artificial Life HD app rejected because one of my popovers did not redisplay itself with the arrow pointing to the proper button after the screen was rotated. I had never thought to test that behavior and has falsely assumed it would be handled automatically via the iPhone SDK internal logic. This is not the case.
In order to have your popover redisplayed properly when the screen is rotated, you must first save all the popover attributes to some state variables. This includes saving the sender which initiated the popover, the containing view, the popover arrow position, and a pointer to the popover itself. Here’s a snippet of code displaying a popover and saving some of the creation details:
Class classPopoverController = NSClassFromString(@"UIPopoverController");
id aPopover = [[classPopoverController alloc] initWithContentViewController:navController];
activePopover = aPopover;
activePopoverSender = sender;
activePopoverView = sidebarView;
activePopoverArrowDirection = UIPopoverArrowDirectionLeft;
[aPopover presentPopoverFromRect:[activePopoverSender frame] inView:activePopoverView permittedArrowDirections:activePopoverArrowDirection animated:YES];
I suggest saving the sender rather than the sender’s frame because when the screen orientation changes, the sender’s frame could change position and size, so you want to be able to get the current frame size and position, not the size and position when the popover was first displayed.
Then, you need to add some code in the view controller’s didRotateFromInterfaceOrientation to check for the presence of a popover, and if one is active, redisplay it. Here’s an example:
- (void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation
{
if (activePopover){
[activePopover presentPopoverFromRect:[activePopoverSender frame] inView:activePopoverView permittedArrowDirections:activePopoverArrowDirection animated:NO];
}
}
Even though the popover is already being displayed, it’s OK to call presentPopoverFromRect: again. Doing this has the effect of simply redisplaying the existing popover at the proper new orientation. If you don’t do this, sometimes the popover will rotate properly, but in most cases it will not and if Apple notices this, your app will be rejected.
2) On the iPad, Apple strongly suggests supporting all orientations. If you do support all orientations, then it is critical that all views display at the proper current orientation.
This seems like an obvious point, however if you are converting an app from an iPhone-specific project and you have lots of view controllers, it’s easy to overlook adjusting a view controller so it supports all the orientations. As a result, you need to make sure you test every single view at every single orientation while testing the app. It may not be immediately obvious if some buried menu item is only displaying at one orientation. It’s an easy enough fix if you do discover something comes out wrong - just find the view controller responsible and make sure shouldAutorotateToInterfaceOrientation returns the proper value for iPad.
If you are doing this in a universal app and the iPhone version only supports one orientation, here’s an easy way to handle it:
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
// Return YES for supported orientations
if (UI_USER_INTERFACE_IDIOM() != UIUserInterfaceIdiomPad){
return (interfaceOrientation == UIInterfaceOrientationPortrait);
}else{
return YES;
}
}
3) If using a UIPicker (such as date picker) on iPad, it must appear within a UIPopoverController. This is mentioned in the HIG, but it's just one sentence and is easy to overlook. If you don't display a picker within a popover, Apple will reject your iPad app. I'm not sure why this is a requirement, but rules are rules, as they say.
These are some fairly simple examples, but may be easy to overlook the first time you create an iPad app from an existing iPhone project. Hopefully they can help someone else avoid time lost in resubmitting an app.
Saturday, April 17, 2010
"The iPad isn't a computer"
You aren't buying a computer when you buy an iPad, you are buying a 16GB Walmart store shelf that fits on your lap - complete with all the supplier beat downs, slotting fees, and exclusive deals that go with it - and Apple got you to pay for the building.-Jim Stogdill, O'Reilly Radar
The above is just a short quote from a very thought provoking article regarding the closed ecosystem of Apple's new iPad. It's got me feeling a bit conflicted since I agree most of what he wrote, I just I hadn't thought of it from that perspective before.
As I've mentioned in another forum, I can understand the idea of having to lock down the iPhone for potential adverse affects on the cell network, but the iPad is another story.
Wednesday, April 14, 2010
Hitting the Moving Target - the inconsistent app review process
Just when I was starting to think Apple’s review process was getting better, fairer, and more consistent, I get proved wrong. Maybe Apple’s employees are getting spring fever or something and need to take out their excess energy on their clients.
As I mentioned a few days ago, I had a couple of radio station apps rejected because the reviewer thought they should be combined into one app via In-App Purchase. Never mind that these were free apps and In-App Purchase, as the name implies, requires the extra content be something that you actually purchase. The main point was these apps were for two different radio stations, and each station wanted their own app. There are literally hundreds of these apps already in the iTunes store. Radio stations want to have their own app - they can advertise it on air (“Hey, download our iPhone app”) and they can have their own icon on the iPhone.
So, the good news for me is the two rejected apps were finally approved, but in typical fashion, Apple made no comment or explanation or ever answered my query as to what the issue was. One app just mysteriously changed state from rejected to approved without me even resubmitting it. Apple simply sent an automated message saying, “Thank you for the additional information. We will continue with the review process and will inform you of any update.” and later “Thank you for contacting the iPhone Developer Program. Our records indicate [your app] has been flagged 'Ready for Sale', and should be available via iTunes shortly.” No explanation of whether a mistake had been made originally, or whether there’s something I could have done to avoid the misunderstanding in the first place.
It reminds me of when we used to have Internet problems at a company I used to work for and we would call our service provider (the local telco at the time) and they’d say “There’s no known problem or work being done with the network.” Meanwhile, we’d look out the window and see the local telco company’s truck parked outside and a guy working on the wires. And, of course, the Internet service would mysteriously start working again after the truck drove away.
But that’s not my point. That’s just me ranting.
My point is the app review process still needs improvement. It has improved as far as timeliness goes, but it still has serious problems. Developers need some sort of consistency and transparency in the process. Receiving boiler-plate email is not helpful, especially when there is a problem that affects your business. In my case, I had several clients projects on hold. I wasn’t even sure if I could continue my existing business model of developing apps on behalf of radio stations. Actually, I still don’t know if I can for certain. I never received a definitive answer from Apple* . The last thing I want is to be doing work for a client, only to find out at the end that I can’t fulfill what was promised due to something out of my control (Apple’s review process).
Here’s another example of the app review inconsistency. Today, Tunemark Radio, an app which allows playing thousands of radio stations in the SHOUTcast directory, was rejected for the reason that “it is transferring excessive volumes of data over the cellular network.” Apple went on to explain that all apps:
The problem is, the above two lines of text are all Apple will officially say about cellular usage. Apple will not provide any exact numbers. It’s not like we’re trying to define how many angels can dance on the head of a pin. The app reviewers must be looking at a specific cut-off number. Why can’t we be told what that number is?
Last year, I had sent a formal (paid) tech support query to Apple asking for clarification on this policy. The engineer who replied stated that there was no official bandwidth usage number to stay under, but instead said I should look at the amount of bandwidth used by the Pandora app and stay around that amount. While the Apple engineer said it wasn’t an official number, he said to stay around 4.5 meg over a 5 minute time period was a safe number. That works out to around 112K/sec. And that was the advice I had followed for about a year.
Then, about 6 months ago I noticed there were many competing radio apps in the iTunes store that were using streams at the 128K/sec rate and I was receiving complaints with my apps because they did not allow 128K streams to be played over cellular. I sent another email to Apple asking if their bandwidth polices had changed and the response was no, the bandwidth limits were the same. But, I could clearly see that based on what was being approved, 128K streams were being allowed. I thought maybe 128K was considered close enough to 112K to be allowed So, I modified my apps to allow 128K, and sure enough, they were approved.
Now, this brings us to today’s rejection. Is it that 128K is no longer permitted over cellular, or was it never allowed but the reviewers hadn’t been paying attention for the past 6 months? I know one thing is certain. Based on past experience, I’m not going to get any helpful answer from Apple. In fact, I’m 100% certain of it. Here’s my query to Apple:
And here is Apple’s official reply received a few minutes ago:
That's all. Now I’m not a man who easily curses, but this response is testing my self control. Are Apple’s replies generated by robots?? Maybe they’re using the old Eliza program to answer support queries. It certainly doesn't look like an English speaking human read my question.
Regardless, one thing I've learned is there's no arguing with the Apple brick wall. You state your case, hope to get a reasonable answer, but regardless of what answer is received, you move on. Repeated queries gets you nowhere. I’m going to have to resubmit my app, disabling the 128K access (which has been available in this app for the past 6 months) and as a result have lots of unhappy users. I’m tempted to have a dialog box pop up saying the 128K is not permitted due to Apple’s policy, but last time I mentioned something like this in my app description, Apple called me on the phone and requested I remove the text before the app would be approved. Seriously. Apple would not approve a feature of my app, but I was not allowed to mention in the description that the feature was removed per Apple’s request. Instead, I get to just deal with negative reviews from unhappy users without being able to offer an explanation.
And that’s my point. The review process seems to be a moving target, changing at the whim of Apple. This being just one example, too many of Apple’s policies are intentionally vaguely worded. It makes life for us developers more challenging than it should be. Yes, when I joined the iPhone developer program I signed an agreement giving Apple the right to reject an app for any arbitrary reason, but it still doesn’t mean I have to be happy about it. And, as much as I may complain about the process, I still find the Apple development environment the best to work with given the alternatives. I’m not jumping ship just yet. It’s just unfortunate that things could be so much better.
* UPDATE: Coincidentally, about an hour after posting this, I received a phone call from Apple regarding the two radio station app rejection and subsequent acceptance. The person I spoke with on the phone wanted to clarify that Apple doesn't have a specific policy regarding single radio station apps. It is just that they would prefer that apps be combined if at all possible (such as two stations from the same company serving the same city).
As I mentioned a few days ago, I had a couple of radio station apps rejected because the reviewer thought they should be combined into one app via In-App Purchase. Never mind that these were free apps and In-App Purchase, as the name implies, requires the extra content be something that you actually purchase. The main point was these apps were for two different radio stations, and each station wanted their own app. There are literally hundreds of these apps already in the iTunes store. Radio stations want to have their own app - they can advertise it on air (“Hey, download our iPhone app”) and they can have their own icon on the iPhone.
So, the good news for me is the two rejected apps were finally approved, but in typical fashion, Apple made no comment or explanation or ever answered my query as to what the issue was. One app just mysteriously changed state from rejected to approved without me even resubmitting it. Apple simply sent an automated message saying, “Thank you for the additional information. We will continue with the review process and will inform you of any update.” and later “Thank you for contacting the iPhone Developer Program. Our records indicate [your app] has been flagged 'Ready for Sale', and should be available via iTunes shortly.” No explanation of whether a mistake had been made originally, or whether there’s something I could have done to avoid the misunderstanding in the first place.
It reminds me of when we used to have Internet problems at a company I used to work for and we would call our service provider (the local telco at the time) and they’d say “There’s no known problem or work being done with the network.” Meanwhile, we’d look out the window and see the local telco company’s truck parked outside and a guy working on the wires. And, of course, the Internet service would mysteriously start working again after the truck drove away.
But that’s not my point. That’s just me ranting.
My point is the app review process still needs improvement. It has improved as far as timeliness goes, but it still has serious problems. Developers need some sort of consistency and transparency in the process. Receiving boiler-plate email is not helpful, especially when there is a problem that affects your business. In my case, I had several clients projects on hold. I wasn’t even sure if I could continue my existing business model of developing apps on behalf of radio stations. Actually, I still don’t know if I can for certain. I never received a definitive answer from Apple
Here’s another example of the app review inconsistency. Today, Tunemark Radio, an app which allows playing thousands of radio stations in the SHOUTcast directory, was rejected for the reason that “it is transferring excessive volumes of data over the cellular network.” Apple went on to explain that all apps:
- Must comply with Apple's best practices and other guidelines on how Applications should access and use the cellular network;
- Must not in Apple's reasonable judgment excessively use or unduly burden network capacity or bandwidth;
The problem is, the above two lines of text are all Apple will officially say about cellular usage. Apple will not provide any exact numbers. It’s not like we’re trying to define how many angels can dance on the head of a pin. The app reviewers must be looking at a specific cut-off number. Why can’t we be told what that number is?
Last year, I had sent a formal (paid) tech support query to Apple asking for clarification on this policy. The engineer who replied stated that there was no official bandwidth usage number to stay under, but instead said I should look at the amount of bandwidth used by the Pandora app and stay around that amount. While the Apple engineer said it wasn’t an official number, he said to stay around 4.5 meg over a 5 minute time period was a safe number. That works out to around 112K/sec. And that was the advice I had followed for about a year.
Then, about 6 months ago I noticed there were many competing radio apps in the iTunes store that were using streams at the 128K/sec rate and I was receiving complaints with my apps because they did not allow 128K streams to be played over cellular. I sent another email to Apple asking if their bandwidth polices had changed and the response was no, the bandwidth limits were the same. But, I could clearly see that based on what was being approved, 128K streams were being allowed. I thought maybe 128K was considered close enough to 112K to be allowed So, I modified my apps to allow 128K, and sure enough, they were approved.
Now, this brings us to today’s rejection. Is it that 128K is no longer permitted over cellular, or was it never allowed but the reviewers hadn’t been paying attention for the past 6 months? I know one thing is certain. Based on past experience, I’m not going to get any helpful answer from Apple. In fact, I’m 100% certain of it. Here’s my query to Apple:
What is the threshold at which you determine an app is "transferring excessive volumes of data over the cellular network"? What number should the app stay under? Nothing has changed in the app in regards to cellular bandwidth-usage from this version from the previous approved 1.6 version.
Without know what number the app should stay within, it is hard for me to know what needs to be changed.
Thank you for any clarification you can provide.
Best regards,
Brian
And here is Apple’s official reply received a few minutes ago:
In order for your application to be reconsidered for the App Store, please resolve this issue and upload your new binary to iTunes Connect.
That's all. Now I’m not a man who easily curses, but this response is testing my self control. Are Apple’s replies generated by robots?? Maybe they’re using the old Eliza program to answer support queries. It certainly doesn't look like an English speaking human read my question.
Regardless, one thing I've learned is there's no arguing with the Apple brick wall. You state your case, hope to get a reasonable answer, but regardless of what answer is received, you move on. Repeated queries gets you nowhere. I’m going to have to resubmit my app, disabling the 128K access (which has been available in this app for the past 6 months) and as a result have lots of unhappy users. I’m tempted to have a dialog box pop up saying the 128K is not permitted due to Apple’s policy, but last time I mentioned something like this in my app description, Apple called me on the phone and requested I remove the text before the app would be approved. Seriously. Apple would not approve a feature of my app, but I was not allowed to mention in the description that the feature was removed per Apple’s request. Instead, I get to just deal with negative reviews from unhappy users without being able to offer an explanation.
And that’s my point. The review process seems to be a moving target, changing at the whim of Apple. This being just one example, too many of Apple’s policies are intentionally vaguely worded. It makes life for us developers more challenging than it should be. Yes, when I joined the iPhone developer program I signed an agreement giving Apple the right to reject an app for any arbitrary reason, but it still doesn’t mean I have to be happy about it. And, as much as I may complain about the process, I still find the Apple development environment the best to work with given the alternatives. I’m not jumping ship just yet. It’s just unfortunate that things could be so much better.
Saturday, April 10, 2010
Linking to an iTunes search via an app
In many of the radio station apps I've developed, the station wants a way for the listener to choose to buy on iTunes the current playing song. Since most stations don't provide the iTunes ID of the song as part of the "Now Playing" information, the best option I've been able to come up with is to have the app launch iTunes using a searching string.
For example, suppose the station was playing the song by the Talking Heads, called "And She Was". A station might simply provide this as "Talking Heads - And She Was" without any indication of who the artist is and what the song title is (other than what may, or may not be correctly inferred from the dash). Performing an iTunes search, this doesn't really matter.
You can use a URL like the following to do a blanket search on iTunes:
http://phobos.apple.com/WebObjects/MZSearch.woa/wa/search?submit=edit&media=all&term=talking%20heads%20and%20she%20was
Simply launch this URL from within your app and iTunes will automatically launch and perform the requested search.
This will work on both iPhone and iPad. Please note: if you omit the "media=all" term, the search will return on error on the iPad.
You aren't limited to searching for music. You could also do a search for movies, or apps, etc.
For example, suppose the station was playing the song by the Talking Heads, called "And She Was". A station might simply provide this as "Talking Heads - And She Was" without any indication of who the artist is and what the song title is (other than what may, or may not be correctly inferred from the dash). Performing an iTunes search, this doesn't really matter.
You can use a URL like the following to do a blanket search on iTunes:
http://phobos.apple.com/WebObjects/MZSearch.woa/wa/search?submit=edit&media=all&term=talking%20heads%20and%20she%20was
Simply launch this URL from within your app and iTunes will automatically launch and perform the requested search.
This will work on both iPhone and iPad. Please note: if you omit the "media=all" term, the search will return on error on the iPad.
You aren't limited to searching for music. You could also do a search for movies, or apps, etc.
Thursday, April 8, 2010
My oddest iPhone rejection yet
I develop iPhone apps mainly on a contract basis with a large focus on radio stations. Most radio stations don't have in-house programmers who are skilled with developing apps, so I am often contracted to develop an app for a station. Since they often lack any in-house programmers they often also ask me to host the app using my iPhone developer account. I've been doing this for about a year and a half and have about 50 radio apps under my developer account.
Today I received the oddest rejection from Apple for a pair of iPhone apps I had submitted for two different radio stations. Apple rejected the apps with the explanation that they were of a similar "Family of radio applications" and "should be packaged in a single application using In App Purchase".
There are a couple obvious problems with this. First, these apps were created for two different radio stations and each station wanted their own app. From a radio station's point of view, it's good advertising for them to have their own app which they can offer their listeners. They don't want to have their station just within some larger list of stations in a single app. It's all about branding.
The second problem with this is the radio stations want their apps to be available for free. Using in-app purchase would not make sense.
I replied to Apple explaining how combining the two apps is not an option, but I haven't yet heard back. I'm hopeful this isn't the start of a new policy on Apple's part prohibiting apps for individual radio stations.
UPDATE 4/13/2010: The two apps have now been approved, although I never received any clarification from Apple regarding my inquiry. The apps just suddenly became approved. Best I can assume is the original reviewer had made a mistake.
Today I received the oddest rejection from Apple for a pair of iPhone apps I had submitted for two different radio stations. Apple rejected the apps with the explanation that they were of a similar "Family of radio applications" and "should be packaged in a single application using In App Purchase".
There are a couple obvious problems with this. First, these apps were created for two different radio stations and each station wanted their own app. From a radio station's point of view, it's good advertising for them to have their own app which they can offer their listeners. They don't want to have their station just within some larger list of stations in a single app. It's all about branding.
The second problem with this is the radio stations want their apps to be available for free. Using in-app purchase would not make sense.
I replied to Apple explaining how combining the two apps is not an option, but I haven't yet heard back. I'm hopeful this isn't the start of a new policy on Apple's part prohibiting apps for individual radio stations.
UPDATE 4/13/2010: The two apps have now been approved, although I never received any clarification from Apple regarding my inquiry. The apps just suddenly became approved. Best I can assume is the original reviewer had made a mistake.
Sunday, April 4, 2010
The Good and the Bad: iPad from a Developer's Point of View
Like lots of other Apple-faithful, I had pre-ordered and iPad and received it on iPad launch day yesterday - April 3rd. Since I develop software for the iPhone and iPad, it was a definite requirement to have an iPad in-house for testing as soon as possible.
While I did have a native iPad app (Artificial Life - HD) ready for sale on launch day, it was a bit of a leap-of-faith endeavor. The Artificial Life app makes use of a lot of texture maps via OpenGL and the performance on the provided iPad simulator from Apple was less than ideal. In all my initial development and testing using the simulator, the frame rate was pretty poor - around 9 frame-per-second. Since it was not possible to test on a real device before the iPad launch day, the simulator was the only available baseline. I knew based on iPhone testing that for certain optimized OpenGL operations (such as using PVRTC textures) the simulator was significantly slower than the iPhone hardware, but for a lot of other simpler operations the simulator was faster than the iPhone.
Apple had required that in order for an iPad app to be guaranteed available in iTunes on launch day, the app had to be submitted to Apple for initial review approximately a week before the launch date. Not wanting to miss the opportunity to be in the store on launch day, I optimized things best I could and sent the app to Apple for review. Thankfully, Apple approved the app with no comments regarding poor performance, but still I was a bit apprehensive. I did however have a fail-safe option. Since I knew I’d be getting my own iPad on launch day, worst case, if the performance was really bad, I could just remove the app from the store. Thankfully, that turned out to be unnecessary.
The Good
The iPad turns out to be one speedy hand-held device. My own app, which ran at a poor 9 frames-per-second in the simulator was running at a smooth 35 frames-per-second on the actual iPad. Because of this, I’ll now be able to make some significant enhancements to future updates of this app - the main one being able to increase the population cap from 300 individual protozoa to over 1000, without much a noticeable change in frame rate.
Others have done some benchmark comparisons of the iPAd processing speed vs. the iPhone 3GS and the results are impressive. For CPU operations the iPad is on average about twice as fast as the iPhone. Based on what I am seeing with OpenGL performance, I suspect the graphics chip may be more than twice as fast than the one in the iPhone 3GS.
While the iPad shares much of the same SDK functionality as the iPhone, the larger screen on the iPad makes possible a lot more functionality than the iPhone. Those who say the iPad is just a larger iPhone are missing the point. The iPad isn’t just a larger iPhone. A more accurate comparison might be to say the iPad is a smaller laptop. The things you can do on an iPad are a lot closer to laptop activities than iPhone activities, and once you start developing applications for the iPad this quickly becomes apparent. While a lot of existing iPhone apps will initially be blown-up iPhone apps, in the long term there will be a much richer experience available with the iPad versions of apps in comparison to iPhone apps.
XCode project conversions
Since many developers will have existing iPhone apps, Apple has made it fairly easy to do an initial port over to the iPad from an iPhone project. There’s a built in menu item which gives the option to convert a project either to a Universal app (which supports both iPhone and iPad) or modify the project to it now contains two separate targets - one for iPhone and one for iPhone. Both options have there plusses and minuses.
A Universal app means just one listing in the iTunes store - someone can buy your app and not have to pay attention to what device it runs on. The drawback is more on the developer side. You have to do run-time checking for which device you are running on and present the appropriate UI. Also, you app will have to contain all nib files and artwork for both versions in one bundle, leading to larger binary sizes.
The double-target approach has the benefit of more easily being able to segment your code. You can use macros to conditionally compile code based on the target. This is the approach I used for Artificial Life.
In either approach, when the XCode project conversion first runs, it automatically creates iPad versions of all your nibs, although their sizes have not automatically been updated - you still have to do that by hand, properly adjusting where all the subviews and controls should be. Also, since Apple highly recommends supporting every view orientation, you’ll want to make sure you have the proper resizing and positioning options so your controls are placed properly as the views rotation. I found this was one of the most time consuming parts of my application porting to the iPad.
Pop-overs are your Friend
One very handy new UI element for porting and iPhone app to iPad is the UIPopoverController. As the name implies, it’s a window that appears over a portion of the screen. From a developer’s perspective, think of it as a modal View Controller that isn’t full screen. What is nice about these is they can take a UIViewController as an argument when they are initialized. This makes converting existing helper view controllers very simple. If you previously had a UIViewController on the iPhone which was used for configuring something, you can easily re-use it as a pop-over without having to change any of the underlying UIViewController code. Just make the pop-over the same size as the original iPhone UIViewController and you instantly have your existing view controller now working as a pop-over.
Using this approach is very helpful if you want to make a fairly rapid port of an existing iPhone app. For example, using this technique I was able to have a fully working iPad version of my existing Artificial Life iPhone app in just one day. For iPad, Apple discourages the use of full-screen transitions which were common on the iPhone (such as animated page slides), so using pop-overs for such content is an easy solution. Granted, long term I’ll be making a lot more enhancements to the iPad version of the app to take better advantage of the larger screen real estate, but short term, this was a quick way to get something up and running with a fairly good presentation.
The Bad - the iPad App Store
One thing with which I was very disappointed on launch day was the iPad App Store. For an indie software developer without a large advertising budget, the new design for the app store is absolutely terrible. As of this date, Apple no longer provides a way to browse the full categories of the app store. Sure, they list all the store categories (music, games, education, etc.), but going to view any one category now gives a limited “New and Noteworthy” view sometimes accompanied by a “What’s Hot” category. Completely lacking is a way to browse all the apps in the category. If you aren’t lucky enough to have your app featured by Apple, the only way a customer will find it is via keyword searching.
I’m hoping this is just an opening weekend glitch, but nevertheless this was a huge disappointment, especially after Apple had encouraged developers to have their apps ready for launch day. Shopping the iTunes store via iPad right now feels sorta like walking into a Wal-Mart and only being allowed to walk into the first 20 feet of the store. Anything else you might want to buy, you have to ask someone to get from the back room for you.
While I did have a native iPad app (Artificial Life - HD) ready for sale on launch day, it was a bit of a leap-of-faith endeavor. The Artificial Life app makes use of a lot of texture maps via OpenGL and the performance on the provided iPad simulator from Apple was less than ideal. In all my initial development and testing using the simulator, the frame rate was pretty poor - around 9 frame-per-second. Since it was not possible to test on a real device before the iPad launch day, the simulator was the only available baseline. I knew based on iPhone testing that for certain optimized OpenGL operations (such as using PVRTC textures) the simulator was significantly slower than the iPhone hardware, but for a lot of other simpler operations the simulator was faster than the iPhone.
Apple had required that in order for an iPad app to be guaranteed available in iTunes on launch day, the app had to be submitted to Apple for initial review approximately a week before the launch date. Not wanting to miss the opportunity to be in the store on launch day, I optimized things best I could and sent the app to Apple for review. Thankfully, Apple approved the app with no comments regarding poor performance, but still I was a bit apprehensive. I did however have a fail-safe option. Since I knew I’d be getting my own iPad on launch day, worst case, if the performance was really bad, I could just remove the app from the store. Thankfully, that turned out to be unnecessary.
The Good
The iPad turns out to be one speedy hand-held device. My own app, which ran at a poor 9 frames-per-second in the simulator was running at a smooth 35 frames-per-second on the actual iPad. Because of this, I’ll now be able to make some significant enhancements to future updates of this app - the main one being able to increase the population cap from 300 individual protozoa to over 1000, without much a noticeable change in frame rate.
Others have done some benchmark comparisons of the iPAd processing speed vs. the iPhone 3GS and the results are impressive. For CPU operations the iPad is on average about twice as fast as the iPhone. Based on what I am seeing with OpenGL performance, I suspect the graphics chip may be more than twice as fast than the one in the iPhone 3GS.
While the iPad shares much of the same SDK functionality as the iPhone, the larger screen on the iPad makes possible a lot more functionality than the iPhone. Those who say the iPad is just a larger iPhone are missing the point. The iPad isn’t just a larger iPhone. A more accurate comparison might be to say the iPad is a smaller laptop. The things you can do on an iPad are a lot closer to laptop activities than iPhone activities, and once you start developing applications for the iPad this quickly becomes apparent. While a lot of existing iPhone apps will initially be blown-up iPhone apps, in the long term there will be a much richer experience available with the iPad versions of apps in comparison to iPhone apps.
XCode project conversions
Since many developers will have existing iPhone apps, Apple has made it fairly easy to do an initial port over to the iPad from an iPhone project. There’s a built in menu item which gives the option to convert a project either to a Universal app (which supports both iPhone and iPad) or modify the project to it now contains two separate targets - one for iPhone and one for iPhone. Both options have there plusses and minuses.
A Universal app means just one listing in the iTunes store - someone can buy your app and not have to pay attention to what device it runs on. The drawback is more on the developer side. You have to do run-time checking for which device you are running on and present the appropriate UI. Also, you app will have to contain all nib files and artwork for both versions in one bundle, leading to larger binary sizes.
The double-target approach has the benefit of more easily being able to segment your code. You can use macros to conditionally compile code based on the target. This is the approach I used for Artificial Life.
In either approach, when the XCode project conversion first runs, it automatically creates iPad versions of all your nibs, although their sizes have not automatically been updated - you still have to do that by hand, properly adjusting where all the subviews and controls should be. Also, since Apple highly recommends supporting every view orientation, you’ll want to make sure you have the proper resizing and positioning options so your controls are placed properly as the views rotation. I found this was one of the most time consuming parts of my application porting to the iPad.
Pop-overs are your Friend
One very handy new UI element for porting and iPhone app to iPad is the UIPopoverController. As the name implies, it’s a window that appears over a portion of the screen. From a developer’s perspective, think of it as a modal View Controller that isn’t full screen. What is nice about these is they can take a UIViewController as an argument when they are initialized. This makes converting existing helper view controllers very simple. If you previously had a UIViewController on the iPhone which was used for configuring something, you can easily re-use it as a pop-over without having to change any of the underlying UIViewController code. Just make the pop-over the same size as the original iPhone UIViewController and you instantly have your existing view controller now working as a pop-over.
Using this approach is very helpful if you want to make a fairly rapid port of an existing iPhone app. For example, using this technique I was able to have a fully working iPad version of my existing Artificial Life iPhone app in just one day. For iPad, Apple discourages the use of full-screen transitions which were common on the iPhone (such as animated page slides), so using pop-overs for such content is an easy solution. Granted, long term I’ll be making a lot more enhancements to the iPad version of the app to take better advantage of the larger screen real estate, but short term, this was a quick way to get something up and running with a fairly good presentation.
The Bad - the iPad App Store
One thing with which I was very disappointed on launch day was the iPad App Store. For an indie software developer without a large advertising budget, the new design for the app store is absolutely terrible. As of this date, Apple no longer provides a way to browse the full categories of the app store. Sure, they list all the store categories (music, games, education, etc.), but going to view any one category now gives a limited “New and Noteworthy” view sometimes accompanied by a “What’s Hot” category. Completely lacking is a way to browse all the apps in the category. If you aren’t lucky enough to have your app featured by Apple, the only way a customer will find it is via keyword searching.
I’m hoping this is just an opening weekend glitch, but nevertheless this was a huge disappointment, especially after Apple had encouraged developers to have their apps ready for launch day. Shopping the iTunes store via iPad right now feels sorta like walking into a Wal-Mart and only being allowed to walk into the first 20 feet of the store. Anything else you might want to buy, you have to ask someone to get from the back room for you.
Friday, April 2, 2010
5 new iPhone radio app released
Stormy Productions has recently produced 5 new radio station apps for broadcaster Local Media of America in San Diego, CA. Apps were created for 5 of their stations: 91X, 105.7 The Walrus, Z90.3, Magic 92.5, and XX 1090. All apps are available for free on iTunes now.
Wednesday, March 31, 2010
Artificial Life - HD, the iPad edition
It’s now official. The iPad version of Artificial Life will be available on the grand opening day of the iPad iTunes store.
While the iPad version does preserve the same minimalistic art style of the original iPhone version, the artwork has been redone to take advantage of the higher resolution screen. Here are a few sample screenshots:
While the iPad version does preserve the same minimalistic art style of the original iPhone version, the artwork has been redone to take advantage of the higher resolution screen. Here are a few sample screenshots:
Sunday, March 21, 2010
A few amusing points from the iPad HIG
I ran across these several weeks ago, but only posted them today due to the lifting of the iPad NDA
Regarding UI Design
"Give people more things to see and control, by adding more camera angles; more knobs, switches, and dials;" page 11
"Downplay application controls by minimizing their number and prominence." page 25
Regarding Icon Design
"...a 72 x 72 pixel application icon. These dimensions give you a sizable area in which to tell a story about your application." page 32
Friday, March 5, 2010
Tunemark User Tutorial: Background Play
I've received a few queries from people who are having trouble getting the "Background Play" option to work in Tunemark Radio.
Below is a very short video clip demonstrating how it is done. The most important not obvious step is to press the Home button on the iPhone after Safari starts playing the audio. You can not press the "Done" button, otherwise the audio will stop. Also, this does have the side-effect that you cannot use Safari while the music is playing, but you can use any other app.
Below is a very short video clip demonstrating how it is done. The most important not obvious step is to press the Home button on the iPhone after Safari starts playing the audio. You can not press the "Done" button, otherwise the audio will stop. Also, this does have the side-effect that you cannot use Safari while the music is playing, but you can use any other app.
Wednesday, March 3, 2010
Tunemark Radio 1.5, now with visualization
Tunemark Radio 1.5 is now available on iTunes. This update includes a new streaming music visualizer. While you are listening to a radio station, you can tap on the animated volume bar graphs to see a full screen animation that is affected by the music.
Here's a video demonstrating the visualizer
Given the iPhone limitations, it will never be as fancy as the visualizers you have on the desktop, but it's decent, and the performance is fairly smooth on actual hardware.
Tunemark Radio is an iPhone app which supports playing over 30,000 radio stations in the Shoutcast directory. It is available for FREE on iTunes and contains no banner advertising.
Here's a video demonstrating the visualizer
Given the iPhone limitations, it will never be as fancy as the visualizers you have on the desktop, but it's decent, and the performance is fairly smooth on actual hardware.
Tunemark Radio is an iPhone app which supports playing over 30,000 radio stations in the Shoutcast directory. It is available for FREE on iTunes and contains no banner advertising.
Tuesday, March 2, 2010
Visualizing music
I’ve been experimenting a bit with a way to add some visualization to live audio streaming on the iPhone. Here’s a very rough demo showing bouncing bars representing the left and right channel levels of the audio. It’s not much, but I think I might be able expand on it to have more advanced visual animations that are influenced by the music as it plays.
I’m not sure how much of a demand there would be for such a feature on the iPhone, but depending on how the experimenting turns out, I may include it in the next release of Tunemark Radio. Give that it will have some affect on battery life, it will definitely be an optional feature that can be toggled on or off.
I’m not sure how much of a demand there would be for such a feature on the iPhone, but depending on how the experimenting turns out, I may include it in the next release of Tunemark Radio. Give that it will have some affect on battery life, it will definitely be an optional feature that can be toggled on or off.
Monday, March 1, 2010
Tunemark Radio 1.4 now available
The latest update for the Tunemark Radio iPhone app is now available on iTunes.
Tunemark Radio is a free iPhone radio player which provides access to the complete Shoutcast stream (over 30,000 stations!) as well as support for entering a custom pls, m3u, or direct URL for any radio station for which you may have a link.
It also includes support for “tunemarking” the current playing song. This allows you to save the song artist and title to list for future reference, email it to a friend, or search for it on iTunes for purchase.
This newest version has a slightly improved design for the user interface, including added support for customizing the background wallpaper image which is displayed while listening to the music. You are also able to select an image from your photo library and use that as the background wallpaper.
More enhancements are in the works, so please stay tuned for future updates.
Tunemark Radio is a free iPhone radio player which provides access to the complete Shoutcast stream (over 30,000 stations!) as well as support for entering a custom pls, m3u, or direct URL for any radio station for which you may have a link.
It also includes support for “tunemarking” the current playing song. This allows you to save the song artist and title to list for future reference, email it to a friend, or search for it on iTunes for purchase.
This newest version has a slightly improved design for the user interface, including added support for customizing the background wallpaper image which is displayed while listening to the music. You are also able to select an image from your photo library and use that as the background wallpaper.
More enhancements are in the works, so please stay tuned for future updates.
Thursday, February 25, 2010
SVN: externals - Key to sharing libraries
As any developer knows, it’s very useful to reuse code. If you have written some code that performs a useful function, it makes sense to modularize it so it can be easily reused in other projects.
If all your development is occurring on one machine, then sharing those modules between projects can be fairly simple. In my case, I have a custom Libs/ directory where I put common source code for various features, such as my web view controller, my RadioKit audio streaming engine, autoscroll label, etc. When I want to use any of those modules in a new project, I directly reference this common Libs/ directory. That way, if I later fix a bug in a module, I don’t have to find everywhere I’ve included the code. All the projects reference the same source and the change is easily reflected across all my projects.
Now, add in the complexity that you don’t have all the modules in a common directory on one computer. How can you still easily share the code across projects and ensure they automatically include new changes when they are made? SVN!
SVN (or Subversion) is a source code version control system. There are plenty of alternatives to SVN, and they all have their merits, but since SVN comes with the Mac, it’s an easy option to use.
I’m not going to get into the details of setting up SVN to use with XCode. That’s been covered well in other places. What I do want to talk about is a handy feature of SVN which makes sharing pieces of other SVN projects in a single project. The feature is called “externals”.
Suppose you have an iPhone XCode project that is being managed via SVN. Now, suppose you want this project to include 2 additional modules, and the source code for each module is hosted on a different SVN repository. You could manually check-out each of the pieces which will make up the project, but now suppose someone else wants to also work on this project. You would need to tell them where to get the extra modules and they would have to manually fetch (or check-out) the code from the other two repositories and put it in the proper place.
With SVN externals, you avoid all that manual work. You can easily define in your project where all the external pieces are coming from. These externals definitions get saved as part of your SVN project, so if someone else checks out the same project, SVN will also automatically check out the necessary pieces that were hosted on the other external SVN repositories. And, when you then open the project in XCode, XCode will automatically track the changes to the whole project, even the modules that were retrieved from the external repositories.
The externals feature makes it a whole lot easier to manage pieces from multiple SVN repositories, all while making them appear to be self-contained in the current project.
There’s a decent description of the syntax for using “externals” here. Also, most graphical SVN tools (such as Cornerstone or Versions) have support for defining externals. Unfortunately, the XCode SVN interface does not provide a method for defining externals. You need to either use the command-line or a GUI tool to initially set them up.
NOTE: since the externals are a property of a project, in order to define them you must first check-out the project which will use them. I didn’t understand this detail at first and spent quite a bit of time trying to figure out why the externals option was read-only when using the GUI tools and looking at the repository. If you run into that problem, check-out the project first, and then set the externals property on the working directory, not the repository.
WFMU 2.0 now available on iTunes
Stormy Productions has developed the latest iPhone app for WFMU and it is now available as a free download from iTunes. WFMU-FM is a listener-supported, non-commercial radio station broadcasting at 91.1 Mhz FM in Jersey City, NJ, right across the Hudson from lower Manhattan. It is currently the longest running freeform radio station in the United States.
The new 2.0 app has many new features including:
* Support for listening to several live audio streams including Ichiban Rock ‘n’ Soul, UbuWeb Radio, and Do or DIY
* On Demand access to show archives and podasts, including interactive playlists for some shows
* Bookmarking song favorites and searching for them on iTunes
* View WFMU’s Twitter feed, station news, blog feed, upcoming specials, and current schedule information
* Rewinding live radio
* Support for background play of all audio (including on demand content)
The new 2.0 app has many new features including:
* Support for listening to several live audio streams including Ichiban Rock ‘n’ Soul, UbuWeb Radio, and Do or DIY
* On Demand access to show archives and podasts, including interactive playlists for some shows
* Bookmarking song favorites and searching for them on iTunes
* View WFMU’s Twitter feed, station news, blog feed, upcoming specials, and current schedule information
* Rewinding live radio
* Support for background play of all audio (including on demand content)
Wednesday, February 17, 2010
Artificial Life 2.0 now available
Artificial Life 2.0 iPhone app is now available on iTunes.
Artificial Life is a simulation of the evolution of behavior of microorganisms. This newest update adds a new mode of play called Survival Mode. In this mode, you create the rules of behavior for one protozoa and see how long it will survival vs. a random population.
You can read more detail about this app here.
Here’s a short video demonstrating some of the features:
Artificial Life is a simulation of the evolution of behavior of microorganisms. This newest update adds a new mode of play called Survival Mode. In this mode, you create the rules of behavior for one protozoa and see how long it will survival vs. a random population.
You can read more detail about this app here.
Here’s a short video demonstrating some of the features:
Labels:
Artificial Life
Thursday, February 11, 2010
DevTip: Improving responsiveness of tab-based view controllers
I recently noticed a behavior difference between two different apps I had developed which both used UITabBarControllers. In one app, pressing each tab would immediately display the associated view controller’s views. In the other app, the first time a different tab was pressed, there would be a noticeable delay before the view controller’s view was displayed. After one time pressing each tab, however, then the response time was immediate for each tab.
When it comes to view controllers created from NIB files, the iPhone conserves memory by automatically loading and unloading them when necessary. So, when your app first launches, even if your view controllers are assigned to IBOutlet variables, their underlying views have not yet been created unless there is an immediate need for them.
In the case of my two different apps, in the one that had all its tabs being immediately responsive, it turns out I was doing some preliminary access to the view controllers views in my applicationDidFinishLaunching: method. Simply accessing the underlying view of the view controller will cause it to be loaded from it’s NIB file.
The benefit of doing this is each view controller will be initially loaded into memory when the app launches. This in turn will give better responsiveness to the view controllers being displayed when you initially press a tab.
The drawback is a slightly longer startup time for the app and you are now using more memory. Also, there is no guarantee that each of the view controllers will remain in memory. The iPhone OS may decide to unload one or more of them if memory conditions warrant it. But, if you have fairly complex views in a view controller and want to increase the likelihood the view will be immediately ready for display when a tab is pressed, using this technique will help.
When it comes to view controllers created from NIB files, the iPhone conserves memory by automatically loading and unloading them when necessary. So, when your app first launches, even if your view controllers are assigned to IBOutlet variables, their underlying views have not yet been created unless there is an immediate need for them.
In the case of my two different apps, in the one that had all its tabs being immediately responsive, it turns out I was doing some preliminary access to the view controllers views in my applicationDidFinishLaunching: method. Simply accessing the underlying view of the view controller will cause it to be loaded from it’s NIB file.
The benefit of doing this is each view controller will be initially loaded into memory when the app launches. This in turn will give better responsiveness to the view controllers being displayed when you initially press a tab.
The drawback is a slightly longer startup time for the app and you are now using more memory. Also, there is no guarantee that each of the view controllers will remain in memory. The iPhone OS may decide to unload one or more of them if memory conditions warrant it. But, if you have fairly complex views in a view controller and want to increase the likelihood the view will be immediately ready for display when a tab is pressed, using this technique will help.
Monday, January 18, 2010
Stormy Productions will participate in Indie+Relief on January 20th
A group of Mac and iPhone developers will all be donating all proceeds made on January 20th, 2010 to Haiti. You can read more about the endeavor at this link. I am happy to announce Stormy Productions will be participating in this fundraiser.
All proceeds from any of our apps (Artificial Life, Time Bomb, Piggy, or The Gavel) purchased on iTunes on January 20th will be donated to Partners in Health.
In addition to our iPhone apps, all proceeds from any purchase of a RadioKit SDK license made on January 20th will also be donated to Partners in Health.
If you aren’t interested in any iPhone apps or a RadioKit SDK license, please consider a direct donation to Partners in Health. They have been doing great work in Haiti for over 20 years and are strongly involved in the relief effort currently underway.
Thursday, January 14, 2010
Stormy Productions - a progress report
As of January, 2010, Stormy Productions has successfully developed over 65 iPhone apps. 45 of them are published under the Stormy Productions company name in iTunes. The remaining 20+ apps have been published under other company’s iTunes accounts.
In addition to these 65 apps, 80 other iPhone radio apps are licensing a portion of the radio client software developed by Stormy Productions.
Apps developed and published by Stormy Productions
All Hits Wired 96.3
Artificial Life
Classical Philippines Radio
Estereosom
1Faith FM
FM 94/9 / San Diego/ KBZT
Gay Dance Radio, GayInternetRadioLive.com (G.I.R.L.)
Gay-D-O Dance Internet Radio from www.gay-d-o.com
HardRadio.com The Heavy Metal Supersite
Heart FM Woodstock
HOT 107.9 WJFX
iRadioSuite powered by Big R Radio
106.3 Joe FM WVBB
KDRP 99.9fm and online at kdrplive.org
KUJO 99 - kujo99.com
KUT 90.5 Music, News, & NPR from Austin, Texas
KZSC Santa Cruz - Non-Commercial Radio That Rocks!
Mega Radio 97.1 FM KRTO
102.9 MGK / Philadelphia's Classic Rock / WMGK
Milwaukee's 102.9 The Hog (WHQG)
Nashville Rock Radio 102.9 The Buzz(WBUZ) - Everything That Rocks
Philadelphia’s 93.3 WMMR Rocks
Piggy- The Pig Alarm Clock
Radio Paradise
Radio 92.9 WBOS
Regina's Rock Station 104.9 The Wolf
The Coast 95.3/95.9 KOZT
The Gavel
The Gavel Lite
The Rock 106.9, WCCC
"The Source" 620 CKRM
The Zephyr / 96.7 FM / WZPH
Time Bomb
Tunemark Radio
94.7 WCSX Detroit's Classic Rock Station
96.5 WKLH Milwaukee
WPRT / Nashville’s Hit Music / 102.5 The Party
WRAT 95.9
101 WRIF Radio
WRNI Radio
89.7 WTMD Radio For Music People
WWJB - AM 1450 - The Voice of Hernando County
X92.9 - Calgary's New Rock Alternative
Z104.5 The Edge, Tulsa's Rock Alternative
Apps developed by Stormy Productions published under other company iTunes accounts:
GLAD WORKS
.977 Music / The Internet’s #1 Online Radio Network / 977Music.com
B96 We r Hip Hop
Hawaiian Rainbow - Hawaiian Music Radio
MIX FM 106.3 / SÃO PAULO / BRASIL
WGBH Radio
A Celtic Sojourn on WGBH Radio
All-Classical WGBH Radio
Public Radio International
PRI Program Stream
JAZZ.FM91 - Ontario, Canada
JAZZ.FM91
bgApps
Text 2 Wallpaper
Jacobs Media
Oldies 101.9 / WKLU / The Greatest Hits of the 60’s & 70’s
US 93.3 / Real Country Variety / WBTU
Air 1 Radio The Positive Alternative
K-LOVE Positive & Encouraging
am1500 / KSTP-AM/ 1500 AM Minneapolis/St. Paul
FM107.1/ WFMP 107.1 / St. Paul / Minneapolis
KS95 / KSTP FM / 94.5
Y-Rock on XPN
WXPN 88.5 / XPN
K-WAVE / KWVE 107.9 / The Wave Of Living Water
Pulse 87.7 FM / New York’s NEW Dance Music Leader!
The House FM / Praise 88.7 / Christian Radio
Listener Interactive
Public Radio App - This was a joint development project with Cadile Systems
.
In addition to these 65 apps, 80 other iPhone radio apps are licensing a portion of the radio client software developed by Stormy Productions.
Apps developed and published by Stormy Productions
All Hits Wired 96.3
Artificial Life
Classical Philippines Radio
Estereosom
1Faith FM
FM 94/9 / San Diego/ KBZT
Gay Dance Radio, GayInternetRadioLive.com (G.I.R.L.)
Gay-D-O Dance Internet Radio from www.gay-d-o.com
HardRadio.com The Heavy Metal Supersite
Heart FM Woodstock
HOT 107.9 WJFX
iRadioSuite powered by Big R Radio
106.3 Joe FM WVBB
KDRP 99.9fm and online at kdrplive.org
KUJO 99 - kujo99.com
KUT 90.5 Music, News, & NPR from Austin, Texas
KZSC Santa Cruz - Non-Commercial Radio That Rocks!
Mega Radio 97.1 FM KRTO
102.9 MGK / Philadelphia's Classic Rock / WMGK
Milwaukee's 102.9 The Hog (WHQG)
Nashville Rock Radio 102.9 The Buzz(WBUZ) - Everything That Rocks
Philadelphia’s 93.3 WMMR Rocks
Piggy- The Pig Alarm Clock
Radio Paradise
Radio 92.9 WBOS
Regina's Rock Station 104.9 The Wolf
The Coast 95.3/95.9 KOZT
The Gavel
The Gavel Lite
The Rock 106.9, WCCC
"The Source" 620 CKRM
The Zephyr / 96.7 FM / WZPH
Time Bomb
Tunemark Radio
94.7 WCSX Detroit's Classic Rock Station
96.5 WKLH Milwaukee
WPRT / Nashville’s Hit Music / 102.5 The Party
WRAT 95.9
101 WRIF Radio
WRNI Radio
89.7 WTMD Radio For Music People
WWJB - AM 1450 - The Voice of Hernando County
X92.9 - Calgary's New Rock Alternative
Z104.5 The Edge, Tulsa's Rock Alternative
Apps developed by Stormy Productions published under other company iTunes accounts:
GLAD WORKS
.977 Music / The Internet’s #1 Online Radio Network / 977Music.com
B96 We r Hip Hop
Hawaiian Rainbow - Hawaiian Music Radio
MIX FM 106.3 / SÃO PAULO / BRASIL
WGBH Radio
A Celtic Sojourn on WGBH Radio
All-Classical WGBH Radio
Public Radio International
PRI Program Stream
JAZZ.FM91 - Ontario, Canada
JAZZ.FM91
bgApps
Text 2 Wallpaper
Jacobs Media
Oldies 101.9 / WKLU / The Greatest Hits of the 60’s & 70’s
US 93.3 / Real Country Variety / WBTU
Air 1 Radio The Positive Alternative
K-LOVE Positive & Encouraging
am1500 / KSTP-AM/ 1500 AM Minneapolis/St. Paul
FM107.1/ WFMP 107.1 / St. Paul / Minneapolis
KS95 / KSTP FM / 94.5
Y-Rock on XPN
WXPN 88.5 / XPN
K-WAVE / KWVE 107.9 / The Wave Of Living Water
Pulse 87.7 FM / New York’s NEW Dance Music Leader!
The House FM / Praise 88.7 / Christian Radio
Listener Interactive
Public Radio App - This was a joint development project with Cadile Systems
.
Subscribe to:
Posts (Atom)