Re: Recommendations for creating a beta with date to expire
Re: Recommendations for creating a beta with date to expire
- Subject: Re: Recommendations for creating a beta with date to expire
- From: Nick Buratovich <email@hidden>
- Date: Mon, 15 Aug 2011 16:36:26 -0700
I am currently running a private beta of an app. I use a combination of private license codes requiring server activation and expiration dates to force users to stay up-to-date. If a user is not okay with that, then he's probably not going to be okay with the usual problems beta releases have.
If I need to investigate a problem from an earlier build reported near an expiration date or need more time with an old version I simply use source control to rebuild the old version and disable the expiration check for my own use.
You probably do not want to do your expiration check later than <NSApplicationDelegate>'s -applicationWillFinishLaunching:. From there you can simply run an NSRunAlertPanel() with an expiration message or if you use Sparkle (or another autoupdater) force an autoupdate to occur. I wrap such code around an IS_BETA #define to make it easy to turn off for an actual release and App Store builds. You also probably want to have separate autoupdate tracks for beta releases and actual releases.
Beyond expiration dates, I suggest using a built-in crash reporter and other tools like something to read console messages your app may output. Make it easy for testers to report problems with 1-click rather than telling them how to use Console. These tools will remain useful post-beta.
- Nick Buratovich
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden