10 Reasons Not to Buy the iPhone Duo Yet

The iPhone Duo is tempting. Buying it immediately is optional. A folding iPhone could change how we read, work, and take photos on the move. But a compelling launch presentation is only the beginning of a purchasing decision.

As of October 2, 2026, Apple says preorders begin October 16, with availability starting October 23 in the first launch markets. This is an opinion piece about reasons to wait, based on announced information—not a hands-on review or a claim that the device has proven faults. Source: Apple’s announcement.

iPhone Duo in Apple's announced finishes
Apple’s first folding iPhone deserves attention—and a considered buying decision. Image: Apple, via Apple Newsroom.

1. The price deserves more than an impulse decision

Apple’s announced starting price is $1,999 in the US; local prices and taxes differ. At that level, take time to calculate what the upgrade actually buys you. A larger screen is appealing, but it needs to earn its place in your daily routine. Source: Apple.

Write down three tasks your current phone handles poorly. If folding the display does not meaningfully improve them, the excitement may be doing more work than the product.

2. First-generation ownership comes with unanswered questions

This is Apple’s first foldable iPhone. That alone does not make it unreliable. It does mean years of everyday ownership evidence are unavailable for this particular design. Source: Apple.

If you need a phone you can forget about, let early owners establish how it fits into ordinary life. Waiting buys information without requiring you to fund the experiment.

3. You should handle it before committing

The specification sheet lists 254 grams and a folded thickness of 11.3 mm. Numbers cannot tell you how it feels in your pocket or whether opening it one-handed is comfortable for you. Source: technical specifications.

Try typing, taking a photo, reading while standing, and putting it away. Repeat with a case. A short practical test can reveal more about suitability than another promotional video.

iPhone Duo held folded and unfolded
The folded and unfolded experience should both suit your hands and habits. Image: Apple, via Apple Newsroom.

4. Your essential apps need a practical test

Apple’s developer resources include guidance for supporting the new device. That is a reminder to assess your own apps, rather than assume every workflow will benefit equally. Source: Apple Developer.

Check your banking app, password manager, work tools, and reading software. Look for comfortable layouts and continuity when switching displays. A beautiful demo of one app does not answer questions about the five you use every day.

5. Battery figures are not your battery life

Apple advertises up to 31 hours of video playback on the inner display and 44 on the outer display. Those are specified test scenarios, not a promise about your mixed day of navigation, camera use, calls, and multitasking. Source: Apple’s product page.

Wait for testing that resembles your habits. If you expect to spend most of the day on the large screen, prioritize results for that pattern of use.

6. Camera buyers should compare results, not screen sizes

The rear system has Main and Ultra Wide cameras, with optical-quality 2x zoom derived from the Main camera. It does not list a separate long telephoto camera. Source: technical specifications.

If concerts, wildlife, or distant subjects matter to you, compare actual photographs at the distances you shoot. A bigger viewfinder is useful, but it cannot settle which camera system best matches your needs.

7. Your carrier and travel setup may need preparation

Apple says iPhone Duo uses eSIM worldwide. Before switching, confirm your carrier can activate it and check how you will obtain service in the places you travel. Source: Apple’s eSIM FAQ.

For someone accustomed to swapping physical SIM cards, this is a workflow change worth resolving before buying, especially if the phone must be ready for an upcoming trip.

8. Future features should stay out of today’s justification

Apple’s announcement places USB-C Apple Pencil support later in the year. If handwritten notes or sketching are the main reason you want Duo, wait until the feature is available and you can test it. Source: Apple.

The same principle applies to any feature whose availability depends on language, region, or a later update: make the decision using what you can actually use when you receive the phone.

Slack running on the iPhone Duo inner display
A larger workspace is valuable when your real workflows make use of it. Image: Apple, via Apple Newsroom.

9. The ownership budget goes beyond the phone

Before ordering, check local prices for the case you want, accidental-damage coverage, and out-of-warranty repairs. Include any accessories you genuinely need.

This is not a prediction that Duo will break. It is a way to avoid discovering the cost of your preferred setup after you have committed most of your budget to the handset.

10. Your current phone might still be the better purchase: keep it

Ask what would change tomorrow if you bought Duo. Would you finish work faster, read more comfortably, or replace another device? Or would your routine remain largely unchanged?

