You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is sometimes useful to be able to use the production environment in a debug build to test something. Currently, the environment is set to .development automatically for debug builds, and to .production for release builds, which I think is a great default, but it would be neat if the user of the library could override that manually if they want to.
If the idea is to replicate the CloudKit framework more closely, then this change could be provided at compile time with a flag different from DEBUG, which would take the place of the entitlement in the original framework.
Updated by Eric:
Dynamic environment selection via initializer
Dynamic environment selection via configuration
The text was updated successfully, but these errors were encountered:
I added environment as an initializer parameter for now. Eventually I'll add another constructor that takes in a configuration that can grab from the plist.
It is sometimes useful to be able to use the production environment in a debug build to test something. Currently, the environment is set to
.development
automatically for debug builds, and to.production
for release builds, which I think is a great default, but it would be neat if the user of the library could override that manually if they want to.If the idea is to replicate the CloudKit framework more closely, then this change could be provided at compile time with a flag different from
DEBUG
, which would take the place of the entitlement in the original framework.Updated by Eric:
The text was updated successfully, but these errors were encountered: