Matt MacDonaldStatus Rejected: You Should Create A Canary Build For Your iPhone App

Matt MacDonald posted on Friday, March 15th, 2013 | Android, iPhone, Mobile | No Comments

Submitting your shiny new iOS app to Apple for review is anxiety provoking. We’ve built a number of apps for both iOS and Android and the review and approval process for iOS still makes me worry. We spend time developing apps, prepping marketing materials and coordinating press releases with PR firms on larger projects. You don’t want to see this message just before your targeted launch date:

iTunes Connect rejection notice

iTunes Connect rejection notice

Enter the “canary build”. We’ve do our best to adhere to code and UI guidelines that Apple publishes, they change, we try to keep up. Still, we’ve found that the only way to really know if your app is going to be approved is to actually submit it for review. We call these “canary builds”. When we hit critical milestones in our development process we often will submit a build to Apple that we have no intention of releasing to the public. The approval process is a pain, but you really don’t want to find out that you have an issue just days before your app is released. We use the setting “Release Control Hold for Developer Release” when submitting these updates so that we can get an app into the approval queue, have the Apple review team ferret out any potential issues and then make our changes.

After having a few apps rejected a little too close to a deadline we started using these as a way to catch things earlier in the process.

Hope that helps someone else.

That is all,
Matt MacDonald

Chris RhodeniOS 6.0 Causes CDN Overages

Chris Rhoden posted on Wednesday, November 14th, 2012 | iPad, iPhone, Mobile | 26 Comments

We received a report from the folks at This American Life of extremely high bills from their CDN for the month of October. It is our belief after researching the problem that this is caused by bugs in the iOS 6 Audio Playback frameworks resulting in files being downloaded multiple times – this could result in dramatic overage charges for both content distributers and data plan customers.


We had seen a pretty intense spike in traffic on 99% Invisible and The Moth (both of which we host) last month, and had a pretty good idea of the when the spike began as a result. At the time, we had chalked the rather extreme increase in bandwidth (seen below) to the release of Apple’s new Podcast app, which featured 99% Invisible prominently at release. We figured that Apple had brought 99% Invisible and The Moth some new subscribers, and were pretty happy once we had battened the hatches a bit.

But when we heard from This American Life that they were seeing an order of magnitude increase in their bandwidth usage, we needed to ensure that there wasn’t a problem with our apps that was causing unusual download behavior. Based on our research, it looks like the issue is iOS 6.

The Behavior

To begin, we wanted to know if there was a way that we could differentiate traffic originating from one of our apps from traffic originating from other apps. Because we are using the AV Foundation framework, it turned out that we couldn’t (the User Agent String is the OS Standard one, not app specific). We were able to see that the version of iOS was 6.0 but not the name of the app playing the audio. However, the Apache logs we looked at suggested something unusual. In the following screenshot, the file being downloaded is 8614457 bytes long.

Click to view full size.

What you can see is that the first 2 bytes of the file (in most cases, this will be ID, as in ID3) are downloaded in one request and then what appears to be the file being downloaded multiple times on iOS 6 and only once on iOS 5. (This appears to be an artifact of the way that Apache logs range requests, and we have reason to believe that the file was not downloaded many complete times, but there are still clearly problems.)

Following this, we set up a proxy so that we could watch requests as they were coming from the app. The player appears to get into a state where it makes multiple requests per second and closes them rapidly. Because the ranges of these requests seem to overlap and the requests themselves each carry some overhead, this causes a single download of an MP3 to use significantly more bandwidth than in iOS 5. In one case, the playback of a single 30MB episode caused the transfer of over 100MB of data.

We saw this behavior start after a period of behaving correctly (in some cases behaving correctly for about 5 minutes before the issue appeared) in both our own apps and the Apple Podcast app. We were able to reproduce the issue with several podcasts in the Podcast app, including podcasts using Limelight and Akamai CDNs. We have been unable to reproduce the issue using iOS 5 or using iOS 6.0.1, but there are still many people using iOS 6.0.0. We believe that this issue, combined with the bug causing the phone to behave as though it is connected to WiFi even when it is not, could account for the significant data overages reported with the release of iOS 6.

