Forum Replies Created
-
Posts
-
Unfortunately, “flag” is not a part of standard XMP, so Nitro’s reject and Bridge’s reject are not compatible with each other. Ratings are standard, which is why they interchange.
Sorry to hear about that performance. There are variables here, such as speed of the drive and which iPad Air, etc.
Also, the iPad USB connection varies a lot in speed from model to model.
Nitro does cache thumbnails in order to speed up display – so I would not expect it to take 38 seconds each time.
There are two tests I can think of:
1) Copy those images to your iPad – is the app much faster or not?
2) If you make some new folders on your SSD and put 100, 200, 400, 800 images in each folder – how does the performance change vs. the 1200?If you are trying to add images to a Shared Album, then that has to be done in Photos. Apple does not provide an API for third parties to manipulate shared albums.
Another approach is to use the Flag feature of Nitro and then find the flagged album in Photos (it’s inside the Nitro folder). Then share those.
It really depends on the query and the size of the library (and the computer, of course). Some queries are expensive and others are cheap. If you want to provide more information: query, size of library, type of computer then I might be able to tell you if it’s expected performance or not.
yes, but there are other, higher priorities. Like RAW 9 and Liquid Glass, etc. External requirements keep pushing things out. Sorry.
That’s okay – you can fill out the form for beta testing. In there, if you include your App Store email address so I can sign you up for Apple’s TestFlight service, that will save a step. Scroll to the bottom of this page: https://www.gentlemencoders.com/nitro-roadmap/index.html
The list on Apple’s site does not differentiate decoder versions. So, it includes cameras with V7, V8 or V9. You cannot tell if a camera has V9 support from that list.
Ok, I was able to reproduce it all of sudden. Very weird. A fix will be forthcoming. Probably version 2026.09.
Sorry to hear that. As I wrote earlier, the problem is in iOS. The best I can do is to move the trash off the user interface thread so that it doesn’t hang up the app, but it’s still up to iOS to do the work properly. I can also add a delete option.
The 2026.08 update is out, so if you have iOS 27, then you should get a Delete alert in Nitro because the Move to Trash is broken on iOS 27.
Since I cannot reproduce this problem, are you willing to beta test when I have the above changes implemented?
Right now, the app always goes to the trash. iOS 27 broke the trash for apps, so the next update to the Nitro will detect that bug and ask if you want to delete the images directly. I don’t know if that will solve your problem or not, because if the OS is stuck, then it may be stuck for delete also. Perhaps the OS is busy indexing the images or something like that.
I don’t know. I tried it myself before posting. If the code is not able to get the mouse position, then it zooms to the center.
Are you using the Nitro app, or the Nitro Photo extension (inside Photos)?
Stacking is supported when using the Photo Library, but not when using the file system. That feature is on the roadmap.
Hi Marius, sorry to hear about this. I have not looked much into the trash freezing up problem, other than to review the logs.
iOS 27 has made things worse – there is no move to trash any more. Only delete. I believe what is happening to you is that the OS is stuck trying to move the files and it is waiting for some other program on the device to finish.
On macOS, Nitro will zoom to the cursor. On iOS, it also zooms to the cursor if you double-click on the image to zoom. If you use the space bar or the Z key, then on iOS, it currently does not. iOS doesn’t have a straightforward way to find the cursor location when a key press occurs. There may be a workaround – I’ll add it to the list of customer requests.
