Most of you have probably heard about the issues being written about around apps that use UDIDs. Apple’s policies on the matter are, like everything else, pretty opaque. This is unfortunate, because it creates panic and speculation.

So I want to give you the latest relevant information and our plan to address this.

First of all, we want to make it clear that we have not heard of a single Corona-based app being rejected because of this. In fact, after talking to partners, it is clear that very few, if any, apps have been rejected by Apple specifically because of the use of UDIDs. At the same time, Apple has deprecated the API and we do want to address this before it becomes an issue.

Given that UDIDs have been integral to how most companies have tracked data about consumer app usage, plans on how this will be addressed are still in flux. Any service provider that moves away from UDIDs overnight risks losing continuity between historical and new data. Therefore many companies we have talked to are planning on having an intermediate solution that uses both UDIDs and a new scheme, moving away from UDIDs entirely after some time. This, for example, is the case with Flurry.

As far as Corona is concerned, here’s what we plan to do:

1) Partner SDKs – In Corona we have integrated SDKs from 3 partners that use UDIDs (Flurry, inneractive and Inmobi). We are now in touch with all 3 and they have given us updates on how they are planning to address this issue. We should receive new SDKs from them in the next week or so and we will quickly integrate them into new builds of Corona. As mentioned above, these new SDKs may still use traditional UDIDs (via Apple’s deprecated APIs), but will be preparing the move towards alternatives. We (Ansca) also want to make sure we minimize disruption for our developers, so we will try to bundle these new integrations into as few new builds as possible.

2) LaunchPad Analytics – As part of our analytics we also will be moving away from using deprecated APIs. We are currently finalizing plans for what solution we will use to replace UDIDs. Like with the partner SDKs, we will phase this into our builds sometime in the next 2 weeks. There are several options to replace traditional UDIDs, but they all have different tradeoffs, so we want to make sure we make the right choice.

As part of this plan, we will be introducing these changes into a daily build, and then also making them available in a public release.

I want to reassure you that privacy and your ability to publish apps with Corona are very important to us. We’re working hard on this to ensure there won’t be any issues. And we will be updating as we make progress. Please let us know if you have any questions or concerns.

Walter

P.S. next month, I’ll be outlining some of the things we’ll be doing to create more regular stable public release builds. Stay tuned!

  1. @MikeJ – as mentioned, we don’t think there is much danger right now of being rejected for this. The vast majority of the apps being submitted to the app store right now that contain any analytics or ads (so pretty much all of them) are still using UDIDs. I would go ahead and submit it.

    Of course, as you know, Apple is unpredictable, so this could change. But we are doing all we can right now. If you hear, or see, otherwise, please let us know.

  2. Will Corona make it easy for devs by simply changing the method in which a hardware identifier is received – mac address maybe? without actually changing the function name (meaning a simple recompile using the latest version of Corona without code changes) once something is implemented instead of UDID’s?

  3. I noticed on OpenFeint dev site about how they are addressing UDID issue:

    OpenFeint’s Answer to UDID Questions
    In response to recent UDID concerns, OpenFeint has prepared a new version of the OF SDK, available now. Although OpenFeint enabled apps have yet to be rejected from the App Store, we want to make sure our developers are prepared, and are therefore recommend that you integrate the new OF SDK 2.12.8 in order to ensure that your players can continue to access their scores and achievements.
    Though SDK 2.12.8 contains UDID, it will also include other identifiers that will allow us to migrate over to a non-UDID based solution. Once Apple removes UDIDs, if you have not incorporated SDK 2.12.8, your players will not be able to access their OF accounts, which is why we are asking for you to update your app as soon as possible.
    After implementing SDK 2.12.8, the next step will be moving to a non-UDID based Single Sign On solution. OpenFeint recognizes the effort this transition requires, and we will do our best to support developers throughout this process.

    Does Corona use OF SDK v2.12.8 and actively preparing for timely update? If OF API has already been updated, that’s great. Just wanted to make sure I can continue to include OF to my project without worries.

  4. Hi Naomi, OF is next on our list.

    As of daily build 797, we’ve updated Flurry, InMobi, and inneractive with the latest bits which as we understand should address the iOS UDID issues. We also removed SuperRewards since they have dropped iOS support and their old library was not UDID-compliant).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>