The strangest bit of behavior happens when the ranges on these requests reach the end of the file. We were able to consistently see that when the file has completed downloading, it begins downloading again from the beginning of the file and continues for as long as one is streaming the file. This means that, for as long as one is listening to audio being streamed with iOS 6, it is using significant amounts of data. Watch the range headers in this video, which is monitoring the HTTP activity of the stock Podcast app (v1.1.2) on iOS 6.0.0 playing back an episode of This Week in Tech. The file finishes buffering and is completely downloaded at around 0:36.


There appears to be a system-wide problem with the AV Foundation framework in iOS 6.0.0, resulting in significantly higher data costs to iPhone users and internet distributors. Users who have not done so should immediately upgrade iOS 6.0.0 devices to iOS 6.0.1, which we can confirm appears to fix the issue on Wifi. While some carriers are offering concessions to customers who may have been affected by this problem, Apple does not appear to have acknowledged the specific issue. The release notes for iOS 6.0.1 mention a change related to Wifi (likely referring to the problem with devices that reported that they were connected to Wifi while connected to 3G and LTE networks), which may be related to the change which fixed this issue.


Our tests did not cover 3g or LTE data, as we relied on connecting to Wifi to perform them. Because of the server logs we have access to, it appears that this issue exists over mobile broadband as well.

Rebecca NessonA graphical pseudo-3D environment in an Android app

Rebecca Nesson posted on Tuesday, March 13th, 2012 | Android, iPhone, Mobile | 2 Comments

At PRX we’re lucky to get to work with creative, fun-loving clients who want their apps to be more interesting to play with than the average app made from iOS standard components or Android widgets.  In one app we’re currently developing, we’re creating an engaging and fun pop-up book style environment in which the user encounters the program content as she navigates through an imaginary world.  It’s beautiful and fun and a real programming challenge.  On the iOS side, Devin created the 3D-ish environment using native iOS layers positioned in 3D space.  It’s my job to create the same effect in the Android version of the app.  The native views in Android don’t support this kind of positioning in z space and there isn’t a build in “camera” that can be transformed to give the illusion of depth.  OpenGL could provide the 3D environment, but it would be a steep learning curve for me and it would make it harder to use the usual Android widgets and activities for performing the basic functions of the app like presenting lists of content and playing audio.  Enter AndEngine.

AndEngine is a free 2D game engine for Android.  It allows the creation of a game activity that I could combine with other Android activities to present content.  (I use Android Fragments via the Android Support V4 library to incorporate traditional Android views into the game environment.)  Although AndEngine is intended for 2D games, a forum thread demonstrated how to do the same perspective trick to the camera we’re doing on the iOS side:

 private void setFrustum(GL10 pGL)
    // set field of view to 60 degrees
   float fov_degrees = 60;
   float fov_radians = fov_degrees / 180 * (float)Math.PI;

   // set aspect ratio and distance of the screen
   float aspect = this.getWidth() / this.getHeight();
   float camZ = this.getHeight()/2 / (float)Math.tan(fov_radians/2);

   // set projection
   GLU.gluPerspective(pGL, fov_degrees, aspect, camZ/10, camZ*10);

   // set view
   GLU.gluLookAt(pGL, 0, 0, camZ, 0, 0, 0, 0, 1, 0); // move camera back
   pGL.glScalef(1,-1,1); // reverse y-axis
   pGL.glTranslatef(-CAMERA_WIDTH/2,-CAMERA_HEIGHT/2,0); // origin at top left

What’s happening here is that the camera is being pulled back away from the scene and a perspective transform is being applied that causes things in the distance to appear farther away.  I can’t explain it any better than the cryptic m34 transform that is applied to the camera on the iOS side, but the effect is the same.

The only other modification I had to make to AndEngine was to create a 3D sprite class that wraps the provided Sprite class and allows the user to set the z position of sprites as well as their x,y position.  In our app world the user doesn’t interact directly with the scene but rather with an scrolling mechanism that moves the scene “on rails” as the user scrolls.  The effect is beautiful but also somewhat hard to capture in screenshots.  You’ll just have to buy the app when it comes out!

