Series · Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | more parts coming

Part 4 ended with my 2014 MacBook Pro. My next MacBook story began with an Apple order that went wrong in a surprisingly good way.

This part is about my 2017 Touch Bar MacBook Pro and four apps that gave me more control over macOS. Theine, iTerm2, and OnyX also come with complete developer interviews made exclusively for Reverse Everything.

Originally published at https://reverseeverything.com on August 18, 2026.

The MacBook Order That Went Wrong

I bought a MacBook Pro (13-inch, 2017, Four Thunderbolt 3 ports) in its top configuration while I was in Germany. I was going to be there for only two days, so I had a very tight window to buy it. Before placing the order, I explained to the Apple employee that getting a US keyboard was a high priority for me. We had a long phone conversation, but he accidentally ordered the MacBook with a German keyboard.

There was not enough time for another order to arrive before I had to leave Germany. The employee could hear how disappointed I was and offered me a 10 percent discount. I accepted it, but I still did not feel happy about the situation. He seemed to notice that as well and transferred me to his supervisor. The supervisor increased the discount to 20 percent. On a top-configuration MacBook Pro, that was a very nice discount.

It turned a frustrating mistake into a very nice experience with the Apple Store. I did not expect them to be so kind.

I was excited to get the new MacBook because I expected it to deliver a new experience. The most obvious change was the Touch Bar.

My Touch Bar Experiment

I type very fast without looking at the keyboard. Before trying the Touch Bar, I was skeptical because I would not be able to feel its buttons under my fingers. It turned out to be exactly the problem I expected.

With physical function keys, my fingers know where to go. With the Touch Bar, I had to stop and look down. That small distraction wasted time and broke my concentration. If you already look at the keyboard while typing, you may not be affected as much. My productivity depends on typing quickly with as few distractions as possible, so I immediately found the Touch Bar useless for the way I type.

The Touch Bar brought one more annoyance. The Escape key was no longer a physical key. It became touch-sensitive as part of the Touch Bar, so I could not feel whether I had pressed it. That made something as simple as using Escape less certain than it had been before.

I still configured it and left it enabled. Maybe after a few months it would become my favorite feature. It did not, but searching for a way to improve it led me to something much more useful.

When I eventually moved back to a MacBook keyboard without a Touch Bar, I immediately felt more comfortable again.

BetterTouchTool — When Apple Did Not Go Far Enough

BetterTouchTool is made by the same developer as BetterSnapTool, the window management app I mentioned in Part 2. I bought a lifetime license for BetterTouchTool. The 2017 MacBook gave it a completely new purpose for me, and I started experimenting with everything it could do to the Touch Bar.

I created buttons for the exact actions I needed. I could also make those buttons appear only when a specific app was active. Instead of accepting the same controls everywhere, I could give each app its own useful Touch Bar.

BetterTouchTool did much more than this. It was also a window manager, hotkey manager, trackpad gesture manager, and a highly flexible automation tool. It had far more features than I needed, but that was part of what made it exciting. I kept finding new ways to change how the Mac responded to me.

https://preview.redd.it/58fkpcoep2kh1.png?width=2000&format=png&auto=webp&s=3dba14a9251a8c41123931b160fa6baf2aace095

BetterTouchTool was first released in November 2009 and is still actively developed more than sixteen years later. The amount of work behind it remains visible in its updates.

This app made me feel that I could do much more than Apple allowed through the standard macOS interface. I was excited to try its features and transform my workflow into something made for me personally. That is the same feeling I now try to give people through the apps I create myself.

Theine — When My Mac Fell Asleep Too

My reason for caring about sleep control began when I first used macOS. I was reinstalling the operating system and left the MacBook alone while I went to sleep, expecting the installation to be finished when I returned. I was used to Windows installations keeping the computer awake until they were complete.

To my surprise, when I came back, the MacBook had gone to sleep as well and the installation had paused. It was a small surprise, but I remembered it. Sleep control eventually became the subject of another app story.

I found Theine in 2017. It was a lightweight app that stayed in the menu bar. Its interface was very simple and let me choose how long I wanted the MacBook to remain awake.

https://preview.redd.it/wn1qlnrgp2kh1.png?width=1818&format=png&auto=webp&s=924d02720ed2c81fc9a1b9e1177c153b493bc4fc

Sometimes I compiled the complete Qt SDK, which took a while. I needed the MacBook to stay awake until it finished. I could disable sleep in macOS settings, but I often forgot to enable it again afterward. The MacBook would then remain awake when I no longer needed it to and drain its battery. Theine was a perfect fit because the change was temporary.

After using it for a while, I noticed that its English localization was perfect, but one of the other languages I understand was translated incorrectly. I contacted the developer, and he answered promptly. I offered to create a Ukrainian translation, and he sent me the localization files I needed.

I translated Theine into Ukrainian, and I was happy that the developer accepted my help. Machine translation was not accurate enough for this kind of work at the time. Today, AI can help developers translate their apps into more languages with much better results.

The next update included my Ukrainian localization, and I was proud to see it there. Theine now lists 23 localized languages, including Ukrainian.

I found several alternatives over the years, but all of them were eventually abandoned. The last thing I want is to keep getting used to a new app that does the same job. Theine has my respect because it has already survived for more than ten years and is still supported. I have used it since 2017, and its name is one I cannot forget.

An Interview with Martin Lexow

Ighor July

What motivates you to continue developing and supporting Theine after so many years?

Martin Lexow

>If you study design in Germany, there's no getting around Dieter Rams. One of his principles states: good design is long-lasting. I try to carry this attitude into my work, wherever it makes sense and is possible. My favorite example is the 606 Universal Shelving System that Rams designed for Vitsœ. It went into production over 60 years ago, and matching parts can still be purchased for it today. Knowing that an app I designed has been accompanying many people for over ten years is a fulfilling feeling: for both sides.

Ighor July

Theine remains a true one-time lifetime purchase, without a subscription or time-limited update period. What has made this model sustainable, and why is permanent ownership important to you?

Martin Lexow

>As a creative who makes products, I generally prefer owning my tools. That's why I offer one-time purchases in my own apps whenever I consider it economically sustainable, and in most cases, I manage to. Occasionally, though, I do believe a subscription is the better choice. Because in my understanding, that's also part of "good design is long-lasting": a product that needs to be maintained or consistently receives new features demands my time, and that alone creates costs. It's in every user's interest that I put in this effort, because it serves the quality of their product.
>
>An app like Theine, for which a user may have paid 3 EUR eleven years ago, has received updates ever since, and has never required any further monetization, doesn't sustain itself economically. I can only justify it through cross-financing from the rest of my app portfolio.
>
>What I miss on the App Store is the ability to monetize new major versions of an app. An app like Theine, whose first version I wrote for OS X 10.11, still runs great on that operating system today. Nobody should have to pay a second time for that, obviously. But it is fair to make significant updates optional, and then paid. At the moment, this model can unfortunately only be implemented outside the App Store.

Read the complete Theine interview.

iTerm2 — When One Terminal Was Not Enough

iTerm2 became part of my evolution as a developer. I started creating services that ran on my own servers, and I eventually built many of them. Some projects needed frequent monitoring, so I wanted to see the live logs from several services at the same time.

I searched for a way to open multiple terminals, with each one connected to the logs of a different service. iTerm2 was exactly what I needed. It let me divide one window into multiple split panes, configure a startup command for each pane, and save the complete arrangement as a workspace.

iTerm2 also let me give each pane a name displayed in large text. It did not interfere with typing or reading the terminal output. I named every pane after the service whose logs it displayed, so I could immediately recognize what I was watching.

https://preview.redd.it/w3piza5op2kh1.png?width=1900&format=png&auto=webp&s=86a05019e2b4d0c56001a1a7864b230d96b89502

I created separate workspaces for my projects. I could open one workspace and instantly see the live logs from every service in that project. I did not need to recreate the terminal layout or reconnect everything each time. This improved my productivity a lot.

I no longer use those saved workspaces, but my workday still begins with opening iTerm2. I use it for local Homebrew tasks and to connect to my servers. I have hotkeys for opening split panes, which give me a compact terminal view that is easy to move around and navigate.

I also have huge respect for the effort behind keeping iTerm2 alive for so many years. When I reported bugs, they were fixed quickly. I cannot remember encountering a new bug in the app for several years now.

iTerm2 is free and open source. It exists because someone found an abandoned terminal project, fixed the problems that affected his own work, and continued when other users started reporting more. Knowing that story made me appreciate the app even more.

An Interview with George Nachman

Ighor July

What motivates you to continue working on iTerm2 after so many years?

George Nachman

>I wrote my first terminal emulator when I was a freshman in high school. I’ve always enjoyed working on this particular problem. I like working in a small team on a project I use, especially if it has a big impact, and I enjoy client-side code more than server side work. Sometimes it seems like the only desktop apps left are web browsers and terminal emulators, and I’m grateful that I can make a dent in the terminal emulator world without a team of hundreds of other engineers.

Ighor July

What advice would you give to developers who want to maintain their apps for ten years or longer?

George Nachman

>For me, the answer is to find a project that’s really engaging. I’ve always worked on iTerm2 because I want to, not because I have to. I am terrible at doing things I dislike. It’s also important for the project to have room to grow. A terminal emulator will never be complete because there are always quality-of-life improvements that can be made and the technology stagnated for decades, leaving a lot of low-hanging fruit.
>
>If you get fed up with it, which definitely happens sometimes, it’s ok to take a break. It’s ok to declare email bankruptcy. It’s ok to make mistakes. Giving yourself permission to be human is the only way to avoid burnout over a long time horizon.

Read the complete iTerm2 interview.

OnyX — Something I Missed from Windows

On Windows, I loved using tweaker tools. Microsoft hid many useful customization options inside the Registry, while those tools collected them in a convenient interface. I changed many of those settings and enjoyed making Windows work exactly the way I wanted.

When I moved to macOS, I searched for something similar. OnyX was the closest thing to the Mac tweaker I wanted. It collected useful maintenance tools and hidden macOS settings in one place. I found many interesting tweaks, changed a lot of them, and was very happy to have that kind of control again.

https://preview.redd.it/9sz1vg5qp2kh1.png?width=2000&format=png&auto=webp&s=2e02a388ce9022bce3f01052f27bef38c83f44c6

I still use OnyX, and I have huge respect for its developer for supporting it for so many years while keeping it free.

One OnyX option became especially important to me. It let me set a single line of text on the lock screen. After losing my first MacBook in Part 1, I started putting information there that could help someone return my MacBook if I lost it again.

Later, I discovered that this option had always been available in macOS settings. That made me wonder how far I could customize it myself. I tried multiple lines and they worked. Then I tried ASCII art, but it did not line up because the lock-screen font uses characters with different widths.

I started thinking about how I could make it look right. That is how LockLines was born. I tested hundreds of lines and made its output as accurate as possible. It can generate nicely aligned ASCII art messages for the lock screen.

I also found a way to make a message say something like "Scroll down to see the owner's contact information." My contact details do not need to be immediately visible to everyone who sees the locked MacBook, but someone who finds it can scroll down and learn how to return it.

An option I first discovered through OnyX eventually inspired me to create another Mac app myself. OnyX began as one person's tool for his own Mac and grew into a free utility that has been maintained since 2003. It is another example of a personal solution continuing to help other Mac users for decades.

An Interview with Joël Barrière

Ighor July

What motivates you to continue developing and supporting OnyX after more than twenty years?

Joël Barrière

>Simply because it is one of my passions, alongside music and motorcycles. Even though OnyX is free, I believe it is important to answer users' questions and try to solve any problems they encounter. Some paid applications do not even provide technical support worthy of the name.

Ighor July

What advice would you give to independent developers who hope to maintain and support their apps for ten years or longer?

Joël Barrière

>That is difficult to say because I am a slightly unusual case. For me, it is not really a job. I am not trying to make money by developing OnyX. I only want to help Mac users.
>
>I think it is important to release regular updates, talk about the app on forums, respond to emails from every user, and be patient, especially at the beginning. Word of mouth will do the rest.

Read the complete OnyX interview.

One More Surprise from Apple

Several years later, some keys on my MacBook's butterfly keyboard came off and could not be put back. I contacted Apple, and they replaced the complete keyboard for free with a newer revision that did not have the same defect.

Apple could not replace only the keyboard. It was part of the top-case assembly, and the battery was glued into that assembly, so every keyboard replacement also came with a new battery. Mine had already degraded significantly by then, so the MacBook received another useful upgrade at no cost.

Series · Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | more parts coming

Originally published at https://reverseeverything.com on August 18, 2026.

Developer Disclosure

Because this post mentions my app, LockLines, here are the relevant details in accordance with the subreddit rules:

• App: LockLines
• Competitors: None
• Price: $0.99
• Website: locklines.app
• Mac App Store: apps.apple.com/app/apple-store/id6772349545
• AI Note: reverseeverything.com/blog/how-to-use-ai-without-losing-control-of-your-code/
• About the Developer: reverseeverything.com/about/

