Add a _pushEnvironment device auto property with a value of development or production. The value starts as unknown (which tracks as production) until a background thread can read and parse the provisioning profile data, if it's available.
There's a few options here:
No embedded.mobileprovision. This could be a simulator build ( so want development) or an App Store one (production):
App Store apps do not contain an embedded provisioning profile because the App Store checks that the app is signed and provisioned correctly as part of its app ingestion process.
There is an embedded.mobileprovision. This could a development build (development) or an Ad Hoc build (production). In this case we can deserialize the provisioning profile and determine the correct environment, falling back to production if anything is unexpected. There's afewexamples of doing this out there.
I haven't been able to test most of the error cases in a meaningful way because I can't modify the embedded.mobileprovision to do something unexpected. From what I've observed, most of the errors should never happen, but at least we'll be able to narrow things down if they do.
I have tested with a simulator, development build, and TestFlight (App Store) build. Our alpha/beta period will provide more opportunities to test different configuration.
Add a
_pushEnvironmentdevice auto property with a value ofdevelopmentorproduction. The value starts as unknown (which tracks asproduction) until a background thread can read and parse the provisioning profile data, if it's available.There's a few options here:
embedded.mobileprovision. This could be a simulator build ( so wantdevelopment) or an App Store one (production):embedded.mobileprovision. This could a development build (development) or an Ad Hoc build (production). In this case we can deserialize the provisioning profile and determine the correct environment, falling back toproductionif anything is unexpected. There's a few examples of doing this out there.I haven't been able to test most of the error cases in a meaningful way because I can't modify the
embedded.mobileprovisionto do something unexpected. From what I've observed, most of the errors should never happen, but at least we'll be able to narrow things down if they do.I have tested with a simulator, development build, and TestFlight (App Store) build. Our alpha/beta period will provide more opportunities to test different configuration.