The good news is, the app is shaping up beautifully and AndEngine has really come through for what we needed to do.  But there’s a big remaining issue that I’d like to solve.  AndEngine takes care of all of the touches on the scene and passes them to the sprites.  But it does it based on their x,y coordinates.  Unfortunately, the x,y coordinates it calculates based on the touches of the screen do not correspond to the location of the sprites within the scene because of the perspective transformation based on depth.  Under the covers OpenGL knows where the sprites are because it drew them correctly on the screen, but AndEngine itself does not know.  Additionally, I can only get access to a GL10 instance which does not provide the functions I need to project and unproject coordinates.  For now I’m working around this issue, but theoretically I should be able to do the math to convert 2D screen coordinates into 3D scene coordinates using the ratio of the scene size to the screen size, the position of the camera, the angle of view, and the distance of the object in question from the camera.  So far I haven’t succeeded in doing it, but when I get a few days to step back from the project I’ll turn to it again.  If you think you know how it should be done, please comment!

Chris KalafarskiBuilding a Better Contact Sheet

Chris Kalafarski posted on Monday, April 25th, 2011 | iPhone, Mobile | No Comments

Last week we decided to update the Photoshop file we provide to radio stations to allow them to customize the look of our core station iPhone app. There were two main problems with the version we had been using, the first being simply the organization of the layers. There was no standardized mapping of layers in the file to the individual files we need to use in the final app. The other problem was that our process for breaking the file down into its component parts was extremely time consuming. We were using an AppleScript that had been built in-house which extracted specific layers from the document, one-by-one. Additionally, we were maintaining low-res and high-res versions of the template for retina and standard displays.

The solution we decided to implement isn’t perfect, but it dramatically speeds up the processing step on our end, allows for a much more sensible organization of the component graphics within the document, and provides a buffer between what the station designer is doing on their end and what we’re doing on our end.

Buttons in the SpriteSheet

Buttons in the SpriteSheet

In order to ensure proper and meaningful organization of the template throughout the workflow, each graphical element we require from the stations is now represented as its own Smart Object. Each button, icon, background, etc is a distinct smart object. This way we can be sure that all changes being made to a graphic are in the appropriate and anticipated place. If our default icon is a single, raster layer but the station has a complex multi-layer vector replacement, there is no issue. Unlike the old version where new layers essentially went unaccounted for unless we were told explicitly that they had been added, now all the changes being made to each graphic are entirely encapsulated in a single object. This also allows us to set the canvas size on a per-graphic basis, so a designer doesn’t accidentally build a graphic that is too large for the space it will have in the final iPhone app.

Beyond that, the file is simply organized in a way such that relevant smart objects are in layer groups, so it’s easy for the designer to find what she is looking for. Icons are all in one place, backgrounds are in another, and status indicators another. All of the default objects are positioned roughly as they would appear in the final app inside a virtual iPhone, ensuring the designer is building the graphics in the correct context.

By using smart objects, we are also able to rethink the way the file is processed once it’s returned to PRX. Rather than run it through a script that is heavily dependent on specific layer names, we are now taking advantage of the dynamic Slice tool that Photoshop offers. You may be familiar with using Slice in Photoshop or Fireworks from when people were building websites with tables. It allows you to define contiguous regions of a file which can automatically be batch output, and additionally each slice can be given a unique name that persists inside the Photoshop file itself. The tool also allows slices to be dynamically linked to specific files in the file, and resizes to fit the contents of the layer. In our case, each smart object is a layer that has been linked to a slice, so if a station designer should choose to replace a default with an image that is larger or smaller, the slice we end up outputting is adjusted automatically.

Unfortunately, the slice tool is a relatively simplistic tool, and is only intended to work on the merged contents of the defined area. This is problematic, for instance, with toolbars, where we allow the designer to change both the background and the buttons. In our template we keep those graphics stacked on top of each other, just as they would appear in the app. The slice tool, though, would not handle that situation properly, and would export a single image rather than the separate parts.

Because we’re using smart objects, though, it’s trivial to duplicate each smart object somewhere else in the file where they can be arranged to prevent overlap. Duplicates of smart objects all point to the same source, so when the designer makes their changes in the part of the file where the layers are arranged to mimic the iPhone, the exploded view of the graphics we maintain behind the seems immediately reflects the changes.

