Not necessary to split into two pods about mixpanel-swift HOT 7 CLOSED

Hey @mxcl, agreed that it's a pain point.

When you suggest checking if it's an app extension at runtime, are you referring to see if it can perform .shared on UIApplication or did you have something else in mind?

from mixpanel-swift.

This issue is actually causing a crash for me now. As a result I am going to switch to only using the appex version (since my perusal of the sources didn't suggest I'm going to lose anything).

The crash is because I have a framework that links to the appex version because it is used by the app and several extensions. The main app uses the non-appex version. The normal version gets its keys set but the appex version is then used by the framework to do tracking. When mainInstance is nil the code fatalErrors.

If this can't be fixed (it looked like it could to me), then maybe the docs should have some details about why there is two frameworks (currently nothing is specified).

from mixpanel-swift.

Thanks @mxcl, I understand your frustration. The fatalError is there more importantly so people integrate Mixpanel correctly by initializing before calling any of the instance's methods/properties. This usually is caught when testing and should arise when any Mixpanel track event or even identify is called. We make the instance easy to reach anywhere in your code (without needing to pass it around) by calling mainInstance() but in order to use that, one has to initialize first. I do understand your confusion that if you initialized in the main app, you would want it to be initialized in the appex as well. However, you do need to initialize in both as they are separate and sandboxed from one another. As a side note, because mainInstance() is usually called many times, we tried to avoid having it an optional so it could return nil on extreme cases and then forcing people to use mainInstance()? on a regular basis.

I will look into a possible solution in the next two weeks on how we can combine both pods into one without causing this Cocoapods/Apple issue to arise: CocoaPods/CocoaPods#6711
As you said, this seems like something that can currently be done only if an app extension is identifiable at runtime.

from mixpanel-swift.

The fatalError is there more importantly so people integrate Mixpanel correctly by initializing before calling any of the instance's methods/properties. This usually is caught when testing and should arise when any Mixpanel track event or even identify is called.

Yeah, it's a common enough pattern and I have done such things myself.

I do understand your confusion that if you initialized in the main app, you would want it to be initialized in the appex as well.

Well I should have known better. But of course, I won't be the first to suffer this way.

As a side note, because mainInstance() is usually called many times, we tried to avoid having it an optional so it could return nil on extreme cases and then forcing people to use mainInstance()? on a regular basis.

I agree this is what IUOs are for. And with this sort of pattern you expect people to initialize up front. So it's the norm. I shouldn't have been surprised or frustrated so I apologize.

One idea I just had is you could make the Mixpanel framework itself depend on the appex framework. This is slightly more elegant than having two that are monolithically seperate. You could rename it MixpanelCore or something.

Ideally it could be one framework, but the compromises necessary may suck, certainly we have all been there when having to make these sorts of decisions.

Whatever way I have had to go back to having both frameworks because I needed some of the features only available on the non-apex framework. To work around my framework issue I composed a protocol for the mixpanel instance and have the framework take a pointer to an instance that conforms before it can do any tracking.

from mixpanel-swift.

Hey @mxcl thank you for your reply, I appreciate it.
I am really fond of the MixpanelCore idea, because it is in a way the core product and then there are added features that are only available for iOS apps.

I did also spend time this week to try and find a solution for the app extension complexities (based on your initial recommendation), because I feel like it is confusing and somewhat a mess to have it at its current state.

Have a look at the PR I sent out: #92
Very curious to hear your thoughts. I basically am now checking if it is an app extension in runtime (using the NSBundle suffix) and then implicitly calling UIApplication.sharedApplication using performSelector when it is not an app extension; thus allowing me to have that code also in the app extension framework. In this way, both the app and app extension can use the same pod and same framework. My only concern I guess is if Apple might not like this approach for some reason.

from mixpanel-swift.

PR looks really good. At first I thought you wouldn't be able to do the tricks you were doing, but I tried it in my app-extension and indeed UIApplication is available as a class name, so perfect. I thought you'd have to do some NSClassFromString.

I will feel terrible if you cannot iterate in ways you need in future because of me, so please consider carefully.

However as a consumer of this API this will make it simpler to use mixpanel in my 4-extension-1-app project!

from mixpanel-swift.

Sweet, thank you so much for taking a look! I feel pretty good about this change in general and in regards to future iterations -- and again I'm really glad you brought my attention to the runtime check approach.

I have pushed out a new release with the changes: https://github.com/mixpanel/mixpanel-swift/releases/tag/v2.1.7

Feel free to reach out if you run into any issues. Thanks again!

from mixpanel-swift.