-
Notifications
You must be signed in to change notification settings - Fork 93
Migrating to v1.4.0
Please follow this migration guide to fully upgrade your codebase to the newest v1.4.0
Certain properties in the PermissionStore data storage model have been deprecated. You may still use them, but they might become obsolete or removed in a future version.
In most cases, Xcode will automatically fix:
- Click on the warning to expand
- Click on
fix
If you are not using
JMModalorJMAlertby passing in a data model, you can ignore this section.
Most of the configuration properties that affect PermissionSwiftUI modal or alert view's behaviors are simplified. There is no more distinction between the modal and alert versions of properties.
For example:
restrictModalDismissal or restrictModalDismissal => restrictDismissal
autoCheckModalAuth or autoCheckAlertAuth => autoCheckAuth
This is because PermissionSwiftUI underwent a massive redesign for version 1.4.0: the previous singleton software design pattern is changed to a dependency injection pattern. Thus, the same property can be used to configure both JMModal and JMAlert style.
You might see an Xcode compiler warning like this:

You can resolve this compiler warning by migrating to v1.4.0, here is a code snippet example:
Before v1.4.0
store.autoCheckModalAuth = true
store.allButtonColors.buttonAllowed.backgroundColor = .blue
store.cameraPermission = .init(imageIcon: AnyView(Image("cool-image")),
title: "Title",
description: "Description")Now, the newest v1.4.0 uses the same property names, but in a more organized manner
store.configStore.autoCheckAuth = true
store.configStore.allButtonColors.buttonAllowed.backgroundColor = .blue
store.permissionComponentsStore.cameraPermission = .init(imageIcon: AnyView(I# mage("cool-image")),
title: "Title",
description: "Description")For more details, please read the related paragraph below, under New APIs section.
ConfigStore is a data store-only structure used to contain configurable settings.
Before v1.4.0, configurable properties used to change the behavior of PermissionsSwiftUI can be changed with properties of PermissionStore.
For example:
var model = PermissionStore()
model.restrictModalDismissal = false
model.restrictAlertDismissal = falseNow, the v1.4.0 version introduces the ConfigStore structure
Configurations such as restrictDismissal now reside in the ConfigStore struct, accessible from the PermissionStore.
For example:
var model = PermissionStore()
model.configStore.restrictDismissal = trueBefore v1.4.0, permission components can be changed with properties of PermissionStore.
For example:
var model = PermissionStore()
model.cameraPermission = .init(imageIcon: AnyView, title: String, description: String)Configurations such as cameraPermission are now considered a permission component, thus accessible in the permissionComponentsStore property from the PermissionStore.
For example:
var model = PermissionStore()
model.permissionComponentsStore.cameraPermission = .init(imageIcon: AnyView, title: String, description: String)Due to a currently known code issue/bug that is difficult to solve, the behavior for JMModal's dismissal had to change for v1.4.0.
JMModal will not be dismissed by swiping. The autoDismiss still work, but the user will always have to use the close button if autoDismiss is enabled. JMAlert is not affected.
Due to difficult known code issue/bug, PermisisonsSwiftUI will now show all permissions passed in regardless of status. But PermissionsSwiftUI will still auto check for authorization on each permission, and not present the view at all if no permissions passed in meet the criteria.
If the top and bottom description text is customized, the text will now always be left-aligned instead of the previously center-aligned.
All the PermissionSwiftUI library's custom view modifiers, that is JMModal, JMAlert, as well as customizing methods such as .changeHeaderTo() now returns type some CustomizableView intead of some View.
Although this is not technically considered a new "public API" or "feature", this is still an important change for v1.4.0. Returning type some CustomizableView means that the configuration modifiers such as .changeHeaderTo or .changeBottomDescriptionTo() can only be used in the correct context.
This will compile because it makes sense to the library's built-in modifiers on a library's built in view:
var body: some View {
VStack {
Text("PermissionsSwiftUI is the best Swift library!")
}
.JMModal(showModal: .constant(true), for: [.camera, .location])
.changeHeaderTo("Jevon's Header")
.setAccentColor(to: .red)
}But this will not compile because it simply does not make sense:
var body: some View {
VStack {
Text("PermissionsSwiftUI is the best Swift library!")
}
.changeHeaderTo("Jevon's Header")
.setAccentColor(to: .red)
}Magical, isn't it?