I am Ighor, the developer of App Archiver.

I kept running out of space on my Mac and became frustrated with the usual solutions.

Most cleaner apps create space in one of two ways.

• They delete apps, downloads, or other data
• They remove caches that applications create again

Deleting data provides lasting savings because the data is gone. Clearing caches can show an impressive number immediately, but those caches often return as soon as you continue using your apps.

That is not the kind of storage management I wanted.

I like downloading Mac apps and keeping them for later. If I delete an app, I may forget it existed. I wanted to reclaim the space without losing the app, its familiar location, or the ability to find it again.

So I built App Archiver.

Real and lasting space savings

App Archiver reduces the space used by the apps themselves.

It does not pretend that repeatedly deleting temporary files is a permanent solution. It does not delete your documents, settings, or app data.

You can choose what happens to each app.

• Archive it in place
• Replace a rarely used app with a lightweight, restorable version.
• Optimize it
• Reduce its size while keeping it installed and ready to use.
• Back it up
• Create a standalone ZIP or DMG copy in any folder or external drive.

An archived app remains visible in Applications, Spotlight, Raycast, Alfred, and other launchers. When you need it again, double-click the same icon and App Archiver restores it.

The reclaimed space does not gradually disappear because a cache grew back. The full app remains archived until you decide to restore it.

No cleanup theater

I am not claiming that caches should never be cleared. Cache cleaning can help with troubleshooting and sometimes recover temporary space.

But repeatedly deleting files that return is not a lasting storage strategy.

App Archiver solves a different problem. It gives large and rarely used apps a smaller form while keeping them accessible. You get meaningful space back without throwing away software you may want later.

Real-world test

I tested Android Studio on an M1 Max using a single compression thread.

Result	Final size	Space saved	Reduction	Time
Original	3.48 GB	-	-	-
Optimized and runnable	1.76 GB	1.72 GB	49.4%	1m 50s
Archived	1.53 GB	1.95 GB	56.0%	3m 40s
Backup DMG	1.31 GB	2.17 GB	62.4%	4m 17s

The optimized version remains installed and runnable. The archived version stays in place and can be restored when needed. The DMG provides the greatest saving as a standalone backup.

These times include both compression and verification of every compressed file, not just the compression step.

This test intentionally used one CPU thread. I may add optional multithreaded compression in a future update to make processing considerably faster on multicore Macs.

Privacy

App Archiver works entirely offline. It has no account, sends no analytics, and makes no network requests.

One current limitation is that some apps are labeled Protected. Optimizing them requires additional system privileges, and I am waiting for Apple's permission before enabling that capability.

App Archiver requires macOS 12 or later and is available on the Mac App Store.

Download App Archiver on the Mac App Store

Visit the App Archiver website

Read the privacy policy

I would genuinely like to hear what you think about this approach to Mac storage management.

Also check out my other apps https://reverseeverything.com/apps

I created Parall to run multiple instances of the same Mac app as if each one were a separate app. It does not copy or modify the original app. Instead, every Parall shortcut launches the installed app with its own identity and configuration.

The philosophy behind Parall is to give you control over how many app instances you run and where each one stores its data. You can run separate Chrome, Claude, Discord, or Slack instances, assign each one a custom data path, give it its own Dock icon, add Dock animation effects, and force it to use Light or Dark appearance independently of your system setting.

Many apps have already been tested and confirmed compatible, with results available on the Parall compatibility page. Most unsandboxed Mac apps are also fully compatible without requiring individual verification.

In addition to running Mac apps, Parall creates lightweight WebKit Web App Shortcuts that make almost any website feel like a native app. Unlike a Safari Web Clip, Parall lets you choose where each web app stores its data, making separate accounts and profiles easier to organize. The launcher is highly optimized for this purpose and uses the WebKit engine already built into macOS instead of bundling another browser runtime.

Web App Shortcuts pass through website notifications, support Dock icon badges, and can use the same custom icons and Dock controls as other Parall shortcuts. Every generated web app is fully sandboxed, adding an isolation boundary between the website and the rest of your system if a web exploit is discovered.

I build all my apps natively with Objective-C, with efficiency, low CPU usage, careful resource management, and privacy as my highest priorities. I believe that any app performing an entirely offline task should remain completely offline and never send requests to Internet, and every app I make follows that principle. Parall itself has no telemetry or background services. Only the Web App Shortcuts connect to the websites you choose because loading those websites is their intended purpose.

• For the complete list of features and more information, visit the Parall website
• Mac App Store https://apps.apple.com/app/parall/id6754065114

Developer information

I am Ighor July, an independent macOS developer with a background in cybersecurity, reverse engineering, and native app development. I use AI while retaining control of my code, as explained in How to use AI without losing control of your code.

I am also the developer of DockLock Lite, App Archiver, LockLines, and App Trust Preview.

Comparison

There have been previous attempts to solve the multiple-instance problem on macOS. One example is AppCloner, a now-deprecated utility that created and installed copies of existing apps. After Parall was released, more apps appeared in this category, including Parallel Spaces and MacDupl.

Some of these products have also raised concerns for me around privacy disclosures and misleading website information, including wording and product details copied from Parall. Despite similar descriptions, all of these tools work in a fundamentally different way. They create or repackage copies of the target app instead of continuing to use the original installed app.

Repacking an app changes its bundle and replaces or invalidates its original signature. This can interfere with push notifications, automatic updates, passkeys, entitlements, permissions, and other macOS features tied to the app's original identity. It can also leave each copy behind the official app's update schedule. Delayed security updates create unnecessary exposure, especially as automated and AI-assisted vulnerability discovery becomes faster. For apps such as Codex and Claude, lowering app security or freezing a copy on an older version is not an acceptable tradeoff.

I created Parall from the beginning to avoid those compromises, and I am proud to have succeeded. Parall runs the original, unmodified app and automatically uses its latest installed version. That makes Parall the first tool of its kind to provide as many independently configured instances as you need, with custom data paths and a near-native Mac experience, without copying or repackaging the target app.

Parall also overlaps with browser profile tools, website wrapper tools, and command launchers, but it is broader than any one of those categories. It creates shortcuts for native apps, websites, files, folders, and commands while preserving the original multi-instance workflow.

Unite Pro overlaps with Parall on website shortcuts. It also creates Mac app bundles from websites, so that part can look similar. The important difference is sandboxing. Parall creates native sandboxed app bundles for website shortcuts, adding an isolation boundary between the website and the rest of the system if a web exploit is discovered.

A big thank you to r/macapps

I want to give a huge thank you to the r/macapps community. Over all these months, your feedback, questions, testing, and ideas have helped me improve Parall and continue developing it in ways that solve real problems for Mac users.

It is genuinely inspiring to talk with people who are happy with how Parall works and take the time to share their experiences and suggestions with me. Every piece of feedback helps make the app better, and many of its improvements exist because someone in this community cared enough to reach out.

Price

Parall is $9.99 on the Mac App Store.

• Website https://parall.app
• Mac App Store https://apps.apple.com/app/parall/id6754065114

If an app or website is not listed on the compatibility page, I can test it before purchase by request. Just ping me at support@parall.app.

I like having useful apps around, but I do not like deleting them just to free disk space. If I remove an app that I rarely use, there is a good chance I will forget it existed by the time I need it again.

That is why I made App Archiver for macOS. Its main goal is to compress apps while keeping them in place and visible in /Applications, Spotlight, Alfred, and Raycast. You never lose track of them, and when you need one again, you can restore it with one click.

App Archiver is the third first-of-its-kind macOS app I have built.

Instead of focusing on temporary caches that quickly return, App Archiver reduces the space used by the apps themselves. It gives you three ways to handle apps you do not use every day.

• Optimize an installed app with native macOS filesystem compression while keeping it ready to open and update
• Archive an app in place as a lightweight, restorable .app bundle without removing it from your usual app launchers
• Create a verified ZIP or DMG backup in a folder or external drive, with the option to remove the installed copy after verification

App Archiver helps identify large and rarely opened apps, estimates potential savings before an operation, and tracks how much space you reclaim. Archives and backups can be restored when you need the app again.

Every operation is staged and verified before the original app is changed. App Archiver also has no Internet access. Analysis, compression, verification, and restoration all happen locally on your Mac.

App Archiver includes an open-source component released under the MIT License. Its source code is available on GitHub.

Protected apps can't be optimized or archived. For that to work, I'm waiting for Apple's permission. Once I get that, I'll release an update that will back up all apps, including protected ones.

Comparison with alternatives

Cleaner apps usually target caches and other temporary files. That can provide quick relief, but those files are often recreated as you continue using your Mac. App Archiver focuses on lasting savings from application bundles instead.

Command-line alternatives for native filesystem optimization include Applesauce and afsctool. Both can apply transparent HFS+/APFS compression from Terminal. macOS also includes ditto --hfsCompression, which can apply filesystem compression while creating a copy.

These tools can work well if you are comfortable with Terminal and managing the process yourself. App Archiver adds a visual overview, app discovery, savings estimates, space checks, staged replacement, verification, and restoration around that optimization process.

Clusters was an early macOS utility that used filesystem compression to reduce folder sizes while keeping files immediately accessible. This is similar to App Archiver's "Optimize" feature. Clusters is no longer maintained and was last updated in 2013. App Archiver supports modern macOS versions and goes further with "Archive in Place", which replaces a rarely used app with a lightweight restorable version that remains visible in Applications.

For archiving, "Archive in Place" mode, I have not found another tool that archives an app in place as a lightweight, restorable .app bundle while keeping it in its original Applications location. This is the main reason I built App Archiver. The app stays visible, uses much less space, and can be restored when opened.

Developer information

I am Ighor July, an independent macOS developer with a background in cybersecurity, reverse engineering, and native app development. I use AI while retaining control of my code, as explained in How to use AI without losing control of your code.

My other Mac apps are DockLock Lite, Parall.app, LockLines.app, and App Trust Preview. You can learn more about my work on my About page.

Price

App Archiver is $4.99 on the Mac App Store.

Links

• Website apparchiver.com
• Mac App Store Download App Archiver

I would be happy to hear what you think, especially how you currently deal with large apps that you want to keep but rarely use.

Hi everyone,

I am the developer of App Trust Preview, a macOS utility for inspecting software before you decide to open or install it.

macOS can warn you about a download, identify its developer, or block it. That is useful, but it does not explain what is inside, which privacy access the software may request, whether its helpers are signed, or which protections it uses.

App Trust Preview turns that technical evidence into a report written for humans. It supports app bundles, installer packages, disk images, Mach-O executables, and executable scripts. The inspected software is not launched.

It is not antivirus software and cannot prove that something is safe. Its purpose is to provide useful evidence and context before you trust unfamiliar software.

What it shows

The report covers identity, signatures, certificate information, Gatekeeper, notarization, quarantine, App Sandbox, Hardened Runtime, runtime exceptions, internal executable components, architectures, linked libraries, technologies, hashes, and other technical signals.

It also translates entitlements and privacy declarations into readable categories such as camera, microphone, screen recording, accessibility, contacts, photos, location, Bluetooth, local network, and Apple Events.

Normally, checking whether one app has access to several protected resources means visiting every Privacy and Security category in System Settings, finding the app in each list, and checking its switch. App Trust Preview brings the available saved TCC decisions into one view and provides buttons to open the corresponding settings pages.

When reverse engineering apps, I used to inspect their resources, extract and analyze strings, and read raw bytes. I built App Trust Preview to automate part of that process. Its static analysis finds embedded domains and URLs that may represent service endpoints, update servers, analytics, or support pages. This is not live traffic monitoring, and finding a URL does not prove the app connects to it.

The app also checks runnable components separately, so a sandboxed or signed main app does not hide a helper with weaker protections.

For installer packages, it shows package metadata, intended locations, payload files, and readable scripts without running them. It can inspect an app inside a DMG without launching it. Quick Look provides a report directly from Finder, while the main app adds deeper interaction and configurable report sections.

The complete list of checks, explanations, supported formats, and limitations is available in the App Trust Preview FAQ.

Save files and export reports

After reviewing an app, you can save its bundle to a folder, create a ZIP archive that preserves executable permissions, create a read-only DMG, or explicitly install it in /Applications.

The same actions work for an app inspected inside a DMG. Choosing Install copies the reviewed app into Applications without leaving the source disk image mounted for you to eject. Creating a DMG is also a convenient way to back up an installed app.

Saving a package extracts its payload, scripts, resources, and readable metadata without running installer code.

Reports can be exported as PDF, PNG, plain text, or structured JSON. JSON is useful for security records, support, comparisons, automation, and external analysis.

Command line interface

The main app binary includes a CLI. Start with

'/Applications/App Trust Preview.app/Contents/MacOS/App Trust Preview' --help

It can open a GUI analysis, select tests, export text or JSON, validate JSON reports, and save inspected apps as app bundles, ZIP archives, or DMG images. Allowed Paths in Settings control where automation may read and write.

The CLI is easy to integrate with AI agents. Tell an agent to learn the --help output from the main app executable. It can then discover the current commands, run local scans against approved paths, consume structured JSON, and summarize the evidence.

Privacy and limitations

• Analysis happens locally
• Inspected software is not uploaded, launched, or modified
• The App Store app has no network entitlements, so App Sandbox prevents it from directly accessing the local network or the Internet
• Certificate revocation uses macOS trust services
• Save, export, and install actions happen only after you request them

A valid signature identifies a signer and helps detect modification. It does not guarantee good behavior. Notarization means Apple checked a submitted build for known malware at that time. Static references show what exists inside a file, not what definitely happens at runtime.

The optional AppTrustPreviewInspect helper performs checks and requested file operations that the App Sandbox cannot complete. It is not the public CLI. Its source is available at julyighor/apptrustpreview.

Comparison with alternatives

A major practical difference is distribution. App Trust Preview is available directly from the Mac App Store, while Apparency, Suspicious Package, Objective-See's KnockKnock, and EasyDMG are distributed outside it. Gatekeeper is built into macOS and VirusTotal is a web service. App Trust Preview is the only standalone app in this comparison available through Apple-reviewed, sandboxed App Store distribution with centralized updates and Family Sharing.

Apparency is the closest alternative for app bundle inspection and is excellent for browsing raw native component metadata in depth.

The most important difference is how the whole bundle is evaluated. Apparency's Quick Look summary can show an app as sandboxed based on the main executable even when runnable inner components are not sandboxed. It also does not show path-based sandbox exception entitlements that grant read or write access outside normal sandbox locations.

App Trust Preview was designed to fill those gaps. It checks runnable inner components separately and reports when a sandboxed main app includes a helper that can operate outside the main executable's restrictions. It also treats temporary absolute-path exception entitlements as warnings and displays the affected paths. This gives a more accurate view of the bundle's effective isolation than a sandbox badge for the main executable alone.

App Trust Preview is also better suited to users who want technical evidence interpreted in human-readable language. Beyond shared bundle and trust details, it adds automated static analysis for potential network connections and technology indicators, current TCC permission decisions and Settings shortcuts, cross-format reports for apps, packages, DMGs, executables, and scripts, VirusTotal hash lookup, configurable Quick Look, report export, CLI automation, and app saving or installation. Those broader workflows are not part of Apparency's documented focus.

EasyDMG and similar utilities are better when the goal is to automate a normal DMG installation with as little interaction as possible. EasyDMG mounts the image, performs a security preflight, copies the app into Applications, unmounts the image, and can open the installed app or trash the DMG.

App Trust Preview takes a review-first approach. It analyzes the app without launching it, explains privacy access, signing, internal components, and potential network connections, then installs only after the user explicitly chooses Install. It can also save the reviewed app as a bundle, ZIP, or DMG backup. EasyDMG replaces the usual DMG installation workflow, while App Trust Preview adds an informed decision before installation.

VirusTotal is better for malware reputation and multi-engine scanning. App Trust Preview is not a malware scanner. It calculates VirusTotal-compatible SHA-256, SHA-1, and MD5 hashes locally and opens an existing report in a browser with one click. It never uploads the inspected binaries or other target files.

Gatekeeper remains authoritative about whether macOS may open software, but it does not show privacy declarations, saved permission decisions, or potential network connections. Suspicious Package provides deeper specialized package exploration, while App Trust Preview combines package inspection with other software formats and safe extraction. KnockKnock finds persistent software already installed on a Mac, while App Trust Preview examines a selected target before it is opened or installed.

Developer information

I am Ighor July, and I post under my own name rather than behind a company or anonymous account. I am an independent macOS developer with a background in cybersecurity, bug bounty research, reverse engineering, and native app development. I mostly work with C++, Qt, Objective-C, and macOS internals.

I use AI while developing my apps. I explain how I use it without giving up control of the code in How to use AI without losing control of your code.

My other Mac apps include DockLock Lite, which locks the Dock to a chosen display, Parall.app, which runs Mac apps with different accounts at the same time, and LockLines.app, which designs Lock Screen messages.

App Trust Preview began as a tool for my own needs and grew through feedback from the Reddit community. I follow a strict rule across my local utility apps. Software performing local actions should never connect to the Internet without an explicit user action.

My background, projects, social profiles, and contact information are available on my About page.

Price

App Trust Preview is $2.99 on the Mac App Store.

Links

• App Trust Preview website
• Detailed FAQ
• Open source helper

Thank you to the r/macapps community for the thoughtful feedback on my previous posts. I implemented many App Trust Preview features requested by users, and I am always open to more ideas and feature requests.

Series · Part 1 | Part 2 | Part 3 | more parts coming

Part 2 ended in the middle of my story with the 2014 13-inch MacBook Pro. This is where Part 3 continues.

Compared with my 2008 MacBook, the 2014 MacBook Pro felt much thinner. I noticed the difference most in its display lid.

I was used to working with a MacBook on my knees, sometimes while keeping it connected to the charger. It still used MagSafe, but the thinner MagSafe 2 connector came loose by accident much more often. The original MagSafe connector on my 2008 MacBook felt much more stable to me.

That MacBook served me extremely well. More importantly, the apps I was finding were helping me build a macOS workflow that felt like mine.

Finding Files Without Spotlight

Years ago, when I used Windows XP, I was satisfied with its slow file search because it searched file names. I never needed the search engine to read the contents of every file.

Later, I used Everything on Windows. It did the simple job I wanted, but almost instantly.

My needs did not change when later versions of Windows introduced indexed search. A large part of my drive contained source code, and I did not want Windows indexing the contents of all those files. When I disabled indexing, it simply fell back to a plain file name search in the current folder. That was perfectly fine for me.

Spotlight brought the same kind of indexing to macOS, along with CPU activity for work I never asked it to do. I eventually disabled file indexing and kept using Spotlight mainly to launch apps.

I expected Finder to do what Windows did and fall back to a plain file name search in the current folder. Instead, with indexing disabled, Finder simply tells me that no files were found, even when I search a folder containing only a few files. The same thing happens while indexing is still in progress. I was surprised then, and I still am. I cannot understand Apple's decision to leave Finder search broken this way.

Spotlight also sometimes keeps a USB drive or SD card busy while indexing it and prevents me from ejecting it when I want to. This is especially annoying because I never asked it to index those drives.

In 2015, I found Find Any File. It became my only graphical replacement for the system file search. It searches directly by file name without requiring a content index and returns results quickly. It can search file contents when requested, but that is not how I use it.

The interface looks simple, but the app has much more inside, including hidden preferences for advanced needs.

When I contacted the developer in 2015, he explained that Find Any File could search the HFS catalog directly, much as Everything reads the NTFS Master File Table on Windows. It could even do this with some AFP network volumes backed by HFS.

https://preview.redd.it/me6df1ugcjeh1.png?width=2236&format=png&auto=webp&s=2b57eb31388768e2046b34d11b89b7ef3da2cf61

That email helped me understand why the app felt so different from Spotlight.

Find Any File is another rare app whose current Mac App Store binary I tested locally and confirmed to be unsandboxed. As I explained in Part 2, Apple requires new Mac App Store apps to use App Sandbox, while some older apps that were already in the store were allowed to preserve their existing architecture. That makes long-maintained apps like this especially difficult to replace inside the store.

I bought Find Any File more than ten years ago. It is still updated, no one has forced me to pay again, and I still cannot remember finding a single bug in it. That combination is rare.

The Calculator I Could Make My Own

As a student, I used many different calculators. PCalc became my favorite. I first used it on my iPhone 3GS and later bought the Mac version.

What made it different for me was its customizable interface. I liked that the calculator was resizable and that I could customize every button, letting me shape it around the way I worked instead of adapting to a fixed layout.

https://preview.redd.it/006nvltkcjeh1.png?width=1320&format=png&auto=webp&s=68ae53c9cbeb692b4ff047d725ff230ba9dc02b5

PCalc began in 1992, long before I found it. It is still maintained and still feels like the same focused app I liked from the beginning.

Learning How Much Memory I Actually Used

I like finding unusual and useful apps, then trying them to see whether they improve my workflow. iStat Menus is one of the apps I kept.

When I first tried it, I wanted to add some useful information to the menu bar. I ended up keeping it for a completely different reason. Today, my menu bar is minimal, and iStat Menus adds only one icon showing the charge levels of my batteries.

What made me appreciate the app even more was its ability to keep a history of my MacBook usage. I can review my memory use over the previous 30 days instead of judging it from a single moment in Activity Monitor. This shows me how I actually use my MacBook's RAM over time and how much I really need.

https://preview.redd.it/t3b7988jcjeh1.png?width=1190&format=png&auto=webp&s=cde2c57755eed06486d9891da136ee6e13c5578f

That history helped me understand how much RAM would be enough for me when I upgrade to a new MacBook. It gave me a practical answer instead of a guess.

The version I bought was later followed by another paid major version. I still recommend supporting it. Sometimes we need developers to keep pushing updates, but sometimes they need us to support their work.

Seeing How Fast My Drives Really Were

Blackmagic Disk Speed Test was one of my favorite benchmark tools. I remember seeing this app everywhere, in YouTube videos and screenshots across the web. It still appears in those places after so many years. Its two large read and write gauges have become iconic, and I believe many of you will recognize the interface immediately.

The simple interface delivered exactly the information I wanted to know. I liked using it to compare the speed of my MacBook's drive with the drive in my Windows PC. The app also let me choose the test file location, so I could point it to a microSD card or external drive and find out its actual read and write speeds.

https://preview.redd.it/ixuur0rmcjeh1.png?width=1484&format=png&auto=webp&s=e49172db0477a7eeb660b45501e4c1f88c4adeb5

A standalone version arrived on the Mac App Store in 2011, and Blackmagic Design continues to update it.

Three More Mac Developer Interviews

These interviews are exclusive to my Reverse Everything blog. I hope other developers, especially new ones, find them useful.

Find Any File — An Interview with Thomas Tempelmann

Ighor July

What motivates you to continue developing and supporting Find Any File after so many years?

Thomas Tempelmann

>Find Any File provides a side income that I rely on. I also enjoy getting feedback for my work, which is why I make my products personal instead of hiding anonymously behind a company name.
>
>I also earn a little from another app, iClip, although its popularity has declined because there are many competitors. On the other hand, Find Any File has become popular enough to maintain a good reputation without advertising, which is not one of my strengths.
>
>I have tried to create other apps that would earn money, but none of them has worked out so far. I keep trying, though.

Ighor July

What advice would you give to independent developers who hope to maintain and support their apps for ten years or longer?

Thomas Tempelmann

>Keep your users happy. Even if they ask for features you do not want to implement or cannot implement, show that you understand what they want and politely explain why you cannot fulfill the request, even if the reason is simply that you do not have enough time or the effort would not be worthwhile.
>
>When possible, add small things, even if you would not find them useful yourself. Users will tell others and praise your effort and reliability. That is how I still have a near-perfect five-star rating on the Mac App Store.

Read the complete Find Any File interview.

PCalc — An Interview with James Thomson

Ighor July

What motivates you to continue developing and supporting PCalc after so many years?

James Thomson

>Stubbornness, mainly :) Really, it's still a good app to keep up with the changes each year, and keep learning. But, I want to keep it going. It's been 34 years, so I don't feel I can really stop now! Maybe when I get to 42 years. Plus, it has provided a good income, and it's nice to be able to pay the bills.

Ighor July

What advice would you give to independent developers who hope to maintain and support their apps for ten years or longer?

James Thomson

>The easiest thing is to make something because you actually want to use the app yourself. Don't just make something because you think it will make money. If your heart is not in it, you will get bored of it easily!

Read the complete PCalc interview.

iStat Menus — An Interview with Bjango

Ighor July

What motivates you to continue developing and supporting iStat Menus after so many years?

Marc

>That’s a great question. It’s a joy to work on a tool that we use ourselves, and it always brings a smile to my face when I see it in someone’s menu bar. It’s even been in TV shows before!

Ighor July

What advice would you give to independent developers who hope to maintain and support their apps for ten years or longer?

Marc

>Honestly, it comes down to people liking your app enough that they’ll use and recommend it. The challenge often isn’t technical. It’s about building up trust and respect.
>
>I also feel like getting noticed is harder now than it used to be. There’s a good chance luck and timing played a big role in how things turned out for us.

Read the complete iStat Menus interview.

Part 4 will continue with more of my Mac experience, more apps that stayed with me, and more stories from the people who built them.

Series · Part 1 | Part 2 | Part 3 | more parts coming

This post was originally published on Reverse Everything and is shared exclusively with r/macapps

Series · Part 1 | Part 2 | more parts coming..

After losing my first MacBook before I had fully switched to Mac, I returned to Windows.