If your current phone is still supported and meets your needs, keeping it gives you time to evaluate reviews, app updates, and your own priorities. There is no reward for upgrading before you have a reason.

When would I reconsider?

After trying one in person, checking my essential apps, reviewing independent battery and camera tests, and pricing the complete setup. If those checks show a clear everyday benefit, the Duo becomes an easier purchase to justify.

The idea is exciting. The sensible buying date is the day you have enough evidence that it is right for you.

Written October 2, 2026. Specifications, prices, and feature availability can change. Images are official Apple press images; Apple does not endorse this article.

Create Light, Dark, and Tinted iOS App Icons with Codex for macOS — No Copy and Paste

Light, Dark, and Tinted iOS app icons spray-painted on a graffiti wall

iOS and iPadOS can display an app icon in three appearances: Light, Dark, and Tinted. The tedious approach is to create three files manually, drag each one into Xcode, and hope the asset catalog metadata stays correct. A better workflow is to let Codex for macOS generate the variants, write them directly into Assets.xcassets/AppIcon.appiconset, update Contents.json, and verify the result.

This guide shows a repository-first workflow: no Finder-to-Xcode dragging and no repetitive copy and paste. Codex works on the project files in place, so every change appears in Xcode automatically.

What Apple expects

Apple’s current guidance describes Light, Dark, and Tinted app-icon appearances for iOS and iPadOS. For the asset-catalog route, the Tinted artwork should be grayscale, while the Dark version can use transparency so the system background can show through. Xcode can also generate a treatment automatically when you provide only the primary icon, but custom variants give you control over contrast, hierarchy, and brand character. See Apple’s guides to configuring app icons in an asset catalog and the App Icons Human Interface Guidelines.

Before you ask Codex to edit the catalog

  • Open the folder containing your Xcode project in Codex for macOS.
  • Make sure the project builds before changing artwork.
  • Commit your current work or create a Git checkpoint.
  • Locate Assets.xcassets/AppIcon.appiconset.
  • Keep the master icon or design reference in the repository so Codex can use it consistently.

OpenAI’s official Codex use cases include building and debugging iOS projects. The same local-project workflow is ideal for asset-catalog maintenance because Codex can inspect the existing structure, edit files, and report a diff for review.

The prompt: generate and install all three icons

Start with a prompt that gives Codex clear authority, constraints, filenames, and validation requirements:

Inspect this Xcode project and find the active iOS app icon set.

Use the existing master icon as the visual reference. Create three coordinated 1024 Ă— 1024 PNG variants:
- AppIcon-Light.png: the standard full-color icon for Light appearance.
- AppIcon-Dark.png: a dark-appearance version with strong contrast and a transparent background where appropriate.
- AppIcon-Tinted.png: a clean grayscale/monochrome version designed for the system tint treatment.

Write the files directly into Assets.xcassets/AppIcon.appiconset. Update Contents.json so the variants map to the default, dark, and tinted luminosity appearances. Do not rename the asset set or change unrelated assets.

Before editing, back up the current Contents.json. After editing, validate the JSON, inspect image dimensions and alpha channels, run the project’s safest available build check, and show me the final diff.

If your master artwork is outside the repository, place it in a temporary project folder first. Once Codex can see that file, it can create the variants and install them without sending you through a manual drag-and-drop loop.

What Codex changes inside AppIcon.appiconset

The result is a small, reviewable set of files:

Assets.xcassets/
└── AppIcon.appiconset/
    ├── AppIcon-Light.png
    ├── AppIcon-Dark.png
    ├── AppIcon-Tinted.png
    └── Contents.json

A typical single-size iOS mapping looks like this:

{
  "images" : [
    {
      "filename" : "AppIcon-Light.png",
      "idiom" : "universal",
      "platform" : "ios",
      "size" : "1024x1024"
    },
    {
      "appearances" : [
        { "appearance" : "luminosity", "value" : "dark" }
      ],
      "filename" : "AppIcon-Dark.png",
      "idiom" : "universal",
      "platform" : "ios",
      "size" : "1024x1024"
    },
    {
      "appearances" : [
        { "appearance" : "luminosity", "value" : "tinted" }
      ],
      "filename" : "AppIcon-Tinted.png",
      "idiom" : "universal",
      "platform" : "ios",
      "size" : "1024x1024"
    }
  ],
  "info" : {
    "author" : "xcode",
    "version" : 1
  }
}

