ISHPermissionKit: an iOS permission layer that ships no screens of its own

The framework asks the question but leaves the screen to you

ISHPermissionKit describes itself as a polite and unified way of asking for permission on iOS, and it also provides UI to explain the permission requirements before presenting the system permission dialog to the user. The key clause is the next one: the framework provides no actual chrome, leaving the developer and designer in charge of creating the views. That is the design decision everything else follows from. Instead of showing a built-in rationale screen with a fixed layout, the library lets you present your own view controllers and then trigger the system dialog when the user has read your explanation. The point of the pattern is timing. The system dialog is a one-shot experience, and once the user has denied a permission the app usually has to route them to Settings. Explaining first, in your own interface, is what makes the request feel less abrupt. The audience is an iOS developer with a design system who wants the flow without a library imposing a look.

One API covers a long list of permission categories

The README lists the supported categories, and the breadth is the point. Calendar covers events and reminders, plus contacts, location in both always and when-in-use variants, motion for activity data such as step counting, HealthKit, microphone, music library, notifications for both local and remote, photos for library and camera, social for Facebook, Twitter, SinaWeibo, and TencentWeibo, plus Siri and speech recognition. There is a structural detail worth noticing. The README distinguishes what the system provides implicitly, where you can only request a permission, from the categories where the framework offers an explicit way to ask. Social is the clearest example, since the social permissions in that list are the ones the system APIs handle in a way the framework can wrap. The unified API is delivered through subclasses, as the README puts it, so each category has its own type rather than one generic permission object with a string key.

Build flags decide which categories end up in your binary

This is the part of the integration that catches teams out, and the README devotes more space to it than to the API itself. Permission categories relate to sensitive user information, and if your app binary contains code to access that information it has to comply with special review guidelines and other requirements to pass binary validation in App Store Connect and app review. So the categories you need must be enabled specifically with build flags, and everything else is not included in the framework. The stated purpose is to protect you from surprising App Store rejections, since privacy guidelines apply to any app that contains code to access user data regardless of whether the code is ever called. The mechanism is preprocessor macros, so unused code is not compiled at all. The build configuration is delivered as `ISHPermissionKitAppConfiguration.xcconfig`, a template file in the repository that lists all supported flags, and you enable what you need by commenting or uncommenting lines.

The xcconfig has to exist in one of two directories

The rule for where the configuration file goes is precise and easy to get wrong. When building the static or dynamic library, ISHPermissionKit looks for a file named `ISHPermissionKitAppConfiguration.xcconfig` in the same directory as the root directory of ISHPermissionKit, not within the root directory itself, and two levels further up the directory hierarchy. A file in either location is enough, and the reason for the two-location search is that the library and the app both need to see the same flags. The README is explicit about the consequence: you have to use the same configuration file to build your app, otherwise the category specific symbols will not be available. If you already have a configuration file, you can include the other one, and the instruction is to always use `$(inherited)` when setting preprocessor macros. The project selects a configuration file per target in the project settings, and the README includes a screenshot of that dialog. This is manual work with no automatic fallback, which is why the framework's own instructions repeat the phrase that you must provide a build configuration manually for both installation routes.

Static library or dynamic framework, with different trade-offs

There are two ways to link the framework, and the README recommends the static library if you are concerned about app launch times, since a high number of dynamic libraries could increase launch time. The static route asks you to add the Xcode project as a subproject of your app, link against the static library `ISHPermissionKitLib.a`, and add it as a target dependency, with both settings in the app target's Build Phases. The dynamic route uses `ISHPermissionKit.framework`, which you add to the app's embedded binaries on the General tab, then verify in Build Phases that the framework is in Target Dependencies and Link Binary with Libraries, and that a new Embed Frameworks phase was created. Carthage is supported for fetching and building the framework, but the README notes you still have to provide a build configuration manually. Imports differ too: `#import <ISHPermissionKit/ISHPermissionKit.h>` for the static library, and the framework can be used as a module with `@import ISHPermissionKit;`. The sample application lives in a separate repository and uses the dynamically linked framework, which is a useful default to copy if you are unsure.

Info.plist usage descriptions are verified at runtime

The framework checks that the required usage descriptions are present in your app's `Info.plist`. If the `DEBUG` preprocessor macro is set, it asserts and explains which keys need to be added, which turns a silent permission failure into a crash with a message during development. Other requirements for each permission category are documented in the header documentation in `ISHPermissionCategory.h`, so the per-category details live with the code rather than in the README. This combination, a build flag that removes unused categories from the binary and a runtime check that the matching Info.plist keys exist, is the part of the design that is genuinely unusual compared to writing the permission calls directly against the system APIs. The trade-off is that the same two moving parts, an xcconfig and a set of Info.plist keys, have to be kept in step with the categories you enable, and a mismatch surfaces as a build-time assert rather than a compile error.

A project with a long gap between releases

The maintenance picture here needs care. The release history stops at 2.1.2, tagged for Xcode 10.2 support on 2019-04-06, with 2.1.1 and 2.1.0 both in September 2018. The last push was on 2026-09-22, so the repository is being touched even though no new release has been published for years, which means the CocoaPods and Carthage versions you can install are from 2019. The README states the library compiles with the iOS 11 SDK and later and deploys back to iOS 9, and that permission categories added later than the deployment target are skipped on unsupported versions. The roadmap lists two missing features, resetting state correctly when the device is reset, and permission monitoring with notifications upon changes, so state change observation is a known gap rather than an oversight. The licence is the other open question: GitHub reports a custom licence it cannot classify, so read the LICENSE file directly before shipping it.

Editorial conclusion

ISHPermissionKit fits an Objective-C team that wants one permission API across many categories and wants to explain the request in its own words before the system dialog appears. It is the wrong tool for a SwiftUI project that wants the modern async permission APIs, and it is the wrong tool if you cannot accept a manual xcconfig step, because the framework will not build without one. Before adopting it, check the category list in the README against what your app actually touches, because the framework is compiled per category and unused categories are deliberately absent, and read the LICENSE file yourself since GitHub reports a custom licence it cannot classify.

Frequently asked questions

Official sources

1. iosphere/ISHPermissionKit on GitHub
2. Issues
3. Project website
4. README
5. Releases