From 2009 until 2014, my main machine was a Windows PC connected to multiple displays. Somehow, all of that PC's original hardware still works and the computer continues to run well. That is another story, and perhaps one day it will become part of a separate My PC Story series.

My next MacBook story started with my open-source project, Qt Bitcoin Trader. Bitcoin was only beginning to become recognizable. I spent $100 on it, the price dropped, and that made me sad, so I decided to build an app that could help me trade and earn the money back.

I made Qt Bitcoin Trader open-source, and people from around the world contacted me. Even well-known cryptocurrency exchanges reached out. Those connections made me want to travel and gain more experience around the world.

When I started planning to travel, I remembered the nearly perfect trackpad on my first MacBook. I could not imagine relying on an external mouse while traveling, so a MacBook became the obvious choice.

That is how I came back to Mac with a MacBook Pro (Retina, 13-inch, Mid 2014). It became my real work machine. Qt Bitcoin Trader was cross-platform, and I used this MacBook to make it run reliably on macOS. That made it the first Mac app I ever built.

This was when macOS stopped feeling unfamiliar. I started finding apps that made it work the way I wanted, and without them, the transition from Windows would have been much harder for me.

Coming Back to Mac

By the time I returned to Mac, I already knew what had bothered me before.

Window management was still one of the biggest differences. On Windows, I was used to quickly filling the screen with a window or arranging windows in predictable places. On macOS, I liked many things, but I still wanted more control over how windows used the available space.

That is why one of the first apps that made macOS feel natural for me was BetterSnapTool. Today, window snapping is part of modern macOS, but back then this app felt like real relief. It made it much easier to use all available screen space, especially on a laptop where every pixel mattered.

BetterSnapTool was a small utility, but I used it every day. This is what I started to like about Mac apps. One small app fixed something in macOS that annoyed me every day.

Today I understand that BetterSnapTool also has an unusual advantage. I downloaded its current Mac App Store version and checked the binary locally, confirming that it is still unsandboxed. I did the same for every app I describe as unsandboxed in this series.

Apple now requires App Sandbox for Mac App Store distribution, but BetterSnapTool predates that requirement. Developers of other long-running Mac App Store apps confirmed how this exception works. They can release fixes and maintenance updates for an existing unsandboxed app, but they cannot use those updates to add new features or expand what the app can do. In effect, the unsandboxed version remains frozen at its existing feature level.

This makes BetterSnapTool's long-standing place in the store especially valuable. It can preserve the deeper access on which its existing window-management features rely. Because the app was already stable and feature-rich, it remains useful even without significant new functionality.

WiFi Explorer

While traveling, I sometimes stayed in hotels where the Wi-Fi signal was weak or unstable. I wanted to know where in the room I could get the most reliable connection. The usual Wi-Fi indicator only showed a few imprecise bars, which was not enough to help me find the best spot.

WiFi Explorer and WiFi Signal showed me an exact signal-strength percentage instead of vague bars. I could watch it change while moving around the room. If several access points used the same Wi-Fi name, WiFi Explorer showed each one separately. I could see which one I was connected to and find the spot with the strongest signal.

Beyond that, WiFi Explorer has a rich, beautiful interface. Its advanced details helped me better understand how Wi-Fi works, including the standards used by each access point and the maximum Wi-Fi data rate it supported. When I changed the channel or channel width on my own access point, WiFi Explorer also let me verify that the new settings had actually been applied.

They were awesome, simple, and stable. More than ten years later, I can still use both apps without a subscription or a forced paid replacement. Huge respect for the developer for keeping them updated and keeping the one-time-purchase model.

How Little Snitch Found Me

Little Snitch is one of the rare apps I never deliberately searched for. After I released Qt Bitcoin Trader, it attracted users who were very serious about computer security. The first feedback I remember was something like, "What is that?" The user sent me a Little Snitch screenshot showing that my app was trying to connect to my server.

The connection came from the update engine, so I explained it. But that screenshot introduced me to Little Snitch. I tried the app and immediately found it useful. It was the first app of its kind I had seen on macOS, and I still use it today.

I have spent much of my life thinking about how everything can be hacked, including my own computers. Little Snitch can block apps from connecting to selected servers. For me, its most important job is showing what my Mac is doing on the network.

I know how a man-in-the-middle attack works. Someone controls the path between an app and its server and can replace an unencrypted response. HTTPS helps protect against this, but some apps still use plain HTTP.

Little Snitch shows the app, domain, protocol, and destination port. If I see port 80 while using an untrusted network, I block it. Port 80 is normally used for unencrypted HTTP, while port 443 is normally used for HTTPS. A port number alone does not prove that a connection is secure, but it still gives me an immediate warning.

Little Snitch also shows me which apps still use unencrypted connections. That tells me something about how seriously their developers take security. Even if port 80 is only used for a redirect to HTTPS, the first response is still unencrypted and can be replaced. If an app checks for updates, downloads files, or accepts instructions through that connection, I see it as bad security design.

A network attacker would not need a sophisticated exploit. If an app downloads an archive over plain HTTP, someone controlling the network path could replace that response with a decompression bomb. If the app then automatically extracts it without cryptographically verifying the download or limiting its expanded size, file count, memory use, and disk use, the archive could exhaust system resources and cause the app or Mac to become unresponsive. This would normally be a denial-of-service attack rather than a way to take control of the Mac, but it still demonstrates why an app should never trust security-sensitive content received over an unencrypted connection.

As a bug bounty hunter, I find bugs almost everywhere. Long ago, I found a crash bug while using Little Snitch and contacted support. They replied quickly and helped me investigate it. The problem was not in Little Snitch. It was a macOS bug that Apple later fixed. I still cannot remember finding a real bug in the app itself. That gives me even more respect for its developers. They do not wait for a new macOS version to reach the public. Once Apple releases the beta, they begin fixing compatibility issues and release Little Snitch updates before the final macOS version arrives. That is another reason I trust it.

Keyboard Pilot

Keyboard Pilot solved another persistent macOS annoyance for me. I use multiple languages, so I constantly switch keyboard layouts when talking to friends, writing documents, and working with code.

macOS does not always keep the layout I expect. For example, I never need the Ukrainian layout while typing commands in Terminal. Keyboard Pilot lets me assign a specific keyboard layout to each app and switches to it automatically whenever that app becomes active.

This is especially useful when entering passwords. Because password fields hide what I type, it may not be immediately obvious that the wrong layout is active. By keeping English as the default layout in apps where I enter passwords, Keyboard Pilot makes the process more predictable and prevents failed login attempts caused by silently typing with another layout.

It made daily typing more reliable in a way that is difficult to appreciate until keyboard switching becomes part of your everyday workflow.

Keyboard Pilot is also one of my rare forever purchases. I bought it once in 2016 and can still use it today without a subscription or a forced paid replacement.

The Apps That Disappeared but I Still Miss

Some apps did not survive.

I used popCalendar and iRamDisk, and I liked both.

popCalendar gave me a simple full-year calendar in the menu bar. I still have not found any alternatives that show a year in such a simple and complete way.

iRamDisk helped me create a RAM disk at startup. Because I had enough memory, I could put a build environment there and use it for experiments. I asked the developer about a case-sensitive RAM disk option, and he added it quickly.

https://preview.redd.it/xeipaf3yvndh1.png?width=1584&format=png&auto=webp&s=47456e88389ece12aae698695189dcd88d9e9174

Later, iRamDisk disappeared from the Mac App Store. When I contacted the developer, he told me that development was dead and that Mac OS X development was the end of the story for him.

https://preview.redd.it/7z19k3uzvndh1.png?width=1650&format=png&auto=webp&s=482231b1d0d58a7af691d15608d439176bae1bb5

I did not expect that reply. It made me think about all the apps I liked that had disappeared. Even an awesome app can be temporary. Developers stop working on them, websites vanish, and years of work disappear with them.

While writing this post, I tried to contact the developer again. The domain from his old email address was no longer registered. I worried that someone could take it and impersonate the developer or distribute malware, so I registered the domain myself and keep it reserved.

After seeing so many apps disappear, I wanted to know why others stayed alive. I contacted developers of apps I had used for more than ten years and asked how they kept going.

They answered honestly. These interviews are exclusive to my Reverse Everything blog. I hope other developers, especially new ones, find them useful.

WiFi Explorer & WiFi Signal — An Interview with Adrián Granados

Ighor July

What motivates you to continue developing and supporting the apps after so many years?

Adrián Granados

>One thing that has always characterized my work is a commitment to keeping the apps up to date and paying attention to the little details. I’ve always made it a priority to support the latest Wi-Fi standards and make sure everything continues to work with each new macOS release. Not every developer is willing to make that long-term commitment, but I think it’s one of the reasons users have stayed with us over the years. They know the apps will continue to evolve, won’t be left behind, and that I genuinely care about the quality of the experience.

Ighor July

What advice would you give to independent developers who hope to maintain and support their apps for ten years or longer?

Adrián Granados

>So, my advice to independent developers is to build something you genuinely care about and stick with it. Don’t get too distracted by copycats or the latest trend. Those things come and go. What lasts is the relationship you build with your users. If you keep improving your product, listen to feedback, and take good care of the people who rely on it, they’ll remember that. That’s something no AI-generated clone can easily replicate.
>
>Looking ahead, I think AI will bring a whole new set of challenges for independent developers, just as sandboxing, Apple silicon, and new Wi-Fi technologies did for me. The landscape is changing quickly, and I’m sure there will be obstacles along the way. But if the last 15 years have taught me anything, it’s that adapting is part of the job. I’m optimistic that I’ll be able to navigate those changes while continuing to build products that people find useful and trust.

Read the complete WiFi Explorer and WiFi Signal interview.

Little Snitch — An Interview with Objective Development

Ighor July

What motivates you and the rest of the team to continue developing and supporting Little Snitch after so many years?

Christian

>Put in exaggerated terms, it's a kind of compulsive behavior. It's not only me, I can speak for the entire team here: We need that tool ourselves. If I get to use a computer that has no snitch installed, I feel like walking down the street blind. When I played around with Linux recently, the first thing I had to do was write a version of Little Snitch.
>
>I must admit that we often discuss how useful a feature is for users and try to cater the "average user". However, where Little Snitch really shines, is where we built the feature for ourselves.
>
>Another thing not to be neglected: Many teams fail because they end up in conflict with each other. We always made decisions unanimously, accepting that others may have other interests and other priorities.

Ighor July

What advice would you give to developers who hope to maintain and support an app for ten years or longer?

Christian

>Don't do it for the money in the first place. You'll need patience, and if money drives you, you'll give up before the revenue comes. Not all our projects were as successful as Little Snitch, but all of them paid off at least their development.
>
>For a project like Little Snitch you need more than being determined, high qualification and what else: you also need luck. Plain luck. And the only way not to have luck is not to play the game...

Read the complete Little Snitch interview.

Keyboard Pilot — An Interview with Richard Hult

Ighor July

What motivates you to continue developing and supporting Keyboard Pilot after so many years?

Richard Hult

>My motivation comes from two places. First, I'm a user of the app myself, so I genuinely want it to work well. Second, whenever a new version of macOS is released, I receive emails from users asking when an update will be available. It's a small user base, but they're incredibly enthusiastic, and their continued interest is very motivating.

Ighor July

What advice would you give to independent developers who hope to maintain and support their apps for ten years or longer?

Richard Hult

>My advice is to keep making small updates and regular releases, if nothing else to exercise the whole process of building with new Xcode versions and SDKs. It is so much easier to do small incremental updates rather than collecting a huge number of deprecations, and worse, risking that so much changed that you cannot even build the project once you come back to it.
>
>Another advantage that this brings is that when you work with your app, you often get some ideas for improvements and new features.

Read the complete Keyboard Pilot interview.

Complete Mac Developer Interviews

Part 2 includes excerpts from three interviews. You can also read every complete developer interview published with the series.

• WiFi Explorer & WiFi Signal — An Interview with Adrián Granados
• Little Snitch — An Interview with Objective Development
• Keyboard Pilot — An Interview with Richard Hult

After using these apps for more than ten years, I understand how easily any of them could disappear. If an independent app makes your Mac better, support its developer while the app is still here.

In Part 3, I will continue with more awesome Mac apps, the problems they solved for me, and more interviews with the people behind them.

Series · Part 1 | Part 2 | more parts coming..

Disclosure

I wrote the original article and conducted the interviews. This post is not sponsored, I have no financial relationship with the other developers, and none of the links are affiliate links.

This post was originally published on Reverse Everything and is shared exclusively with r/macapps

I have used macOS lock screen messages for years because a locked Mac can still be useful before anyone logs in.

A lock screen message can show owner information, return instructions, school or office asset labels, repair notes, lab warnings, conference machine details, demo machine instructions, or a simple note that helps the next person understand what the Mac is for.

The problem is that the built-in macOS lock screen message field is tiny and hard to design for. The text area is small, the real lock screen does not use a monospaced font, and anything that looks aligned while typing can break when it appears on the actual lock screen. Borders shift. Centered text stops looking centered. ASCII-style boxes become uneven. Scroll prompts are easy to miss. Longer messages are hard to structure.