Treat that JSON as an example, not a blind replacement. Existing projects can include additional platforms, legacy slots, or Xcode-generated metadata. Codex should merge the three iOS entries into the structure it actually finds.

A safer two-pass workflow

Pass 1: inspect and propose

Inspect the current AppIcon.appiconset without changing files. Report its platforms, sizes, appearance entries, filenames, and any risks. Then propose the exact files and Contents.json edits needed for Light, Dark, and Tinted iOS icons.

Pass 2: implement and verify

Implement the approved plan. Preserve unrelated entries. Validate every PNG as 1024 × 1024, confirm the tinted asset is grayscale, check the dark asset’s alpha channel, validate Contents.json, and run an Xcode build or asset-catalog compilation check. Stop and report if any validation fails.

How to preview the three appearances

  1. Open Assets.xcassets in Xcode.
  2. Select AppIcon and confirm the Any, Dark, and Tinted wells are populated.
  3. Build and run on a recent iOS Simulator.
  4. Long-press the Home Screen, choose the customization controls, and switch among Light, Dark, and Tinted appearances.
  5. Test several tint colors. A tinted icon that looks good only in blue is not finished.

Pro tips

  • Design Tinted as a mask, not a desaturated poster. Remove tiny color-dependent details and preserve a strong silhouette.
  • Do not simply invert Light for Dark. Rebalance highlights, shadows, and edge contrast.
  • Ask Codex to preserve geometry. The symbol, padding, and optical center should remain consistent across all three variants.
  • Keep generated intermediates out of the asset set. Only final PNGs and valid catalog metadata belong in AppIcon.appiconset.
  • Review the diff. A three-icon task should not modify unrelated Swift files, build settings, or other assets.
  • Prefer Icon Composer for the newest layered workflow. Apple now offers Icon Composer for platform and appearance variants, but the asset-catalog method remains useful for existing projects and explicit PNG control.

The payoff

The real improvement is not just generating three pictures. It is giving Codex responsibility for the complete, verifiable change: create the artwork, name the files, place them inside xcassets, update the appearance metadata, validate the catalog, and show the diff. Xcode sees the result immediately, and you stay focused on design decisions instead of moving files between windows.

How to Integrate Codex Directly into Xcode — Plus the Best SwiftUI Skills

Xcode can now host Codex directly inside its Coding Assistant. That changes the workflow completely: instead of keeping an AI agent in a separate terminal or desktop window, you can start a Codex conversation beside your source code, give it project context, review edits in place, and let Xcode expose native capabilities such as building and testing.

This guide covers the settings-level integration, the separate MCP route for external Codex sessions, and a careful way to add third-party SwiftUI and Swift Concurrency skills.

Before you start

Use a current Xcode release that includes Intelligence settings and the Coding Assistant. Availability can depend on the Xcode release, region, account, and managed-device policy. Update Xcode first, then open a project that already builds successfully. Commit or create a Git checkpoint before asking any agent to edit the code.

1. Install Codex from Xcode Settings

  1. Choose Xcode > Settings.
  2. Select Intelligence in the sidebar.
  3. Under Agents, find Codex and click Get.
  4. Review the installation sheet and click Install.
  5. Open the Codex agent settings. In the Account row, click the More button and follow the sign-in flow if you want to use your account.

Xcode can update downloaded agents automatically when possible. Before using an agent on proprietary code, read the privacy information linked from Intelligence settings. The selected agent may receive project files and other context needed to process a request.

2. Open Codex in the Coding Assistant

Open the Coding Assistant with its toolbar button or press Command-0. Start a new conversation and choose Codex as the agent. The selected agent runs in Xcode’s conversation workspace, where you can keep the transcript, source, and generated artifacts visible together.

For a focused source-editor request, select code and use the coding tools popover, or press Command-Option-0. Starting from a selection is especially useful for explaining unfamiliar code, adding documentation, or refactoring one type without inviting a repository-wide rewrite.

A good first prompt is:

Inspect this project without editing files. Identify the active app target, deployment target, test targets, concurrency settings, and the safest build-and-test plan. Report any assumptions before making changes.

3. Configure permissions deliberately

Agents can become much more useful when they may run build tools, tests, formatters, and project-specific scripts. They also become more powerful, so treat permissions as part of the project’s security model.

In Xcode > Settings > Intelligence, open the Permissions row under Agents. Review previously allowed commands and tools. Add only the command-line tools the project actually needs, such as a formatter or a project-owned test script.

A sensible starting policy is:

  • Allow read-only project inspection and normal builds.
  • Allow the project’s tests and formatter.
  • Require review for dependency changes, scripts downloaded from the internet, signing changes, and destructive commands.
  • Do not grant broad shell access merely to avoid an occasional approval.

4. Customize Codex specifically for Xcode

Xcode keeps agent-specific configuration in subfolders beneath:

~/Library/Developer/Xcode/CodingAssistant

Codex configuration used only when Codex launches inside Xcode belongs in:

~/Library/Developer/Xcode/CodingAssistant/codex

This separation is useful: settings for Codex inside Xcode do not have to affect every Codex session on your Mac. You can set an appropriate model, add MCP servers, or provide Xcode-specific guidance while keeping external workflows independent.

Also place an AGENTS.md file in the repository root for project rules that should travel with the code:

# Apple project guidance
- Use SwiftUI and modern Swift Concurrency.
- Assume strict concurrency checking.
- Prefer async/await, actors, and structured concurrency over GCD.
- Preserve bundle identifiers, signing, capabilities, and entitlements.
- Do not add dependencies without approval.
- Run the app target build and relevant tests before finishing.
- Use availability checks and fallbacks for newer platform APIs.
- Keep views accessible with Dynamic Type and VoiceOver.

5. Add SwiftUI and concurrency skills

Agent skills are focused instruction packages that teach an agent a repeatable workflow or domain-specific rules. In current Xcode releases, agentic coding plug-ins can contain skills, subagents, and MCP servers.

  1. Open Xcode > Settings > Intelligence.
  2. Choose the Plug-ins row under Agents.
  3. Click Add Plug-in.
  4. Choose an import method. For a repository, select the URL option and paste its GitHub URL.
  5. Review the components, select only the skills you need, and click Install.

Not every repository is packaged as an Xcode-compatible agent plug-in. If Xcode does not accept it, use the project’s documented Agent Skills installation method for an external Codex workflow instead of forcing it into Xcode.

Popular skills worth evaluating

  • SwiftUI Pro by Paul Hudson — covers modern SwiftUI APIs, state management, navigation, layout, performance, accessibility, and common model mistakes.
  • Swift Concurrency Pro by Paul Hudson — targets async/await, actors, Sendable, task groups, structured concurrency, and newer language behavior.
  • SwiftUI Expert by Antoine van der Lee — emphasizes modern APIs, view composition, invalidation and performance, lists, localization, Liquid Glass, and Instruments traces.
  • Swift Concurrency by Antoine van der Lee — includes Swift 6 migration, actor isolation, async sequences, testing, performance, and concurrency triage.
  • Swift iOS Skills by Daniel Pearson — a broad collection with focused skills for SwiftUI, concurrency, SwiftData, StoreKit, accessibility, networking, testing, and Apple frameworks. Install only the modules you use.

For an external Codex installation, many of these repositories document a command such as:

npx skills add https://github.com/twostraws/swiftui-agent-skill --skill swiftui-pro
npx skills add https://github.com/twostraws/swift-concurrency-agent-skill --skill swift-concurrency-pro

These commands install third-party code and instructions. Review the repository, license, recent maintenance, SKILL.md, scripts, and permissions before running them. Prefer a pinned release or commit for a team workflow, and retest skills after major Xcode or Swift changes.

6. Use external Codex with Xcode’s MCP bridge

Installing Codex inside Xcode and connecting an external Codex session are two different workflows. If you want the Codex CLI or desktop workflow to use the open Xcode project and its tools, enable Xcode’s MCP bridge:

  1. Choose Xcode > Settings > Intelligence.
  2. Under Model Context Protocol, turn on Allow external agents to use Xcode tools.
  3. In Terminal, run:
codex mcp add xcode -- xcrun mcpbridge
codex mcp list

Keep the intended project open in Xcode before prompting the external agent. Xcode displays when an external agent connects and when it is active.

This route is ideal when you prefer the Codex app or CLI but still want Xcode-native build, test, project, and simulator capabilities. The in-Xcode agent route is better when you want conversations, diffs, and source context inside the Xcode workspace.

7. A modern Swift Concurrency prompt

Skills work best when the task still states the target and proof clearly:

Use the Swift Concurrency skill to review this feature for Swift 6 strict-concurrency issues. Check actor isolation, Sendable conformance, task lifetime, cancellation, and accidental unstructured concurrency. Do not silence diagnostics with unchecked conformance. Make minimal fixes, build the app, run focused tests, and explain any remaining warnings.

For SwiftUI, ask the skill to inspect data ownership, @Observable flow, ForEach identity, view invalidation, accessibility, navigation, and availability checks. Do not ask it to “modernize everything” in one pass; separate correctness, migration, and performance work.

Pro tips

  • Use one skill per concern. Loading every iOS skill wastes context and can produce conflicting advice.
  • Keep skills advisory. Your deployment target, architecture, and product requirements outrank generic rules.
  • Review generated project-file changes. Treat edits to project.pbxproj, entitlements, capabilities, build settings, and signing as high risk.
  • Ask for evidence. Require the build command, test result, changed files, and remaining diagnostics.
  • Create checkpoints. Xcode conversation rollback is helpful, but Git remains the durable source of truth.
  • Audit updates. A popular skill can still become outdated or compromised. Re-review changes before updating a shared installation.

Official references

The strongest setup is intentionally small: Codex enabled in Xcode, carefully scoped permissions, a concise AGENTS.md, one SwiftUI skill, one concurrency skill, and a build-and-test loop you trust.

How to Configure Codex for Xcode: A Practical Setup and Pro Tips

Codex can be a remarkably effective partner for iOS and macOS development, but there is one important detail to understand first: you do not configure it as a native Xcode extension. The best workflow is to let Xcode remain your visual editor, signing environment, preview canvas, and debugger while Codex works directly with the same project folder from the Codex app or CLI.

Once both tools point at the same repository, Codex can inspect Swift and SwiftUI code, make focused edits, run builds with xcodebuild, analyze compiler errors, write tests, and help debug simulator issues.

1. Prepare the Xcode project

Start with a project that builds successfully in Xcode. Resolve signing errors, select the intended scheme, and run the app once on your preferred simulator. This gives Codex a clean baseline and avoids confusing an existing project problem with an AI-generated change.

If the project uses Swift Package Manager, let Xcode finish resolving packages first. For workspaces, open the .xcworkspace rather than the .xcodeproj when CocoaPods or another tool generated the workspace.

2. Open the same repository in Codex

In the Codex desktop app, create or open a project that points to the folder containing the Xcode project or workspace. If you prefer the terminal, change into that directory before starting Codex. Keeping the repository root as the working directory gives the agent access to source files, tests, configuration, assets, and project instructions.

A useful first prompt is:

Inspect this Xcode project without changing files. Identify the app target, scheme, deployment target, test targets, package dependencies, and the safest xcodebuild command for a simulator build.

Ask Codex to inspect first, then make changes. That small habit prevents many incorrect assumptions about schemes, destinations, and project structure.

3. Establish a repeatable command-line build

Codex is most reliable when it can verify work without depending on clicks in the Xcode GUI. Ask it to list available schemes:

xcodebuild -list -project MyApp.xcodeproj

Then establish a simulator build command, for example:

xcodebuild \
  -project MyApp.xcodeproj \
  -scheme MyApp \
  -sdk iphonesimulator \
  -destination 'platform=iOS Simulator,name=iPhone 17 Pro' \
  build

For a workspace, replace -project with -workspace MyApp.xcworkspace. Simulator names vary by installed Xcode version, so let Codex query available devices instead of hard-coding one blindly.

4. Add project instructions with AGENTS.md

Create an AGENTS.md file at the repository root. Codex reads this file as project-specific guidance, making it the ideal place to record conventions that should survive across tasks.

# Project guidelines
- Use SwiftUI and Swift Concurrency.
- Support iOS 18 and newer.
- Prefer @Observable for new shared state.
- Do not add dependencies without approval.
- Keep views small and extract reusable subviews.
- Run the app scheme build and unit tests before finishing.
- Never modify signing, bundle identifiers, or entitlements unless asked.

