# RSKImageCropper's Makefile names one exact simulator, and version 6.0.0 arrives with no changelog

> RSKImageCropper is a small Objective-C view controller that gives an iOS app the cropper from the Contacts app, landscape included. It is about as simple as a component library gets: one library directory, one example app, one test target. The interesting parts are all in the seams. Its Makefile pins a single simulator OS version and device model, its default target silently builds the debug configuration, its two longest code examples stop mid-statement, and a major version number arrived after fifteen months with nothing on the page describing what changed.

**ruslanskorb/RSKImageCropper** — An image / photo crop view controller for iOS like in the Contacts app with support for landscape orientation.

- Repository: https://github.com/ruslanskorb/RSKImageCropper
- Stars: 2,446 · Forks: 463
- Language: Objective-C
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/ruslanskorb-rskimagecropper

## Every Make target names one simulator version and one device

The build file is four targets and four variables, and one variable makes three of them fragile:

```make
PROJECT = Example/RSKImageCropperExample.xcodeproj
SCHEME = RSKImageCropperExample
CONFIGURATION = Release
DEVICE_HOST = platform='iOS Simulator',OS='26.2',name='iPhone 17 Pro'
```

Build, clean, test and the aggregate target all pass that destination string to the build tool, so the destination is a single simulator operating system version and a single device model rather than a generic destination. The consequence is that the four targets stop working the first time a toolchain update removes that runtime or that device from the installed set, and they fail at destination resolution rather than at compilation, which is a confusing way to discover it. Pinning a device is occasionally deliberate, usually to control a code signing or layout assumption, but here it looks like a leftover from whoever last ran it. The fix is one line; the cost of not fixing it is that the project's only continuous integration entry point is coupled to one machine's toolchain.

## The default target builds debug, and the Release default goes unused

The configuration variable defaults to Release, which is the sensible choice for a library that will be distributed. No target ever uses it, because of how make resolves variables for prerequisites. The aggregate target depends on the continuous integration target, and that target carries a target-specific assignment setting the configuration to Debug before depending on the build target. Target-specific assignments are inherited by prerequisites, so the build runs in Debug. Since the aggregate target depends only on that one, the default invocation of make never produces a Release build. The test target is a separate case: it hardcodes Debug in its own command line and ignores the configuration variable entirely, so it would stay Debug even if the default were changed. Only invoking the build target directly gives you what the file says the default is.

## A major version with no changelog and no migration note

The release history is three tags. Five point zero in November 2024, a patch two weeks later, and then six point zero in March 2026, the same day the branch was last pushed. So the last two years of work culminated in a major version bump, which for a component with a public protocol and a delegate is the signal that something broke. Nothing on the page says what. There is no changelog file in the repository, no upgrade section, no note about which delegate or data source methods changed, and the usage example in the readme is written in the same style as it would have been in 2019. That combination is the awkward one: a major version tells you to check your integration, and then nothing tells you what to check. If you are upgrading, the header files and the commit history are where the answer is, and the page will not get you there.

## Both of the long examples stop in the middle of a statement

There are six code blocks on the page and two of them end mid-expression. The delegate example, which is the one you would copy to get a working cropper, finishes on an opening bracket and a property name, so the last line of the method that assigns the cropped image is incomplete. The data source example, which is the interesting one because it shows how to compute a mask for a fixed aspect ratio in both orientations, stops in the middle of a division inside a loop. That loop is the part worth reading, because it is what keeps the mask inside the view when the available width changes with orientation, and it is exactly where the example ends. The short examples, the import and the two protocol declarations, are complete. So the page is complete at the level of wiring up and incomplete at the level of doing something custom, which is a reasonable trade for a readme and still means the header is the real documentation.

## A rotation angle comes back because a rectangle cannot say it