I built LockLines to solve that.

LockLines is a small Mac app for designing plain-text macOS lock screen messages that actually fit the real lock screen message area. It helps you write the first visible message, add scroll-down details, preview both lock screen states, decorate the text, apply supported custom font styling, and copy a final message that is ready to paste into System Settings.

It does not change your wallpaper. It does not install profiles. It does not modify system files. It does not run a background service. It only prepares plain text for the standard macOS lock screen message setting.

The workflow is simple:

• Write the first-screen message people see before scrolling
• Add longer scroll-down details for contact info, return instructions, labels, notes, or warnings
• Preview both the first visible state and the scrolled state
• Add plain-text borders, repeated-character borders, styled boxes, spacing, background fill, or supported custom font styling
• Copy the complete message and paste it into System Settings → Lock Screen → Show Message When Locked

The main thing I wanted was confidence before pasting anything into macOS. LockLines separates the first visible part from the scrollable part, then shows both in a lock screen-style preview so you can check whether the message makes sense before it is used.

One use case I personally like is lost-device contact information. Instead of showing your email or phone number immediately in public, the first visible part can say something like:

⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️
⬇️  IF FOUND, PLEASE SCROLL DOWN ⬇️
⬇️     OWNER CONTACT IS BELOW    ⬇️
⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️⬇️

Then the scrollable part can contain the actual contact details and return instructions. Someone who finds the Mac can scroll down and read the details, but your private contact info is not exposed at a glance.

LockLines is useful for:

• Lost Mac return instructions
• Owner contact notes
• Scroll-down prompts for longer messages
• School or office asset labels
• Shared Macs
• Lab devices
• Repair intake notes
• Test machines
• Conference or demo machines
• Pickup instructions
• Reward notes
• Any locked Mac that needs context before login

The app includes editable themes and presets for common message structures. You can start from a theme, then adjust the visible text, scroll text, borders, fill style, spacing, supported font styling, and final message structure manually.

Current features include:

• First-screen message editor
• Scroll-down message editor
• Separate previews for visible and scrolled lock screen states
• Plain-text border controls
• Repeated-character borders
• Styled box borders
• Background fill
• Custom font styling for supported languages
• Editable theme gallery
• Paste-ready final output
• Copy screen with final message preview
• Built-in workflow guidance
• Standard macOS System Settings workflow
• No wallpaper changes
• No system file modifications
• No configuration profiles
• No background service

Custom font styling is available only for supported languages and text combinations. Some languages, characters, and scripts cannot use every styling option because the final lock screen message still has to remain plain text that macOS can display correctly.

I built LockLines by testing hundreds of lines on a real Mac lock screen and measuring how the text actually renders. The goal is to get as close as possible to the real macOS lock screen layout, including the annoying parts caused by the non-monospaced font and the small message area.

LockLines supports macOS 14 and later. Earlier macOS versions are not supported because their lock screen message field is much narrower, which makes this kind of precise layout design impractical.

Competitors

I am not aware of a direct alternative to LockLines.

Generic ASCII art tools, text box generators, and monospace layout editors are not built for the macOS lock screen message field. Most ASCII art assumes equal-width characters, but the macOS lock screen message does not render text that way. Because of that, designs that look aligned in a normal editor can become uneven once they appear on the real lock screen.

LockLines is different because it is made specifically for the macOS lock screen message area. The app focuses on the actual field size, the first visible state, the scroll-down state, plain-text borders, spacing, fill, supported font styling, and the practical limits of what macOS can display in that small non-monospaced lock screen field.

Price

LockLines is currently discounted to $0.29 on the Mac App Store for 24 hours. The regular price is $0.99.

Website: https://locklines.app
Mac App Store: https://apps.apple.com/app/apple-store/id6772349545

Developer information

I am not hiding behind a company name or an anonymous account. My name is Ihor July. You can read more about me here: https://reverseeverything.com/about/

I am also the developer of DockLock Lite, my first-of-its-kind macOS tool for locking the Dock to a chosen display.

I made Parall, another first-of-its-kind macOS tool for launching Mac apps with different accounts at the same time.

I also made App Trust Preview, a macOS utility that explains what macOS can verify about an app before you open it.

My background is cybersecurity, bug bounty research, indie development, and native app development. I hack for good and help large companies find and fix security issues. Reverse engineering has always been a lot of fun for me. Now I am applying the same mindset to macOS itself: finding long-standing workflow limitations, working around them cleanly, and turning those solutions into Mac apps.

More broadly, my main work is building first-of-its-kind Mac utilities that solve specific problems Apple does not solve directly. Buying any of my apps helps me keep working on that full time.

I mostly work with C++, Qt, Objective-C, and macOS internals.

I have a strict principle for local utility apps: software that performs local actions should never connect to the internet without an explicit user action. This principle is applied across my apps.

I will also add more app languages in the next update.

Social profiles:

• Medium: https://ighor.medium.com
• LinkedIn: https://linkedin.com/in/ighor
• HackerOne: https://hackerone.com/ighor
• Personal Blog: https://reverseeverything.com

AI note

None of my apps are vibe coded. I use AI only as a support tool for bug research, typo detection, code completion, and translations. I also use AI to translate my apps into supported languages, including English, since English is not my native language.

Feedback and feature requests

I am open to feedback and feature requests. I am especially interested in useful lock screen message templates, edge cases where the preview could be improved, and practical workflows where a better lock screen message would help.

If you try it and something does not fit the real lock screen exactly, I would like to know the text, border settings, LockLines version, and macOS version so I can improve the measurements.

I am writing a small series about my Mac journey since 2008, the apps I discovered along the way, and the apps I later created because I felt something was missing in macOS.

By the time this series is complete, I want it to become a practical collection of Mac apps that I personally consider must-have. Some of them are tools I discovered more than a decade ago and still use today. Others are apps I created for myself because macOS was missing something I wanted to have.

This will not be just a list of app names. I want to explain how I found each app, why it stayed with me, what problems it solved, and what my long-term experience with it looks like after years of real use.

Series: Part 1 | more parts coming if you like the post

Who I am

My name is Ighor July. I am a software developer, tester, reverse engineer, and bug hunter.

I have always been the kind of person who finds bugs everywhere, sometimes in apps, sometimes in operating systems, and sometimes in products made by very large companies. Over the years, that led me to responsible security research, bug bounty reports, and public research involving companies such as NVIDIA, PayPal, Amazon, and others.

I do not hack to harm or steal. I hack to understand how things work, find what is broken, and help make software better.

That same mindset is also why I build Mac apps. When I find something missing or annoying in macOS, I often end up creating my own solution.

Before Mac

My Mac story started near the end of 2008.

At that time I was a student, but I already had many ideas and was working on some relatively large software projects. I learned Qt and C++, which gave me the ability to create cross-platform apps.

Before Mac, I was a big Windows fan. I had used Windows since Windows 2000, and I had my own small computer repair service focused on software. Because of that, I spent a lot of time digging inside Windows, fixing things, changing settings, and learning how the OS worked.

That gave me huge respect for Microsoft. Windows was flexible, powerful, and feature-rich. I felt like I could modify almost anything the way I needed. I had my own PC back then, and by the way, it is still alive.

My first MacBook

Then in 2008 my mother gave me a gift. She bought me a brand new MacBook 13-inch Late 2008 from the Apple Store. That is how my Mac story began.

The first thing that surprised me was how many small hardware details felt unusual compared to Windows laptops of that time. On the very first lid open, without pressing any power button, it started to boot and played the startup chime. That small detail made me smile.

The MacBook itself looked almost perfect to me. On the bottom, there was a latch that opened access to the hard drive compartment. It felt extremely convenient. I also added more RAM, and I remember how easy that was compared to many Windows laptops I had opened before.

With many Windows laptops, disassembling anything was a red flag unless I checked everything carefully with a flashlight first. There were often hidden clips, fragile cables, and parts that had to be removed in a very specific order. With that MacBook, it felt much harder to break something by accident. A few screws, the back came off, and the design made sense.

On the side, there was also a battery indicator button, so I could check the battery level without even opening the MacBook. New Macs do not have that anymore.

The MagSafe charging connector was also great. Unlike later thinner versions, this one felt thick and solid, so it held the cable more firmly. I also liked that it could be connected in either direction, so I did not have to think about which side was up. I could move or slightly bend the charging cable without accidentally disconnecting it all the time.

It also had an IR receiver, so the MacBook could be controlled with a remote. I honestly never found much practical use for it, but I still liked that it was there. It made the MacBook feel like it had more thoughtful little possibilities built into it.

The Apple logo on the lid also glowed. That felt unusual to me, and I liked the look of it, but I also remember wishing there was a way to turn it off at night. Its brightness depended on the screen brightness, but when I used the MacBook in a dark room, it still lit the room a little. Sometimes I had to cover it just to feel comfortable, which was a bit annoying.

Another thing that impressed me was the accelerometer. It was available to apps, and I remember running an aquarium screensaver where the water moved realistically when I tilted the MacBook. Seeing that on a laptop screen felt unusual and fun.

But the accelerometer was not there just for fun. Its real purpose was to detect a fall and park the hard drive before impact. That was another small but smart detail I had not seen in Windows laptops I used at that time.

Leopard, Boot Camp, and trying to switch

The OS was Mac OS X 10.5 Leopard. I still have the original disc.

Visually, I liked Mac OS X right away. But actually using it was painful for me at first. A big part of that was window management.

I was used to Windows, where I could easily maximize a window and use all available screen space. On Mac OS X, I did not understand why resizing a window to fill the usable screen area was not as direct. It felt like the system wanted me to keep parts of the desktop visible, but I never cared about that. Even on Windows, I almost never saw my desktop wallpaper because my windows usually covered everything. So the problem was not only that Mac OS X was unfamiliar. It also worked against the way I had trained myself to use a computer.

At that time I was still developing software for Windows, so I installed Windows XP through Boot Camp. My plan was simple. I would mostly stay on Windows and sometimes boot into Mac OS X until I got used to it.

But Boot Camp had its own surprises. The Windows drivers were not working as well as Mac OS X. By February 2009, I was still trying to make Windows XP feel usable on that MacBook, especially the keyboard. Some hotkeys and Fn keys did not work properly, and many regular Windows key-remapping apps could not catch those keys at all.

That is when I found an app called InputRemapper. It helped fix some of those keyboard problems and made it possible to rebind parts of the MacBook keyboard into something more useful under Windows. It was one of those small utility apps that existed because the default experience was not good enough.

Trackpad support was also disappointing. There was no proper multitouch support, and two-finger click generated a click and release immediately. That made the context menu annoying to use, and it also made some things impossible. For example, in games where the right mouse button had to be held for zoom or aiming, it instantly released instead of staying pressed.

That was not the only issue. The keyboard backlight level also kept resetting. At that point I thought, okay, maybe Apple's strategy was working. Mac OS X clearly had the better trackpad experience, and that kept pulling me back.

The trackpad started pulling me in

And honestly, the trackpad experience in Mac OS X did start pulling me in. The gestures felt natural. Scrolling webpages with fingers was really smooth. It did not just jump a few lines like many Windows laptops did at that time. Every small finger movement moved the page exactly like touching a screen on a smartphone.

That made me realize Apple had really thought through the trackpad experience. I did not expect that this kind of convenience would become one of the things pulling me toward Mac OS X, but it did.

For about half a year, I kept switching between Mac OS X and Windows. I would try to stay in Mac OS X, then return to Windows because it felt more familiar.

Eventually I decided that instead of fighting Mac OS X, I should try to change it and configure it in a way that would feel comfortable for me.

Finding my way around Finder

I went through every setting I could find in Finder, Dock, and System Preferences.

In Finder, I found the option to show folder sizes. That felt very useful, because on Windows I needed third-party apps for that. I could sort folders by size and quickly find what was using too much disk space.

I also noticed Finder's column view. It allowed me to select files and folders across different levels, which was practically impossible in Windows Explorer.

I also found the option to show the folder path at the bottom of Finder. Much later, I discovered that right-clicking a folder name in that path bar allowed copying its full path to the clipboard, which was useful for Terminal.

The first Mac app I still use today

Another thing I wanted was better battery information. On my Windows laptop, I used an app called BatteryLife, which helped me understand what was really happening with the battery and how to extend its life.

For Mac OS X, I found coconutBattery. I liked it immediately because it was simple and showed exactly what I wanted to know. At that time, I remember it being free.

Years later, when the developer added a paid Plus version, I bought it right away. I also wrote to him and asked if he could make the menu bar font larger.

He replied that I was actually the first purchaser, so he could not let me wait for the menu bar font feature. He had already finished a beta version that included a font selector in the preferences.

https://preview.redd.it/5yp7j6om0iah1.png?width=1440&format=png&auto=webp&s=cc65eae3038d5285789f19569e333db831865d7a

