aps-environment, AdHoc vs Debug

[skot]

So the push notification service has two separate environments, Development and Production.

When your app registers for push notifications, it delivers up a device token which is either for Development or Production, depending on the app's "aps-environment" setting. The device tokens for Development and Production are different.

[Pardon the review, I'm saying this out loud so someone can correct me if I've got it wrong.]

Now my app is still in development, but I use an ad hoc distribution to share the app with my team for testing. The ad hoc distribution is considered a "release" build and generates Production device tokens.

But if I'm working in XCode and run the app on my phone (so I can see the logging/debugging output in XCode), the app generates Development device tokens.

Obviously this creates difficulties for my server app, since it's receiving Development device tokens from some clients and Production tokens from others.

Is there a way I can get my Debug configuration to generate Production device tokens? Maybe by setting "aps-environment" to "Production" somewhere?

Or: can I read the "aps-environment" setting at runtime, so I can pass this information to the server along with the device token?

[baja_yu]

Theoretically, you can distribute Debug builds as ad hoc. I haven't tried it, but I've seen here people that actually uploaded Debug builds to the App Store without getting any automated errors, so it should work just fine for Ad Hoc.

[Duncan C]

Originally Posted by baja_yu

Theoretically, you can distribute Debug builds as ad hoc. I haven't tried it, but I've seen here people that actually uploaded Debug builds to the App Store without getting any automated errors, so it should work just fine for Ad Hoc.

Gack. Really? Debug builds in the app store?

That's bad for a number of reasons.

First is security. Debug builds have built-in symbols. That's like a roadmap for hackers. It makes reverse-engineering your code much, much easier.

Second, debug builds are not optimized. They tend to run quite a bit slower than release builds. It depends on the type of code. Code that does a lot of number-crunching tends to be CPU-bound, so it benefits a lot from the optimizations that are the default for a release build.

Our company has a fractal renderer for Mac OS, and the release build is very fast, while the debug build can be painfully slow. That's an extreme case of a compute-bound application, and the release version is tens of times faster. (It's also an extreme case of code that really benefits from code optimizations.)

All that being said, I regularly send out debug builds to our trusted remote testers. They're simpler to set up than ad hoc builds, and best of all, crash logs include symbol information so they're much easier to figure out.

[baja_yu]

Yeah. I think someone recently asked here about it. They uploaded a Debug build by mistake and it got into review before they realized and asked what to do about it.

[skot]

Duncan,
Can you tell me how you set up & send out the Debug builds? Or point me to something I can read to find out?

[Duncan C]

Originally Posted by skot

Can you tell me how you set up & send out the Debug builds? Or point me to something I can read to find out?

Just have your users send their device's UDIDs, add them to your development provisioning profile, and send out both the app and the provisioning profile. The user drags both into the library section of iTunes and syncs. That's all there is to it.