The delegate has three methods and one of them carries four parameters: the controller, the cropped image, the crop rectangle and a rotation angle. That last parameter is the whole design. A crop performed on a photo the user has rotated cannot be expressed as a rectangle in the original image's coordinate space, so an API that returns only a rectangle forces the caller to either guess the rotation or re-derive it. Handing back the angle as well makes the result self-describing. The rest of the protocol follows the same pattern of minimal surface: a cancel callback with no result, and a crop callback with everything. The data source is its mirror image, three methods, all optional in practice, one for a mask rectangle, one for a mask path and one for the rectangle the image may be moved within.

## The privacy manifest decision cites a forum thread

There is a short privacy section and it is the most precisely sourced statement in the document. The component does not require a privacy manifest, and rather than asserting that, the page links to an answer on Apple's developer forum and reports what it says: frameworks should avoid adding an empty privacy manifest. That is the right way to document a decision that a reviewer might otherwise ask about, and it is also a decision with a shelf life, because it rests on guidance rather than on a rule, and guidance from a forum thread is exactly the kind of thing that changes without a changelog. Worth noting what is not claimed: the page says nothing about tracking, analytics or network access, which for a view controller that takes a local image and returns a cropped one is the expected situation, but silence is not a claim. If your app's own manifest is being assembled, this component's contribution to it is nothing.

## One installation method, chosen for a much older library

The installation section has exactly one path: add the package through the Swift Package Manager and paste the repository URL into the Xcode dialog. There is no CocoaPods podspec in the repository, no Carthage support, no manual framework step and no submodule recipe, and the tree confirms it, holding a package manifest, a build file, the library directory, the example project and a screenshot. So a component that has been through six major versions and describes itself with an Objective-C class name and an import line has exactly one supported installation mechanism, and that mechanism is the newest one available. The stated deployment floor is a much older system version, which means the effective toolchain requirement is far higher than the platform requirement, and anyone maintaining a build that predates the package manager has no path through this page.

## Conclusion

RSKImageCropper is worth taking if you are writing an iOS app that needs a cropper and would rather not build one, and it is small enough to read in full before you decide. The crop result handing back both a rectangle and a rotation angle is the design detail that matters most, because it is the difference between a cropper that can handle a rotated photo and one that cannot. Three things to check before you commit. The installation route, which is the Swift Package Manager only, so your toolchain has to support it even though the deployment target is a much older system version. The customisation surface, where three data source methods are described in prose and the worked example stops before the interesting loop, so expect to read the header rather than the page. And the maintenance question, because the last push to the branch was on 2026-03-26, which is over six months ago, and the version six release that day carried no changelog, so pin a tag rather than tracking the branch.

## FAQ

### What is RSKImageCropper?

An iOS image crop view controller that behaves like the cropper in the Contacts app, with support for landscape orientation. It is written in Objective-C, importable from Objective-C or Swift, and MIT licensed.

### What is the minimum iOS version for RSKImageCropper?

iOS 12.0 or later, as the installation section states.

### How do you add RSKImageCropper to a project?

Through the Swift Package Manager: add the package dependency from the Xcode menu and enter the repository URL. That is the only installation method the page describes.

### Does RSKImageCropper need a privacy manifest?

No. The page says the component does not require one, and cites an answer on Apple's developer forum that frameworks should avoid adding an empty privacy manifest.

### How do I use a custom crop mask with RSKImageCropper?

Implement its data source protocol. There are three methods: one returning a custom rectangle for the mask, one returning a custom path for the mask, and one returning the rectangle within which the image can be moved.

## Sources

- [Issues](https://github.com/ruslanskorb/RSKImageCropper/issues)
- [License: MIT](https://github.com/ruslanskorb/RSKImageCropper/blob/master/LICENSE)
- [README](https://github.com/ruslanskorb/RSKImageCropper/blob/master/README.md)
- [Releases](https://github.com/ruslanskorb/RSKImageCropper/releases)
- [ruslanskorb/RSKImageCropper on GitHub](https://github.com/ruslanskorb/RSKImageCropper)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ruslanskorb-rskimagecropper