That felt great. I was happy that I supported the developer, and also happy that my feedback helped improve an app I liked.

I have always had huge respect for developers who actually listen to feedback from people who use their apps and then improve the app because of it. That email stayed in my memory for exactly that reason.

As a developer myself, I try to do the same thing. When users report problems, suggest improvements, or explain what makes an app uncomfortable to use, I try to treat that feedback seriously.

Today, coconutBattery is much more than the simple battery window I first used. It does not just show the current battery state of my MacBook. It can also keep battery history in its own database, so I can see how battery health changed over time.

I also like how flexible the app settings became over time. The menu bar app can always show selected battery information, so I can choose what I want to see at a glance, such as battery health, charge cycles, temperature, or current system usage. That turns coconutBattery into something I can keep visible all the time, not only an app I open when I remember to check the battery.

https://preview.redd.it/hl8bgizp0iah1.png?width=1556&format=png&auto=webp&s=6aaebd1d69b321c8349387ab61e6d079827793b4

It also works with iPhone and iPad. After Wi-Fi connection is enabled, it can collect battery information from those devices too. I especially like the history view, because it gives me a table of monthly battery health and cycle count stats. That makes battery degradation much easier to understand than just checking one number once in a while.

Over time, coconutBattery became a small archive of my Apple devices. Inside it, I have battery history from devices I no longer use, and I keep that data partly because it is useful and partly because it keeps memories of those devices.

I also used coconutBattery to check old iPhones. Recently, I connected an iPhone 3GS, and it still displayed battery information. That helped me check whether the battery looked original based on the details the device exposed. I like that a modern version of the same app can still give useful information about hardware from so many years ago.

Current coconutBattery history view with Mac, iPhone, and iPad battery stats

I still use coconutBattery today, all these years later. The developer still actively maintains it. I recommend it to everyone because it helps you understand whether your battery is degrading normally or too fast.

Almost staying on Mac

After about half a year of trying to switch to Mac OS X, I finally started to like it. I spent more and more time there. Then Qt Creator was released, and I could write C++ Qt apps more comfortably on Mac OS X. For the first time, it felt like I might actually stay on Mac.

But then one day I left my MacBook in the car for a few hours. When I came back, someone had broken into the car and stolen the bag with my MacBook and Dell X51v inside.

Just like that, I had no Mac anymore and could no longer use Mac OS X. I did not have money to buy another Mac at that time, so I had to return to my Windows PC.

Not the end of the story

I was stuck on Windows again for a while. But my Mac story did not end that way. In many ways, it had only just started.

If you find this kind of long-term app review useful, I will continue the series next week, around the same time.

I was stuck on Windows again for a while. But my Mac story did not end that way. In many ways, it had only just started.

Series: Part 1 | more parts coming if you like the post

My personal blog: https://reverseeverything.com

Poster image taken from here.

Hi everyone!

I develop first-of-their-kind Mac apps that push macOS beyond its usual limits and solve long-standing annoyances users have dealt with for years.

My name is Ihor July. I am a cybersecurity expert, bug bounty hunter, reverse engineer, and indie Mac developer. I hack for good and help large companies find and fix security issues. Reverse engineering has always been a lot of fun for me. Now I am applying the same mindset to macOS itself.

Here is my short review of my Mac App Store apps, what they solve, and why I made them.

Parall - Multi-Instance App Launcher

For years, I wanted macOS to let me run multiple truly separate instances of the same app. Not just with open -n, but as separate app-like instances with their own data, their own Dock icons, and their own window spaces.

Before Parall, I solved this for myself by making tiny app bundles manually and separating their data. I used that workflow for years. Not long ago, I realized this was not just my personal problem. Many Mac users need the same thing, especially for apps that do not properly support multiple accounts or separate profiles. So I made Parall!

Parall lets you create separate launchers for the same Mac app. Each one can behave like its own native macOS app, with its own Dock icon, app name, and separated data profile. It is not just an open -n shortcut. The goal is to make each instance feel like a real separate app.

I manually tested hundreds of Mac apps and created compatibility profiles to make them work properly with separate data. You can have multiple Google Chrome apps in the Dock, each opening its own dedicated set of profiles. You can do the same kind of workflow with many other not sandboxed apps that were never designed for this.

As a bonus, I also made Parall able to animate Dock icons for any app, so your Dock can feel more alive instead of being completely static.

There are many more features inside the app, and I am still adding more.

Parall website: https://parall.app
Compatibility table: https://parall.app/compatibility/
Mac App Store: https://apps.apple.com/app/apple-store/id6754065114

App Trust Preview - Safety Preview for Apps, DMGs, and PKGs

App Trust Preview is a simple app I made to show safety and trust signals for downloaded Mac apps, DMGs, and PKGs before you open or install them.

For years, I used Apparency and liked it, but there were features I personally needed that were missing. So I decided to build my own tool around the workflow I wanted.

That was not the complete story. After my Reddit posts, I received a lot of feedback from the Mac community. People sent many useful feature requests, and I implemented most of them. The app grew from a small tool into a much more advanced Quick Look preview utility for the Mac App Store.

The goal of App Trust Preview is to make app safety signals understandable for people who do not know anything about sandboxing, hardened runtime, entitlements, signatures, frameworks, or app internals. It explains in simple language what is inside an app and what security-related signals it has.

One of my favorite parts is that you can finally view user-granted privacy permissions in one place. Select an installed app, press Space to open Quick Look, and App Trust Preview can show which permissions you granted to that app, with quick buttons to change them. Before this, it was always annoying to open System Settings, go through each privacy category separately, and search for the same app again just to check whether it had access to the camera, microphone, or other permissions. Now you can check that in a moment!

The app also explains how the target app is made, whether it is Electron-based or Chrome-based, which frameworks are inside, whether the signature is valid, and much more.

Finally, there is one app that can preview apps, DMGs, and PKGs in the same workflow.

App Trust Preview website: https://apptrustpreview.com
Mac App Store: https://apps.apple.com/app/apple-store/id6767974737

DockLock Lite - Stop the Dock from Jumping Between Displays

My Mac development story started with DockLock Lite, a first-of-its-kind app made to solve one of the most annoying multi-display problems on macOS.

Before making the app, I had been using Macs for over a decade. Once I started using multiple displays, I quickly became irritated by the Dock jumping between screens exactly when I was trying to find my mouse. I would move the pointer down, hit the bottom of a random display, and the Dock would unexpectedly move there.

Some people say, "Just move the mouse to the bottom of your main display to get it back." But it is not that simple.

When the Dock moves between displays, it can also move windows around and leave them resized. That drove me crazy. I like my windows to use the full available space, and now I had to constantly resize them back.

I searched for a solution for months. There were no tools and no real fixes. Some people avoided the issue by disabling “Displays have separate Spaces”, but that breaks the full-screen multi-display experience. And this Dock behavior still exists even on macOS 27 Golden Gate.

One day, I got an idea for how to stop the Dock from jumping. I quickly made a prototype, tested it, and it worked.

I started sharing comments under posts from people suffering from the same issue, and they were excited to try it. That inspired me to build DockLock Lite.

Later, I made DockLock Plus as a more advanced automation-focused version. But the story does not end there.

During my reverse engineering work, I figured out that I could push the original Dock beyond its normal behavior and move it around in ways macOS does not normally allow. That became the foundation for DockLock Pro, which I am working on now.

In symbolic protest against this long-standing annoyance, I made DockLock apps compatible with macOS 10.9 and later. That means they solve this issue across all existing macOS versions affected by this Dock behavior.

DockLock Lite/Plus/Pro website: https://docklockpro.com
Mac App Store: https://apps.apple.com/app/apple-store/id6741814079

LockLines - Make the Lock Screen Message Actually Useful

I have used the built-in macOS lock screen message feature for a while. I put contact information there in case my Mac is ever lost or stolen, so the person who finds it has a way to contact me.

Recently, I got an idea for how to improve that and make the lock screen message feel like something new.

There are already tools that can run widgets on the lock screen, but LockLines is different. It does not run background services and does not change system settings. It is focused on creating text that perfectly fits into the native macOS lock screen message area.

The interesting part is that macOS uses proportional text there, where letters do not all have the same width. That makes aligned text and ASCII-style layouts hard to create manually. LockLines solves that by helping you design text that lines up correctly inside the actual lock screen message.

This makes it possible to create borders, place text inside them, and build a message that looks intentional instead of messy.

It also helps with privacy. You can show a short visible message first, then ask the person to scroll down to see the full contact details. That way, your contact information is not fully exposed unless someone actually needs it to return your Mac.

LockLines website: https://locklines.app
Mac App Store: https://apps.apple.com/app/apple-store/id6772349545

What Comes Next

My Mac developer story is not over. I am already working on a few new projects that push through more macOS limits and bring new experiences to the Mac.

My focus is first-of-its-kind ideas. I like building tools that solve real problems, unlock workflows that were not possible before, and make macOS feel more powerful without replacing what makes it great.

If you support my work, you help make more original and innovative Mac tools possible.

If the market only supports people who copy existing ideas, it gets more copies. If people support original work, they get more original apps.

I made App Trust Preview, a Mac app for checking what macOS can verify about software before you open or install it.

Since my last Reddit post, App Trust Preview has grown from a focused app-bundle inspector into a broader pre-open/pre-install inspection tool. The amount of useful feedback from this community was amazing, and I am very happy to say that most of the requested features are now implemented in v1.2.

My todo list is still not over, and I am still open to feature requests. Feel free to leave a comment with anything you would like to see added.

A few examples:

>u/north_st-hot-weather: "Just purchased. I hope the .pkg and .dmg check comes soon!"

.pkg and .dmg support is now added in v1.2.0.

>u/Uatuwatchesmyscreen: "Is there any possibility of expanding it so that you can also see what rights it has in the settings for at a glance convenience?"

The report now shows saved user-granted macOS privacy decisions for the scanned app, and includes quick buttons that open the relevant System Settings privacy sections.

>u/Icy_Associate2022: "Please, could you make sure that the application's architecture is not hidden and is quickly visible in the apparent window?"

Architecture is now visible directly in the report, together with bundle size details.

>u/sujee81: "It'd be useful if your app shows this info" for apps using native Swift, web views, Electron, Node.js, and similar web technologies.

Framework and technology detection is now part of the report, including Electron and Chromium-based apps.

>u/bluedoggee: "I hope you can provide a MCP server(or somthing similar) for this app, so I can ask my AI agents... to invoke the MCP for investigating any app."

I started with a more universal first step: a command line interface that exports JSON or text reports, so scripts and AI agents can call App Trust Preview from Terminal. From the app UI, you can also export to PDF and PNG as well.

What is new in v1.2.0:

• Added inspection for installer packages, disk images, binary executables, and readable scripts.
• Added display of user-granted privacy permissions for the scanned app.
• Added quick buttons to open relevant System Settings privacy sections.
• Added framework and technology detection, including Electron and Chromium-based apps.
• Added app architecture and bundle size details.
• Added CLI export for JSON and text reports.
• Added Settings for configuring Quick Look and the main report view.
• Added section ordering and section hiding, so reports can be customized.
• Added multi-window support, so multiple items can be analyzed at the same time.
• Improved the interface, optimized trust signal detection, and fixed multiple report and analysis issues.

App Trust Preview can show:

• Signing status, developer identity, Team ID, bundle ID, notarization indicators, certificate chain, and certificate revocation status.
• Sandboxing, hardened runtime, internet access declarations, privacy purpose strings, saved macOS permission decisions, and quick links to relevant System Settings privacy panes.
• App architecture, bundle size, internal helpers, nested apps, frameworks, plug-ins, XPC services, and app extensions.
• Package scripts, package contents, binary metadata, script previews, framework detection, and detected technologies.

Privacy permissions

One of the most useful additions is being able to see which privacy permissions were already granted to the scanned app without opening every System Settings privacy category one by one. That saves a lot of time when you want to review what an app can access.

If you want to change something, App Trust Preview provides quick buttons that open the corresponding System Settings privacy section, so you can adjust the permission from the right place with one click.

The new CLI is useful for automation, documentation, and AI-agent workflows. An agent or script can call App Trust Preview from Terminal, inspect a target, and analyze the exported report. Example:

"/Applications/App Trust Preview.app/Contents/MacOS/App Trust Preview" --export json --target "/path/to/App.app"

Or run all tests against a disk image:

"/Applications/App Trust Preview.app/Contents/MacOS/App Trust Preview" --export json --target "/path/to/file.dmg" --tests all

For AI-agent workflows, you can also ask the agent to learn the App Trust Preview CLI by running the --help flag, then write exported reports to a writable path that you add in App Trust Preview Settings. After that, the agent can inspect apps from any folder it is allowed to access, collect JSON or text reports, and provide a review with deeper analysis of signing, permissions, bundled code, package scripts, architecture, frameworks, and other trust signals.

Example agent instruction:

Learn the "App Trust Preview.app" CLI using --help. Analyze the trust signals of apps in the /Applications folder, providing the most important signals.

