Developing a new app I didn’t want to pollute my analytics data in mixpanel with development / test data. So I wanted a clean way to be able to separate the test data with the release data. “Not” tracking anything when in development mode was an option but I kinda wanted to be testing this as well … making sure I was always tracking the right things. At the same time, I also wanted to be able to blow away the metrics from development really easily. You hit Mixpanels 500K free events surprisingly quickly.
So a drop dead simple way to do this was to create two different Mixpanel projects – one for release, and the other for debugging.
Then in your ios AppDelegate.m you can simply use the appropriate key based on what mode you’re in.
#define MIXPANEL_TOKEN @"YOUR_DEBUG_KEY"
#define MIXPANEL_TOKEN @"YOUR_RELEASE_KEY"
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
Now that I’ve done that, my development analytics data is nicely partitioned in one place (so I know things are working), and it’s easy to delete.
I finally took enough time to form a stronger opinion in the html5 vs. native, vs Appcelerator, vs phone gap debate and for me, I’m all in on native. Here’s a bit of a breakdown on the different choices.
- Cons: Compiling to multiple platforms is a bit of a double edged sword. It feels like they’re constantly having to make design decisions that support the lowest common denominator between the multitude of mobile platforms. Furthermore, inherent in this model is a bit of follow mentality. Any time a mobile platform introduces changes, they have to catch up to provide support. I’ve heard anecdotes about developers experiencing performance hits when using appcelerator … but I actually think I’d call BS on that. It’s fast.
- UIWebView is a pig and has major performance issues. Your app is NEVER gonna be as performant as a native app.
I’ve heard people argue for an HTML5 version of an app instead of native, but truthfully, I’m not sure these people really know what they’re talking about. I guess they’re suggesting an html5 website that users browse to in their phones web browser. But that’s got incredibly obvious shortcomings – Among others, no access to native controls or assets (obviously); no ability to receive push notifications; a very different look and feel; and having zero presence that persists on the users device.
Developing native applications across platforms is more expensive, no doubt. But without native, far too many UI and UX compromises are made in a market that’s so dominated by solutions that really nail UI and UX.