Once we get the file back, we simply hide the designer-facing layers and bring up the matching layers we need for the batch export. A trip to the Save for Web dialog makes the export process take all of 10 seconds, orders of magnitudes faster than the old AppleScript. Since the names of the files being generated are being pulled from the slice metadata we ensure all of the station’s images will end up in the appropriate files we need to produce the iPhone app.

There are two caveats with this process. The first is that even though the the canvas size necessary for the user-facing layers is relatively small (technically just the resolution of a retina display), the actual file ends up being much larger. Because we need an unobstructed view of every single element, even when they are placed as closely together as possible the canvas ends up being about 4000×1500. This ends up being just empty space most of the time, and not really a major issue, but it is not ideal.

Because we will need to extract images through cropping, the canvas is much larger than the working area.


The other problem is something Photoshop is actually doing to give the user more control. Because smart objects can contain vector graphics, Photoshop allows them to be positioned at a sub-pixel level, even in the raster-based world of the actual Photoshop file. It does this even when the smart object contains only raster items itself. An unfortunate side effect of this is that unpredictable rendering can occur. Sometimes when the canvas height or width of a smart object is an odd number, Photoshop will try to center it inside the parent document, which places it halfway between real pixels. When that happens edge pixels of the smart object’s contents are improperly rendered (one edge is truncated a row early, and the edge pixels of the opposite edge are repeated). It’s not a hard problem to correct, but some care must be given since the entire document is based on smart objects.

Rebecca NessonBuilding an iOS Application Platform

Rebecca Nesson posted on Monday, March 21st, 2011 | Git, iPhone, Mobile | No Comments

In the last several months PRX introduced a new product to stations: an iPhone public radio station app platform. In the upcoming months the first several apps built on this platform will begin to appear in the iTunes app store. The goal with these apps is to provide a highly customizable application that allows stations to showcase their content and their brand. The challenge for the stations is that they are on constrained budgets and cannot pay the large app development costs usually associated with a custom built iPhone app. The challenge for us to is provide them with a satisfying alternative that has a full feature set, a custom feel, and a price tag that they can afford. To meet this challenge we’ve developed a platform that abstracts as much data as possible out of the application and streamlines the maintenance and updates of shared code between our applications. Here’s a laundry list of the techniques we’re using to accomplish this.

The Server Backend

We use a rails application backend server to maintain the data about the stations. This includes the information about their programs and their schedules as well as other app-related data such as the content of various HTML-based views that appear in the app. We also use this backend to integrate with third-party providers of data for the app, such as Publink.com which provides access to some stations’ member or listener discount systems. Using a backend server application makes it easy to update data in the app without a new application release to the iTunes store, offers the potential of letting stations maintain their own data, and helps us to standardize the models and formats of the data on which the iPhone code relies.

App Customization using Inheritance

After removing as much of the data (and the variations in the data formats) from the phone as possible, there still remains the problem of how to provide a core set of features and native views for the iPhone app but also to give stations a lot of leeway to customize the way their app looks and functions and to maintain the ability to provide improvements to features without breaking or overwriting customizations. We’re using inheritance to solve this problem. Each model, view, and controller in our app has both a “Base” version and a “Custom” version where the Base version is the parent class of the Custom version. We develop all features in the Base versions and expect clients not to make customizations or other changes within these files. That way when we update a Base version of a class we can push the change into all of the apps without fear of overwriting a customization. Throughout the code outside of the class we refer only to the Custom version of a class so that any customizations made in the custom version will be used instead of the code in the Base. This allows a station to make small changes to a particular area of their app or even to completely redo the way a particular area of the application works.

Managing Improvements Using git branches

One of the trickiest parts of keeping the platform development manageable was figuring out how to maintain the code bases for each app in a way that allows easy integration of improvements over time. We’re using git (and GitHub) for this purpose. We maintain a master version of the code as a main branch. It includes all of the features and the Custom classes but no customizations. Each station app has its own branch based on the master branch but including all of the customizations. When I’m developing, I always work in a specific station’s branch. When I make changes to Custom classes or non-shared resources I commit them in the station branch. When I make a change to Base classes or other shared code or resources, I commit in the master branch and merge back into the branch I’m working on. When it’s time to go to work on another station’s app, I check out the branch and the first thing I do is merge with the master branch to pull in the latest Base changes.