Local-first behavior

App Trust Preview still works locally:

• It does not upload inspected files.
• It does not launch inspected apps.
• It does not modify inspected apps, packages, disk images, executables, or scripts.
• It does not grant or revoke permissions.
• The app itself makes no network requests.
• Certificate revocation status comes from macOS trust services.

The internal core inspection component is open source under the MIT license here: https://github.com/JulyIghor/AppTrustPreview. This is the helper used for external local inspection work, so anyone who wants to review how that part works can inspect the source.

It is not antivirus, and it does not claim that software is safe or malware-free. The goal is to show useful context before you trust software: identity, permissions, isolation, bundled code, installer contents, network access declarations, and unusual technical signals.

Comparison

There are already excellent Mac tools near this area, but they usually focus on one slice of the workflow. Apparency is great for inspecting app bundles. Suspicious Package is great for looking inside installer packages. What's Your Sign is great for quick code-signing checks from Finder. KnockKnock is focused on persistently installed software already on the Mac.

App Trust Preview is different because it is built around one local pre-open/pre-install report for multiple formats: apps, PKGs, DMGs, executables, and scripts. It combines signing and notarization context with privacy permissions, quick privacy settings buttons, architecture and bundle size details, bundled components, package scripts, framework and technology detection, report customization, and CLI export.

So I do not see it as a replacement for those tools. It is a different workflow, select something before you trust it, get a readable local report that explains the technical signals in plain language, and decide whether it deserves a closer look.

Developer information

I am not hiding behind a company name or an anonymous account. My name is Ihor July, and you can find my other projects by searching for "Ighor July".

I am also the developer of DockLock Lite, my first-of-its-kind macOS tool for locking the Dock to a chosen display. I made Parall.app, my second first-of-its-kind macOS tool, for launching Mac apps with different accounts at the same time. I also made LockLines.app, a macOS utility for designing Lock Screen messages.

My background is cybersecurity, bug bounty research, indie development, and native app development. I hack for good and help large companies find and fix security issues. Reverse engineering has always been a lot of fun for me. Now I am applying the same mindset to macOS itself: finding long-standing workflow limitations, hacking around them cleanly, and turning those solutions into Mac apps.

App Trust Preview was built to solve my own needs first, but it has expanded way beyond what I originally imagined thanks to feedback from the Reddit community. More broadly, my main work is building first-of-its-kind Mac utilities that solve specific problems Apple does not solve directly. Buying any of my apps helps me keep working on that full time.

I mostly work with C++, Qt, Objective-C, and macOS internals.

I have a strict principle for local utility apps: software that performs local actions should never connect to the internet without an explicit user action. This principle is applied across my apps.

Social profiles:

Medium: https://ighor.medium.com
LinkedIn: https://linkedin.com/in/ighor
HackerOne: https://hackerone.com/ighor
Personal Blog: https://reverseeverything.com

AI note

I use AI as a support tool for bug research, typo detection, and code completion. I also use AI to translate my apps into supported languages, including English, since English is not my native language. One component, which is open-source, the internal bash script helper was made with AI based on my own research and command testing, and it has been manually tested carefully. I also like to use AI for UI testing proof-of-concepts. If I like the idea, I recreate everything from scratch myself in Objective-C.

Price

App Trust Preview is $4.99 on the Mac App Store.

Website: https://apptrustpreview.com

Mac App Store: https://apps.apple.com/app/apple-store/id6767974737

After my post about macOS 27 and Xcode 27 ending support for backward-compatible Mac App Store apps, I decided to check what changed for iOS.

I care about this because I am a developer myself. In my own Mac apps, I made my best effort to keep the minimum macOS target as low as possible while still using a modern SDK and keeping the app experience good on current Macs. That is why I started testing this in the first place.

It looks like iOS is now in a similar situation. Apple already requires App Store submissions to be built with Xcode 26 or later. So once Apple moves that requirement to Xcode 27 after the iOS 27 release cycle, this will likely become enforced for App Store updates too.

And that is where the clock starts ticking. Before September, developers may still have a chance to release final iOS updates built with Xcode 26. Those updates can still support older iPhones and iPads, because Xcode 26 still allows lower deployment targets to build.

After that, if Apple requires Xcode 27 for App Store submissions, the cutoff is here. The minimum iOS version allowed by the toolchain becomes iOS 15.0. In practice, iOS 14 and lower may stop receiving App Store app updates at all, even from developers who still want to support those devices.

In Xcode 26.5, an app targeting iOS 9.0 still builds. Xcode shows a warning because the recommended minimum iOS version is higher, but it is still only a recommendation, not enforcement. The build succeeds.

In Xcode 27 beta, the same project fails to build:

>"The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 9.0, but the range of supported deployment target versions is 15.0 to 27.0.x."

Apple’s own Xcode requirements page now lists Xcode 27 beta deployment targets as iOS 15 to iOS 27.

That means Xcode 27 now enforces iOS 15.0 as the minimum deployment target.

Because many older iPhones and iPads are still perfectly usable. The hardware works. The apps work. Many developers are willing to continue supporting them.

Until now, Apple allowed that. If App Store submissions become required to use Xcode 27, developers will no longer be able to publish normal updates for apps that support iOS 14 and older. After September, those devices may be cut off from future App Store updates entirely.

The result is not that old devices suddenly stop working. The result is that developers who were willing to keep supporting those devices may no longer be able to ship updates through the App Store.

So there may be a short window left. Developers who still care about older iPhones and iPads may need to ship their last broadly compatible updates before the Xcode 27 requirement arrives.

After that, the door may close. Over time, fewer and fewer apps will continue supporting older iPhones and iPads, not because developers chose to drop them, but because the tools no longer allow it.

With macOS, the situation is very similar. Xcode 27 beta now enforces macOS 12.0 as the minimum deployment target, while Xcode 26 still allowed much older macOS targets to build with warnings. That cuts off macOS 11 Big Sur, macOS 10.15 Catalina, macOS 10.14 Mojave, macOS 10.13 High Sierra, and older releases from future Mac App Store updates once Xcode 27 becomes required.

For macOS, developers will still have one escape route. They can keep older Xcode versions installed, build separate legacy versions, and distribute those apps outside the Mac App Store from their own websites.

That is extra work, and many developers will not want to maintain separate builds, separate update systems, separate licensing, and separate support flows. But at least the option exists.

For iOS, that escape route does not really exist. Regular users cannot install normal iPhone and iPad apps from a developer’s website the same way Mac users can.

So if the App Store toolchain cuts off iOS 14 and older, the cutoff is much harder. For most users, the App Store is the only practical way to get app updates. After the Xcode 27 requirement arrives, iOS 14 and lower may effectively stop getting App Store app updates altogether.

For iOS, the new enforced line appears to be iOS 15.0. I do not expect Apple to support old iOS versions forever. What surprises me is the size of the jump. Xcode 26 still allowed builds targeting much older iOS releases. Xcode 27 beta jumps directly to iOS 15.0.

For owners of older iPhones and iPads, this may become one of the most significant compatibility changes Apple has made in years.

Edit: Important update after more testing.

The Xcode 27 beta error can currently be worked around by setting __DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR to NO, which makes older iOS deployment targets buildable again.

So this is not currently a hard technical cutoff in Xcode 27 beta. The remaining concern is whether Apple keeps this possible, documents it, or later enforces newer minimum targets through App Store submission requirements.

I have been a C++ developer for over a decade, and while learning Objective-C I was happy to find out that Xcode gives this awesome possibility to support much older macOS versions with minimal effort while still using a modern SDK.

Many users keep older Macs for years. Some of those Macs cannot be updated because Apple drops hardware support. So being able to support old macOS versions is not just some legacy developer habit. It is actually useful for real users.

Apple has this page with SDK minimum requirements, and right now it says apps uploaded to App Store Connect must be built with Xcode 26 or later for the listed platforms.

For Mac apps, Xcode 26 is great because it still lets me build apps with very old deployment targets. Apple’s Xcode requirements page lists Xcode 26 with macOS deployment targets from macOS 11 to macOS 26. In Xcode 26, the warnings were only for macOS deployment targets older than 10.13 but still compile. macOS 10.13 itself was still the lowest target I could use without warnings in my project.

I have made Mac App Store apps that work on macOS 10.9+. Xcode gives warnings to update the minimum version, but the apps are fully functional and were recently approved in the Mac App Store.

Objective-C and AppKit allowed me to support older users without holding back the experience for users on current Macs, and no features dropped. That means I could release apps that run on almost any macOS released in the last 13 years. That is awesome!

Now Apple announced macOS 27 Golden Gate and Xcode 27. I downloaded the beta to try it and confirm that my apps are compatible. Good news - all of my apps are compatible.

But what took my attention is that I could not compile my apps with Xcode 27 anymore.

Unlike Xcode 26, where I got warnings, now it is an error:

>"The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.9, but the range of supported deployment target versions is 12.0 to 27.0.x."

Wow. That is huge. Apple’s Xcode requirements page now lists Xcode 27 beta with macOS deployment targets from macOS 12 to macOS 27.

So Xcode 27 beta does not just warn about old macOS deployment targets anymore. It refuses to build them. That means, at least in Xcode 27 beta, Apple dropped build support for all macOS releases older than macOS 12.

Why is this important? Because if Apple later updates the App Store requirements and requires Mac App Store apps to be built with Xcode 27, then developers will lose the possibility to publish app updates that support macOS 11 and older.

That is macOS 11 Big Sur, macOS 10.15 Catalina, macOS 10.14 Mojave, macOS 10.13 High Sierra, and older releases. Many users are still stuck on those versions because their hardware does not allow them to update.

So macOS 27 Golden Gate, released together with Xcode 27, may not just drop Intel Mac support. It may also make the Mac App Store even more useless for users on macOS 11 and older, because developers would have only bad choices:

• Drop macOS 11 and older support in the next update.
• Keep support for old users, but stop releasing Mac App Store updates for the existing app, ending up with a re-release as a separate app.

The second option would force users on newer macOS versions to buy the same app again, which would likely push many developers to drop old macOS support entirely instead.

There is still a small hope that Apple may fix this before the final Xcode 27 release and treat lower macOS deployment targets as a warning again, not as an error. But as of now, the Xcode 27 beta build fails.

Also, I noticed that the new Xcode 27 beta uses about 3 GB less disk space. That may be unrelated, but together with the new hard minimum deployment target, it makes me think Apple may have removed not only some x86_64 related parts, but also a lot of pre-macOS 12 support.

For direct distribution outside the Mac App Store, developers will likely still be able to keep older Xcode versions installed and use them to build separate legacy versions for older macOS releases. So apps distributed from a developer’s own website may continue supporting older systems for longer.

Most developers will not want to maintain separate build pipelines, separate update systems, separate payment or licensing systems, and separate support flows. Some developers also do not want to distribute outside the Mac App Store at all.

I don’t expect Apple to support macOS 10.x forever. Dropping old versions is normal. I would expect this to happen gradually, one major macOS version per year, so developers and users have time to prepare.

So yes, macOS 27 Golden Gate may become the end of the golden era for backward-compatible Mac App Store apps.

I built App Trust Preview, a macOS Quick Look extension that lets you inspect a Mac app before opening it.

Select a .app in Finder, press Space, and App Trust Preview shows a readable safety and privacy report directly in Quick Look.

It checks things like:

• Apple notarization status
• Code signing, Team ID, and certificate chain
• Sandbox status
• Hardened Runtime
• Network access entitlement
• Camera, Microphone, Screen Recording, Accessibility, Location, Bluetooth, Contacts, Calendars, Photos, and other privacy-related capabilities
• Saved macOS privacy decisions when available, such as permissions already granted or denied
• Internal components like frameworks, plugins, helpers, XPC services, and app extensions
• Built-with technology detection, including Electron, Chromium-based apps, Qt, Swift, Sparkle, and more
• Architecture, bundle size, minimum macOS version, and other app metadata

The goal is not to say every app is good or bad. The goal is to make macOS app trust signals easier to see and understand before you run something.

App Trust Preview itself is sandboxed and has no network entitlement, so the inspection is local and privacy-focused. The inspected app is not launched, not modified, and not uploaded.

Website: https://apptrustpreview.com

Mac App Store: https://apps.apple.com/app/id6767974737

I would appreciate feedback from Mac users, developers, and people who install apps from outside the Mac App Store.

I'm the developer of Parall, a native macOS app that creates independent shortcut apps from apps you already have installed.

The previous post about WhatsApp support received a lot of useful feedback, and many people were happy with that integration. Based on that feedback, I decided to bring the same level of lightweight web frame compatibility to Microsoft Teams.

Parall v2.2.5 adds Microsoft Teams support, zoom controls for compatible web frame apps, and per-shortcut Appearance override.

Website: https://parall.app
Mac App Store: https://apps.apple.com/app/parall/id6754065114

What Parall is useful for

