# Ziyarex — full text > Ziyarex makes Mac utilities, browser extensions and mobile apps, and publishes free browser-based tools for developers and app makers. This file is the complete text of every free tool description and every article on ziyarex.com, so it can be read in one request. The short index is at https://ziyarex.com/llms.txt. Everything Ziyarex publishes is free to quote with attribution to Ziyarex and a link to the page it came from. ## Browser tools ### App Store screenshot resizer https://ziyarex.com/tools/screenshots Resize app screenshots to the exact pixel dimensions the App Store and Google Play accept, including iPhone, iPad, Mac and the Play feature graphic. Runs in the browser, nothing is uploaded. People look for this with: app store screenshot size; google play screenshot dimensions; resize app screenshots; app store screenshot generator; play store feature graphic size. How to resize screenshots for the App Store and Google Play 1. Drop your screenshots in: Straight from the simulator or a device capture. They are read in the browser, not uploaded. 2. Choose the store sizes you need: iPhone, iPad, Mac, the Play phone sizes and the Play feature graphic. 3. Choose how they should fit: Fill the frame and crop the edges, or fit the whole screenshot and let a bar colour fill the gaps. 4. Download the zip: Sorted into folders, at the exact pixel dimensions each store accepts. ### App icon generator https://ziyarex.com/tools/icons Turn one square image into every app icon size iOS, macOS, Android, watchOS and the web need, with Contents.json and the Android XML written for you. Runs in the browser, nothing is uploaded. People look for this with: app icon generator; ios app icon sizes; android adaptive icon generator; appiconset generator; favicon generator. How to generate app icons from one image 1. Drop in your artwork: One square image, 1024x1024 or larger, so every size is scaled down rather than stretched up. 2. Pick the platforms you need: iOS, macOS, Android, watchOS and web. Every set comes with its config files written for you. 3. Set a background if it needs flattening: The App Store rejects icons with transparency, so choose the colour that fills it. 4. Download the zip: Every size, plus Contents.json and the Android XML, assembled in your browser. ### QR code generator https://ziyarex.com/tools/qr Make a QR code for a link, Wi-Fi network, contact card, event or payment, style it with your own colours and logo, and download it as PNG, SVG, JPG or PDF. Free, no account, nothing uploaded. People look for this with: qr code generator; free qr code generator no sign up; wifi qr code generator; vcard qr code; qr code with logo. How to make a QR code 1. Pick what the code should do: A link, a Wi-Fi network, a contact card, an event or a payment. 2. Fill in the details: Everything you type stays on your device. Wi-Fi passwords never leave the browser. 3. Style it: Colours, module shapes, your logo in the middle and a frame with a call to action. 4. Download it: PNG or JPG for screens, SVG for a designer or printer, PDF to send straight to print. ### Smart app link https://ziyarex.com/tools/app-link Make one short link that sends every visitor to the right place: the App Store on an iPhone, Google Play on Android, the Mac or Microsoft Store on a desktop, and your website for everyone else. Comes with a styled QR code, campaign parameter forwarding and coarse click stats. Free, no account, no expiry. People look for this with: smart app link; one link for app store and google play; app store and play store link in one; onelink alternative free; app download link generator. How to make one link that works on iPhone and Android 1. Paste your store links: The App Store and Google Play addresses of your app. Each one is read back automatically, so the name, icon and rating fill themselves in. 2. Add a fallback: Where anyone who isn't on a phone should go — usually your website. This is also what search crawlers see, so the link is never a dead end. 3. Name it and pick the behaviour: Choose your own short name, keep campaign parameters attached through the redirect, and decide whether to redirect straight away or show the app first. 4. Share the link or print the QR: Copy the link, or download the QR code as PNG, SVG or PDF. Both keep working after you change where they point. ### ASO audit https://ziyarex.com/tools/aso-audit Paste an App Store or Google Play link and get a 0 to 10 score for the listing, with feedback on the icon, title, subtitle, screenshots and description, and the fixes ranked by what each is worth. A full sample report is on the page. People look for this with: aso audit; app store optimization audit; app store listing audit tool; app store listing review; google play listing audit. How to audit your app store listing 1. Copy your listing link: The App Store or Google Play address of your app, exactly as it appears in the address bar. 2. Paste it and run the audit: The icon, screenshots and copy are read in the order a shopper meets them. It takes up to a minute. 3. Read the score and the element cards: Icon, title, subtitle, screenshots, description and overall coherence, each graded separately. 4. Work the fixes from the top: They are ranked by the points each one wins back, with ready-to-paste copy where the fix is a wording change. ### Word to PDF https://ziyarex.com/tools/word-to-pdf Convert Word, Excel, PowerPoint, OpenDocument, RTF, TXT and CSV files to PDF with the layout intact. Free, no account. This is the one Ziyarex tool that sends your file to a server: it is converted inside a virtual machine created for that one job and destroyed straight after. People look for this with: word to pdf; docx to pdf; convert word to pdf free; excel to pdf; powerpoint to pdf. How to convert a Word document to PDF 1. Choose the document: Word, Excel, PowerPoint, OpenDocument, RTF, TXT or CSV, up to 40 MB. 2. Convert it: The file goes to a virtual machine running LibreOffice, which renders the layout properly rather than approximating it. 3. Download the PDF: It comes straight back in the same response. 4. Nothing is kept: The machine that converted your document is destroyed when it finishes, and the file was never written to a disk. ### PDF compressor https://ziyarex.com/tools/compress-pdf Compress a PDF in your browser. Rewrite the file structure to save space with the text left intact, or re-photograph the pages to shrink a scan by an order of magnitude. Free, no account, nothing uploaded. People look for this with: compress pdf; reduce pdf file size; make pdf smaller; compress pdf without losing quality; shrink pdf online free. How to make a PDF smaller 1. Drop the PDF in: It is opened in your browser, not uploaded to a server. 2. Pick how hard to squeeze: Keep text sharp rewrites the structure and keeps the text selectable. Smallest file re-photographs each page. 3. Compress it: You are told the before and after size, including when a file was already as small as it gets. 4. Download it: Straight from your own machine. ### PDF to JPG https://ziyarex.com/tools/pdf-to-jpg Turn a PDF into JPG or PNG images, one per page, at screen, good or print resolution. Runs in the browser, nothing is uploaded. People look for this with: pdf to jpg; pdf to png; convert pdf to image; pdf to jpg converter free; extract images from pdf. How to convert a PDF to JPG 1. Drop the PDF in: It is read in your browser, not uploaded. 2. Choose the format: JPG for a smaller file, PNG for sharper edges on text and flat colour. 3. Choose the resolution: 96 DPI for screens, 150 for general use, 300 for print. 4. Download the zip: One image per page, numbered in order. ### JPG to PDF https://ziyarex.com/tools/jpg-to-pdf Combine JPG and PNG images into a single PDF, sized to each image or laid onto A4 or Letter pages. Runs in the browser, nothing is uploaded. People look for this with: jpg to pdf; png to pdf; image to pdf converter; combine images into pdf; photos to pdf free. How to convert images to a PDF 1. Drop your images in: JPG or PNG. They are read on your device and never uploaded. 2. Choose the page size: Match each image exactly, or lay them onto A4 or Letter pages. 3. Choose how they sit: Fit inside the page, fill it and crop, or stretch to the edges. 4. Download the PDF: One file, pages in the order you picked them. ### PDF unlocker https://ziyarex.com/tools/unlock-pdf Remove a PDF's password, or the owner restrictions that stop it being printed, copied or edited. The file is rewritten properly, so text stays text and nothing is flattened into an image. Runs in the browser, nothing is uploaded. People look for this with: unlock pdf; remove pdf password; pdf password remover free; remove pdf restrictions; enable printing on a pdf. How to remove a password from a PDF 1. Open your PDF: Drag it onto the page or choose it from your computer. It opens inside the tab and is never uploaded. 2. See what kind of lock it has: A file with only printing and copying restrictions is unlocked straight away. One that asks for a password to open needs that password from you. 3. Remove the protection: The file is rewritten without its encryption. Every page, all the text and every form field come through unchanged. 4. Download it: The unlocked PDF saves to your device, the same size and quality as the one you started with. ### PDF password protector https://ziyarex.com/tools/protect-pdf Encrypt a PDF with AES-256 and a password, and set whether readers may print it, copy text out of it, edit it or fill in its forms. Runs in the browser, so neither the document nor the password is ever uploaded. People look for this with: password protect pdf; encrypt pdf free; add password to pdf; lock a pdf; stop a pdf being printed. How to password protect a PDF 1. Open your PDF: Drag it onto the page or choose it from your computer. It never leaves your browser. 2. Choose the password: This is the password a reader is asked for before the file will open. Nobody can recover it, so save it somewhere first. 3. Decide what readers may do: Printing at full quality, low quality or not at all, and whether copying, editing, commenting, form filling and reordering pages are allowed. 4. Download the protected file: It's encrypted with AES-256, and every reader that respects the standard will ask for the password. ### PDF editor https://ziyarex.com/tools/pdf-editor Edit the text already in a PDF, add images, shapes, highlights and signatures, white anything out, fill in forms and reorder pages. Everything happens in the browser, so the file never leaves your device. People look for this with: free pdf editor; edit pdf text online; sign a pdf free; whiteout pdf; fill in pdf form free. How to edit a PDF in your browser 1. Open your PDF: Drag the file onto the page or choose it from your computer. It opens inside the tab and is never uploaded. 2. Rewrite the text that is already there: Pick the Text tool and click any line. It is covered in the page's own background colour and replaced with an editable box holding the same words. 3. Add what is missing: Drop in a signature, an image, shapes, highlights or ticks, and white out anything that should not be there. 4. Sort out the pages: Rotate, duplicate, delete or insert blank pages from the rail on the left, or number the whole document in one go. 5. Save it: Press Apply changes and the edited PDF downloads to your device. ## Articles ### Move off browser-saved passwords in an hour https://ziyarex.com/journal/move-off-browser-saved-passwords — 2026-08-17 Letting the browser remember passwords is not a moral failing. It is the default, it works, and it beats writing them on paper. It has two real problems, and neither is the one people worry about. The first is that the passwords live inside one browser. Change browsers, or try to log in on a phone that syncs with something else, and you are locked out of your own list. So you start reusing something memorable for anything you might need to type by hand. The second is that reuse is invisible. The browser will happily store the same password for forty sites and never mention it. That is the actual risk: not that someone breaks into your browser, but that one unrelated site gets breached and hands over a password that also opens your email. ## First, find out what's already out Before moving anything, check what has already leaked. Have I Been Pwned (https://ziyarex.com/discover/have-i-been-pwned) takes an email address and tells you which known breaches contained it. Read the result carefully. It lists the breach and what was exposed. "Email addresses, passwords" on a site you forgot you joined in 2014 matters *only* if that password is one you still use elsewhere. That is the list you are about to fix. One honest caveat: a clean result proves very little. It only knows about breaches that became public. ## Pick the manager, then leave it alone Almost any dedicated password manager beats the browser. We list Bitwarden (https://ziyarex.com/discover/bitwarden) because it is open source, audited, and its free tier is genuinely usable rather than a trial — unlimited passwords on unlimited devices, which is the part competitors charge for. Install it in two places on day one: the browser extension and your phone. A manager you can only reach at your desk gets abandoned by Wednesday. ## The migration, in the order that matters Do not start by importing everything. Import first and you will have a tidy vault full of the same three passwords. 1. Export from the browser. Every major browser has a password export in settings; it produces a CSV. Import that CSV into your new vault. 2. Delete the CSV properly. It is a plain-text file with every password you own. Empty the trash too. This is the single riskiest object in the whole process, and it exists for about ninety seconds. 3. Run the vault's health check. Every manager has one. It flags reused, weak and breached entries. This is your work queue, and it is usually shorter than you fear — most people have four or five real passwords wearing different hats. 4. Fix in blast-radius order, not alphabetically: - Email first. Whoever controls your email can reset everything else. This is not a tie for first place. - Then anything with money: bank, card, payment services, anywhere your card is stored. - Then identity: phone carrier, cloud account, domain registrar, government logins. - Then everything reused. - Then the rest, lazily. Change those as you next log in. Trying to fix two hundred sites in one sitting is how people quit halfway. 5. Turn off the browser's password manager. Not just cleared, off. Otherwise it keeps offering to save things and you end up with two half-lists. 6. Add two-factor to the accounts from step 4. An authenticator app, not SMS where you have the choice. SIM swapping is a real attack and text messages are the weakest of the common options. ## The risk you just took on Be clear-eyed: you have concentrated everything into one vault behind one password. That is a genuinely better trade than reuse across forty sites, but it is a trade. So the master password has to be strong and *memorable without being written into another app*. Four or five unrelated words beats a short scramble of symbols — long and typeable wins over clever. And print the recovery material. Most managers cannot reset your master password, by design, because they never had it. That is the property you are paying for, and it means losing it loses the vault. A printed recovery code in a drawer is not paranoid. ## What this doesn't fix Passkeys are quietly replacing this whole dance on sites that support them, and where a site offers one, take it. But adoption is patchy, and until it is not, you still need the boring vault underneath. --- ### Send a big file to another device without the cloud https://ziyarex.com/journal/send-a-big-file-without-the-cloud — 2026-08-17 Two devices in the same room. One has a file the other needs. The normal answer is to upload it to a server in another country so it can be downloaded straight back to a machine three feet away. You pay for that twice: once in the upload, which on most home connections is far slower than the download, and once in whatever the file picks up on the way through — an account, a link that works for anyone who finds it, a retention policy you didn't read. There is a whole class of tool for this and most people never meet it. ## One-off transfers: LocalSend LocalSend (https://ziyarex.com/discover/localsend) is the closest thing to AirDrop that does not care what you own. Install it on both devices, open it on both, and each appears in the other's list. Pick the file, accept on the far end, done. No account, no link, no size ceiling, and the bytes never leave the network. This is the answer to the oldest annoyance in a mixed household: getting video off an iPhone and onto a Windows laptop without iCloud in the middle. The catch is the network. Both devices must be on the same one, and plenty of Wi-Fi has *client isolation* switched on — guest networks, hotels, offices, most public Wi-Fi — which stops devices seeing each other at all. If discovery silently finds nothing, that is usually why, and it is not something the app can fix. A phone hotspot with both devices joined to it is the reliable workaround. ## The same two folders, forever: Syncthing If this is not a one-off — a folder that should simply be identical on the desktop and the laptop — you want continuous sync instead of repeated sending. Syncthing (https://ziyarex.com/discover/syncthing) does that with no server in the middle. You introduce two machines once, tell them which folders to share, and it keeps them matched from then on. There is no storage tier to outgrow because there is no storage: it is your disks, talking. It earns its place by being boring. Set up correctly, it runs for years without attention. Two honest catches. The first setup is genuinely fiddly — device IDs, folder IDs, deciding which side is authoritative — and budget an evening rather than ten minutes. The second: there is no first-party iOS app, so if the phone in this story is an iPhone, this is not your tool. Also, and this matters: sync is not backup. Delete a file on one machine and Syncthing faithfully deletes it everywhere. Versioning is a setting, and it is worth turning on. ## Not on the same network: Tailscale The local tools stop working the moment the devices are genuinely apart — laptop at a café, desktop at home. Tailscale (https://ziyarex.com/discover/tailscale) closes that gap by putting your own machines on a private network as though they were in one room, wherever they physically are. No port forwarding, no router configuration, no VPN config written by hand. Once it is running, the home machine has a stable address the laptop can reach from mobile data, and every tool above starts working again over that link. The catch: the convenience depends on trusting Tailscale's coordination service to broker those connections, and the mental model — nodes, tailnet, exit nodes, access rules — takes an afternoon before it clicks. Worth it if you have more than two machines. Overkill for one transfer. ## Choosing, quickly - Once, devices side by side → LocalSend. - The same folder on two machines, indefinitely → Syncthing, with versioning on. - The devices are in different places → Tailscale, then either of the above across it. - Sending to someone else, who will not install anything → this is the one case where a normal upload link is the right tool. Use one with an expiry. --- ### Leave a photo subscription without losing your library https://ziyarex.com/journal/leave-a-photo-subscription — 2026-08-17 The bill arrives, the tier is full again, and you do the arithmetic: this is rent, forever, on photographs you already took. So you look at moving the library somewhere you own. It is very doable. It is also the kind of project where the exciting part — picking the software — is the least important, and the boring part decides whether you keep your photos. ## Get the files out first, before choosing anything Export before you evaluate. Until you have the archive on a disk you can hold, you do not have a migration, you have a plan. Both big providers have a bulk export. Ask for the whole library, expect it in multiple large archives, and expect it to take a while. Then, before deleting anything anywhere, check three things: 1. The count. Does the number of files roughly match what the service claimed you had? Order-of-magnitude, not exact — exports handle duplicates and edits differently. 2. The videos. They are the biggest files and the most likely to be quietly truncated or skipped. 3. The edits. If you cropped or filtered a photo years ago, decide whether you expect the original, the edited version, or both. Exports vary, and some give you both as separate files with confusingly similar names. ## The metadata trap This is the part that ruins migrations, and it is worth understanding before you import anything. A photo's date, location and description usually live *inside* the file, in EXIF. But large exports frequently ship that information beside the photo instead, in a sidecar JSON file per image, because the service kept some of it in its own database rather than in the file. Import the folder naively into new software and you get a library where everything is dated the day you downloaded it, sorted into one enormous 2026 pile, with no locations. The photos are all there. The twenty years of order is gone. So: check for sidecar files before importing. If they are there, use a tool that reads them and writes the values back into the images — this is what people mean by "merging the JSON" in migration guides. Do it once, on a copy, and verify a handful of known photos have the right dates before you trust the whole run. Test with a small folder first. A hundred photos will teach you what a hundred thousand would, in four minutes instead of two days. ## Where to put it Immich (https://ziyarex.com/discover/immich) is the first self-hosted photo app that does not feel like a downgrade. Phone auto-backup, face and object search, shared albums, a timeline that scrubs smoothly through a large library. The things that made the subscription pleasant are mostly here. Be honest about what it needs: a machine that stays on. A spare mini PC, a NAS, an old desktop in a cupboard. If your answer is "my laptop", this project will disappoint you — auto-backup from a phone needs something always reachable. The real cost is the sysadmin role. Releases move quickly, so read the upgrade notes rather than updating blind, and know where the database backup lives before you need it. ## The backup maths, which is the whole thing Your subscription was quietly doing something you are about to stop paying for: keeping copies in more than one building. A single drive at home is not a backup, it is a single point of failure with your photographs on it. Drives die, and they die without warning. So: - Three copies of anything you cannot re-create. - Two different kinds of storage. - One somewhere else entirely — another building, or encrypted cloud storage. Cheap object storage for a compressed archive costs a fraction of a photo subscription and does not need to be fast, because you will hopefully never read from it. An external drive at a relative's house, swapped when you visit, is a legitimate offsite copy. ## Then, and only then, cancel Keep paying for one more month after everything works. Run one real restore test: pick a photo from 2016, recover it from your backup, confirm it opens with the right date. Untested backups fail at exactly the wrong moment. Then cancel, and let the service delete on its own schedule. ## The honest recommendation If you enjoy running a small server, this is a good trade: better search than you had, no monthly bill, and your library on your own disk. If you do not, stay subscribed. A photo library maintained by someone who resents maintaining it is more fragile than a rented one, and "I'll sort the backups out later" is how people lose baby photos. Paying someone to be responsible is a perfectly rational purchase. --- ### Paid tools you can replace with a browser tab https://ziyarex.com/journal/paid-tools-you-can-replace-with-a-browser-tab — 2026-08-17 Browsers got quietly, dramatically more capable. Work that needed a licensed desktop application ten years ago now runs in a tab, on your own machine, without the file leaving it. Two things make this worth caring about. It is free, obviously. But the better property is that the good ones are local: the file is processed by your own browser, so there is no upload, no queue, no copy sitting on a stranger's server. That distinction matters far more for a signed contract than for a meme. Here are the jobs where a tab is genuinely the right tool now. ## Shrink an image without guessing Squoosh (https://ziyarex.com/discover/squoosh) shows the original and the compressed version side by side with a slider, so you stop exporting at "quality 80" out of habit and start seeing where an image actually falls apart. Usually far lower than you would dare. Everything happens in the browser. *Catch: one image at a time, no batch, and development has been quiet for a while.* ## Open a PSD on a machine that has never had Photoshop Photopea (https://ziyarex.com/discover/photopea) opens PSD, XD, Sketch and RAW files with layers, masks and adjustments intact. Handing someone a layered file and having them open it on a borrowed laptop is genuinely useful. *Catch: ad-supported unless you pay, and big files make the tab work.* ## Draw the diagram before the argument Excalidraw (https://ziyarex.com/discover/excalidraw) opens instantly with nothing to sign into. The deliberately hand-drawn style is the feature: it reads as a sketch, so people discuss the idea instead of the alignment. *Catch: that same look is wrong for anything that must appear finished.* ## Edit and sign a PDF without uploading it This is the one where "free online tool" usually means "upload your document to us". A signed agreement, a passport scan, a bank statement — those are exactly the files that should not be posted to a stranger's server to have a page rotated. Our PDF editor (https://ziyarex.com/tools/pdf-editor) does merge, split, reorder, rotate, delete pages and signatures entirely in the browser. Nothing is uploaded, because there is nowhere to upload it to. There is a longer piece on why that matters: how to sign a PDF without uploading it anywhere (https://ziyarex.com/journal/sign-a-pdf-without-uploading-it). ## Make a QR code that still works next year Most free QR generators route the code through their own domain so they can charge you later or count the scans. If that redirect ever lapses, every printed copy dies. Our QR generator (https://ziyarex.com/tools/qr) encodes the destination directly, so nothing sits between the code and the URL. Every type, every style, no account, no watermark. The trade-off is real and worth understanding: static versus dynamic, and who owns the redirect (https://ziyarex.com/journal/qr-codes-that-dont-expire). ## Export every app icon size at once If you ship an app, you know the tedium: dozens of exact pixel sizes across iOS, macOS, Android and Chrome, each wrong in a way the store notices. Our icon generator (https://ziyarex.com/tools/icons) takes one square source and emits the whole set, and the screenshot resizer (https://ziyarex.com/tools/screenshots) does the same for store screenshots. Both run locally. The sizes are the ones we ship ourselves — the full table is in the icon size cheat sheet (https://ziyarex.com/journal/app-icon-sizes-cheat-sheet). ## Check a store listing before you pay someone to Our ASO audit (https://ziyarex.com/tools/aso-audit) scores an App Store or Google Play listing — icon, title, subtitle, screenshots, description — and ranks the fixes by what each is worth. It will tell you unflattering things about your own app, which is the point of an audit. ## When you should still pay Being fair about the limits, because a list like this usually is not: - Batch work. Tabs are built around one file. Three hundred images want a real desktop tool or a script. - Colour-critical output. Print work, wide-gamut, ICC profiles — none of this is browser territory. - Anything on a deadline with support attached. Free tools owe you nothing. If a failure costs you a client, buy the thing with a support address. - Daily professional use. If a tool is how you earn a living, pay for it. The good desktop applications are worth their price, and the people who make them should keep making them. The point is not that paid software is a scam. It is that a lot of us are carrying subscriptions for jobs we do four times a year, which a tab now does properly and locally. Every tool of ours mentioned here is on the free tools page (https://ziyarex.com/tools). No account, nothing uploaded. --- ### Your menu bar is out of room. Here's the triage. https://ziyarex.com/journal/menu-bar-triage — 2026-08-16 Open a fresh Mac and the menu bar has maybe six things in it. Eighteen months later it has twenty-four, the ones on the left have vanished behind Safari's menus, and you have no idea what four of the icons do. This isn't a discipline failure. It's a design incentive. Every utility that ships wants ambient presence, the menu bar is the only always-visible surface an app can claim without stealing a Dock slot or a window. So every utility claims it, whether or not it has anything to say. ## The constraint nobody warns you about Menu bar items don't scroll. They get *overlapped*. macOS gives the frontmost app's menus priority from the left, and status items fill from the right; when the two meet, yours silently disappear. On a 13-inch screen with an app that has a lot of menus, you lose items you're still paying for. The notch makes it worse by carving a hole in the middle of the run. Items don't wrap around it, the usable width just shrinks. A 14-inch MacBook Pro running an app with wide menus can hide half your status items with no warning and no indicator. So the question isn't "how do I fit more." It's "what deserves to be there at all." ## The triage: three buckets, one rule each Go through the bar left to right and put every icon in exactly one bucket. The rule for each is deliberately narrow. ### Keep, it changes state you act on An icon earns a permanent seat only if *looking at it* tells you something that changes what you do next. Not "I might click it someday." It has to be readable at a glance, in a 16-pixel monochrome glyph, without clicking. Realistically that's three to five things. Battery when you're on the road. VPN when you're on someone else's network. The recording indicator when you're recording. A timer that's running. ### Hide: useful, but only on demand This is the biggest bucket and the one people get wrong. Clipboard history, screenshot tools, window managers, audio switchers. You *use* these constantly, but you use them by keyboard shortcut, not by looking at them. The icon is a launcher for something you never launch by clicking. These don't need to be visible. They need to be *running*. Those are different requirements, and macOS has never distinguished between them, which is why a whole category of menu bar managers exists. ### Quit, it's furniture Anything you can't explain in one sentence. Anything whose app you've stopped using but whose helper still launches at login. Anything that's an advertisement for an app you already own. Be honest here. The test is: if you can't remember the last time this icon helped you, it isn't helping you. ## Doing it, without third-party software first Before you install anything, macOS already gives you three levers. Rearrange with ⌘-drag. Hold Command and drag any status item. Put your Keep bucket on the right, where the frontmost app's menus can never overlap them. This one takes two minutes and solves the "my important icons vanished" problem outright. Prune Control Centre. A good chunk of what's up there is system modules, not apps. System Settings → Control Centre lets you set each one to "Show in Menu Bar", "Don't Show", or show only when active. Wi-Fi, Bluetooth, Sound, Focus, Now Playing, most people can move at least four of those into Control Centre itself and reclaim the width. Kill the login items. System Settings → General → Login Items & Extensions. The "Allow in the Background" list is where the Quit bucket actually lives. Turning an icon off in an app's preferences usually leaves the helper running; turning it off here stops it. ## Then, a manager for the Hide bucket Once Keep is small and Quit is gone, whatever's left goes behind a divider you expand when you want it. - Ice (https://ziyarex.com/discover/ice), free, open source, and now the default recommendation for most people. It hides items behind a divider, and it handles the notch sensibly. - Bartender, the oldest and deepest option, with the best rules engine (show this icon only when it changes, hide it again after five seconds). Paid, and worth knowing that it changed hands in 2024 and the transition was handled badly enough that some long-time users left over it. - Hidden Bar, free, minimal, does one thing. None of these reduce the number of apps running. They reduce the number you *see*. That's the honest framing: a manager is a filing cabinet, not a diet. ## The part where we admit our own bias Three of the things in our own bar are ours, and they exist because of exactly this problem: Oreo (https://ziyarex.com/store/oreo) is the argument that some of this shouldn't be in the menu bar at all. Now playing, timers, progress on a long export, that's live state that deserves more than a 16-pixel glyph, and the notch is sitting right there doing nothing. That's a $12 opinion, and the honest comparison against the other notch apps (https://ziyarex.com/compare/best-macos-notch-apps) is on this site too. Insomniac (https://ziyarex.com/store/insomniac) is a Keep-bucket icon by our own rule: when it's on, your Mac isn't sleeping, and that's state you want to see without clicking. When it's off it's a static glyph, which is precisely why it's free. Clickk (https://ziyarex.com/store/clickk) fails our own test and we ship it anyway. It makes your keyboard sound mechanical. It tells you nothing. Put it in Hide, keep it running, enjoy it. ## Re-run it quarterly The bar refills. New app, new icon, and six months later you're back to twenty-four. Put a recurring reminder somewhere you'll actually see it (if you use Slate (https://ziyarex.com/store/slate), that's your wallpaper) and run the three buckets again. It takes ten minutes and you get the top of your screen back. --- ### Why your Mac wakes at 3am, and how to read the sleep log https://ziyarex.com/journal/why-your-mac-wakes-at-3am — 2026-08-16 You closed the lid at midnight. At 3am the fan spins up, the charging light changes, the machine is warm in the morning and the battery is down eleven percent. Nobody touched it. Most advice for this is a list of things to turn off. Don't do that. macOS writes down exactly why it woke, every single time, and the fix depends entirely on the reason. Read the log first, it takes about ninety seconds. ## Step one: ask what happened pmset -g log | grep -e "Wake " -e "DarkWake" | tail -40 You'll get lines that look roughly like this: 2026-08-14 03:00:11 +0100 Wake DarkWake to FullWake from Standby [CDNVA] : due to RTC/HID Activity 2026-08-14 03:24:52 +0100 DarkWake due to ARPT/Maintenance Two fields matter. Wake vs DarkWake, and the reason after "due to". A DarkWake is a maintenance wake: the screen stays off, the machine does a task, it goes back to sleep. That's normal and mostly harmless. A Wake is a full wake, screen, fans, the works. Repeated full wakes overnight are what you're hunting. ## Step two: decode the reason These are the ones you'll actually see: - RTC (Alarm), a scheduled wake. Something asked the machine to get up at a specific time. Run pmset -g sched to see the schedule. - ARPT / Wake on Network, something on your network sent a packet the Mac was told to care about. Screen sharing, a Back to My Mac descendant, a NAS, or another Apple device. - EC.LidOpen: you opened the lid. Not your mystery. - XHC1 / XDCI / USB, a USB device twitched. A mouse on a slightly uneven desk, a dock, a hub with flaky power, a monitor's built-in hub. - HID Activity, a keyboard, trackpad or Bluetooth input device reported activity. Bluetooth mice in a bag are a classic. - BATC / Battery, a battery threshold event. - Maintenance / PowerNap: Power Nap doing mail, calendar, photo sync, Time Machine or a software update check. The single most common cause of the 3am pattern specifically is a scheduled maintenance window: Power Nap plus automatic update checks plus Time Machine tend to cluster overnight, and they're the reason the machine picks a suspiciously round hour. ## Step three: see what's holding it awake right now Different question, same evening. If the machine won't sleep *at all*, the culprit is an assertion, not a wake: pmset -g assertions The top block shows which assertions are held, and the block below names the process holding each one. PreventUserIdleSystemSleep held by a video app, a download manager, or a stuck helper is the usual answer. If you find something you don't recognise, that's your lead. For the full picture at once: settings, assertions, scheduled events and recent history in one dump: pmset -g everything | less ## Step four: fix the cause you actually found Apply only the one that matches your log. Each of these is a real trade-off, not a free win. If it's Power Nap / Maintenance: sudo pmset -a powernap 0 Cost: mail, calendar and photo sync stop happening while asleep. They resume the moment you wake it. For most laptops this is a good trade. If it's ARPT / Wake on Network: sudo pmset -a womp 0 Cost: you can no longer wake this Mac remotely, and screen sharing to a sleeping machine stops working. On a desktop that you remote into, leave this alone. If it's a network stack keepalive (a Mac on power, waking every few hours): sudo pmset -a tcpkeepalive 0 Cost is real and worth stating plainly: Find My, iMessage delivery and push notifications stop arriving while the machine is asleep. macOS will warn you about this. Only reach for it if the log clearly points here. If it's Bluetooth / HID: System Settings → Bluetooth → Advanced, and turn off "Allow Bluetooth devices to wake the computer." Then check whether a mouse is living in a bag with something pressing on it, because that's frequently the whole story. If it's USB: unplug the hub or dock for one night as a test. A single failing hub can generate dozens of wakes, and no software setting fixes bad hardware. If it's RTC with a scheduled event: pmset -g sched will name it. Time Machine, an update check, or something you set up years ago and forgot. Remove the schedule at its source rather than blanket-disabling wakes. ## The setting to reach for last You'll find sudo pmset -a disablesleep 1 recommended in forum threads for this. It does work, in the sense that a machine that never sleeps never wakes. It also disables the sleep safety entirely, including lid-closed sleep. Leave it on, put the laptop in a bag, and it will run at full tilt in an enclosed space with no airflow. That's a real way to cook a battery. If you need closed-lid awake behaviour deliberately, that's a different job with different guardrails, and we wrote it up separately (https://ziyarex.com/journal/keep-macbook-awake-lid-closed), it's also the entire reason Insomniac (https://ziyarex.com/store/insomniac) watches the thermal state instead of just flipping the switch. For the 3am problem, don't use it. You have a log line telling you the actual cause. Fix that. ## A note on what "fixed" looks like After you change one setting, check the log again the next morning rather than declaring victory: pmset -g log | grep -e "Wake " | tail -20 Machines usually have more than one cause. Fix them one at a time, in the order the log ranks them by frequency, and you'll find two settings cover almost everything. --- ### Mechanical keyboard sound without the mechanical keyboard https://ziyarex.com/journal/mechanical-keyboard-sound-without-the-keyboard — 2026-08-16 A butterfly-era MacBook keyboard sounds like tapping a countertop. Even the good ones since sound flat and short. Meanwhile the thing people actually enjoy about a mechanical keyboard, more than the travel or the actuation force, is the *noise*, the confirmation that something happened. You can have that on a laptop keyboard for free. The mechanism is trivial: something watches for keystrokes and plays a sample. The interesting part isn't the feature, it's what the app has to be allowed to do in order to provide it. ## What these apps are actually permitted to do To hear a key press while you're typing in another application, an app has to install a system-wide event tap. On macOS that means one of two permissions: - Input Monitoring, the app receives keyboard events, including which key, system-wide. - Accessibility: broader still; can also *send* events and drive other apps. There's no lighter option. macOS has no "tell me a key moved but not which one" API. So every app in this category, ours included, is asking for a permission that, misused, is indistinguishable from a keylogger. That's not a reason to avoid the category. It's a reason to pick carefully, and the criteria are concrete. ## Five questions worth asking before you grant it 1. Does it ask for Input Monitoring or Accessibility? Input Monitoring is the narrower of the two and the correct one for this job. An app that wants Accessibility for sound playback wants more than it needs. 2. Is it sandboxed and distributed through the App Store? Not a guarantee of anything, but it means a review process looked at the entitlements, and the app can't quietly reach outside its container. 3. Does it make network requests at all? This is the one you can check yourself. Little Snitch, LuLu (free) or a look at Activity Monitor's Network tab will tell you in a minute whether the app phones anywhere. A typing-sound app has no legitimate reason to. 4. Does it distinguish keys? Here's the tell. A sound app needs to know *that* a key moved, and at most which physical key so the sound can pan or vary. It does not need the character, the modifiers, or the sequence. Apps that describe their behaviour in terms of keycodes rather than text are describing the right thing. 5. Is it open source, or does someone credible vouch for it? For this category specifically, that's worth a lot. ## The options Klack (https://ziyarex.com/discover/klack), the one that made the category respectable on macOS. Excellent sample set, well-behaved, paid, and the default recommendation if you want the safest known quantity. Mechvibes, free, cross-platform, and the community sound packs are enormous. Rougher edges, but if you want a specific board's sound recorded by an enthusiast, this is where it lives. Clickk (https://ziyarex.com/store/clickk): ours. Every keystroke gets a real switch sample; it reads which physical key moved and nothing else; no characters, no logging, nothing leaves the machine. It has zero productivity value and we're not going to pretend otherwise. An actual mechanical keyboard, genuinely the better answer if you're at a desk most of the day. Software gives you the sound; it can't give you the travel, and the travel is half the point. ## Getting it to sound right instead of annoying Three settings separate "nice" from "please stop." Randomise the samples. A single sample repeated at typing speed sounds like a machine gun, because it *is* the same waveform sixty times a minute. Any decent app rotates through several recordings of the same switch. If yours doesn't, that's the reason it grates after ten minutes. Vary by key. Spacebar and Enter on a real board are stabilised keys, deeper, rattlier, distinctly different from an alpha key. Apps that model this sound convincing; apps that don't sound like a toy. Set the volume far lower than feels right. The sound is meant to sit under your typing, not over it. Start at the point where you can barely hear it and leave it there for a day. If you notice it, it's too loud. And the obvious social rule: it goes off on calls, in shared offices, and in libraries. Bind a mute to a shortcut you can hit without thinking, because you will need it mid-sentence. ## Why this is worth five minutes at all Typing is the single most repeated physical action in the day for most people reading this. Making it feel better has a return that's out of proportion to the effort, it's the same argument as a good chair or a matte screen, at a fraction of the cost. Just spend the extra minute on the permission question first. This is one of the few app categories where "it's only $5, why not" is the wrong instinct. --- ### Sherlocked: what happens when Apple ships your app https://ziyarex.com/journal/sherlocked-when-apple-ships-your-app — 2026-08-16 The word comes from 2002. Karelia Software shipped Watson, a small Mac app that put web services (flights, movies, dictionaries) into a native interface. It was excellent and it sold. A year later Apple shipped Sherlock 3, which did the same things, came free with the OS, and ended Watson. The verb stuck because the pattern kept repeating. Konfabulator's widgets became Dashboard. Growl's notifications became Notification Center. f.lux's warm evening screen became Night Shift. Duet and Astropad's iPad-as-second-display became Sidecar. 1Password's core job became a Passwords app in the menu bar. If you build small utilities on Apple's platforms, you are building inside a blast radius. That's worth thinking about clearly rather than anxiously, because the outcomes have been much less uniform than the folklore suggests. ## The three outcomes, and what separated them Killed outright. Watson. Konfabulator, effectively, after being sold on. Growl, which limped for years and shut down in 2020. What these shared: the app *was* the feature. One capability, no workflow around it, nothing the OS version couldn't reach in a version or two. When the free version arrived, there was no remaining argument. Badly wounded but alive. f.lux still exists, and is still better than Night Shift on several axes. Finer control, more platforms, more considered colour science. It also stopped being a thing most people install, because 90% of the value became a checkbox in Settings. This is the most common outcome and the most brutal, because it doesn't kill you. It caps you. Barely scratched. 1Password was supposedly finished when Apple shipped Passwords in 2024. It wasn't, because password management for a person is a small feature and password management for a team, across four operating systems, with sharing and audit and recovery, is a business. Astropad kept going by chasing the professional end (pressure, colour accuracy, hardware) that Sidecar never addressed. The line between those three isn't luck. It's this: > Apple ships the 80% case, for free, on one platform, and then mostly stops. Every survivor lived in one of the other three quadrants: the last 20%, the paid depth, the platforms Apple doesn't care about, or the iteration speed Apple can't match on an annual release cycle. ## What Apple actually does, in practice It's worth being precise, because "Apple will copy it" is usually wrong in the details. Apple ships the version that is defensible, universal and finished. It has to work for everyone, ship on a schedule, survive a keynote demo, and not require support. That forces a specific shape: fewer options, no edge cases, no per-user configuration, and, critically, very little change afterwards. Night Shift in 2026 is roughly Night Shift from 2017. That last part is the whole opportunity. The OS feature is a floor, and it's a floor that doesn't move. ## So what do you actually do about it Assume it, and price it in. If your app is one capability with no depth, you have a window, not a business. That's a legitimate thing to build, just know which one you're building and don't be surprised at the end of it. Own a workflow, not a feature. "Warm my screen" is a feature. "Manage my whole day's light" would have been a workflow. The distinction is whether removing your app leaves a gap someone has to fill with three other things. Go where the annual release cycle can't. Ship on Tuesday. Respond to a user in an hour. Support the weird monitor, the eight-year-old Mac, the non-Apple phone. None of that is available to a platform team. Be honest about competition, publicly. This one is underrated. If a free built-in does most of what you do, saying so, and saying exactly where it doesn't, earns more trust than the alternative, and the people who convert after reading it are the ones who actually needed the extra 20%. That's why our comparison pages (https://ziyarex.com/compare) name the competitors in the title and recommend against ourselves in places. ## Where this leaves what we ship Two of the things in our own catalogue sit squarely in the blast radius, and it would be strange not to say so. Oreo (https://ziyarex.com/store/oreo) puts live activities in the MacBook notch. Apple has already built exactly this concept on iPhone, called it the Dynamic Island, and shipped Live Activities as a public API. The Mac version of that story is not a question of *if*. Our position is: the notch is a UI surface, someone should be using yours, and if Apple eventually agrees, that will have been the correct opinion. Held early, by us, for $12. Insomniac (https://ziyarex.com/store/insomniac) is free, does one job, and is a thin layer over a pmset flag Apple could expose in Settings tomorrow. It exists because the thermal-safety part is the actual work, not the toggle. Neither of those is a hedge. They're both bets that the last 20%, the part Apple ships without, is where the users who care actually live. That bet has a twenty-year track record of being sometimes right, and it's the only one available to anyone building small software on someone else's platform. The alternative is to not build, and that's a worse plan. --- ### Setting up a Mac from scratch in 2026: the 20-minute utility layer https://ziyarex.com/journal/new-mac-setup-2026 — 2026-08-16 Every "new Mac setup" list is sixty apps long, and following one leaves you with a machine that's slower than the one you started with and a menu bar you'll be triaging in six months (https://ziyarex.com/journal/menu-bar-triage). This is the short version: the settings that are wrong out of the box, the six utilities that carry their weight, and the order to do them in. Twenty minutes, once. ## First: the settings that are actually wrong by default Do these before installing anything. Several are things you'd otherwise blame on the hardware. Key repeat. The default repeat rate is slow enough that holding an arrow key feels broken. defaults write NSGlobalDomain KeyRepeat -int 2 defaults write NSGlobalDomain InitialKeyRepeat -int 15 Log out and back in for these to take. If you're a developer and hold-to-repeat still doesn't work in some editors, that's press-and-hold accent picker: defaults write NSGlobalDomain ApplePressAndHoldEnabled -bool false Trackpad. System Settings → Trackpad: turn on Tap to Click, and push Tracking Speed up two notches past where it feels right, it'll feel correct within a day and slow forever afterwards if you don't. Screenshots, out of your Desktop. The default dumps every screenshot onto the Desktop, which is why everyone's Desktop looks like that. mkdir -p ~/Pictures/Screenshots defaults write com.apple.screencapture location ~/Pictures/Screenshots killall SystemUIServer Finder, made usable. Path bar, status bar, folders sorted first, and the sidebar showing your home folder. defaults write com.apple.finder ShowPathbar -bool true defaults write com.apple.finder ShowStatusBar -bool true defaults write com.apple.finder _FXSortFoldersFirst -bool true defaults write com.apple.finder FXDefaultSearchScope -string "SCcf" killall Finder That last one makes Finder search the current folder by default instead of the whole Mac, which is what you meant every time. The Dock's hide animation. If you auto-hide the Dock, the delay is the thing that makes it feel sluggish. defaults write com.apple.dock autohide-delay -float 0 defaults write com.apple.dock autohide-time-modifier -float 0.15 killall Dock Control Centre. System Settings → Control Centre, and move everything you don't read at a glance out of the menu bar. Doing this now saves the triage later. ## Then: the six utilities, in priority order 1. A launcher. The single highest-return install on a Mac. Raycast (https://ziyarex.com/discover/raycast) is the current default answer, free, fast, and it absorbs clipboard history, window management, snippets and a calculator, which means it can replace three of the things further down this list. Alfred is the veteran alternative and still excellent. Set it to ⌘-Space and move Spotlight to something else. Half the value of a launcher is muscle memory, and you won't build it on a second-choice shortcut. 2. Window management. macOS finally ships tiling, and for a lot of people it's now enough: drag to an edge, or hold Option and use the Window menu. If it isn't: Rectangle is free and does keyboard-driven halves and quarters, and that covers 95% of the need. 3. Clipboard history. You will not appreciate this until the first time you paste something from four copies ago. Raycast has it built in; Maccy is free and standalone if you'd rather keep it separate. 4. Screenshots. The built-in tool is genuinely good now (⌘⇧5, and ⌘⇧4 then Space for a window). Upgrade only if you annotate constantly, CleanShot X (https://ziyarex.com/discover/cleanshot-x) is the premium answer, Shottr (https://ziyarex.com/discover/shottr) is the fast, cheap, surprisingly deep one. 5. A menu bar manager. Not on day one, install it in month two when the bar has actually filled up. Ice (https://ziyarex.com/discover/ice) is free and is what we'd point most people at. 6. Backups, before you need them. Time Machine to any external drive takes four minutes to set up and is the only item on this page that can save you from a genuinely bad day. Do it before you customise anything else, not after. ## The order matters more than the list Do the defaults block first, because several of the utilities exist to paper over settings you can just fix. Do backups second, because the risk is highest when the machine is new and you're moving data. Do the launcher third, because it changes how you use everything installed after it. Everything else can wait until you actually feel the friction. The trap is installing utilities *in anticipation* of friction. That's how you get sixty apps and a slow Mac. ## What we'd add, being upfront that it's ours Four of the things on our own new-machine list are ours, and they're all small: - Slate (https://ziyarex.com/store/slate), the todo list rendered as the wallpaper, so the setup checklist you're working through right now is visible without opening anything. - Oreo (https://ziyarex.com/store/oreo): live activities and a file tray in the notch, which is otherwise the only part of a new MacBook doing literally nothing. - Insomniac (https://ziyarex.com/store/insomniac), free, for the first time you need the lid closed and the work to continue. - Clickk (https://ziyarex.com/store/clickk), because a new laptop keyboard sounds like a countertop. Install those last, after the settings, the backup and the launcher. If you only do the first section of this page and stop, the machine is already better than most. --- ### Pocket shut down. Where did everyone actually land? https://ziyarex.com/journal/pocket-shut-down-where-everyone-landed — 2026-08-16 Mozilla announced Pocket's shutdown in May 2025. The apps stopped working that July, exports stayed open until October, and then fifteen years of a category-defining product was a zip file in everyone's Downloads folder. It's worth doing the accounting now that the dust has settled, because the interesting finding isn't which app won. It's how many people didn't replace it at all. ## First, the thing nobody wants to say Pocket wasn't killed by a competitor. It was killed by the economics of the category. Read-later is expensive to run (you're fetching, parsing and storing the full text of the web on behalf of people who mostly don't come back) and it's very hard to charge for, because the core function feels like it should be a bookmark. Omnivore, the promising open-source-ish challenger, folded in late 2024 after its team was acquired. Pocket went in 2025. Two of the best-known names in the category died inside a year of each other, and it wasn't a coincidence. That should inform how you pick the next one. The question isn't just "which is best." It's "which of these has a business model that survives my next five years of saving." ## Where people went ### Instapaper, the safe harbour The oldest survivor, and the most direct like-for-like: clean parsing, good typography, highlights, an actual reading experience. It's independently run and has outlived several better-funded competitors, which at this point counts as the strongest possible endorsement. Take it if you want what Pocket was, with fewer surprises. ### Readwise Reader, the maximalist option Read-later merged with highlight management, RSS, newsletters, PDFs, YouTube transcripts and spaced-repetition review. Genuinely the most capable thing in the category, and priced accordingly. It's also the one most likely to become a second job. If your Pocket queue was already a source of guilt, adding four more input types to it is not the fix. ### Raindrop.io: bookmarks that grew up Strictly speaking a bookmark manager, which is why a lot of Pocket refugees landed here: nested collections, tags, good search, a generous free tier, and a clear paid plan behind it. Reading is the weaker half, it saves and organises links better than it renders articles. Take it if what you actually wanted was a library, not a queue. ### Wallabag and self-hosting, the "never again" crowd The reaction to being shut down twice is, reasonably, to stop depending on anyone. Wallabag is the mature open-source option and it works; it also means you now operate a small service, complete with a server, updates and a backup story. The honest version: this is the right answer for maybe one reader in twenty, and the other nineteen will have an unmaintained instance within a year. ### Browser reading lists and the Notes app, the quiet majority Safari's Reading List, Chrome's reading list, or just pasting URLs into Apple Notes. No parsing, no highlights, no sync guarantees beyond your browser vendor's whim, and no cost or setup. This is where far more people went than any vendor's migration blog post admits, and for light savers it's a completely defensible answer. ### Nowhere, the largest destination The pattern in every conversation we had about this: people exported their Pocket archive, looked at 2,400 saved articles, recognised that they'd read maybe two hundred of them, and never imported the file anywhere. That's not failure. That's a year-late audit finally happening. Which brings us to the actual lesson. ## What the shutdown revealed A read-later service is a queue with no cost of entry and no scheduled consumption. Saving is one tap; reading is twenty minutes you never book. Any system with that asymmetry grows without bound, and the growth is invisible until something forces you to look at the total, like the service closing. We wrote about the mechanics of that separately in the read-later graveyard (https://ziyarex.com/journal/the-read-later-graveyard), because it's the part that no choice of app fixes on its own. ## Migrating properly, if you're doing it now If that zip file is still sitting in Downloads: 1. Don't import all of it. Import the last 90 days. Everything older than that has already told you what it's worth. 2. Keep the export anyway. It's a small file and it's a personal archive of what you found interesting for a decade. Archive it somewhere with your other keepsakes, not in your new reading queue. 3. Check the export format before you commit to a destination. Pocket's export was HTML and CSV; most services take one or both, but the fidelity of tags and read-state varies a lot between importers. 4. Pick based on what you'll do daily, not on the feature matrix. The best read-later app is the one whose queue you'll look at tomorrow morning. ## And what we build, disclosed ueue (https://ziyarex.com/store/ueue) is ours: save any link from iPhone, Android, Mac or Chrome, and get to it. It exists because of the same shutdowns, the design goal was a queue you can actually clear, not a bigger library. It is younger and smaller than everything above, and if you want the safest possible bet you should take Instapaper. Prism (https://ziyarex.com/store/prism) is the Chrome-side version of the same idea, for people whose whole watch-later problem lives in a browser. We have an honest comparison page for the Pocket question specifically (https://ziyarex.com/compare/pocket-alternative), which recommends other people's apps in several places. Worth reading before you take our word for anything here. --- ### The read-later graveyard: why most saved links die https://ziyarex.com/journal/the-read-later-graveyard — 2026-08-16 Count your saved links. Then count how many you've read. Everyone who does this arrives at roughly the same ratio, and it's not close to half. The interesting question isn't why you're undisciplined. You're not: you read plenty. The question is why *this particular system* produces a graveyard when your inbox, your calendar and your actual reading habits don't. There are four mechanics, and they compound. ## 1. Saving is a completion ritual When you tap Save, something in your head files the item as handled. The tension of "I should read this" resolves. You get the small satisfaction of having *dealt with it*, and you get that satisfaction whether or not you ever read the thing. That's the core defect. The action that's supposed to create an obligation instead discharges one. A todo list where writing the item down made you feel like you'd done it would be obviously broken. This is that, and it's invisible because the reward is so small and so immediate. ## 2. The queue has no cost of entry Saving is one tap, free, instant, unlimited. Reading is twenty minutes you have to find. Any system where adding is nearly free and removing is expensive grows without bound. It's the same maths as a warehouse with a loading dock and no shipping door. Nothing about your character changes this; it's structural. An unbounded inbox with no scheduled processing time becomes a graveyard *by default*, and the only surprising thing is that we keep expecting otherwise. ## 3. A link's value decays much faster than you think You saved that article because of a *state* you were in: a project you were on, a decision you were making, an argument you'd just had. Two months later, the article is intact and the state is gone. The thing that made it interesting isn't in the link. This is why cleaning out an old queue feels so easy and so strange. You look at forty saved items and delete thirty-five without hesitation. You're not being ruthless. You're just no longer the person who saved them, and you can tell instantly. Practically: most links are worth reading within about a week of saving, or not at all. The half-life is short. ## 4. There is no consumption slot Everything that survives in your life has a time attached. Email has the gaps between meetings. Books have bedtime. Podcasts have the commute. Read-later has… whenever? It has no slot, so it competes with everything at once and loses to all of it. A queue with no scheduled time isn't a queue. It's a pile. ## The fixes that actually hold None of these are about willpower, because willpower is exactly what the four mechanics above exhaust. Cap the queue. Pick a number, twenty is a good one, and refuse to exceed it. To save the twenty-first thing, something has to go. This restores the cost of entry that the tap-to-save button removed, and it's remarkable how much better your saves get when the slot is scarce. Save with a reason, in three words. "For the pricing bit." "Because Ana asked." "Counterargument to X." Later, this is the only thing that tells you whether the state that made it valuable still exists. Untagged links are unreadable to your future self. Book the slot. Twenty minutes, same time, most days. The specific time matters far less than it being *a* time. Read-later without a reading time is a saving hobby. Delete first, read second. Start each session by binning everything you don't want to read *right now*. Not "eventually": now. This takes two minutes and does more for the queue than any amount of reading. Set an expiry. Anything untouched after thirty days goes automatically. If your tool can do this, turn it on; if it can't, do it manually once a month. Yes, you'll lose a few good things. You were never going to read them, and the sunk-cost preservation of a 400-item backlog costs you more than those few pieces were worth. ## What this means for the tool you pick Most read-later apps optimise for the wrong half. They compete on capture (share sheets, browser buttons, one-tap saving from anywhere) because capture is the easy part to build and the easy part to demo. The hard part, and the part that decides whether you get anything out of the system, is the return trip. Does the app show you a shortlist or an archive? Does it surface today's five, or all 412? Does it make deleting as fast as saving? That's the design brief we set ourselves with ueue (https://ziyarex.com/store/ueue): a queue you can actually clear, on whichever device you're holding: iPhone, Android, Mac, Chrome. Prism (https://ziyarex.com/store/prism) is the same idea confined to the browser, where most people's watch-later problem lives. But be clear about the order of operations. The tool is a distant second. Cap the queue, book the slot, delete first. Do those three with Apple Notes and you'll read more than you will with the best app in the category and none of them. Related: where everyone landed after Pocket shut down (https://ziyarex.com/journal/pocket-shut-down-where-everyone-landed), and our honest comparison of the alternatives (https://ziyarex.com/compare/pocket-alternative). --- ### How to sign a PDF without uploading it anywhere https://ziyarex.com/journal/sign-a-pdf-without-uploading-it — 2026-08-16 Think about which PDFs actually need a signature. A tenancy agreement. An offer letter. A loan form. A contract with a rate in it. A medical consent. Passport-number-bearing anything. Now think about what "free online PDF signer" means mechanically: you upload that document to a server owned by someone you've never heard of, funded by something you haven't checked, in a jurisdiction you don't know, with a retention policy you didn't read. The good news is that you almost never have to. Every major platform can sign a PDF locally, and has been able to for years. ## macOS: Preview, which you already have This is the best-kept-secret answer on the Mac. 1. Open the PDF in Preview. 2. Show the markup toolbar (the pen-tip icon), then click the signature icon. 3. Create Signature offers three routes: sign on the trackpad with your finger, hold a signature written on paper up to the camera, or sign on a connected iPhone or iPad. 4. Drag the resulting signature onto the page and resize it. The iPhone route gives by far the best-looking result, you're writing with a finger or Pencil on glass rather than dragging on a trackpad. Signatures are saved to your keychain and reappear in Preview, Mail and anywhere else with markup. You can also do this without opening Preview at all: select the file in Finder, press Space for Quick Look, and hit the markup button. ## iPhone and iPad: Files, or straight from Mail Open the PDF in Files or tap the attachment in Mail, then tap the markup icon and use the + button → Signature. Same signature store as the Mac if you're on the same Apple account. For a scanned document, the Notes app's built-in scanner produces a much cleaner PDF than a photo, Notes → new note → camera → Scan Documents. It deskews and thresholds properly. ## Windows, two local options Microsoft Edge opens PDFs and has a Draw tool. It's crude but it is genuinely local, and it's already installed. Adobe Acrobat Reader (the free one) has Fill & Sign, which is purpose-built for this and produces a much better result. Ignore the prompts to upload to Adobe's cloud, the local flow works without an account. ## Linux: Xournal++ or Okular Xournal++ is the one to use: import the PDF, draw or place a signature image, export back to PDF. Okular also does freehand annotation and can save annotations into the file. ## The browser route, done properly There is a legitimate version of an online tool: one where the PDF never leaves your machine because the processing happens in the page itself, in JavaScript, with no upload. The distinction is not marketing language, it's observable. Open your browser's developer tools, go to the Network tab, and sign a document. If you see a request carrying your file, it was uploaded. If the tab stays quiet, it wasn't. Any tool making the claim should survive that test in ten seconds. That's the bar we built our own PDF editor (https://ziyarex.com/tools/pdf-editor) to meet: it runs entirely in the browser, so you can draw a signature, type one, or drop in an image of one, and also rewrite text, white out what shouldn't be there, fill in form fields and reorder pages, with nothing sent anywhere. No account, and it works offline once the page has loaded. ## The part that actually matters legally Almost everything above produces a drawn or typed signature image placed on a page. For the overwhelming majority of everyday agreements (rentals, freelance contracts, school forms, consent) that's what's being asked for and it's fine. It is *not* the same thing as a digital signature, which is a cryptographic operation binding a certificate to the document so that any later modification is detectable. That's what standards like PAdES describe, and what enterprise e-signature platforms provide alongside an audit trail of who signed what, when, and from where. The practical rule: - Personal, commercial, everyday → a drawn signature is what's expected. Sign it locally and send it back. - Someone specifically requires a certified or qualified electronic signature, or you need a defensible audit trail → you need a certificate-based signature, which means either a certificate you hold or a platform that provides one. Local Preview markup will not satisfy that requirement, and nobody should pretend otherwise. If you're unsure which one you're being asked for, the request usually says so. "Please sign and return" means the first. "Please complete via our e-signature portal" means the second. ## Two small habits worth having Flatten before sending. An annotation layer can sometimes be moved or removed by the recipient's viewer. Exporting or printing to PDF afterwards bakes it in. In Preview: File → Export as PDF. Don't email a signature image around as a file. A clean PNG of your signature on a transparent background is a small, reusable asset for anyone who receives it. Keep it in your signature store, place it in documents, and don't attach it on its own. More free tools that run in your browser and upload nothing: ziyarex.com/tools (https://ziyarex.com/tools). --- ### Every app icon size for iOS, macOS, Android and Chrome, one cheat sheet https://ziyarex.com/journal/app-icon-sizes-cheat-sheet — 2026-08-16 Every launch, the same twenty minutes: which sizes does this platform want, in which folder, under which filename, and why did the build just fail. Here's the whole thing in one place. The numbers below are the ones we actually ship across our apps on four platforms, they're what our own icon generator (https://ziyarex.com/tools/icons) emits, not a list copied from a blog post. ## Start with one master Design at 1024 × 1024, square, no transparency, no rounded corners. Everything else is derived from it. Two rules that catch people: - Don't round the corners yourself. iOS, macOS and Android all apply their own mask. Pre-rounded artwork gets a double-rounded, visibly wrong icon. - Don't ship alpha in the store icon. Apple rejects the 1024 App Store icon if it has an alpha channel. Flatten it onto a solid background. Design it so it survives at 16 px. Most icons that fail do so because they contain a wordmark or a thin line that dissolves below about 48. ## iOS / iPadOS Modern Xcode accepts a single 1024 × 1024 image and generates the rest, which is what you should do for new projects. Since the 2025 design refresh, Apple's Icon Composer takes layered artwork and produces the light, dark and tinted appearances from one source. If you're targeting the current OS, that's the path. You still need the full set when you're maintaining an older asset catalogue, filling one by hand, or supporting a framework that expects individual files: | Purpose | Sizes (px) | |---|---| | iPhone notification | 40, 60 | | iPhone settings | 58, 87 | | iPhone spotlight | 80, 120 | | iPhone app | 120, 180 | | iPad notification | 20, 40 | | iPad settings | 29, 58 | | iPad spotlight | 40, 80 | | iPad app | 76, 152 | | iPad Pro app | 167 | | App Store | 1024 | The App Store icon is the one that gets rejected. Opaque, 1024, no rounding. ## macOS macOS wants an .icns built from an .iconset folder, and the filenames are load-bearing, iconutil will refuse the folder if they're wrong. icon_16x16.png 16 icon_16x16@2x.png 32 icon_32x32.png 32 icon_32x32@2x.png 64 icon_128x128.png 128 icon_128x128@2x.png 256 icon_256x256.png 256 icon_256x256@2x.png 512 icon_512x512.png 512 icon_512x512@2x.png 1024 Then: iconutil -c icns MyApp.iconset Note the deliberate duplication: 32, 256 and 512 each appear twice under different names. That's not a mistake in the list, the same pixel size serves two point sizes. Mac icons traditionally sit inset within the canvas rather than filling it edge to edge, which is why a straight iOS export often looks oversized in the Dock. ## watchOS Round mask, and the sizes are their own set: 48, 55, 58, 80, 87, 88, 100, 172, 196, 216, plus 1024 for the store. Since the icon is circular, anything important needs to be well inside the inscribed circle. ## Android Two separate problems: the launcher icon, and the store listing. Launcher: adaptive icons. Android composites a foreground and a background layer and masks the result to whatever shape the launcher wants. Both layers are 108 dp; only the centre 72 dp is guaranteed visible, and the outer ring gets cropped or used for parallax. | Density | Legacy launcher (px) | Adaptive layer (px) | |---|---|---| | mdpi | 48 | 108 | | hdpi | 72 | 162 | | xhdpi | 96 | 216 | | xxhdpi | 144 | 324 | | xxxhdpi | 192 | 432 | The single most common Android icon mistake is designing the foreground to fill the 108 dp square. It won't, a circular launcher mask will eat the corners, and your logo will be cropped on a lot of devices. Keep the mark inside the middle two-thirds. Play Store listing: a 512 × 512 32-bit PNG with alpha. Separately, the feature graphic is 1024 × 500 and must have no transparency, that one is a real rejection reason. ## Chrome extensions Small list, declared in manifest.json: 16 toolbar / favicon 32 Windows, some contexts 48 extensions management page 128 installation and the Chrome Web Store The 128 is the one people see. The 16 is the one that has to survive being 16 pixels. ## Web - favicon.ico containing 16 and 32 - 180 × 180 apple-touch-icon.png - 192 and 512 PNGs for the web app manifest - an SVG if you have one, for the browsers that take it ## The rules that actually cause failures 1. Alpha in the iOS App Store icon → rejected at upload. 2. Transparency in the Play feature graphic → rejected in review. 3. Pre-rounded corners → accepted, and looks wrong forever. 4. Android foreground artwork outside the 72 dp safe zone → cropped on round-mask launchers. 5. Wrong .iconset filenames → iconutil fails with an unhelpful error. 6. A detailed icon → fine at 1024, mush at 16. ## Doing it in one step Our app icon generator (https://ziyarex.com/tools/icons) takes a single image and writes every file above, in the right folder structure, with Contents.json for Xcode and the mipmap directories and adaptive-icon XML for Android. It runs in your browser, the image isn't uploaded anywhere, and hands back a zip. The alternative is doing it by hand once per launch, forever, which is exactly why the tool exists. --- ### App Store screenshot sizes that still get accepted in 2026 https://ziyarex.com/journal/app-store-screenshot-sizes — 2026-08-16 "The dimensions of one or more screenshots are wrong." That's the whole error. It doesn't say which screenshot, or which dimension, or what it wanted instead. If you've shipped to the App Store you've seen it, usually at the worst possible moment. Here are the numbers. These are cross-checked against what we actually have live (ueue's iPhone screenshots are 1242 × 2688, Slate's Mac screenshots are 2560 × 1600) and they're the same set our screenshot resizer (https://ziyarex.com/tools/screenshots) targets. ## App Store: iPhone | Display | Pixels | Status | |---|---|---| | 6.9″ | 1290 × 2796 | required | | 6.9″ (alt) | 1320 × 2868 | also accepted | | 6.5″ | 1242 × 2688 | still accepted | | 6.1″ | 1179 × 2556 | accepted | | 5.5″ | 1242 × 2208 | legacy | The important simplification: Apple now derives the smaller sizes from your largest ones. Supply a complete 6.9″ set and you're done: you don't have to produce four separate size families any more, which is the single biggest time saving available in this whole process. Both portrait and landscape are fine; just don't mix orientations within one set. ## App Store: iPad | Display | Pixels | Status | |---|---|---| | 13″ | 2064 × 2752 | required for iPad apps | | 12.9″ | 2048 × 2732 | accepted | | 11″ | 1668 × 2388 | accepted | If your app ships on iPad at all, you need a real iPad set. Uploading upscaled iPhone shots is allowed by the validator and immediately obvious to anyone reading the listing. ## App Store: Mac | Pixels | Note | |---|---| | 2560 × 1600 | the one we ship | | 2880 × 1800 | accepted | | 1440 × 900 | accepted | | 1280 × 800 | the size in-app-purchase review images want | Mac screenshots are 16:10 and must not include the desktop background outside the window unless you want it there, Apple accepts either, but a full-bleed 2560 × 1600 canvas with the window composited on a designed background looks dramatically better than a raw window grab. ## App Store: Watch and TV | Device | Pixels | |---|---| | Apple Watch 46 mm | 416 × 496 | | Apple Watch 45 mm | 396 × 484 | | Apple TV | 1920 × 1080 | ## Google Play Play is far more forgiving, it takes a ratio range instead of fixed pixels, but it has its own hard requirements. | Asset | Pixels | Rules | |---|---|---| | Phone | 1080 × 1920 | 2 to 8 required | | 7″ tablet | 1200 × 1920 | required if you claim tablet support | | 10″ tablet | 1600 × 2560 | required if you claim tablet support | | Feature graphic | 1024 × 500 | required, no transparency | Each side must be between 320 and 3840 px, and the aspect ratio can't exceed 16:9 in either direction. The feature graphic's no-alpha rule is a genuine rejection reason and catches people who export a PNG straight out of a design tool with a transparent artboard. ## The workflow that stops this being annoying Design once, at the largest size. Build your 6.9″ iPhone frames (1290 × 2796) and your 13″ iPad frames (2064 × 2752). Everything else is a resize. Resize, don't re-export. Going back to the design file per size is how a screenshot set takes three hours. A resizer that fits your source into each canvas (padding rather than cropping, so nothing important is lost) turns it into one step. Check the first two. On both stores, the first two screenshots are what appear in search results, and a large share of people never swipe past them. Whatever your best argument is, it goes in slot one. Put words on them. A raw UI screenshot assumes the reader already understands your app. A screenshot with a five-word caption above the frame explains it to someone who's never heard of you, which is everyone in a search result. Keep the sources. You will redo these at the next OS design refresh. A layered file beats regenerating from scratch. ## The tool Our screenshot resizer (https://ziyarex.com/tools/screenshots) has every size on this page built in, including the Play feature graphic with its alpha stripped automatically. Drop in your source images, pick the targets, get a zip. It runs in the browser and nothing is uploaded. Related: every app icon size (https://ziyarex.com/journal/app-icon-sizes-cheat-sheet), and what screenshots have to do now that discovery has moved (https://ziyarex.com/journal/aso-when-nobody-browses-the-store). --- ### QR codes that don't expire: static vs dynamic, and who owns the redirect https://ziyarex.com/journal/qr-codes-that-dont-expire — 2026-08-16 A QR code on a screen is disposable. A QR code on a menu, a poster, a business card, a product label or an equipment tag is infrastructure. You're committing to a link staying alive for as long as the printed thing exists. Which makes the static-versus-dynamic choice the only decision that really matters, and it's the one most generators are least honest about. ## What a QR code physically contains A string. That's it. There's no server, no lookup, no account, the black squares *are* the data, encoded with error correction. Nothing about the code itself can expire. So when a QR code "expires," something else expired: the URL it contains, or the redirect service sitting behind that URL. ## Static: the code holds your actual URL Scan it and the phone goes straight to yoursite.com/menu. Good: it works forever, with no account, no subscription and no third party. Nobody can turn it off. Nobody can retarget it. There's no company that has to still exist in 2031. Bad: the destination is baked in. Change the URL and every printed copy is dead. And you get no scan analytics, because nothing is in the middle to count. ## Dynamic: the code holds a vendor's short link Scan it and the phone goes to qr-vendor.io/a9f, which looks up a destination and forwards. Good: you can change where it points after printing, and you get scan counts, locations and times. Bad, and stated plainly: you are now renting your printed material. Three things follow from that. 1. It can be switched off. Free tiers routinely become paid tiers. The common pattern is a generous free trial, then an email saying your codes stop resolving in 14 days. Anyone who printed 5,000 flyers now has a pricing problem, not a marketing problem. 2. The company has to survive. Your poster's lifespan is now capped by a startup's runway. 3. Whoever controls the account controls the destination. That's fine while it's you. It's less fine when it's an ex-agency, a former employee, or an acquirer. None of this makes dynamic codes wrong. It makes them a *dependency*, and dependencies should be chosen deliberately. ## The third option most people miss Own the redirect yourself. Put a short path on a domain you control, yoursite.com/r/menu, and have your own server forward it to wherever the destination currently is. Encode that short URL in a static code. You get: - Editability, because you can change the redirect target whenever you like - Analytics, because the request passes through your own logs - Permanence, because the only thing that has to survive is your domain This is the correct answer for anything printed at volume, and it costs a redirect rule. It's also exactly how our QR generator (https://ziyarex.com/tools/qr) handles dynamic codes, they resolve through this site's own /r/ endpoint, with deliberately coarse logging: a country and a device class, no IP stored, no cookie set, nothing that identifies a person. Static codes from the same tool contain your URL directly and involve us not at all, which is what you want for most things. ## Choosing, in one line each - Screen, email, slide, temporary sign → static. It costs nothing and there's nothing to maintain. - Print run you can reprint cheaply (a table tent, an A4 sign) → static. - Print run you cannot reprint (packaging, engraved plaques, 10,000 flyers, equipment labels) → dynamic, through a redirect *you own*. - You genuinely need per-campaign scan analytics → dynamic, and read the pricing page before you print. ## Five things that make a printed code actually scan Getting the strategy right doesn't help if the code doesn't read. Keep the quiet zone. Four modules of clear space on every side. Designers crop this constantly and it's the most common reason a code fails on a busy layout. Size it against the scan distance. The working rule of thumb is roughly 1:10, a code read from 1 metre away wants to be about 10 cm across. Under about 2 cm, phone cameras start to struggle regardless of distance. Shorten the URL before you encode it. More characters means more modules means a denser, harder-to-scan code. yoursite.com/r/menu produces a visibly cleaner code than a 90-character URL with UTM parameters. Put the tracking in the redirect, not in the printed code. Raise error correction if you're adding a logo. Level H tolerates about 30% damage, which is what makes a centre logo survivable. If you're not covering anything, a lower level keeps the code sparser and easier to read. Don't invert it. Scanners expect dark modules on a light background. Light-on-dark works on some phones and fails on others, and you won't find out until it's printed. Test the final artwork (the exported file, at final size) on at least an iPhone and an Android phone before it goes to print. That two-minute check has saved more reprints than any other item on this list. --- ### ASO when nobody browses the store any more https://ziyarex.com/journal/aso-when-nobody-browses-the-store — 2026-08-16 The original ASO playbook assumed a specific human being: someone who opens the App Store with nothing particular in mind, browses a category, scrolls a chart, and picks something. Everything downstream (keyword stuffing in the title, chasing category rank, obsessing over the icon's contrast in a grid of twelve) followed from that person existing. That person is now rare. Discovery moved, and it moved in four directions at once. ## Where it went Search with a name. A large share of store searches are now for an app the person already knows about. The store isn't the discovery surface; it's the checkout. They heard the name somewhere else and came to install it. Answers instead of lists. "What's the best app for putting my todo list on my Mac wallpaper" used to return a store search page. Increasingly it returns a paragraph naming three apps, assembled from web pages, forum threads and reviews, not from your listing metadata. You are being summarised before you're ever visited. Video and social. A thirty-second clip of the app doing the thing, on someone else's account, drives more installs than any keyword change you will make this quarter. The web, into the store. Someone searches a problem, lands on an article or a comparison page, and clicks through to your listing with intent already formed. In three of those four, the person arrives at your listing already convinced. The listing's job changed from *persuading a browser* to *confirming a decision*, and everything about how you write it should follow that. ## What still matters, in order ### 1. Being nameable If you can't be referred to in one sentence, you can't be recommended, not by a person, and not by a machine summarising a forum thread. "The todo app whose list is your wallpaper" is nameable. "A powerful productivity suite" is not. This is now upstream of every other item on this page. Everything else is downstream of somebody being able to say what you are. ### 2. Existing outside the store An app that exists only as a store listing has almost no surface for anything to cite. A real product page, an honest comparison against the alternatives, a changelog, a support page that answers actual questions, these are what get read, quoted and summarised. That's not a growth hack. It's the observation that the systems now doing discovery read the web, and a store listing is a very thin, very late part of the web. ### 3. The fields that are still hard limits Both stores still index text, and the constraints are unforgiving: | Field | App Store | Google Play | |---|---|---| | Title | 30 chars | 30 chars | | Subtitle / short description | 30 chars | 80 chars | | Description | 4,000 chars | 4,000 chars | Apple has a separate 100-character keyword field that users never see; Play has no keyword field and indexes your description instead. So the same text does different jobs on each store: on Play, the description is a ranking input; on Apple, it's read by humans who scrolled. Two rules that survive from the old playbook: - Don't repeat words between title and subtitle on Apple, you're wasting characters that could carry a different term. - Front-load Play's 80-character short description. It's the first thing shown and often the only thing read. ### 4. Screenshots, which are the actual pitch The description is mostly unread. The first two screenshots are seen by everyone, in search results, before any tap. If your app is not self-evident from those two frames with their captions, the listing is not doing its job, and no keyword work will compensate. We wrote the exact dimensions up separately (https://ziyarex.com/journal/app-store-screenshot-sizes), because getting them wrong is the other half of this problem. ### 5. Ratings, and what people say in them Review *text* is the raw material for a great deal of what now gets summarised about your app. A one-star review that names a specific bug is a durable liability that will be quoted for years. Reply to them. Fix them. Ask happy users at a moment when they're actually happy: after a task succeeds, not on second launch. ## What to stop doing - Chasing chart position. Charts are downstream of installs, and installs are now driven from off-store. Ranking is a scoreboard, not a lever. - Keyword stuffing the title. You get 30 characters. Spend them on being nameable. - A/B testing the icon before the app is nameable. You're optimising a conversion rate on traffic you don't have. - Writing the description for the algorithm. On Apple it isn't indexed. On Play it is, but a description written for machines reads badly to the humans who reach the bottom of the page, and those are the ones about to install. ## What we do about our own listings We built an ASO audit tool (https://ziyarex.com/tools/aso-audit): paste a store URL and it scores the listing (icon, title, subtitle, screenshots and copy) against the limits above and returns the fixes ranked by how much they're likely to matter. It exists because we ran the same checks by hand across nine listings, found the same four mistakes repeatedly, and got tired of doing it manually. It's free, it runs in the browser, and it will tell you unflattering things about your own app, which is the entire point of an audit. --- ### Pricing a $12 Mac app: one-time vs subscription, with real numbers https://ziyarex.com/journal/pricing-a-12-dollar-mac-app — 2026-08-16 Two of our apps are paid: Oreo (https://ziyarex.com/store/oreo) at $12 once, and Slate (https://ziyarex.com/store/slate) free with a $19.99 one-time unlock. Both of those are decisions we can defend, and neither was obvious. One thing up front, because the internet is full of pricing posts that quietly invent their evidence: the numbers modelled below are a model. The assumptions are stated so you can substitute your own. The only figures here that are literally ours are the two prices in the paragraph above and the reasoning behind them. ## The maths, stripped down One-time. Revenue in a month = new buyers × price. That's the whole equation. Your existing users contribute nothing this month. If acquisition is flat, revenue is flat. Forever. Subscription. Revenue in a month = (last month's base × retention) + new subscribers, × price. Every month compounds on the last, which is why the curve bends upward, and why churn is the only number that really matters. Take a concrete comparison: $12 once against $2/month, with 300 new users a month. | | one-time $12 | subscription $2/mo | |---|---|---| | Month 1 | $3,600 | $600 | | Month 6 | $3,600 | ~$3,000 | | Month 12 | $3,600 | ~$5,300 | | Month 24 | $3,600 | ~$8,600 | | 24-month total | $86,400 | ~$137,000 | Assumptions: flat 300 new users a month, 5% monthly churn on the subscription, no price changes. The subscription wins in the long run, decisively. Every "should I subscribe" analysis reaches this conclusion, and it's correct arithmetic. It's also incomplete in three ways that matter more than the arithmetic does. ## The three things the table leaves out ### 1. Churn is not a parameter you get to choose That model used 5% monthly churn. At 5%, half your base is gone in about 14 months. Push it to 8%, entirely normal for a cheap consumer utility that people forget they're paying for, and the curves look very different: the subscription's base plateaus early, and the compounding advantage mostly disappears. The apps where subscription genuinely runs away are the ones with structurally low churn, and those are almost always apps holding your data or embedded in daily work. A notch widget is not that. Being honest about which one you've built is the single most useful thing in this whole piece. ### 2. Consumer utility buyers resist subscriptions specifically Not as an abstract preference, as a purchase decision. A $12 one-time purchase and $2/month have very different conversion rates, even though the subscription is cheaper for the first five months. The one-time price is a bounded decision; the subscription is an open-ended commitment plus a small ongoing chore. So the honest comparison isn't "$12 once vs $2/month at equal volume." It's "$12 once at your conversion rate vs $2/month at a lower one," and the gap between those rates is a number you can only get by testing. ### 3. Support costs are permanent either way A one-time buyer from 2023 will still email you in 2027 about an OS update that broke something. You've booked their revenue once; their cost recurs. Nobody models this and everybody experiences it. That asymmetry is the strongest genuine argument for subscriptions in software with an ongoing service component, and it's a much better argument than "recurring revenue is nicer." ## The rule that actually decides it > Does your app cost you money every month that a user keeps using it? If yes (servers, sync, storage, API calls, moderation, content) you need recurring revenue, or the maths eventually eats you. A one-time price against a recurring cost is a slow-motion insolvency, and every developer who has learned this learned it the expensive way. If no (it runs entirely on the user's machine, and your marginal cost per existing user is approximately zero) a one-time price is defensible, honest, and easier to sell. Oreo runs entirely on your Mac. There's no account, no server, nothing that costs us anything when you keep using it. Charging monthly for that would be charging rent on a thing we already delivered. $12, once. ## The store's cut, which changes the numbers more than people expect Apple takes 30%, or 15% for developers under $1M in annual proceeds via the Small Business Program. Almost every indie qualifies. Applying for it is genuinely the highest-return hour available in this entire discussion. On $12 that's the difference between $8.40 and $10.20 per sale, a 21% swing in what actually reaches you, for a form. Two further deductions people forget when modelling: refunds (Apple grants them, at their discretion, and you find out afterwards), and the fact that displayed prices in most regions include VAT that never belonged to you. ## Paid upgrades, and the workaround everyone uses The obvious answer to "one-time revenue is flat" is charging for major versions. The App Store has never supported upgrade pricing as a first-class feature, so everyone improvises: - Ship version 2 as a new app. Clean, and you lose your reviews, your ranking, and a chunk of your existing users. - Sell the unlock as an in-app purchase. This is the common path: the app is free, the paid capability is a non-consumable unlock. It gives you a free tier, keeps one listing and one review history, and lets you introduce a *second* unlock later without a migration. That's exactly what Slate does, free app, one-time pro unlock. It's also why the free tier is real rather than a crippled demo: the free version has to be worth using on its own, or the unlock has nothing to build on. ## What we'd tell someone pricing their first Mac app 1. Start with the rule. Ongoing cost per user → subscription. No ongoing cost → one-time. 2. Price higher than feels comfortable. $12 is not expensive to someone who wants the thing. The developers who regret their pricing almost universally regret going too low, and raising a price later is far harder than launching at it. 3. Take the 15% programme on day one. 4. Give it a free tier if you can make one that's genuinely useful. It converts better than a time-limited trial, and it produces users who talk about your app before they've paid. 5. Don't do lifetime deals on a subscription product. You're selling infinite service for a finite payment, and the maths never recovers. And if you're on the fence between $9 and $12: it's $12. Nobody has ever declined to buy a good utility over three dollars. --- ### Make your own apps sell each other: the cross-promo strip https://ziyarex.com/journal/make-your-apps-sell-each-other — 2026-08-16 If you ship more than one product, you have a silo problem, and it's almost certainly worse than you think. Ours looked like this: a whole catalogue of apps, most with their own subdomain, each with its own visitors. Someone lands on the Slate site, likes it, installs it, leaves. They will never learn that the same people make a notch app, a link queue and a Chrome extension. Every product was starting distribution from zero, every single time, while sitting on traffic that had already decided it liked our work. The fix is a cross-promo strip: a small, consistent band on every one of your properties that shows the rest of the catalogue. It is the cheapest distribution channel you will ever own, and it takes an afternoon. ## Why it works better than it should The visitor has already passed the hard filter. They found you, read a page, and formed a positive opinion about your taste. That's the expensive part of marketing, and you've already paid for it. Showing them three more things you've made costs nothing and converts unusually well, because it's not an ad, it's an answer to a question they've just started asking, which is "who made this?" ## The design rules Bottom of the page, not the top. The strip must never compete with the product the visitor came for. Above the fold it's an interruption; at the bottom it's a reward for someone who read to the end. Show three or four, not nine. A wall of nine icons reads as a portfolio and gets skipped. Three reads as a recommendation. Rotate deterministically (by page, by product family, by whatever's most relevant to where the visitor is) rather than randomly, so it doesn't flicker between page loads. Exclude the current product. Obvious, and the single most common bug in a strip like this. Say what each thing is. An icon and a name means nothing to someone who has never heard of it. Eight words of what it does converts several times better than a logo grid. Match the host site's chrome, not your own brand. The strip should feel like a footer that belongs to the page it's on, not an injected banner. If it looks like an ad network, it gets tuned out like one. One link out per item, no dark patterns. No interstitials, no "you may also like" modals, no exit-intent popups. You're not trying to trap this visitor; you're trying to be remembered. ## The technical shape Two decisions matter, and they're both about avoiding future maintenance. One manifest is the source of truth. Every product (name, one-liner, icon, platforms, links, status) lives in a single file. The strip reads from it, and so does everything else: your store grid, your homepage, your OG images, your sitemap, your API. Adding a product becomes a one-file edit rather than a nine-site deploy. Ours is a single products.ts. If you take one thing from this piece, take this one, it's the difference between a strip you maintain and a strip that quietly goes stale and starts advertising an app you sunset last year. Ship it in two builds. This is the part people skip and then regret. Your sites are almost certainly not all the same stack: some are React, some are a static HTML file someone wrote in 2022, one is a landing page in a framework you no longer use. So build the strip twice from the same manifest: 1. A component for the modern sites, imported directly. 2. A standalone script embed, one