A cool side effect of this process is that GitHub maintains a helpful view of how up-to-date a given app is with the changes to Base as well as how customized an a given app is. Here’s a snapshot of that view right now:

Customized Graphics with Photoshop Contact Sheets

It was important to us and to our clients to work with their own designers to create a their look for their apps. In order to do this we abstracted out as many common and reusable user interface elements as we could and created a Photoshop “contact sheet” for the app. This contact sheet provides templates of the graphics that are used throughout the app separated into a single layer per item. We provide this contact sheet to our clients’ designers and they replace the default graphics with their own designs. This allows stations to use the defaults where they like but also to come up with their own design and look for the app. We then created an AppleScript that exports all of the images and saves them with the file names the app expects. This keeps the designer’s role strictly to design and limits the amount of time we as developers have to spend to incorporate the graphics into the app.

Using .strings Files for Text Customization

One other facet of customization worth mentioning, although we still haven’t quite worked out the kinks in it, is the repurposing of iOS internationalization features to do text customization within the app. Rather than using literal strings for text throughout the app, we pull the strings out of .strings files. This allows stations to provide their own “translations” for each bit of text in the app without having to make a customization within the code. I call this customization method half-baked because when we add new strings to the app it is best if we can regenerate the strings files which will cause them to be regenerated using the defaults specified in the application’s code. To avoid this we could add new strings in new .strings files, but this would result in a proliferation of these files over time.

Chris RhodenGit Hooks and Ruby

Chris Rhoden posted on Wednesday, March 16th, 2011 | Git, iPhone, Ruby | 1 Comment

Happy Wednesday, everyone! I don’t have very much time this week, so I’ll keep this short and sweet: While we’ve historically used Subversion at PRX, we have recently been migrating to Git to take advantage of some awesome tools and to better interact with the community.

We’re also most comfortable with Ruby, so when I was asked to look into setting up a build server for our iOS apps, there wasn’t much question as to how I would do it.

I set up a bare git repository running on a spare MacBook Pro with XCode and found the commands that were necessary to run when a new build was ready to be deployed. The next step was to set up the appropriate hook for that Git repository so that the builds could be triggered by a push.

In the SVN world, this would be a post-commit hook, but because Git works differently (one push can contain many commits), the hook we are interested in is the post-receive hook. You can take a look in your .git/hooks directory for some samples, most of which are written in sh. We wanted something in ruby, and here’s what we came up with:

#!/usr/bin/env ruby

require 'rubygems'
require 'grit'

repo = Grit::Repo.new(File.join(File.dirname(__FILE__), '..','..'))
while msg = gets
  old_sha, new_sha, ref = msg.split(' ', 3)
  commit = repo.commit(new_sha)
  case ref
  when %r{^refs/heads/(.*)$}
    branch = $~[1]
    if old_sha.to_i(16) == 0
      # A new branch was pushed
      # A branch was updated
  when %r{^refs/tags/}
    tag_object = Grit::GitRuby::Repository.new(repo.path).get_object_by_sha1(new_sha)
    tag = tag_object.tag
    tag_message = tag_object.message
    if old_sha.to_i(16) == 0
      # A tag was created
      # A tag was moved

Simply save this in your .git/hooks/post-receive file and make it executable. Then, every time you push to this remote, the script will execute. You can make whatever modifications are necessary for your specific application.

I hope this helps everyone working with Git hooks and Ruby!

Andrew KuklewicziPhone Radio Apps Are Not Banned

Andrew Kuklewicz posted on Saturday, November 27th, 2010 | iPad, iPhone, Mobile | 8 Comments

UPDATE 11/28 4:45 PM:
Lance Venta of Radio Insight is following up on the possibility that AirKast may also have been banned as well. In the AirKast store where 277 apps are listed, the latest new release is dated 10/30. (Coincidentally, their last app was for ‘KNUE’, which is a station I grew up listening to in Tyler, TX.)

This would be a big deal, both because they have so many apps, but also because they have significant commercial partnerships (e.g. ESPN, Triton, Radio One which “primarily targets African-American and urban consumers” in 15 markets with 53 stations, Salem Communications “targeting audiences interested in Christian and family-themed content and conservative values” with 94 stations, Bonneville International with 26 stations, Citadel Broadcasting comprised of “165 FM stations and 58 AM stations”, & NextMedia with 33 stations.

I’ve started compiling a list of other providers possibly hit by this when I started this post; time to go back and see who else might have been affected by the policy. Statements from Apple specify that apps in a station’s own store should continue to be approved, but it will be interesting to watch the white-label app sellers’ stores, and see if they can add more station apps.

For example, Jacobs Media (with 249 apps in its store) has not had a new app in their own store since 11/10 (though as Lance pointed out to me, they have had updates as recently as 11/24). They have probably taken to putting all new apps in individual station stores in accordance with Apple’s policies (which they were previously doing with some station apps anyway).

For customers of white label app providers, in effect the price just went up by $100/year, as they now have to buy their own iOS Developer Account rather then riding on the app creator’s. For DJB Apps, with a price of $199.99 (1 platform, 1 station app), adding another $100 for Apple is not a minor difference.

Original Article:
We’ve been asked by a number of partners and acquaintances to weigh in on the recent controversy started by Jim Barcus’s letter to the editor in Radio Magazine.

The jist of the letter it that Apple rejected 10 of his iPhone apps because they no longer accept single stream/station apps:

On Nov. 10, 2010, we had 10 radio station apps rejected by Apple because Apple says “single station app are the same as a FART app and represent spam in the iTunes store” and Apple “will no longer approve any more radio station apps unless there are hundreds of stations on the same app.”

He does not identify a particular source at Apple (few can or do), or cite an official notification from them (such as the reason(s) that would be included in a rejection), but adds:

We have talked to many Apple reps about this, but they appear to have a script that they all read from saying that a single station app is not an enriching end user experience.

While this particular letter has engendered remarkable response (as it seems intended to do), the tale of a developer rejected is a common one. In fact, Brian Stormont had a similar odd rejection back in April (emphasis is mine):

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”.

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.

A point of interest is that this precedes Apple’s 9/9/2010 statement which accompanied the first set of official and public approval guidelines for the app store. This document makes clear that “We have over 250,000 apps in the App Store. We don’t need any more Fart apps. If your app doesn’t do something useful or provide some form of lasting entertainment, it may not be accepted.”, and shortly thereafter a point that perhaps Barcus missed, “If your app is rejected, we have a Review Board that you can appeal to. If you run to the press and trash us, it never helps.”

As with Barcus, Brian Stormont expressed (more skeptically) the fear that Apple is trying to cut down on the sheer number of radio apps, and instead focusing on aggregation apps that play an uncounted number of stations, as iTunes does for streams on OS X, or an actual radio does for broadcast.

If this were to happen, and Apple were to enforce a no single station apps policy, it would be immensely troubling to say the least.

The thing is, you shouldn’t believe it.

The app store right now is flush with single station apps, including many featured in ‘What’s Hot’ (such as ‘WMBR’ and ‘RadioU’), and ‘New and Noteworthy’ (‘TuneLab Radio’ appears as #7).
Surely if this were truly a blanket policy they would be rejecting these apps, not featuring them in such coveted spots.

There must be more to this, some of which came out when Trevor Long of your tech life also spoke with Apple:

I’ve spoken with Apple, as have several developers and the situation, while not crystal clear, is certainly very clear on principal. There is no ‘ban’ on Single station Apps.

My own summary is that App developers submitting identical apps with just a logo/stream change under their own developer accounts are not looked well upon. (and if you take the time to download a few of this chap’s apps, you’ll see how uninspiring they are, and similar too)

However, if a station has an app developed, and submitted under their own name, it should breeze through.

Likewise, if an individual or group create an app that links to a single station stream or show, it might face some hurdles.

From a station owner perspective I think that’s a good thing – but, from Apples point of view, good on them for ‘encouraging’ the development of rich apps with a user experience that is more than ‘just a stream’ – in the end, if it was ‘just a stream’ the industry won’t survive!

Moral of this story for Radio stations – be creative, own the rights, own the application submission.

Confirming this account and adding further detail is a translation of another conversation with Apple representatives:

Translation from German article in Radioszene.de:


Faster than expected, Apple has reacted in a telephone call from german radio organization VPRT, This is a summary of the call:

“Apple will not delete any radio apps or prohibit access of radio apps to Apple Store. Apple suggests that every radio station makes their own developer account (79 Euro) and uploads their apps in there themselves. The apps can be developed by third parties (White label solutions). New and the apps in the future will be handled as so far. Apple confirmed, that several identical apps -which are provided from ONE developer account- will no more be accepted. (Comment: there has been some cases in the near past where a developer has submited hundred identical apps into the store). This rule is also applying to newspapers and other industries. If the app will be uploaded by the radio station this is no problem. Radio stations can also upload more than one app on their own developer account”.

Consistent with these posts, other radio app creators as or more prolific than Barcus have made it known they are not experiencing systematic rejections, nor are aware of any policy changes:

Claiming that Barcus is wrong, Paul Jacobs, VP/GM Jacobs Media/jacAPPS, tells RBR-TVBR that he’s been able to build radio station apps since Nov. 10: “Since that date, we have had apps for radio stations accepted as new as well as upgrades. And we are not alone. I invite you to go to the iTunes App Store and go into the “free” apps portion of the Music section. There you will see examples of dozens of radio stations – domestic, international, and Internet – that have been accepted and/or upgraded since November 10.”

Battle of the screen shots?
Jacobs even sent us a screen shot proving it. There were at least five radio stations — both AM and FM –with apps listed post-Nov. 10. Now, not to make any rash judgments here, but Barcus also sent RBR-TVBR a similar image, indicating the opposite was true.

Neither screen shots has been made public, but I have found results consistent with Paul Jacobs claim in my own perusal of the app store (I’ll leave this to you for homework).

UPDATE 11/27 12:05 PM: RBR.com has posted the screen shots. The one of the entire app store, sent by Jacobs, clearly shows many new radio apps. Barcus sent in list of apps by Jacobs Media (not what Jacobs invited users to look at), who has not published a new app since Nov 10. I have seen many Jacobs apps submitted in individual station accounts, so I tend to believe the Jacob’s claim that they have apps approved since the 10th, just not ones in their seller account.

Barcus’s letter seems aimed at causing uproar, positioning this as a conflict between Apple and the whole of radio. It now seems to be a more specific policy that has been applied to him (and perhaps other, less vocal, sellers).

It is unfortunate that other outlets, such as The Register and other sites added their voices to this uproar, and have yet to post corrections.

UPDATE 11/28: The Register and Martin Bryant from The Next Web have both updated their stories (thanks for the link Martin). The Register received a statement from Apple:

“There are many unique radio apps on the App Store and we look forward to approving many more,” reads a statement from an Apple spokesman sent to The Register. “One developer has attempted to spam the app store with hundreds of variations of essentially the same radio app and that is against our guidelines.”

This makes the 3rd communication from Apple confirming that this is an issue regarding a single developer, and a particular type of activity that Apple has previously described as a reason for app rejection (i.e. ‘spamming’).

As others have found Trevor’s post, they have reported this as a developer’s sour grapes rather than a draconian policy against radio, as Lance Venta did in Radio Insight, or in the corrected piece by Steve Safran in Lost Remote. That’s a wonderful retraction Mr. Safran; gracefully done, and with good humor – it ought to increase your readership (I know it did by at least one).

As the app store has reached a population of hundreds of thousands, Apple has been raising the bar on approvals, and you should expect this to continue as even more flock to the growing iOS platform. The best way to get your own apps approved it to start by providing apps people actually want (rich functionality and crafted interfaces). From there, you need to consider many factors in getting your apps approved, not to mention adopted, but that is the subject of my next post…

Matt MacDonaldUseful OmniGraffle stencils and templates for iPhone and iPad

Matt MacDonald posted on Tuesday, October 19th, 2010 | iPad, iPhone, Mobile, Wireframes | 1 Comment

I’ve been using OmniGraffle Pro for most of my iPhone and iPad wireframe jobs. I love the product, simple and easy to use. One of the things that I dig the most about it is the vibrant stencil and template community at http://graffletopia.com/. There are a number of stencils and templates that you can find out on the internet. The two that I’ve found to be most useful over the past few months are:

They are well thought out and I’ve been able to find and modify just about any component I’ve needed.

Support Us!


Categories & projects