Parall creates independent macOS shortcut apps. Each shortcut can have its own Dock icon, name, optional menu bar icon, optional data storage path, environment variables, command-line arguments, Dock effects, Info.plist overrides, and now its own Appearance override.

That means you can create one Chrome shortcut for "Work", another for "Personal", another for "Client A", give each one a different Dock icon/name, pin them to the Dock, and run them with separate data.

But it is not just for browsers. Parall can create shortcuts for apps, files, folders, documents, and command-line tools. Each shortcut behaves like its own macOS app.

Common use cases:

• Running multiple accounts for apps that normally do not support it
• Keeping work, personal, and client environments separated
• Creating separate browser, IDE, AI agent, Dropbox, OBS, Signal, Telegram Desktop, Microsoft Teams, WhatsApp, or terminal setups
• Giving different profiles their own Dock icons instead of digging through app windows
• Making profiles easier to identify with different Dock icons, names, labels, and now Light/Dark appearance settings
• Creating Dock shortcuts for files, folders, documents, or command-line tools
• Adding a menu bar icon to apps that do not normally have one
• Creating separate app profiles on external drives, project folders, or synced folders
• Running multiple Philips Hue Sync instances for different displays and lighting zones

Parall does not modify your original apps or system files. It creates small shortcut app bundles that launch the original app or a supported lightweight web frame with the settings you choose.

It also has no background daemon and no telemetry. Parall itself only runs when you open it. The shortcuts you create run directly as macOS app bundles.

New: Microsoft Teams support

Microsoft Teams is now supported in Parall through the same kind of lightweight native web frame approach I previously added for WhatsApp.

Most Parall shortcuts launch the selected Mac app directly. Microsoft Teams and WhatsApp are special cases: Parall creates a lightweight native web frame app instead.

For Teams, this means you can create a dedicated Microsoft Teams shortcut app that runs the web version of Teams inside the native macOS WebKit/Safari engine.

It does not use Electron.
It does not bundle Chrome.
It does not run the native Microsoft Teams desktop app bundle.

The result is a lightweight Microsoft Teams client shortcut that behaves like a dedicated Mac app while staying efficient and predictable.

Current Microsoft Teams web frame support includes:

• Separate Microsoft Teams shortcut app with its own Dock icon and name
• Multiple Teams shortcuts for multiple accounts or organizations
• Separate data storage path per shortcut
• Optional menu bar icon
• Notifications
• Dock unread badge
• Menu bar unread count
• Background mode when the menu bar icon is enabled
• Closing the Teams window hides the window and Dock icon while Teams keeps running from the menu bar
• Audio calls, video calls, and screen sharing
• View scaling from the app menu or with Cmd + - and Cmd + = hotkeys, preserved across restarts so you can fit Teams into your layout
• No Electron or bundled Chrome runtime
• Web engine updates through the system WebKit/Safari engine

This means you control how many Teams instances and accounts you run, where each shortcut stores its app data, and when each Teams shortcut is actually running.

Why this matters for Teams

I do not like how heavy modern desktop chat apps have become.

The Microsoft Teams desktop app on macOS installs a background service after first launch. In my testing, that service can connect to the internet periodically even when I am not actively using Teams.

With a Parall Microsoft Teams shortcut, there is no extra Parall background service. If the shortcut is closed, it is closed. If you want Teams to keep receiving notifications after closing the window, enable the menu bar icon so it intentionally keeps running from the menu bar.

A Parall Teams shortcut connects to Microsoft Teams services because it is Teams. It does not connect to Parall servers and it does not add telemetry.

This is especially useful if you manage multiple Teams accounts, tenants, clients, or organizations. You can create separate shortcuts such as:

• Microsoft Teams Work
• Microsoft Teams Client A
• Microsoft Teams Client B
• Microsoft Teams Personal

Each shortcut can have its own app data path and can run side by side as a separate macOS app.

Because this uses Teams on the web, web app limitations still apply. If something is not available in Teams on the web, Parall cannot add it on top.

WhatsApp support is still included

WhatsApp support was added earlier and is still one of the most useful web frame integrations in Parall.

The official WhatsApp Mac app is sandboxed, and Parall currently cannot separate sandboxed app data the same way it can for many non-sandboxed apps. So WhatsApp is handled through a WhatsApp-optimized lightweight native web frame using web.whatsapp.com.

Because this uses WhatsApp Web, WhatsApp Web limitations still apply. For example, if a feature is not available in WhatsApp Web, Parall cannot add it on top.

New: per-shortcut Appearance override

Parall v2.2.5 also adds Appearance override.

When creating a shortcut, you can now choose:

• Follow System
• Light
• Dark

This lets you force a shortcut to use a specific Light or Dark appearance regardless of the current macOS system appearance.

The practical benefit is identification. You could already give each profile a different Dock icon, label, name, and storage path. Now you can also make profiles visually different by theme.

For example:

• Chrome Work in Light mode
• Chrome Personal in Dark mode
• VS Code Work in Light mode
• VS Code Personal in Dark mode

This makes it easier to immediately see which profile you are using.

Current limitation: Dark override while macOS itself is in Light mode may vary by app. Light override while macOS is in Dark mode works reliably in my testing. Some apps also ignore native macOS appearance settings if they implement their own internal theme system.

Other v2.2.5 improvements

This update also includes:

• Improved dark theme support
• Persistent view scaling for WhatsApp and Microsoft Teams shortcuts
• Continued compatibility fixes based on user feedback

I have been shipping compatibility and stability updates actively. Recent updates also added Microsoft Teams support, WhatsApp support, zoom controls for compatible web frame apps, improved Alfred/Raycast behavior, fixes for Dock effects and menu bar icons, better reliability on Intel Macs and older macOS 10.11+ versions, and verified support for many apps.

Examples of supported apps

Some of the apps currently verified or supported include:

• Google Chrome, Chromium, Brave, Edge, Firefox, Vivaldi, Zen Browser, Tor Browser
• Cursor, VS Code, Windsurf, JetBrains apps, Eclipse-based apps, DBeaver
• AI coding and agent tools such as OpenAI Codex, Claude, Cursor, Windsurf, and other supported AI app workflows
• Community video by Ben Can Help showing how to run multiple Claude accounts with Parall: youtu.be/IF1qZmCLWFk
• Dropbox, Discord, Signal, Telegram Desktop, Viber, Beeper Desktop
• Microsoft Teams through the native WebKit web frame integration
• WhatsApp through the native WebKit web frame integration
• iTerm2, Ghostty, Emacs, Sublime Text, Sublime Merge
• OBS, Philips Hue Sync, Blender, Audacity, Plex, Fork

There is a full compatibility list here: https://parall.app/compatibility

If an app is not listed, I can test it before purchase by your request. Just ping me at support@parall.app

Comparison

Parall overlaps with several existing macOS tools, but usually only for one part of the feature set. It is not just a browser profile manager, not just a site-specific browser, not just a menu bar utility, and not just a command launcher.

For example, if your goal is to access multiple Dropbox accounts, you can use a cloud mounting app such as CloudMounter. That can be useful if you want to mount cloud storage through public APIs and browse accounts like network drives.

Parall takes a different approach. It lets you run multiple native Dropbox clients side by side, each with its own separated profile and Dropbox folder. In that case, you are still using Dropbox's own desktop client and its native sync engine, not a third-party cloud mounting layer. That means uploads and downloads use Dropbox's native desktop sync behavior instead of relying on public API-based file access. The Parall FAQ has important Dropbox setup notes: https://parall.app/faq

For web-app wrapper tools such as Fluid, Coherence X, or Unite, the difference is also important. Those tools mainly turn websites into apps, and many web wrapper approaches rely on Electron or a Chrome-based engine. Microsoft Teams and WhatsApp are web frame exceptions in Parall, and they use the lightweight native WebKit engine built into macOS. Parall does not need to ship or update its own browser engine for this. When macOS updates WebKit, these web frames benefit from the system engine update, so you are not stuck on an old bundled Chrome or Electron runtime.

Unite Pro appears to use native WebKit too, so the web-app experience can be similar. But the generated Teams app I tested was not sandboxed and included bundled frameworks. Parall’s Teams and WhatsApp shortcuts are fully sandboxed, expose only the data path you choose, and are lightweight native Objective-C bundles with no framework dependencies. That gives a smaller risk surface if the web view or app process is ever compromised. Parall also adds persistent UI scaling for fitting each shortcut into your layout.

For menu bar tools, Parall also works differently. The menu bar icon belongs to the specific shortcut and appears only while that shortcut is running. It is not a separate background utility that stays open independently from the target app.

Developer information

I am not hiding behind a company name or anonymous account. My name is Ihor July, and you can find my other projects by searching for "Ighor July".

I am also the developer of DockLock Lite, a first-of-its-kind macOS tool for locking the Dock to a chosen display, LockLines, a tool for adding persistent on-screen alignment guides, and App Trust Preview, a tool for previewing app trust and security signals.

My background is cybersecurity, bug bounty research, indie development, and native app development. I hack for good and help large companies find and fix security issues. Reverse engineering has always been a lot of fun for me. Now I am applying the same mindset to macOS itself: finding long-standing workflow limitations, hacking around them cleanly, and turning those solutions into first-of-their-kind Mac apps. I mostly work with C++, Qt, Objective-C, and macOS internals.

I have a strict principle for local utility apps: software that performs local actions should never connect to the internet without an explicit user action. This principle is applied across all of my apps.

Social profiles:

• Medium: https://ighor.medium.com
• LinkedIn: https://linkedin.com/in/ighor
• HackerOne: https://hackerone.com/ighor

AI note

None of my apps are vibe coded. I use AI only as a support tool for bug research, typo detection, code completion, and translations. I also use AI to translate my apps into all supported languages, including English, since English is not my native language.

Important limitations

Not every macOS app can have its data separated. Some apps enforce a single-instance policy. Apple system apps are not supported. Sandboxed apps can often run as separate instances, but custom data redirection is not available because macOS forces their data into the app container. I am working to find the best solution for sandboxed app support, and it may be added in a future version of Parall.

Microsoft Teams and WhatsApp web frame shortcuts use the web versions of those services. That means web app limitations still apply.

One launch-order limitation is also worth mentioning. If you use a Parall shortcut together with the original main app, the main app should be started first before launching Parall shortcuts. To avoid this limitation, you can switch to using multiple Parall shortcuts exclusively instead of mixing the original app and shortcuts. In that setup, the shortcuts can be started in any order and no launch-order restriction applies.

Price

Parall is $9.99 on the Mac App Store.

Website: https://parall.app
Mac App Store: https://apps.apple.com/app/parall/id6754065114

I released a new Parall v2.2.5 and wanted to share what changed.

Parall is a Mac App Store app that creates separate shortcut apps from apps you already have installed. Each shortcut can have its own Dock icon, name, menu bar behavior, optional data path, launch settings, and appearance settings.

The main use case is running separate app contexts side by side. For example, you can run the same compatible Mac app multiple times with separate data, separate Dock icons, and separate settings instead of switching everything inside one shared app state.

Parall works with most non-sandboxed macOS apps. Sandboxed apps are more limited because macOS forces them to use their system container.

The new update adds WhatsApp and Microsoft Teams support.

These two are special cases. Most Parall shortcuts launch the original Mac app directly. WhatsApp and Microsoft Teams now use lightweight native web frame shortcuts instead.

That means:

• No Electron
• No bundled Chrome
• Uses the native macOS WebKit/Safari engine
• The web frame stays aligned with system Safari/WebKit updates
• Separate shortcut app with its own Dock icon and name
• Optional menu bar icon
• Notifications
• Dock unread badges
• Menu bar unread count
• Background mode when the menu bar icon is enabled
• View scaling from the menu bar or hotkeys, useful for fitting Teams or WhatsApp into a specific layout

Parall makes multiple-account setups easier. You can create separate Teams shortcuts with separate data paths and run as many accounts side by side as your Mac can handle.

One reason I wanted this is that the Microsoft Teams desktop app on macOS installs a background service after first launch. In my testing, that service can connect to the internet periodically even when I am not actively using Teams.

With a Parall Teams shortcut, there is no extra Parall background service. If the shortcut is closed, it is closed. If you want it to keep receiving notifications after closing the window, enable the menu bar icon so it intentionally keeps running from the menu bar.

The update also adds per-shortcut appearance override.

You can now choose Follow System, Light, or Dark while creating a shortcut. This makes it possible to run the same app twice with different appearance settings. For example, one instance can be Light and another can be Dark.

Current limitation: forcing Dark may not work for every app while the system is in Light mode, but forcing Light on system Dark mode works reliably in my testing. Some apps also ignore native macOS appearance settings if they implement their own internal theme system. More supported apps to be added soon.

Parall is available in the Mac App Store and supports macOS 10.11 and later.

Website: https://parall.app
Compatibility list: https://parall.app/compatibility

I am still testing more apps. If you have a Mac app you want checked for multi-instance support, send it to me and I can test whether Parall can support it.