This update focuses on connection stability, USB recovery, and the new Mac screen-state handling introduced in the 1.7 line. It is recommended for all MetaGrid Pro 1.7 users.
What’s improved
Dedicated Mac screen-state screens — when your Mac enters Screen Saver, Lock Screen, display sleep, or system sleep, MetaGrid Pro now shows clean full-screen MetaGrid Pro states instead of dimming the dashboard underneath.
Cleaner Screen Saver mode — the screen saver state is now logo-only, with no cards or labels. Tapping can wake the Mac display, and a second tap lets you leave the screen if macOS is still waiting at the password screen.
Gentler Mac Sleep handling — when the Mac is truly asleep, MetaGrid Pro stays dark and passive. A small device-power hint appears briefly and can be shown again with a tap.
Smarter USB recovery — USB reconnect is more resilient after Mac sleep/wake, app backgrounding, cable hiccups, and reconnect probes.
Fixes
Fixed wake recovery flashing the dashboard before the Mac was actually active and usable.
Fixed Lock Screen taps sending a wake command that could make the Mac display go black.
Fixed additional USB reconnect and app-data recovery crash paths, including cache file I/O races.
Fixed GridVista receipt relay so entitlement state waits for an active MetaServer connection.
Fixed incorrect colour indicators in the Button Editor for shadow and text-background settings.
Improved USB diagnostic logs so sent packets are identifiable by packet id, packet name, payload length, and PeerTalk tag.
Recommended companion update: MetaServer Mac 6.1.2 or later, MetaServer Win 6.0.2 or later
As always, thank you for the logs, crash reports, and real-world connectivity cases. This hot fix is mostly about making the 1.7 connection engine calmer and more predictable in the edge cases that only show up in actual studio setups.
First of all, I would like to thank the developers for the time they have spent investigating these issues, and also for the continuous and excellent support. It is really appreciated.
I just wanted to share my experience in case it helps someone else.
I installed the latest MetaServer and the latest MetaGrid Pro version on my iPad, but the issue was still the same for me. MetaGrid Pro kept closing/crashing every 40-50 seconds, even when MetaServer was not running at all.
In the end, I decided to completely uninstall/delete MetaGrid Pro from the iPad and then download and install it again from scratch.
After reinstalling, the app opened as a completely fresh installation, with the default settings and without my grids. I then went to the Backups & Restore section in MetaGrid Pro, used Restore, and imported my latest backup from iCloud.
After restoring the backup, everything returned to its previous state, and the app no longer crashes. So far, everything seems to be working as expected.
Maybe this will help someone experiencing the same behavior.
Thanks for your kind words and the feedback @HGM - I think it could be related with the icon cache size accumulating over the standard use - we are working on improvements to icon handling and we should have a working solution in 1.8 in July . Let us know if you see anything suspicious. Enjoy Metagrid Pro :-).
Thanks for working so diligently on the issue.Sadly, my experience with restoring a previously working backup prior to the crashes causes the latest version to crash as well. MetaGrid will work fine with a completely fresh install, so I would think that your assessment regarding the icon cache size can be the culprit.
My dilemma now is that I either rebuild my entire configuration, which will be painful, or find another solution to successfully restore a backup. Thoughts?
We will do our best to figure it out - please upload you backup to a file service and send us the link - we will try to open it and then try to export individual profiles. Also we need to find the cause for this.
Thanks for sharing this. I was having the exact same issue with my iPad Pro 2nd Gen, and I couldn’t find a solution even after sending multiple logs to support.
I can confirm that your method works perfectly. I followed the same steps: completely uninstalled the app, performed a clean reinstall, and restored my configuration from a backup. The connection stability issue is completely gone now.
This seems to be the only effective workaround for now. Thanks again for the helpful tip!
So as not to clog up this thread, I sent an email to support asking for a rollback to v1.7.1. v1.7.2 is causing connectivity issues for me whereas v1.7.1 worked just fine.
Much to my amazement, they still don’t provide rollbacks. AFAIK the only way around it is to turn of automatic updates on your iPad(s) and do a full iPad backup to your computer before updating to the latest version, that’s what I do - I learnt the hard way. Somehow restoring from a back up downloads the same version of the app as when the backup was done.
For an app that people rely on so heavily for their work, it’s seriously BS to not provide roll backs or at least some kind of workaround like provide a TestFlight link to older versions. They have done it before, they should do it every time they roll out a new version.
I am honestly terrified of installing the latest version of MGP. Because it means that I may be unable to work properly for weeks, if not months, until they roll out the bug fixes.
I’m on 1.6.19 and I ain’t going near this new version for at least a month if not two.
I understand that you are frustrated, but calling it “BS” is not a professional or fair way to describe the factual state of things related to the App Store reality.
This has already been explained several times: we cannot provide guaranteed rollbacks for App Store builds because Apple does not provide a developer-controlled rollback mechanism. TestFlight is not a production rollback system either. Builds expire, availability is limited, and it is intended for testing, not for maintaining old production versions on demand. Period.
For mission-critical setups, we have repeatedly recommended the same workflow:
turn off automatic App Store automatic updates
make a full local iPad backup before installing a major update
update outside active project deadlines
send logs immediately if something goes wrong
That is the only reliable way to protect a production iPad before updating. We cannot change how App Store distribution works.
If 1.6.19 is stable for your current work, staying on it for now is completely reasonable. But presenting the lack of App Store rollbacks as something we simply refuse to provide is inaccurate, and calling it “BS” does not help us diagnose or fix anything.
I would recommend start a thread called ‘Access The Latest Working Version’ where you outline the procedure required to download and sign up to TestFlight.
Apparently TestFlight would have allowed 10,000 external users access to 1.6.19 for 90 days after the rollout of 1.7. After 90 days you guys can simply upload the same version and call it something else like 1.6.191. I imagine this would have taken a lot of pressure off you guys to release 2 hotfixes in a week and respond to countless complaints here on the forum and no doubt support via email
Unless you want to use us all as beta testers that is