Include real commands for formatting, linting, tests, and code generation. The more deterministic the verification loop, the more useful Codex becomes.

5. Give Codex focused tasks

Good tasks include the desired behavior, constraints, and the proof required before completion. Instead of saying “fix the settings screen,” try:

Fix the settings screen layout on compact-width iPhones. Preserve current behavior and accessibility identifiers. Build the app for an available iPhone simulator, run the relevant tests, and summarize every changed file.

For risky refactors, ask for a plan first. For small visual tweaks, keep the task narrow and request a screenshot or simulator verification when available.

Pro tips for experienced Xcode users

Use a dedicated derived-data directory

Give automated builds their own derived-data path. This makes cleanup predictable and reduces interference with an Xcode session:

xcodebuild ... -derivedDataPath .build/DerivedData

Add the directory to .gitignore.

Prefer structured compiler output

Long build logs consume attention and context. Use a formatter such as xcbeautify if it is already part of the project, or ask Codex to focus on error: and warning: lines. Do not let it hide the original exit status.

Separate build, test, and UI-debug loops

A fast compile loop should not always launch the simulator. Use three explicit commands: one for building, one for unit tests, and one for UI or simulator debugging. Codex can then choose the least expensive proof for each change.

Protect signing and project metadata

Changes to project.pbxproj, entitlements, capabilities, and signing settings deserve extra review. Tell Codex not to touch them unless the task requires it, and inspect those diffs carefully before committing.

Use worktrees for parallel experiments

When exploring multiple implementations, use Git worktrees or separate branches so each Codex task has an isolated checkout. This avoids overlapping edits and makes it easy to compare approaches before merging one.

Add XcodeBuildMCP for deeper automation

Advanced users can add an Xcode-focused MCP server such as XcodeBuildMCP. It can provide a more structured bridge to schemes, builds, simulators, screenshots, and UI automation. Treat third-party MCP servers like development tools: review their permissions, pin versions where possible, and start with the narrowest access that works.

Ask for evidence, not confidence

The best final prompt is often simple: “Show me the build command, test result, remaining warnings, and the exact diff.” A successful build and focused tests are much more valuable than a confident explanation.

A practical daily workflow

  1. Open the project in Xcode and confirm the current branch builds.
  2. Open the same repository in Codex.
  3. Ask Codex to inspect the relevant files and propose a short plan.
  4. Approve a focused implementation.
  5. Let Codex build and test from the command line.
  6. Review the diff in Codex or Xcode.
  7. Run the final UI check, previews, signing, and archive flow in Xcode.

This division of labor works well: Xcode remains the authoritative Apple development environment, while Codex handles codebase navigation, repetitive edits, tests, build diagnostics, and carefully scoped automation.

Official resources

Tip: keep the first version of your setup deliberately simple. A reliable xcodebuild command plus a clear AGENTS.md file delivers more value than a large collection of tools that nobody maintains.

A Fresh New Design for Doctor OLED X

Doctor OLED X has always had one clear goal: help users quickly understand the real condition of a screen. Whether you are buying a second-hand phone, checking your own device before selling it, or simply curious about OLED behavior, the app gives you visual tools to spot issues that are hard to notice in everyday use.

With the latest design update, the app now feels much clearer, faster, and easier to navigate.

A Cleaner Main Menu

The old menu was a long list of test options. It worked, but it was not ideal. Doctor OLED X contains different kinds of tools: screen checks, video demos, sound demos, information pages, and the OLED test certificate. Putting everything in one long list made the app feel more complicated than it needed to be.

The new menu groups related features together:

  • Screen checks
  • Videos and sound demos
  • More information and tools

The OLED Test Certificate is now featured more prominently at the top, while the individual tests are arranged in a compact dashboard-style layout. This makes it easier to understand what each section is for and helps users get to the right test faster.

What’s New in ProShelf 1.7.0?

ProShelf keeps growing into a more useful workspace companion for macOS. This update focuses on staying in flow: easier access to your photos, better music playback, and more tools that stay close without getting in the way.

The biggest change is the new local MP3 player. ProShelf no longer depends on Apple Music, so you can play your own audio files directly from your Mac. Add your music, keep it close to your shelf, and control playback without leaving your current workflow.

Internet radio is still built in, too. You can add your favorite stations, organize them by genre, mark favorites, and keep listening while you work. The player stays with ProShelf and remains hidden until you need it.

This update also improves photo workflows. Recent photos are available directly in the shelf, and the larger collection view makes it easier to browse, select, share, export, and manage images. Selected photos can now be previewed with the Spacebar, making it faster to inspect an image before sharing or exporting it.

Timers are part of the audio experience as well. You can use a sleep timer when listening in the background, or start the built-in 25-minute Pomodoro timer when you want a focused work session.

Together, these changes make ProShelf feel more personal and practical: your files, photos, music, radio, timers, and workflow tools all stay within reach, without taking over your screen.

Get your copy here before they sell out.

ProShelf Update: Radio, Refined

ProShelf just got a focused quality update centered on speed, clarity, and better control. Here’s what’s new.

Redesigned Radio Player
The Radio Player has been reworked to feel cleaner and more intuitive. Navigation is simpler, controls are easier to access, and the overall layout is built for quicker station switching with less friction.
This redesign keeps the experience lightweight while making daily listening smoother.

New Mini Radio Player Mode
You can now switch to a Mini Radio Player mode for a compact, always-available listening experience.
It’s ideal when you want music in the background without giving up space on your shelf. Quick controls stay within reach, while the UI stays out of your way.

Resizable Photo Grid Thumbnails
In Photos grid view, preview thumbnails are now resizable.
You can scale them up for better detail or shrink them down to scan more items at once. This gives you better control depending on whether you’re browsing quickly or inspecting specific images.

ShelfMate continues to evolve around practical improvements: less clutter, more control, and a better flow across everyday actions.

Get it here

ProShelf 1.4.5: Full macOS Tahoe Compatibility with Liquid Glass, Plus a New Free Feature!

We’re excited to announce the release of ProShelf version 1.4.5! This crucial update features a complete overhaul to ensure seamless compatibility with macOS Tahoe (version 26 and newer)

Now Free: Intuitive Shelf Nudging

We’ve made a highly requested feature free for all users! The blue touch zones allow you to effortlessly manage your ProShelf’s position. Simply hover your mouse over these zones to gently nudge the shelf in, out of the screen, or snap it back to the top center. Experience enhanced desktop control.

Performance Fix: Lightning-Fast System Stats

macOS Tahoe introduced an unexpected bug that caused the System Stats View to load slowly. We’re happy to report that this is now completely fixed—the launch is super fast again! The System Stats panel continues to provide detailed metrics, including full support for the latest Apple M5 processor (SoC) series statistics.

System Stats Menu Bar

As always, you can also access the System Stats directly from your menu bar for quick, at-a-glance monitoring.

Download the update

We’ve poured a lot of work into this release and are confident you’ll love the improved stability and new free feature. Download ProShelf 1.4.5 today and experience the best desktop companion for macOS Tahoe!

Download ProShelf Here

ProShelf – 📸 Photo Editing & Effects

Unlock Creative Power: Advanced Photo Editing & Side-by-Side Compare

When it comes to organizing digital life, ProShelf is already known for its beautiful blend of AI smarts and Mac-native design. But ProShelf is more than just a file organizer—it’s now also your creative playground, putting real photo editing muscle right inside your shelf. Let’s dive into the powerful new photo editing and effects capabilities, and shine a spotlight on our intuitive side-by-side compare feature.


All-in-One Photo Editing, No Exports Needed

Tired of switching between apps to make simple edits? With ProShelf, you don’t have to. Open any image right in ProShelf, and instantly access a robust set of editing tools that cover everything from basic adjustments to artistic enhancements.

Key Features:

  • One-Click Filters: Apply stunning looks and quick fixes with our curated set of customizable filters.
  • Color Adjust & Tints: Fine-tune brightness, contrast, and color, or add a creative flair with tints.
  • Undo / Redo Everything: Non-destructive edits with a full history make experimentation totally safe.

🎨 14 Professional Filters

  • Auto Enhance – Intelligent one-click optimization
  • Vintage Collection – Chrome, Fade, Instant, Transfer effects
  • Artistic Styles – Sepia, Process, Tonal, Mono, Noir
  • Creative Effects – Vintage Vignette, Vignette Noir, CMYK Halftone
  • Color Enhancement – Dedicated Vibrance filter

⚡ Real-Time Adjustments

  • Exposure Control – Perfect lighting in any condition
  • Contrast & Brightness – Fine-tune your image’s mood
  • Shadows & Brilliance – Professional highlight/shadow recovery
  • Vibrance & Saturation – Make colors pop naturally
  • Blur & Sharpen – Creative focus control

🔄 Transform Tools

  • Rotation – 90° increments with smooth animation
  • Mirror/Flip – Horizontal flipping for creative compositions
  • Zoom Control – 0.5x to 4x magnification with precision slider

See the Difference: Side-by-Side Compare

One feature users are especially loving is Side-by-Side Compare. We know the uncertainty—sometimes you wonder, “Did my edit really improve the photo?” or “How does the enhanced version stack up against the original?” Now, with a click, you can see the transformation for yourself.

How It Works:

  • Tap on a filter button or change a effects slider
  • Instantly view your original image and the edited version side-by-side.
  • Drag a slider (or swap left/right panels) to inspect details up close.
  • Revert changes if you’re not satisfied—or export/share the improved version with confidence.

This feature isn’t just for perfectionists. It empowers everyone to make informed creative choices, experiment freely, and build trust in their editing workflow. See your improvements in real time, and never worry about “over-editing” or losing your unique vision.


Work Faster, Save Smarter

With ProShelf’s photo tools, you don’t need to juggle photo editors and file managers. Every adjustment is saved right where your photos live.


Ready for a Better Photo Experience?

If you want to edit, and compare photos as naturally as managing files, ProShelf is ready for you. Update today, and experience smart, delightful editing.

Product Page

App Store

Avoid Paying Bitbucket for Git Storage

I’ve been using Bitbucket for my personal development projects for quite some years now without too many issues. They triggered my interest in the times that GitHub was payable and Bitbucket was providing a free git hosting service, great so far.

Recently one of my git pushed failed because apparently I crossed over the 1 GB hosting limit, a new limit which they decided to apply recently. After some investigations I saw that their website was showing this: Your workspace has exceeded the 1 GB limit and has been placed in read-only mode. Learn more about upgrading your plan and checking storage usage. — Learn more

I actually have around 14 GB of repositories already, and understand that things cost money.

Their new hosting tiers are not very large on storage neither: 5 GB standard edition and 10 GB for the premium edition. So… I went on exploring to self hosting the git repos on my own server, that I already use for backend services of all my (mobile) applications. I host this on Linode with very good experience.

It turned out that this went very smoothly and should have done sooner probably.

Here is what I did — my sever is running Ubuntu Linux by the way.

// update the server packages
sudo apt update

// install git
sudo apt install git

// add the git user
sudo adduser --system --group --disabled-password --home /home/git git

// Set up SSH access:
// Create a .ssh directory for the git user: 
sudo su git
mkdir ~/.ssh && chmod 700 ~/.ssh 
// Add your public SSH key (content of id_rsa.pub on your Mac ~/.ssh/id_rsa.pub) to the authorized_keys file within the .ssh directory 
// Restrict the git user's shell to git-shell: 
sudo usermod -s /usr/bin/git-shell git 

// create a home directory
sudo mkdir -p /home/git/repos

// change the ownership
sudo chown -R git:git /home/git/repos

// go to the new repos dir
cd /home/git/repos

// initialize a bare repo that you are hosting already on bitbucket
git init --bare todoapp.git

// change the ownership again for the new repo, do this every time you initialize a new bare repo
sudo chown -R git:git /home/git/repos

// now open a terminal session on you local pc and go to the directory of the application already under git control

// example 
cd /username/todoapp/

// set the new remote repo location, replace the IP with the address or IP of your server.
git remote set-url origin git@139.122.121.21:/home/git/repos/todoapp.git

// if you get an error here check in /username/todoapp/.git/config what is here: [remote "origin"] sometimes origin is called something else.

// now push any new code changes and it will upload the whole local git repo to the new server. I use SourceTree to push all branches.

After I’ve done this for all my applications, I went to the server to check the size of the pushed repos, I found that Ubuntu’s free tool ncdu is great for this.

Screenshot

Thanks to Bitbucket for all the years of free hosting ♥️ — and I keep my read-only 14 GB repose there for free as a second cloud backup, you never know.